10 ms·

> Someone who wants to learn Smalltalk should try Pharo or Squeak, not GNU, GNU will just leave them with a bad taste of weirdness for no good reason. As someo

> Someone who wants to learn Smalltalk should try Pharo or Squeak, not GNU, GNU will just leave them with a bad taste of weirdness for no good reason. As someone who has tried Pharo and Squeak, I was left with a bad taste of weirdness for no good reason. The colorful Playskool environment, while neat at first, was not only ugly and alien, but also quite minimal compared to Vim or Emacs. I still don't understand how anyone could possibly be productive in such an environment. What is it that's so attractive about it to Smalltalkers?

horrido 10y ago
The article explains how you can be productive. It's mostly in the "live coding/debugging" environment, which dramatically shortens the edit-test-debug cycle. The low cognitive friction of the language itself is also preeminent. The clutter-free Smalltalk IDE is one its main selling points. I've used Xcode and Eclipse and Visual Studio, and the Smalltalk IDE is a breath of fresh air. Beauty is in the eye of the beholder, and I like Smalltalk very much. Dolphin, in particular, is prized for its excellent IDE implementation. In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here.
- groovy2shoes 10y ago
  > Beauty is in the eye of the beholder I think this is what it comes down to in the end. I don't find anything about it beautiful, from the aesthetics to the workflow to the isolation from the rest of the system. But I'm coming to realize thanks to the massive response to my comment why someone else might find any or all of those things beautiful, so thank you for that. I find it interesting that you compare it favorably against Eclipse, considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment. Would you mind going into more detail why it is that the Squeak or Pharo environment is better for you than Eclipse? > In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here. I disagree, and I think that dealing with a well-organized codebase composed of cohesive modules each containing an array of small methods (or equivalent) is an area (though far from the only one) where Emacs and Vim shine, especially when making use of multiple buffers, windows, netrw/dired-mode, wildmode/wildmenu, something like ctags/etags, registers, marks, ... the list goes on and on. I have a feeling that if you're not missing Vim or Emacs when using the Squeak/Pharo environment, you likely weren't making full use of Vim's or Emacs's power (which is excusable, given the learning curve of the those tools). When I say that I've been using Vim for over 10 years, the implication is not that I've just been getting used to it for 10 years, it's that I've been constantly learning it for 10 years, and even now not a month goes by where I'm not able to more fully utilize its power than before. The only environment I've found that's more powerful/productive for me than Vim has been SLIME with Emacs (I've recently found out about SLIMV and am looking forward to giving it a try, though I tend to have an aversion to using plugins in Vim). In the end, though, I think what it comes down to is the different emphasis on the environments. Whereas Vim and Emacs emphasize navigating and manipulating text, Squeak and Pharo emphasize navigating and manipulating a live environment. I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image. But if that style of development has been beneficial for you, then of course a tool like Vim or Emacs isn't going to cut it. To each their own, I suppose.
  - nilram 10y ago
    (Note, I’m not the poster your responding to.) > considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment. I was an active Smalltalker and Java developer in that timeframe and I used both Java and Smalltalk environments. IBM’s titles were "VisualAge for Smalltalk" (VAST) and "VisualAge for Java" (VA Java). They were both built on top of Smalltalk. . In fact, or at least my recollection, the VA Java environment had basically the same code browsers and tools available as the VAST environment, and the word on the street was that building on top of the Smalltalk environment allowed IBM to meet their time-to-market objectives for the Java product. So I have to disagree with the idea that Eclipse is a direct descendant of VisualAge for Smalltalk. The same company was involved, but at best they’re siblings, and really, bastard siblings at that. Eclipse was a "rewrite" of the environment in verb only; it was a new environment in it’s own right and the tools didn’t allow for exploring and debugging existing code, or trying out new code, as well as VA Java did. > I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image. Both VisualAge for Smalltalk and Digitalk/V (the first of many subsequent re-writes that avoided Xerox’s licensing fees of Smalltalk-80) could commit "change sets" to an external code repository. Loading those changes to a fresh image would allow reproducing a product predictably, perhaps addressing your objection. I can speak definitively only for the Digitalk/V case, but the resulting image would include the dev tools and for the application, the VM would ensure that only the application code was executed. There was subsequent development (after a merger of Digitalk and it’s competitor, ParcPlace) that would allow creating an application in the more traditional sense, but that was never released. It was rumored that Dolphin Smalltalk had that capability, but that, too, never saw the light of day (as far as I'm aware).
    - groovy2shoes 10y ago
      Thank you for the history lesson. I find this stuff very interesting, but it can be hard to find reliable information except by talking to people who know (I mean, you don't get that kind of detail from typical articles on the Web). That pretty much means we have to piece together a lot of this history by talking to people, which seems strange to me in this day and age given how easily we can record and preserve such information.
gnaritas 10y ago
If you see programs as a collection of static text files, you're not going to understand, but if you approach it as Smalltalk does, no files, no compile time, see the image as a live runtime, you'll realize you can prototype things via on the fly tinkering faster than virtually any other environment; you don't even need a database as you can just store collects of objects in class variables since it's always run-time in Smalltalk your object instances live in the image as long as you want them to. Smalltalk'ers believe that code should be optimized for reading, not writing, which is why Smalltalk code browsers focus far more on organization than any other languages IDE's do and the power of this cannot be emphasized enough. Simply put, once you let go of your text editor addiction, and embrace the image, it's the most productive programming environment there is as far as Smalltalk'ers are concerned.
- groovy2shoes 10y ago
  I'm familiar and reasonably comfortable with the "image" concept from Lisp, but frankly I think outside of prototyping it's an inferior way to program. When you're doing some sort of exploratory/experimental programming or trying to incrementally prototype some program, the ability to modify a live environment is fine, but it's only just barely better than coding in a file, and only because it saves you a small amount of time. But once you're ready for distribution, images have a ton of drawbacks. For example: * The running image is either particular to some physical machine, or it's constrained to a virtual machine, leaving you to pick one of portability or efficiency. * I have to believe that there's some way to remove the development environment from the final image, but I didn't find a way to do that with Squeak when I tried it -- if there's really no way to do that, then suddenly your production image includes a full development environment in addition to your application, costing you and your customers unnecessary storage space, memory, and bandwidth. * There's also a question of how well the environment within the image can communicate and interact with the host environment -- from the end user's point of view, it looks and behaves differently from everything else they use; how is it for the programmer? The biggest problem with the image-based development style is reproducible builds. If your application has been created by incrementally tweaking a live environment here and there, how do you make that reproducible? How can you then save all the necessary code and data to recreate that state from a fresh image? Lisp solves the issue by supporting the file-based paradigm in addition to the image one, with constructs like LOAD, COMPILE, and COMPILE-FILE. At a higher level, Lisp also has a notion of "systems", which can be defined in a file and describe how to map a set of files to a final product (c.f. ASDF). Even in Lisp, however, you run the danger of forgetting about some change you made to the image and forgetting to include it in your source files. How would you do any of this in Squeak? Along the same lines, how would you work with source control? Checking an image into git doesn't seem like an ideal solution. In regard to code organization: files let developers organize the code however they feel is best, not the way some browser author decided is best. The idea of cohesion isn't just a sound engineering principle -- it's also a sound stylistic principle that can aid understanding of a system. Furthermore, a good text editor can help with navigating, exploring, querying, and processing text as well. Text editors aren't somehow limited to only enabling writing -- they have features to assist in reading and comprehending text, too. I, for one, never felt more productive in any Smalltalk-type environment I've ever used, and such a development model seems to have quite a few drawbacks in exchange for only very few, very minor advantages.
bencoman71 10y ago
> 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.

horrido 10y ago

The article explains how you can be productive. It's mostly in the "live coding/debugging" environment, which dramatically shortens the edit-test-debug cycle. The low cognitive friction of the language itself is also preeminent. The clutter-free Smalltalk IDE is one its main selling points. I've used Xcode and Eclipse and Visual Studio, and the Smalltalk IDE is a breath of fresh air. Beauty is in the eye of the beholder, and I like Smalltalk very much. Dolphin, in particular, is prized for its excellent IDE implementation. In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here.

groovy2shoes 10y ago
> Beauty is in the eye of the beholder I think this is what it comes down to in the end. I don't find anything about it beautiful, from the aesthetics to the workflow to the isolation from the rest of the system. But I'm coming to realize thanks to the massive response to my comment why someone else might find any or all of those things beautiful, so thank you for that. I find it interesting that you compare it favorably against Eclipse, considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment. Would you mind going into more detail why it is that the Squeak or Pharo environment is better for you than Eclipse? > In practice, you don't need the full power of Vim or Emacs in a programming environment where you're ever only dealing with small methods and where everything is laid out neatly in the System or Class Browser. I love Vim, but I don't miss it here. I disagree, and I think that dealing with a well-organized codebase composed of cohesive modules each containing an array of small methods (or equivalent) is an area (though far from the only one) where Emacs and Vim shine, especially when making use of multiple buffers, windows, netrw/dired-mode, wildmode/wildmenu, something like ctags/etags, registers, marks, ... the list goes on and on. I have a feeling that if you're not missing Vim or Emacs when using the Squeak/Pharo environment, you likely weren't making full use of Vim's or Emacs's power (which is excusable, given the learning curve of the those tools). When I say that I've been using Vim for over 10 years, the implication is not that I've just been getting used to it for 10 years, it's that I've been constantly learning it for 10 years, and even now not a month goes by where I'm not able to more fully utilize its power than before. The only environment I've found that's more powerful/productive for me than Vim has been SLIME with Emacs (I've recently found out about SLIMV and am looking forward to giving it a try, though I tend to have an aversion to using plugins in Vim). In the end, though, I think what it comes down to is the different emphasis on the environments. Whereas Vim and Emacs emphasize navigating and manipulating text, Squeak and Pharo emphasize navigating and manipulating a live environment. I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image. But if that style of development has been beneficial for you, then of course a tool like Vim or Emacs isn't going to cut it. To each their own, I suppose.
- nilram 10y ago
  (Note, I’m not the poster your responding to.) > considering that Eclipse is a direct descendant of IBM's VisualAge Smalltalk environment. I was an active Smalltalker and Java developer in that timeframe and I used both Java and Smalltalk environments. IBM’s titles were "VisualAge for Smalltalk" (VAST) and "VisualAge for Java" (VA Java). They were both built on top of Smalltalk. . In fact, or at least my recollection, the VA Java environment had basically the same code browsers and tools available as the VAST environment, and the word on the street was that building on top of the Smalltalk environment allowed IBM to meet their time-to-market objectives for the Java product. So I have to disagree with the idea that Eclipse is a direct descendant of VisualAge for Smalltalk. The same company was involved, but at best they’re siblings, and really, bastard siblings at that. Eclipse was a "rewrite" of the environment in verb only; it was a new environment in it’s own right and the tools didn’t allow for exploring and debugging existing code, or trying out new code, as well as VA Java did. > I personally loath that style of development because I'm lacking tools to track changes to the product and tools to reproduce the product from a fresh image. Both VisualAge for Smalltalk and Digitalk/V (the first of many subsequent re-writes that avoided Xerox’s licensing fees of Smalltalk-80) could commit "change sets" to an external code repository. Loading those changes to a fresh image would allow reproducing a product predictably, perhaps addressing your objection. I can speak definitively only for the Digitalk/V case, but the resulting image would include the dev tools and for the application, the VM would ensure that only the application code was executed. There was subsequent development (after a merger of Digitalk and it’s competitor, ParcPlace) that would allow creating an application in the more traditional sense, but that was never released. It was rumored that Dolphin Smalltalk had that capability, but that, too, never saw the light of day (as far as I'm aware).
  - groovy2shoes 10y ago
    Thank you for the history lesson. I find this stuff very interesting, but it can be hard to find reliable information except by talking to people who know (I mean, you don't get that kind of detail from typical articles on the Web). That pretty much means we have to piece together a lot of this history by talking to people, which seems strange to me in this day and age given how easily we can record and preserve such information.

gnaritas 10y ago

If you see programs as a collection of static text files, you're not going to understand, but if you approach it as Smalltalk does, no files, no compile time, see the image as a live runtime, you'll realize you can prototype things via on the fly tinkering faster than virtually any other environment; you don't even need a database as you can just store collects of objects in class variables since it's always run-time in Smalltalk your object instances live in the image as long as you want them to. Smalltalk'ers believe that code should be optimized for reading, not writing, which is why Smalltalk code browsers focus far more on organization than any other languages IDE's do and the power of this cannot be emphasized enough. Simply put, once you let go of your text editor addiction, and embrace the image, it's the most productive programming environment there is as far as Smalltalk'ers are concerned.

groovy2shoes 10y ago
I'm familiar and reasonably comfortable with the "image" concept from Lisp, but frankly I think outside of prototyping it's an inferior way to program. When you're doing some sort of exploratory/experimental programming or trying to incrementally prototype some program, the ability to modify a live environment is fine, but it's only just barely better than coding in a file, and only because it saves you a small amount of time. But once you're ready for distribution, images have a ton of drawbacks. For example: * The running image is either particular to some physical machine, or it's constrained to a virtual machine, leaving you to pick one of portability or efficiency. * I have to believe that there's some way to remove the development environment from the final image, but I didn't find a way to do that with Squeak when I tried it -- if there's really no way to do that, then suddenly your production image includes a full development environment in addition to your application, costing you and your customers unnecessary storage space, memory, and bandwidth. * There's also a question of how well the environment within the image can communicate and interact with the host environment -- from the end user's point of view, it looks and behaves differently from everything else they use; how is it for the programmer? The biggest problem with the image-based development style is reproducible builds. If your application has been created by incrementally tweaking a live environment here and there, how do you make that reproducible? How can you then save all the necessary code and data to recreate that state from a fresh image? Lisp solves the issue by supporting the file-based paradigm in addition to the image one, with constructs like LOAD, COMPILE, and COMPILE-FILE. At a higher level, Lisp also has a notion of "systems", which can be defined in a file and describe how to map a set of files to a final product (c.f. ASDF). Even in Lisp, however, you run the danger of forgetting about some change you made to the image and forgetting to include it in your source files. How would you do any of this in Squeak? Along the same lines, how would you work with source control? Checking an image into git doesn't seem like an ideal solution. In regard to code organization: files let developers organize the code however they feel is best, not the way some browser author decided is best. The idea of cohesion isn't just a sound engineering principle -- it's also a sound stylistic principle that can aid understanding of a system. Furthermore, a good text editor can help with navigating, exploring, querying, and processing text as well. Text editors aren't somehow limited to only enabling writing -- they have features to assist in reading and comprehending text, too. I, for one, never felt more productive in any Smalltalk-type environment I've ever used, and such a development model seems to have quite a few drawbacks in exchange for only very few, very minor advantages.

bencoman71 10y ago

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