How learning Smalltalk can make you a better developer

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.

With experience programming complex applications both on C++ and Smalltalk, I have experienced coding in a live environment is all but a tiny advantage, it is a real productivity booster. The more complex your application the more productivity gain you have. In an interactive geometry application as Dr. Geo (http://drgeo.eu) , the combined use of in-situation inspector, debugger and live code editing on graphic geometry items, ease issues finding and fixing. Fixing issues is much more easier and pleasant thanks to the developer tooling. This is not without mentioning other advantages as a better source code access and understanding thanks to the class browser. In C++ I was using Emacs.

> I have to believe that there's some way to remove the development environment from the final image, It really depends on the Smalltalk implementation. I heard Dolphin Smalltalk (http://www.object-arts.com/) or Smalltalk X (https://www.exept.de/en/smalltalk-x.html) are really good at that. Pharo itself is doing progress in that specific direction.

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

This is true of many Scheme environments. Some Scheme environments do support the image-based development model, and at least Scheme48 uses it exclusively for compiled code.

However, it's more common to find image-based development in other Lisp dialects. In the case of Common Lisp, for example, have a look at this[0] paper on the SBCL bootstrap process.

> And this is where the misunderstanding stems from: The image is a live environment, yes, but it is also your entire application, and your source code: When you hit 'save' in a smalltalk image, all of your code, as well as a snapshot of the state of every single object in the system, is saved to disk. There is no file to forget to add things to. If you added it live, it's in your system, same as if you'd typed it into a text file in lisp.

Right. Perhaps an example would help clear up what I mean: Say you have an application in some Smalltalk environment, but you want to bring that application up in some other Smalltalk environment (on another platform, for example). All of your code is stored within image A for the original environment, and you have a fresh image B for the other environment. How do you reproduce image A for the new environment starting with image B? If your source code is stored in files, you can easily enough just load those files into the new environment.

On the other hand, I really don't understand what kind of benefits you gain by doing all of your programming in a live environment. I always felt the same way about Lisp's REPL: the interactive interpreter is handy for quickly testing out some code for sure, but I wouldn't want to write my entire application in an interactive interpreter. Why? Because if my sources are represented in plain text files, I can use any number of specialized tools to query and process them. This is the kind of thing people mean when they say things like "Unix is my IDE", and why I am the most productive with Vim open next to a shell prompt and a REPL.

> It's not. Which is why Smalltalk has its own version control system, and (I believe), a git bridge, allowing you to save only your classes, your projects, and what you've changed to a repo, and download them to other images.

It seems that this would solve some of the issues I raised, especially the ability to download into other images. The last time I played with Squeak, there wasn't any git bridge (in fact, there may not have been any git whatsoever... it was quite some time ago), and any builtin version control was pretty awkward and limited.

> You're still thinking in terms of files: In a smalltalk vm, the browser isn't organizing files: it's organizing classes. And you can sort those classes into packages, and the methods into protocols. Not perfect, but pretty good.

Yes, I am thinking in terms of files. I was trying to make the point that using files gives the programmer far more flexibility in organization, which I see as an advantage compared to using an image. Furthermore, most of the IDEs I've used offer package/class/method browsers on top of files, giving the best of both worlds. Take Eclipse for example: its navigation pane displays a hierarchy of packages, classes, and methods -- it's effectively the same as using the Smalltalk class browser, but the underlying storage is based on a file hierarchy which has been processed by the IDE.

> An ST environment can query, navigate, and explore the objects that text represents, and tell you far more about what your code is doing that any text editor.

I don't believe that one bit, especially considering that there is a variety of tools available for processing text files beyond just a text editor (and, of course, any text editor worth its weight in bits can interface with external programs).

[0]: http://www.doc.gold.ac.uk/~mas01cr/papers/s32008/sbcl.pdf

The way you explain the advantages, it seems like the live environment is much more beneficial when developing highly interactive applications, perhaps GUI applications especially, but the advantages of the live environment wouldn't come into play so much when developing non-interactive, "batch mode" applications. Do you think that's a fair assessment?

If so, then perhaps one reason I didn't find much value in the Smalltalk environment is that I wasn't developing interactive applications. With batch applications, I've come to find that even classical debuggers aren't quite as helpful as they are with interactive applications, because depending on how long it takes your program to run, it can often be faster to run a test case and inspect the log than to set a few breakpoints and step until you find your problem.