I've been on a Smalltalk kick the last couple of weeks (studied/used it in college, remembered many of the ideas but had never done a proper deep dive before). This was one of the papers I read and found particularly interesting, not just for its talk about Smalltalk itself but also about teaching programming (both to kids and adults).
There have been several past discussions. Ones with more than 1 comment:
Now that this is back here and I've realized it (thanks second chance pool!) some other content you may find interesting if you liked this one:
Dan Ingalls' Evolution of Smalltalk: http://worrydream.com/refs/Ingalls%20-%20The%20Evolution%20o.... This covers some of the same time period as Kay's article but goes on through the early commercial history of Smalltalk and the development of Squeak.
Lots of free books courtesy of Stéphane Ducasse and the people who released them for free and OCR'd them: http://stephane.ducasse.free.fr/FreeBooks/. I'm reading The Bluebook, Smalltalk-80: The Language and its Implementation by Goldberg and Robson, presently.
I can recommend the book "Smalltalk Design Patterns Companion" for the purpose of - learning Design Patterns. Because of Smalltalk's simplicity the design patterns' "essence" comes through more easily than in a clunky low-level language like C++. This book also provides good examples of what good Smalltalk code looks like.
One thing I'm wondering about is, what's with the cursive-ish font? It seems like a very bad time for coding. Doing some searching now I can't seem to find a reference (hard to know what to search for, Google thinks I might mean recursive). Does anyone have an idea?
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?
Having worked with Smalltalk a lot I think I know what its main flaw for industrial software development is. It is the image, and your ability to change anything in it (easily), like the Compiler for instance. Then you save your image. Your image is no longer compliant with anybody else's image and the programs you develop "on it" will not run on anybody else's image.
Compare this to a language like JavaScript. There too you can modify the base-objects like Object and Function and Array. But the changes you make to them will be part of your program which is not saved as part of an "image" (only as source-code). Your JavaScript program does not assume anything more about its environment than anybody else's JavaScript program, because you can not develop against a modified "base-image"
(since there is no such thin in JavaScript, is there?).
Smalltalk would be great for things like programming all the smart devices in your house. I think that was part of its original goals, provide an environment where everybody can create their own programs, without worrying much about how your program might later integrate with programs of others.
It's not they don't run on anybody else's image. They might. It is that they are difficult to get to run on other images.
Have you tried porting Smalltalk apps between different vendors' Smalltalks? Problem is there is no standard Smalltalk base-image. That is caused by the fact it is so easy to modify everything in the image you have and then save it and give it to others. Others then start developing against that.
You can try meticulously to avoid this problem but it takes special attention.
Contrast this with Java. You can run any Java program that was developed on a given version of JDK by using that same or later versions of JDK.
I must disagree. Image concept is just a tool, and it only depends on how you use it. In Smalltalk, you can modify the "base-objects" and assign these changes to your package and export them with the other sources (managed by Git, for example), so there is no difference to JavaScript here. But unlike JavaScript and others, you can use the image for things like saving the system state with a debugger open on a bug that is very rare and hard to reproduce.
It is a tool which is very easy to misuse, by forgetting to file out all the changes you make to it.
That is not uncommon in practice. Most (or all?) Smalltalk's come with an image, but there is no source-file telling you how that image was derived, or how you can derive it from some more basic "standard" vanilla image.
That is the reason why it is so difficult to get code developed on one Smalltalk -platform to work on images provided by other vendors. You could say that is caused by "misuse" of the image-tool, but seems like all Smalltalk vendors are doing it.
I ported many projects between different Smalltalk versions, and I never had a bit of feeling that the image concept caused the related issues. Smalltalk implementations are just doing some things differently. The language ANSI standard is too minimal for practical purposes and obsolete. To ruin your basic premise: Common Lisp also uses the image concept, and it is famous for good stability and compatibility among different implementations.
> Philosophically, Smalltalk's objects have much in common with the monads of Leibniz and the notions of 20th century physics and biology
Love this line as this was definitely my impression of monads when venturing into Haskell-land...
The whole history of Smalltalk is interesting and it's an interesting way to reason about data and behaviour. And even if Smalltalk is obscure, C++, Java, Ruby, Python and others aren't, and OOP remains a great way to model many domains.
>Love this line as this was definitely my impression of monads when venturing into Haskell-land
Despite the name though, Leibniz monad's don't have anything to do with monads in category theory/math and Haskell.
In Leibniz the name monads is used for a philosophical concept, kinda like a blend of "atoms" in Democritus and platonic "ideas" ("https://en.wikipedia.org/wiki/Monadology")
Specifically, Leibniz's monads couldn't have any communication of any kind with anything (including each other or themselves), so they are not really a great model of anything in computer science!
I could be wrong because I don't know much about Leibniz's monads, but aren't those a completely different thing from Haskell monads?
I don't just mean "slightly different" like how arrays in javascript are slightly different than arrays in C. I mean like they are completely different ideas/concepts that happen to share the same word. I think "Homonym" is the right word for this situation?
This...what do you call it? A mindset? A way of life? The answer to all questions? Because you cannot simply call it a programming language that's for sure.
I started programming in 1979 and throughout my long career I have constantly been exposed to various Smalltalk articles and genuflections.
Wow! Just look! Fucking EVERYTHING is an object! Holy shit can you believe the audacity of the developers?
Along with LISP, Smalltalk is just one of Holy Shrines That One Must Visit In Order To Complete One's Path As A Real Programmer.
I almost think "Ancient Religion" should be the right moniker...
I started programming around 1972 or so, so we are likely of similar vintage. I think we tend to find what we seek. I have found much to learn from Smalltalk and Lisp in the fifty years since I first wrote FORTRAN programs on punch cards at UofT's High-Speed Job Stream, and while yes, there are various people whose enthusiasm and narrow focus rivals any religious cult...
Here's the thing. Some people will hate a thing so much they'll accuse you of professional misconduct for using it. Seriously, you can find people who say, in writing, that programming without static type-checking is professional misconduct.
Should that stop us from using JavaScript, Clojure, Ruby, Python, &c.?
No. Although hey, at least read their arguments with an open mind and decide for yourself.
On the other side, there will be people who love a thing so much that they can't imagine using anything else. We may not love it as much as they do, but should that stop us from using that thing if we like?
Also no.
Bottom line: Why judge a thing by what the most extreme opinions about the thing are, or how extreme those opinions are? Judge by its utility for you.
Back when each of those cost extra, Smalltalk/V 286 was an affordable development tool ;-)
March 7, 1988 — "Smalltalk/V 286 is available now and costs $199.95, the company said. Registered users of Digitalk's Smalltalk/V can upgrade for $75 until June 1."
There have been several past discussions. Ones with more than 1 comment:
https://news.ycombinator.com/item?id=25012425 - Nov 7, 2020 (28 comments)
https://news.ycombinator.com/item?id=17913668 - Sept 4, 2018 (69 comments)
https://news.ycombinator.com/item?id=9907556 - July 18, 2015 (5 comments)
https://news.ycombinator.com/item?id=9588316 - May 22, 2015 (5 comments)
https://news.ycombinator.com/item?id=7926141 - June 21, 2014 (10 comments)
https://news.ycombinator.com/item?id=1311282 - May 1, 2010 (17 comments)