On Learning Smalltalk

Seems like it makes operational tasks, and really anything that involves distributing the code to anyone who is not the developer, is more difficult than with non-image based languages.

That's an interesting perspective, thank you for sharing.

Smalltalk was trying hard to be different, and there were a lot of neat ideas in there, but while it seems like a very powerful concept to have your OS/editor and language all rolled up into one, that doesn't mean it's a good idea. Kind of like LISP macros. Seems like such a powerful and useful concept, but on the other hand, if you give programmers too much power, they are guaranteed to misuse it.

Such that I'm curious if moving models around for use would have been easier in some image based languages.

It's simply anachronistic to judge Smalltalk implementations of that past decade against version control of this decade, when there have been newer Smalltalk implementations with version control.

Even back in 1983 the blue book discussed "Storing the set of Changes on a File" (page 465) and "Commands that check for conflicts" ( http://rmod-files.lille.inria.fr/FreeBooks/TheInteractivePro... page 472).

"Whether your development team consists of one person, or many: Do understand and use the change manager. The change manager is one of the most important tools for software development in the Smalltalk-80 environment. … It allows you to selectively browse [changes], remove [changes] incorporate them into another version of the system, check for conflicts, and prepare the changes for release to other members of the development team or to end users." (page 500 "Smalltalk-80 Software Development Do's and Dont's")

> Your image persists your data and changes forever—including any mistakes you make…

Even back in 1988, source code changes made with the Smalltalk IDE were automatically logged to a text file (the change log) and we could choose which of the logged source code changes to apply later to an unchanged image file.

So no, mistakes were not forever.

Smalltalk always felt like it was from the future to me. Its vision and respect for human thought and creativity is so grand it makes me blush. It represents a real belief in technology and what people might do with it. It's full of hope and humanity. It's basically the Shire of programming environments -- if the Shire were part of the Standford campus.

If you haven't checked Smalltalk out, you should free your mind and give it a shot.

The idea of a bundled IDE is also something I am not completely convinced that it is the best solution. On the one hand, it allows powerful operations, but on the other hand, every feature has to be developed explicitly for that language.

Instead, I prefer the modularity of Unix tools which can be used to develop tools by combining multiple technologies.

"Like Docker, but for Smalltalk images."

"What if everything was immutable?"

Which I guess doesn't really include the language itself.

But it seems more fundamental to Haskell than first class functions, which exist in many other popular languages.

You're essentially building up a catalogue of messages and answers and so it's not particularly ergonomic to jump through several layers of abstraction in the browser to get what you need. And there's no arbitrary limitation on your code such that a class can only have 10 methods in it, or 100 lines, or some other silly thing that forces you into creating a more convoluted architecture with more indirection.

I've grown weary of OOP for a long time because of how hard it is to find an effective application of it that doesn't grow into a collection of explicit design patterns with some business logic buried in the depths of the hierarchy. My brief experience with Smalltalk essentially revived my interest in it and encouraged me to be more thoughtful about my approach without throwing it all out and pining for a purer, more functional language that trades OOP's big problems with a set of its own.

As far as working with the code, debugging, reading and writing were concerned, it was great. It really gave me a taste for thoughtful OOP, simple documentation, and even TDD-style development again, because the whole environment just worked perfectly for it in a way that would be hard to reproduce in a traditional language where you're organising things on the file system.

Dealing with version control was a little more awkward (getting Git in place), and I'm glad I didn't have to worry about deployment or any kind of maintenance. Possibly GNU Smalltalk would be an ideal middle-ground there.

It's also one of the few occasions where I've not really had to rely on the internet so much to get help when I need it. It's been enough to have a book on Smalltalk and to rely on the documentation in the IDE.

I fail to see how shipping a tree shaked version of the image was any different than shipping a C++ application with MVSCRT.dll, for example.

As for source control, while it was indeed a problem with workarounds like text export/import, image based SCM were eventually developed.

Deployments can start with a stock image, load your code and run, without you having to move around an actual binary blob from machine to machine.

https://stefan-marr.de/renaissance/

https://github.com/smarr/RoarVM

This was a research project so performance on a single core was poor compared to the official Squeak virtual machine, but it was an interesting exploration of the natural fit between objects/message passing and multiple cores.

It wasn't abandoned, rather rebuilt on top of a virtual file system.

Also, git is well-integrated.

Pharo can make applications with a native look & feel - https://github.com/pharo-spec/Spec-Gtk.

Current Pharo has a very solid and powerful FFI, so using C libraries is easy.

I often bootstrap experimental code with pry "built in" in various ways, e.g. with a small "prolog" with a few utility methods to hot-reload the code and set up basics to let me keep an editor in one window a pry session in another, make changes and just load the changes without dropping the current state so I can get instant feedback using the test data I already have loaded.

For the last two years or so I've used a text editor I wrote in Ruby instead of emacs which spins up a server process on first start that it then exposes via DrB (an IPC library for those not familiar with Ruby) that stores the contents of the buffers and persists them regularly. I did that both so I can implement multiple views on the same buffer without having the same client process keep everything open, and so that if anything crashes I'm unlikely to lose data.

But the side effect is that because DrB forwards exceptions too, and the editor itself is set up to catch all exceptions and throw me into pry, if something crashes my editor, I get a pry prompt where I can live-debug it on the real buffers, edit the editor with another instance of itself talking to the same backend server instance, and then hot-replace the code to see if it fixes the bug. For hard-to-reproduce bugs in particular it's amazing to be able to keep the buggy instance running while fixing the problem and figuring out which conditions causes it.