[groovy2shoes]

> That was likely Squeak, not Pharo. Pharo has muted a lot of the UI colours to be more appropriate for a business environment.

I've used both. Yes, Pharo is considerably more professional-looking, but it's still rather ugly and alien (as in, it looks very odd when juxtaposed with the other applications running on the host system).

> Avdi Grimm has written a few books about Ruby. He records his experience trying Pharo in "I make you hate Ruby in 7 minutes"

Does it normally take 7 minutes to write "hello world" in Pharo? If so, that doesn't sound productive to me at all. Really, the only thing I saw in that video that made me feel envious in the least was the exemplary method search. But you don't need an environment like that to have exemplary search; I've been told Hoogle offers something like it for Haskell, for example.

Apart from that, I was pretty unimpressed with most of what I saw in that video, to be honest. The class browsing didn't seem particularly different from what Eclipse has to offer (which should be unsurprising given Eclipse's heritage in IBM VisualAge Smalltalk). The debugger didn't seem to be anything special -- it looks like a debugger. Going further, the heavy reliance on the mouse and the floating/stacking model of window management seriously cramp my style and slow me down.

Even as a language, I don't see what Smalltalk has to offer the programmer when compared to other languages. Yes, it's nice- and clean-looking. Yes, it was hugely influential. But it forces you to build your entire application out of nothing but objects and methods belonging to them, and cannot offer the flexibility of a multiparadigm language. Even as a strictly-OO language, it limits you to single inheritance and single dispatch. What other tools does it offer for creating and composing abstractions beyond its degenerate notions of objects and methods? Perhaps in 1980 it was an excellent choice, but we've had better choices since the 90s rolled in.

I've got enormous respect for the likes of Alan Kay, Dan Ingalls, L Peter Deutsche, and their whole crew at PARC. They certainly made history and have had a great deal of influence on our field. Notwithstanding, they were not alone in their innovation, and their product was not and is not perfect. Perhaps nothing will ever be perfect, but I feel as though Smalltalk has been surpassed at this point in time.

[qwertyuiop924]

There are some massive advantages to smalltalk's all-object approach: Metaprogramming (like MOP), becomes far easier and more useful.

And while the object model is degenerate, and there is only single dispatch, It's not that bad: The above are similar to Java, and smalltalk has much better metaprogramming than Java. I think dynamic dispatch in ST wouldn't be too hard to hack in. But I haven't explored enough about ST metaprogramming to be sure.

>Perhaps nothing will ever be perfect, but I feel as though Smalltalk has been surpassed at this point in time.

You may well be right, but it IS one of the very few OO languages that meet Kay's definition of the term, and is said to be akin to lisp in many respects. And lisp is a language many would say the same for.

But you may be right, and while much the ST family aside from ST-80 died, a few survived: namely, Self, Newspeak, and Io, all based to some degree upon ST-80. Of the three, at least one seems dead, all three are still usable and offer glimpses into what might have been.

None of them have MI, though.

[groovy2shoes]

> There are some massive advantages to smalltalk's all-object approach: Metaprogramming (like MOP), becomes far easier and more useful.

That's fine. I wasn't questioning Smalltalk's all-object approach, though. Lots of languages do that now.

> And while the object model is degenerate, and there is only single dispatch, It's not that bad: The above are similar to Java, and smalltalk has much better metaprogramming than Java.

"It's better than Java" is hardly a consolation :p

> I think dynamic dispatch in ST wouldn't be too hard to hack in. But I haven't explored enough about ST metaprogramming to be sure.

From what I could tell when I looked into it, the standard solution is to use the Visitor pattern, as you would in Java or C++. That leaves me pretty wanting, to say the least, and anything beyond double dispatch via Visitor is too tedious and spaghetti-like to be worth it at all.

> You may well be right, but it IS one of the very few OO languages that meet Kay's definition of the term, and is said to be akin to lisp in many respects.

That's because Lisp was one of Kay's inspirations for Smalltalk. It's not unique to Smalltalk, either, and it wasn't unique to Smalltalk even when it was conceived -- tons of languages are "akin to Lisp in many respects" nowadays. Doesn't make them Lisp, though :p

> And lisp is a language many would say the same for.

Sure, you can implement Smalltalk-style message-passing semantics in Lisp (it's how Scheme was born, after all), but I find CLOS-style generic-function-application semantics to be far more powerful and expressive. Not only do you get multiple dispatch and multiple inheritance, but the separation of methods from objects means that the methods themselves (the generic functions, technically) are first-class objects and can be passed to and returned from other functions, stored in data structures, etc. The separation also leads to a nice solution to what I call the "Expression Problem for Untyped Languages", which is a weaker form of the Expression Problem, differing only in that it relaxes the requirement for static type safety.

Anyway, what I'm trying to get at here is twofold: 1) CLOS > ST; 2) I wonder how Alan Kay feels about CLOS-style OOP, given that objects no longer behave as actors sending and receiving messages (though, I guess if you squint a little, you can view multiple dispatch as sending a message to a group of actors, such that they work in parallel to accomplish some task and produce a response; and, of course, you can still write singly-dispatched methods in CLOS, too).

> But you may be right, and while much the ST family aside from ST-80 died, a few survived: namely, Self, Newspeak, and Io, all based to some degree upon ST-80. Of the three, at least one seems dead, all three are still usable and offer glimpses into what might have been.

Eh, I'm okay with the way things turned out :p

[horrido]

Smalltalk doesn't only rely on OOP. It has lambdas and closures so that you have functional capabilities, too. Not strictly multi-paradigm, but close enough. This is why Smalltalk is so powerful.

Multiple inheritance has its problems, too. I prefer the greater simplicity of single inheritance.

[groovy2shoes]

Most "problems" with multiple inheritance stem from languages that don't provide a well-defined method resolution scheme. Languages that do have a well-defined hierarchy linearization tend to avoid most of the problems with multiple inheritance.

See, for example: Common Lisp, Dylan, Python (since 2.3), Perl 6, ...

[qwertyuiop924]

However, to use Steve Yegge's example, say you're making a game, and you have a LightSource class, and a Weapon class, and now you want a glowing sword. :)

Given, this sort of problem is far easier in ST than in java, because we have MessageNotUnderstood (I think that's what it's called), so you don't have to do as much stubbing.