How learning Smalltalk can make you a better developer

In short, no.

Are there any major differences between Pharo and Squeak I should know about?

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.

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.

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'

    behavior1
        Transcript show: '1'.

    behavior2
         Transcript show: '2'.

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.

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.

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

That flexibility is why I love Smalltalk.

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.