> I couldn't believe that anyone would want to mouse-around to poke through the available classes and methods.
So I dont know a ton about smalltalk outside of what I've read and poking aside in squeak for a few minutes, but is this how smalltalk apps were supposed to be distributed and run? Inside a sandboxes system like that?
On certain systems, there are tools that make them feel more native. Eg. on Dolphin Smalltalk which ran on Microsoft Windows, you can run a utility to stripped off the unnecessary parts (eg. the browser/editors and unused classes) of the image and it gets bundled into an .exe which includes a VM. A user wouldn't know it's running Smalltalk.
It turned out to be an excellent tool to write Windows app during its time. The live environment worked extremely well in working with and figuring out ActiveX and COM objects.. Even better than VS Studio at that time.
I worked for 3 years using VisualAge and GemStone/S.
As Allen says in the article, Squeak was a special case: based on Smalltalk-80 is oriented to have an environment to support the experimentation with e-toys (a platform for learning).
Other Smalltalks were different. VisualAge supports native UIs, and you have tools to produce the final product. The usual process is to create a reduced image based on modules that you load from the version control system (Envy in the case of VisualAge). Then you package an EXE that uses your image.
At some point, one actually does poke around and understand what is going on to know how a system works. alrs states that they are contributing to K8s. That does require poking around to learn the plumbing of the system.
You could very well write Smalltalk apps without poking around the underlying classes. The Visual Age for Smalltalk environment just made it very easy to do so. You can do this with any language IDE today where you attach the source code of libraries to the project workspace.
I have been using vim for about 2 decades so I can empathise with not having the familiar key bindings and speed of moving around.
A good Smalltalk environment does let a developer navigate the image [1]. On many systems that means it allows you to poke at everything about that Smalltalk system, not just your own code, but 3rd party libraries, as well as the Smalltalk system itself, including what we normally consider the text editor or IDE.
It's true that you lose access to vim [2], but you trade that it for the image as well as wonderful code browsing capability in the sense of looking up a type definition, senders and implementors of a message, stepping into any code, live debugging and editing during debugging, etc.
So Smalltalk is a tradeoff. If one can give up vi and work with the paradigm, it is really really great. [3]
[1] The Smalltalk image is a wonderful and beautiful concept. There is one glaring downside to it for most Smalltalk systems. It creates a divide between the image and the rest of the world.
[2] Since you can redefine how any code in the image work, it's possible to define a few shortcuts so you get a very limited set vim functionality, but it's not feasible to reproduce the vi environment (even if we want to invest the effort) because the paradigms are different.
[3] One can say that's generally true for everything. "Once you can accept X, you get Y", but the argument is that Smalltalk is really great once a developer does that.
> … how someone would want to poke around with a mouse…
Back in the day, not having a TKL keyboard could become a pain.
Back in the day, poking around could be an effective way to learn not just what batteries were included but whether, with a tweak and nudge, they might solve le problème du jour.
Poking a running program not just a source code file.
So I dont know a ton about smalltalk outside of what I've read and poking aside in squeak for a few minutes, but is this how smalltalk apps were supposed to be distributed and run? Inside a sandboxes system like that?