5 ms·

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

> 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-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 http://youtu.be/eGaKZBr0ga4

bencoman71 10y ago
> 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 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 10y ago
  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.
groovy2shoes 10y ago
> 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 10y ago
  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.

bencoman71 10y ago

> 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 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 10y ago
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.

groovy2shoes 10y ago

> 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 10y ago
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.