[bencoman71]

> The colorful Playskool environment

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

> How anyone could possibly be productive in such an environment. What is it that's so attractive about it to Smalltalkers?

Perhaps its useful to get some outsiders perspectives....

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

http://www.virtuouscode.com/2015/05/11/in-which-i-make-you-h...

Noel Rappin has written a few books about Ruby & Javascript. He provides an introduction to Smalltalk in "MountainWest RubyConf 2014 - But Really, You Should Learn Smalltalk"

http://youtu.be/eGaKZBr0ga4

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

[bencoman71]

> How anyone could possibly be productive in such an environment. What is it that's so attractive about it to Smalltalkers?

Now you've probably heard that in Smalltalk everything is an object. Sure its an nice catch-phrase but hard to grasp its significance. Consider then, that classes and methods are live objects within the Image. You can operate on them as you work within the live Image and from your application program.

For example, the Pharo mail list was recently asked the following question... > I want to have many different object instances with different > behaviors picked at random from a list of available behaviors. What I had in mind was a functionality similar > to prototyped languages like Self and Javascript in which you > could change the behavior inside the object and not the class/prototype.

A way to achieve this is to define each behavior as a normal method. For convenience, we'll define two protocols, 'behaviors' and 'non-behaviors' in the system Browser to hold these. For the uninitiated here is a short intro to the Browser. Protocols show in the third pane. https://www.youtube.com/watch?v=zgQjcZ9SCCs

The class MyObject is defined with an instance variable to hold which behavior to invoke...

  Object subclass: #MyObject
      instanceVariableNames: 'behavior'
      classVariableNames: ''
      package: 'Example'

In the Browser, add these two methods to the 'behaviors' protocol...

    behavior1
        Transcript show: '1'.

    behavior2
         Transcript show: '2'.

When an object is created, we'll set an object's behavior by asking its class for all its methods, selecting those that are in the #behaviors protocol, then from that collection making a random selection.

In the Browser, add these two methods to the 'non-behaviors' protocol...

    initialize
        | behaviors |
        behaviors := self class methods select: [ :m | m protocol = #behaviors ].
        behavior := behaviors atRandom selector.

    perform
        self perform: behavior.

Thats all that is required.

To test this, from Playground (our REPL) evaluate... Transcript open. 10 timesRepeat: [ MyObject new perform ].

==> 2221212212

But how do I add new behavior at run-time you may ask? Now since classes are objects within the runtime Image, the application can ask the class to compile a new behavior. This is can be demonstrated by evaluating this code in the Playground...

    newBehavior := 'behavior3
             Transcript show: ''3'' '.
    MyObject 
        compile: newBehavior 
        classified: #behaviors
        notifying: nil.

To test this, from Playground evaluate...

     Transcript clear.
     10 timesRepeat: [ MyObject new perform ].

==> 211133212

That flexibility is why I love Smalltalk.

[groovy2shoes]

That's pretty neat. Thank you for taking the time to write all this up.

That said, you can get the same kind of flexibility in Lisp or even Lua, among others, and I'm having a hard time thinking of a use-case where such a thing would come in handy.