The Slate Programming Language(slatelanguage.org)
slatelanguage.org
The Slate Programming Language
http://www.slatelanguage.org
4 comments
Hi Brian,
I've only read a few pages of the Slate site so far but it's brought back fond memories of image based systems I played with in the 80s.
(I've done a total of about 5 years worth of professional programming over the last 30 years, primarily assembler and BCPL in the 80s and some Pascal and Perl in the 90s; I've played with many langs -- lisp, snobol, the toy smalltalkish systems Smalltalk/V and Actor, etc. -- in the late 80s; I'm currently a Perl 6 "enthusiast" -- my periodic HN search for "perl6" caught your mention of it.)
If you have little to no idea what NQP [1] is, then my question is:
What are the characteristics that a language/compiler/runtime/library have to have to adequately support an image based approach? I'm imagining OO; source code as objects; running code as objects; object serialization; incremental compilation; etc. I know I should research this myself (and will, now you've rekindled my interest) but I think your off-the-cuff answer will be an interesting and valuable start for me and perhaps others.
Or, in the unlikely event that you DO know what NQP is, then my question is:
Is it reasonable to think about building an image based system using the NQP toolchain?
Thank you offering AMA. :)
[1] https://github.com/perl6/nqp
I've only read a few pages of the Slate site so far but it's brought back fond memories of image based systems I played with in the 80s.
(I've done a total of about 5 years worth of professional programming over the last 30 years, primarily assembler and BCPL in the 80s and some Pascal and Perl in the 90s; I've played with many langs -- lisp, snobol, the toy smalltalkish systems Smalltalk/V and Actor, etc. -- in the late 80s; I'm currently a Perl 6 "enthusiast" -- my periodic HN search for "perl6" caught your mention of it.)
If you have little to no idea what NQP [1] is, then my question is:
What are the characteristics that a language/compiler/runtime/library have to have to adequately support an image based approach? I'm imagining OO; source code as objects; running code as objects; object serialization; incremental compilation; etc. I know I should research this myself (and will, now you've rekindled my interest) but I think your off-the-cuff answer will be an interesting and valuable start for me and perhaps others.
Or, in the unlikely event that you DO know what NQP is, then my question is:
Is it reasonable to think about building an image based system using the NQP toolchain?
Thank you offering AMA. :)
[1] https://github.com/perl6/nqp
I've heard of NQP but haven't dug into it. I suppose you could, but I'd estimate the effort as higher than for say Rubinius which has been tracking a Smalltalk model since its inception.
Really, an image is just a heap snapshot with roundtrip serialization possibilities. You want to be able to serialize all the operational data structures, so the model of data has to sort of respect a certain abstraction layer. One consideration is whether the image has to be portable; word-size of 32 or 64 bits, or under endianness. This has strong implications about what kind of code you can keep in the image.
You also would want hooks for startup and shutdown if you expect to be able to snapshot a heap and then restart it under a debugger, say, and get the runtime circumstances that are relevant, like open sockets and files, dynamic-linked libraries, and so on.
Really, an image is just a heap snapshot with roundtrip serialization possibilities. You want to be able to serialize all the operational data structures, so the model of data has to sort of respect a certain abstraction layer. One consideration is whether the image has to be portable; word-size of 32 or 64 bits, or under endianness. This has strong implications about what kind of code you can keep in the image.
You also would want hooks for startup and shutdown if you expect to be able to snapshot a heap and then restart it under a debugger, say, and get the runtime circumstances that are relevant, like open sockets and files, dynamic-linked libraries, and so on.
Thank you for your clear and concise answer.
I am now really curious about building an image-based edition of Rakudo Perl 6. I'm going to ask about this on #perl6 and reply here if anything comes of it.
Thanks again. May the eggnog season serve you well.
I am now really curious about building an image-based edition of Rakudo Perl 6. I'm going to ask about this on #perl6 and reply here if anything comes of it.
Thanks again. May the eggnog season serve you well.
How long have you been playing with developing languages? How much do you think syntax matters? Will a homoiconic language ever capture the mainstream?
Actually, what hope is there in capturing the imagination of the mainstream? Seems like they're so used to having languages forced down their throat by corporate entities that our brightest hope lies in children.
Actually, what hope is there in capturing the imagination of the mainstream? Seems like they're so used to having languages forced down their throat by corporate entities that our brightest hope lies in children.
I was perverted by AutoLISP and CADForth in the very early 90's. By 1995 I was in college and researching on my own, found Self and Squeak and made a rather stupid but fun little lisp that ran on DOS4GW and built a Motif-style Morphic-like UI out of it.
And then I threw it away as a learning exercise. It was a few years of skills building before I really tried to make a language project. Slate had a few incarnations which were quite different from what it currently presents as.
And then I threw it away as a learning exercise. It was a few years of skills building before I really tried to make a language project. Slate had a few incarnations which were quite different from what it currently presents as.
> Will a homoiconic language ever capture the mainstream?
Not the author (obviously) but I think it already has -- Clojure has gone mainstream.
Not the author (obviously) but I think it already has -- Clojure has gone mainstream.
Clojure deserves a lot of respect for attacking concurrency in a totally new way, but I would not call it mainstream.
Homoiconicity is overrated; Atomo and Atomy represented better where I wanted to go, which is to adapt notation to the problem, even have it be flexibly remapped and recombined per modular scope.
Homoiconicity is overrated; Atomo and Atomy represented better where I wanted to go, which is to adapt notation to the problem, even have it be flexibly remapped and recombined per modular scope.
[deleted]
I'm not sure Clojure has even matched the "Lisp high-water mark" of '80s Common Lisp, which I'd consider only quasi-mainstream. Though it is definitely more vibrant in 2014 than the others.
That's difficult. Symbolics alone had a billion dollar revenue in the 80s (sum of the years), with a maximum of 1000 employees. Then there were TI, Xerox, Franz, Lucid, LispWorks, Intellicorp, ... as companies. I'd guess that Lisp earned in direct sales around 2-3 billion dollars in the 80s... In a much smaller market. Inflation adjusted that would be 4-6 billion dollar today. A large Lisp company today might employ 20-40 people. Large user groups in companies might have less than hundred employees (like ITA/Google had (has?) a few years ago).
> Image-based bootstrapping was useful, but too monolithic.
I feel that. I have no problem with images in theory, but history has made me flinch at them.
> As it is, I'm disillusioned with the open source and software research fields
That's a shame. Open source is very diverse... I hope you have better experiences in the future.
> You may as well AMA.
Awesome. What do you think of Io? — http://iolanguage.org/
I'm asking because I rarely ever hear PL people talk about Io.
I'm also curious, was there a coherent design goal or philosophy behind Slate? Alan Kay is very clear about his values, I have a handle on what Io is about, and so on. All I'm getting from Slate is "better than Smalltalk" but is there something more specific to it?
I feel that. I have no problem with images in theory, but history has made me flinch at them.
> As it is, I'm disillusioned with the open source and software research fields
That's a shame. Open source is very diverse... I hope you have better experiences in the future.
> You may as well AMA.
Awesome. What do you think of Io? — http://iolanguage.org/
I'm asking because I rarely ever hear PL people talk about Io.
I'm also curious, was there a coherent design goal or philosophy behind Slate? Alan Kay is very clear about his values, I have a handle on what Io is about, and so on. All I'm getting from Slate is "better than Smalltalk" but is there something more specific to it?
I know Steve Dekorte and remember him bringing me along to visit David Ungar over beer and pizza more than a decade ago. :) Io doesn't quite address the goals I wanted, and it was dynamic in ways that prevented some optimizations. But it is rather charming.
Slate had some design goals, but a lot of the goal was general, like "how much can we fit into Smalltalk and still have that core idea be recognizable and coherent?" Multimethods, prototypes, macros, optionals, etc. were all just a part of that.
We did spend a lot of the project's focus on how heavily we could leverage multimethods to clarify and collapse code. Slate probably uses multimethods better than any language I know of, although I admire what Julia does with it within the Matlab/R compatibility constraints.
Mainly, we wanted to take operating systems and meld them with computer languages. The TUNES project says a lot of what I think about that (with a good deal of ideological distortion and handwaving, but that's group editing for you).
Honestly, I checked Alan Kay's philosophical reading list, and its depth in phenomenology and developmental psychology was stuff I covered in college. While he belongs to another generation, I'm keenly following the ideas of the FoNC project and hope to deliver something that takes that to an everyday context broadly.
Slate had some design goals, but a lot of the goal was general, like "how much can we fit into Smalltalk and still have that core idea be recognizable and coherent?" Multimethods, prototypes, macros, optionals, etc. were all just a part of that.
We did spend a lot of the project's focus on how heavily we could leverage multimethods to clarify and collapse code. Slate probably uses multimethods better than any language I know of, although I admire what Julia does with it within the Matlab/R compatibility constraints.
Mainly, we wanted to take operating systems and meld them with computer languages. The TUNES project says a lot of what I think about that (with a good deal of ideological distortion and handwaving, but that's group editing for you).
Honestly, I checked Alan Kay's philosophical reading list, and its depth in phenomenology and developmental psychology was stuff I covered in college. While he belongs to another generation, I'm keenly following the ideas of the FoNC project and hope to deliver something that takes that to an everyday context broadly.
Images are like filesystems or sandboxes, by the way. They just need better tool support.
No argument here.
The problem I have in practice is images are so often lacking, or they start you off with an alien universe full of preconceptions rather than just a collection of tools. This isn't an inherent problem, but it seems to show up half the time or more.
I want to like images, but I think what I really want is a system that has a fully functional base state with a good image that can be (and usually is) loaded at startup. I guess that might get in your way if you're worried about optimal performance.
The problem I have in practice is images are so often lacking, or they start you off with an alien universe full of preconceptions rather than just a collection of tools. This isn't an inherent problem, but it seems to show up half the time or more.
I want to like images, but I think what I really want is a system that has a fully functional base state with a good image that can be (and usually is) loaded at startup. I guess that might get in your way if you're worried about optimal performance.
Well, I'd like to explore a link-phase to build images. I think that'd be really quite interesting and might break up the monolith and mix Smalltalk ideas in with Unix as they ought to have.
I'm not sure what you mean about the lexical awkwardness -- that it's unfamiliar or that it's not so good on its own terms? (Smalltalk's syntax always rubbed me the wrong way at least a little, but it feels like there should be some variation that I would like.)
A little bit of both; I'll skip unfamiliarity and get to the awkwardness.
Smalltalk lexical style makes certain kinds of notational customizations difficult to compose. I want multiple kinds of brackets that could get used for DSLs. Slate did manage to make prefixes and suffixes customizable and make much more into operators than Smalltalk allowed, at least.
But we did have extreme whitespace sensitivity between tokens so "3+4" was a single token. That was our fault, even if it enabled many interesting notations.
Smalltalk lexical style makes certain kinds of notational customizations difficult to compose. I want multiple kinds of brackets that could get used for DSLs. Slate did manage to make prefixes and suffixes customizable and make much more into operators than Smalltalk allowed, at least.
But we did have extreme whitespace sensitivity between tokens so "3+4" was a single token. That was our fault, even if it enabled many interesting notations.
Thanks, I think I'll review this -- it's been many years since I looked at Slate.
There's an idea from Fortress (I think?) of squeezing out spaces to express tighter grouping -- that at least struck me as promising.
There's an idea from Fortress (I think?) of squeezing out spaces to express tighter grouping -- that at least struck me as promising.
Yeah, Fortress had a lot of good ideas that we were looking at. We toyed with a way to render and enter unicode operator characters using angle tag notation a la "<circle-plus>". The whitespace idea is interesting but a little dangerous; I think we just need to be able to separate the syntax from the viewer and editor interactions.
Would you have time to chat, perhaps an hour, on language design? Email address is on my blog which is in my ycom bio.
Sure. My email is my username at gmail.
I will say that I'm not done yet; I fully intend to build a practical system that hands the lessons of FoNC to the everyday context. I've learned a lot over the years and tried my best to smooth out my early rough edges.
The question is how to do it and with whom and for what audience.
The question is how to do it and with whom and for what audience.
Unfortunately, this seems to be no longer developed - last github commit is from a year ago. It might've been interesting to see another language with the image system.
I've been playing with Smalltalk recently, and it's really interesting as an environment. It has a number of RAD tools built in - the flexible Morphic GUI from which you can quickly create your interface and middle-click to debug any given morph, the image system allowing you to store state without explicitly dealing with a database, and being able to develop from the same environment that your code runs in, allowing quick turn-around in adding and testing features - and I'm wondering why it's not used more often for line-of-business applications.
I've been playing with Smalltalk recently, and it's really interesting as an environment. It has a number of RAD tools built in - the flexible Morphic GUI from which you can quickly create your interface and middle-click to debug any given morph, the image system allowing you to store state without explicitly dealing with a database, and being able to develop from the same environment that your code runs in, allowing quick turn-around in adding and testing features - and I'm wondering why it's not used more often for line-of-business applications.
I don't feel motivated to work on it (this particular artifact) any more. I want to make something relevant to and appreciated by an audience, and programmer culture seems to be unwilling to do that in a deep way.
If I continue, it will be with a specific story in mind about who it's for and what message to convey. I have been attending The Strange Loop for a few years now and growing some ideas to write about.
It's worth noting that Slate was one major project in a long stream of development I started privately in the early 1990's and then brainstormed with some nerds on at the TUNES project until I made Slate its own thing (a kind of stepping stone towards the TUNES goals).
If I continue, it will be with a specific story in mind about who it's for and what message to convey. I have been attending The Strange Loop for a few years now and growing some ideas to write about.
It's worth noting that Slate was one major project in a long stream of development I started privately in the early 1990's and then brainstormed with some nerds on at the TUNES project until I made Slate its own thing (a kind of stepping stone towards the TUNES goals).
For fun, I want to build a language. After see you can do a lisp very easy, I stop and wonder for what my "new" language can be useful. This make me think in how do a REPL, a debugger, what kind of task this must solve naturally, etc, and for which kind of users!
However, pull of a successfully language is very hard. That depress me.
--- See more at
https://www.reddit.com/r/coding/comments/2ocw2r/how_to_creat...
However, pull of a successfully language is very hard. That depress me.
--- See more at
https://www.reddit.com/r/coding/comments/2ocw2r/how_to_creat...
You'll never regret it, and although every language is ultimately worth criticizing, it's worth having a project of your own to refine or learn from.
> I want to make something relevant to and appreciated by an audience, and programmer culture seems to be unwilling to do that in a deep way.
Being a language designer is rough like this.
Being a language designer is rough like this.
I actually had a big vision to merge Morphic into the CLIM/DUIM tradition from Lisp and Dylan. I was very inspired by Lisp Machines, and still own one to run an emulation for for demonstrations.
Morphic alone was not good enough to build the future out of. First-class information objects called presentations from the CLIM history would have complemented it nicely.
Morphic alone was not good enough to build the future out of. First-class information objects called presentations from the CLIM history would have complemented it nicely.
> Morphic alone was not good enough to build the future out of. First-class information objects called presentations from the CLIM history would have complemented it nicely.
Agreed, but the solution sounds like the whole naked object fad from a decade ago.
Agreed, but the solution sounds like the whole naked object fad from a decade ago.
Hum. I hear you. I've tracked demos come and go with their hype and lack of delivery.
Are they fads, though, inherently, or because of a lack of cultural and financial support? I like to learn from all of them but have no idea how to make a new effort that is worth more than just a splash of publicity.
My current bet is on just getting smart software in the hands of a wide audience that don't listen to programming culture.
What else can one do? Who are we rewarding by the way things work now?
Are they fads, though, inherently, or because of a lack of cultural and financial support? I like to learn from all of them but have no idea how to make a new effort that is worth more than just a splash of publicity.
My current bet is on just getting smart software in the hands of a wide audience that don't listen to programming culture.
What else can one do? Who are we rewarding by the way things work now?
>>not good enough to build the future out of
I think i hear this idea from the smalltalk community (or former community members) than anywhere else. The sense that there is supposed to be something out there thats an order of magnitude better than what we have today. Where does that come from? Whats so great about "the future" ie what promise does it hold?
I think i hear this idea from the smalltalk community (or former community members) than anywhere else. The sense that there is supposed to be something out there thats an order of magnitude better than what we have today. Where does that come from? Whats so great about "the future" ie what promise does it hold?
UI research and development stopped dead in its tracks in the early 90s, and most people who've developed UIs now effectively think a whole class of problems are not solvable or even worth thinking about.
XCode's Interface Builder is an Objective-C knockoff of a Lisp tool from the 80's which needed a lot of work even back then and never received it.
We're talking about two decades of extremely limited conceptual progress on interaction. The only GUIs that are run over network streams are HTML/JS/CSS, and those took about fifteen years to turn into fully standalone clients, and not terribly reliable or secure ones at that.
We still don't have a continuation concept (workflows that can be set aside like data items and continued at any point in time) in any shipping UI, despite that being demonstrated 10 years ago at MIT.
We still very typically treat dates and times as text strings instead of first-class manipulable objects whose identity is separate from presentation.
I could go on, but I'm just trying to convey the sense that our (known) future is stuck in the past.
XCode's Interface Builder is an Objective-C knockoff of a Lisp tool from the 80's which needed a lot of work even back then and never received it.
We're talking about two decades of extremely limited conceptual progress on interaction. The only GUIs that are run over network streams are HTML/JS/CSS, and those took about fifteen years to turn into fully standalone clients, and not terribly reliable or secure ones at that.
We still don't have a continuation concept (workflows that can be set aside like data items and continued at any point in time) in any shipping UI, despite that being demonstrated 10 years ago at MIT.
We still very typically treat dates and times as text strings instead of first-class manipulable objects whose identity is separate from presentation.
I could go on, but I'm just trying to convey the sense that our (known) future is stuck in the past.
Self is also an interesting language in the Smalltalk tradition. I did a short screencast of the GUI here http://bluishcoder.co.nz/2014/12/17/changing-attributes-in-s...
There are others in the 'self' tag of the blog. A modern look at this type of environment, which Slate seems to be progress towards, would be interesting.
There are others in the 'self' tag of the blog. A modern look at this type of environment, which Slate seems to be progress towards, would be interesting.
Slate development goes back many years. Perhaps sometimes you've got to let the field lay fallow for a season, before that next big burst of inspiration.
Had no idea this project was still active. Used to have some correspondence with an author (Lee Salzman) of the prototype oo multiple dispatch paper many years ago (over 10 now I guess), and had written my own implementation of it for a toy language of my own.
Good to see this still ticking. Though these days I'm more interested in static typed languages, this is still very cool.
Good to see this still ticking. Though these days I'm more interested in static typed languages, this is still very cool.
See also Atomo: http://vito.github.io/atomo/
And Atomy: http://vito.github.io/atomy/
Both of these, I feel, are interesting small offshoots that explore more in a pattern-matching metaprogrammable grammar direction, although they never became large visions or systems.
And Atomy: http://vito.github.io/atomy/
Both of these, I feel, are interesting small offshoots that explore more in a pattern-matching metaprogrammable grammar direction, although they never became large visions or systems.
I wish Lee were still around. I miss working with him and appreciate him putting up with me.
Looks like he's still active.
https://github.com/lsalzman?tab=activity
https://github.com/lsalzman?tab=activity
Damn, that's new to me. He resisted joining github until recently, it seems...
It's a relief to find out this language is dynamically typed. That way I don't have to think about it.
So, there's something about that that is true, but we weren't aiming for this per se.
We wanted to make the idea of a programming world as an OS manifest, so Slate images and object networks are like a file system image. The most straightforward way for us to get into that was dynamic with optional typing.
The idea at some point was to have staged meta-programming (like we did to build the VM out of Slate) that was typed, so that the static existed within the dynamic but in a more obvious way than "sure, my Haskell universe exists on a nasty filesystem".
We tried.
We wanted to make the idea of a programming world as an OS manifest, so Slate images and object networks are like a file system image. The most straightforward way for us to get into that was dynamic with optional typing.
The idea at some point was to have staged meta-programming (like we did to build the VM out of Slate) that was typed, so that the static existed within the dynamic but in a more obvious way than "sure, my Haskell universe exists on a nasty filesystem".
We tried.
I guess I should say that we built a type system in Slate using objects and multimethods; it was used for metaprogramming and self-hosting.
Obviously not ideal, but we leaned in the direction we hoped others would see. I don't think enough people saw what we were doing beyond the front page news blurbs. Slate has a lot of good code in it.
Obviously not ideal, but we leaned in the direction we hoped others would see. I don't think enough people saw what we were doing beyond the front page news blurbs. Slate has a lot of good code in it.
Main regrets: - Starting with multiple delegation from Self; we migrated to Traits a la Squeak and Perl6 but it was pretty late in the project. - Hewing too closely to Smalltalk syntax, instead of ditching the lexical awkwardness for keyword syntax and more conventional but unambiguous lexical patterns. - Image-based bootstrapping was useful, but too monolithic. I wanted to make it have a symbolic graph linker to stitch together images from modules. That would have kept the project flexible enough to keep going.
As it is, I'm disillusioned with the open source and software research fields, and working on startups to accumulate my own funds to run a project like this without being subject to the rhetorical whims of a diseased culture. Hah!
You may as well AMA.