I was afraid Lee Salzman had left though, but wasn’t sure. I’d be curious to hear Lee’s take on his loss of interest in Slate.

Unfortunately, Slate seems to have a bleak future. There just isn’t that much interest in it based on the mailing list and irc archives. That coupled with the loss of Lee and (AFAIK), still no environment that Smalltalkers are used to doesn’t bode well for the project.

Factor is another language that its creator has stated is partially inspired by Slate. I think Forth is the primary inspiration though.

It’s too bad that something like Slate couldn’t have at least gotten to a state where it could’ve been explored by Smalltalkers.

The social environment surrounding Slate was always less than optimal. That’s about as diplomatic I can get on that subject.

But hopefully Slate can get a second wind at some point in time.

Of course, he is well beyond me (and most everyone else) in systems programming skill and so this creates a certain imbalance which naturally makes me look like I co-opted it when I was doing all the talking on the mailing list and making releases and so forth. I don’t want to give that impression and I’d rather be ( and be known as ) a coordinator of much smarter people than I than the “lone hero” of a little language-island.

Anyway, I just helped jao rephrase it fairly. Hopefully this keeps things clear.

then Lee lost interest, and abandoned the project, but still this is not fair/correct as it is:

” into a quite usable programming environment named Slate, developed and maintained by Brian Rice.”

CLOS, for instance, provides both multi-methods and accessors to a class slots (to aid in encapsulation). Whether encapsulation (forced by the language rather than by convention) is ‘one of the strongest motivations for using OOP’ is highly debatable, though. I won’t enter right now in such a debate. Anyway, defining OOP is one of those religious issues with no right answer, but let me just point out that you would have a hard time arguing that CLOS or Self are not object-oriented languages ;).

Regarding the benefits (or lack thereof) of encapsulation, i would recommend this recent news post in comp.lang.smalltalk whose spirit i basically endorse.

If methods are external to the class, it means that “things” (the methods) outside of a class will have to know about a class’es internal implementation.

This means that if I change a class’es implementation, the impact of this change is not contained (encapsulated) inside this class. In fact, I couldn’t predict the impact of such a change.