Hacker News Reader

Comment by briantrice | Hacker News Reader

Ohai. I'm one of the authors. Thanks for noticing this, but we did wind down the project several years ago after failing to bootstrap it into what we wanted it to be.

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.

View on HN

> 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 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.

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.

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.

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.

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.

> Will a homoiconic language ever capture the 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.

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).

Wow, I never realized Symbolics was that big. Were they just not able to keep up in the era of cheap, commodity hardware for workstations?

A lot of that, a lot of NIH, and a lot of bad behavior and very bad management.

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 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.

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'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.

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.

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.

Reply on news.ycombinator.com