Normally they do, but some implementations (notably GNU SmallTalk) are so afraid of the SmallTalk way of doing things that they use source files instead, which IMO removes a large part of the attraction of using SmallTalk at all.
The image-based nature of Smalltalk-80 is both a positive and a negative. Inability to interoperate seamlessly with a "standard" developer workflow (editors, revision control, deployment) has, I'm pretty sure, hampered adoption.
I know there are tools and workarounds, and I'm quite familiar with how things are done there, and I used to be a huge advocate of the Smalltalk style approach. But over time, I've come to see two sides to this discussion.
No, not necessarily. Various Smalltalks have a wide range of different approaches to UI and IO more generally. This (their "operating system aspect" https://eighty-twenty.org/2019/01/13/why-learn-smalltalk) is the area in which they're most diverse, in fact. For instance, GNU Smalltalk has, by default, only a REPL, while Smalltalk 80 has a bitmapped GUI.
It can already kind-of do a REPL, so it'd be about making sure access to that functionality was robust, and then it's a matter of removing packages from the system until it's as small as you'd like. Assuming a subtractive approach, of course. There are other interesting subtractive approaches like Craig Latta's "Context" (nee Spoon) http://www.netjam.org/spoon/ which does something a bit like a page cache, marking used methods, classes, etc and eventually garbage-collecting those not used. In Craig's system, there's an upstream over the network from which missing classes/methods/etc can be faulted in, so this isn't as scary as it sounds. Then there are the additive approaches, which I've kind of lost track of, but there are several on the go, for compiling a fresh image from scratch from sources.
25 comments
[ 3.3 ms ] story [ 72.7 ms ] thread"Smalltalk VM Written in Zig with methods stored as type-annotated ASTs"
https://en.wikipedia.org/wiki/Little_Smalltalk
Minimal images without UI and a kick-ass package management system should be the foundation of whatever else you want to build with it.
I know there are tools and workarounds, and I'm quite familiar with how things are done there, and I used to be a huge advocate of the Smalltalk style approach. But over time, I've come to see two sides to this discussion.
I need Smalltalk for a lot of backends that have nothing to do with UI.
I saw Pharo 6 and 7 and some 10 instances serving dozens of thousands operations per second in production reliably for years.
Related:
ST 4U 282: Preparing a Pharo Image for Production - https://www.youtube.com/watch?v=TQfKnSR6izY
Overview of Pharo Web Stack [W4S7-EN] - https://www.youtube.com/watch?v=okHHUu9jsw0
How to setup a Pharo project - https://www.youtube.com/watch?v=Wnt3OBhR18I (although for CI I recommend using GitHub workflows these days)
Application development with Pharo - ESUG 2022 - https://www.youtube.com/watch?v=FdZUAWH__vk
Lastly, I'm working in using htmx and use Smalltalk stateless - https://www.youtube.com/watch?v=4_gmvN0pimI
but there is also a commandline repl: https://github.com/svenvc/NeoConsole
and other tools: https://github.com/svenvc/minimal-pharo-server-tools
and thank you for all those links. i hope other readers will find them as well
The guys there enjoy being helpful.
i see that Pharo is implemented 99.5% in smalltalk, which seem like a more reasonable target, implementing a language in itself is usually desirable
or is zig used just to bootstrap this implementation, and if so, how will this be better than Pharo
That alone is something C failed to improve in 50 years of history, features already provided by other languages of similar vintage and older.
If Zig manages to take a few developers away from C, that is already a win.
[~/ghq/github.com/dvmason/Zag-Smalltalk]$ cloc .
Language files blank comment code
--------------------------------------------------------------------------------
Smalltalk 306 4483 2203 18669
Zig 46 137 1000 10959