For what? Practically speaking in 2022 it has no benefit over any other system or language or libraries.
It seems to be a cool thing that we can talk about as we look at our college days with nostalgia.
A few people will even vehemently insist that they use it just as well today and it’s the “best thing ever” and you ingrates and peons belonging to the uneducated and unsophisticated masses should use it.
So we guiltily head over to the smalltalk language site and maybe even do a brew install. And yes it looks neat! Damn, if we were in a different world then everyone should be using it!
But what’s that? I see the weekly e-mail report on traffic and revenue from my ruby app. As I head off to my home and family to plan our monthly weekend vacation at the lake cottage paid for by my 9-5, I’ve forgotten about smalltalk until the next HN article…
I'm of a similar opinion (having been a Smalltalk developer in the 1990s boom) but I think it's worth looking at for modern programmers. I wouldn't use it for anything myself any more, but for me it's a nice way to get the flavour of the work being done in the AI community and at Xerox Parc in those days. Like a history book you can crawl into rather than just experience vicariously.
One thing I do find interesting is that the programmers who usually come up as "legendary" in this context were usually just better than average guys who ended up in the right place at the right time. A lot of their code is still running in the Cincom VisualWorks product and not all of it is gold.
Curiosity, mostly. I have no plans on doing anything major (let alone released to an end user) in Smalltalk, but it's a very different mode of programming than most of what I've done in my professional life (largely dominated by work in the embedded systems space and a lot of tooling around that). On the desktop side, by fiat, I've spent a lot of time with C# for new development, and a bit with some older C++ and Java systems (with the current job, more those two).
Because of the way that embedded systems work, you can't easily escape the standard build, load, test cycle (at best, on some projects, you get simulators to help speed up test), and deployment is often delayed for, sometimes, good reasons around coordination with a fleet of systems.
On the desktop software side, because I haven't convinced my employer to go with smaller batch sizes for releases, we still have big-bang releases every 3-6 months (and the first year with COVID we didn't even hit that pace with remote work growing pains). When an end user comes across a non-critical issue, this means they will be waiting months to have it addressed (if it gets put into the next release, it could be years in a worst case).
This leads to end user empowerment, at least in principle. One of the current systems I'm working on has a pretty comprehensive scripting language (a bespoke DSL) that lets end users (not formally trained as programmers, and their job isn't to work as programmers) extend the system to meet their needs without calling for help most of the time. None of the other systems do that, but most could without hitting any corporate IP issues (the customer, in our case, owns most of the source code anyways, but they aren't a software company and outsourced the development and maintenance work). Smalltalk (the system) is an extreme case of end user empowerment and I wanted to explore that concept.
It still has many cool features that are not common elsewhere, and it is still evolving (https://pharo.org/features, the list does not mention some things like object-centric debugging). And yes, it can pay your bills.
maybe the best we can do is learn from smalltalk, especially the idea of being immersed in the language itself as the "os" where we can make any tools we need when we need them, right out of the environment as if it were pen and paper except its a programming system
think about how we easily make scripts and tools etc in the terminal, now imagine that for your whole os including the gui, it could be very empowering for the average person
You cannot change the form of an object while debugging a thread that halted because that object didn't understood a message you sent with C and then recompile, restart the stack all without killing that thread, can you?
For what? Practically speaking in 2022 it has no benefit over any other system or language or libraries.
It seems to be a cool thing that we can talk about as we look at our college days with nostalgia.
A few people will even vehemently insist that they use it just as well today and it’s the “best thing ever” and you ingrates and peons belonging to the uneducated and unsophisticated masses should use it.
So we guiltily head over to the smalltalk language site and maybe even do a brew install. And yes it looks neat! Damn, if we were in a different world then everyone should be using it!
But what’s that? I see the weekly e-mail report on traffic and revenue from my ruby app. As I head off to my home and family to plan our monthly weekend vacation at the lake cottage paid for by my 9-5, I’ve forgotten about smalltalk until the next HN article…