9 ms·

Ruby and Its Neighbors: Smalltalk

229 points by jrochkind1 1y ago

postexitus 1y ago
What this blog omits to mention and I think the most impressive part of Smalltalk ecosystem is the structure of the image - the application's state that you can freeze and distribute and resume elsewhere (makes supporting client side applications so much easier). The Smalltalk image is a very interesting beast. Look at it as a kind of immortality. Many current Smalltalk systems, Pharo, Squeak, VisualWorks among them, share a common ancestor, that is, a Smalltalk image from Xerox PARC. This common ancestor however is not some remote thing, but actually still alive in those modern systems. The modern variants were produced by sending messages to the objects in that image. Some of those messages actually morphed the current objects. Classes are full-blown objects, and creating new classes is done by sending messages to class objects. Some of the objects in a Smalltalk image may date back to 1972, when the first Smalltalk image bootstrapped! Smalltalk images never die, they just fade into something potentially fundamentally different. You should view your application building as not fundamentally different from creating a new Smalltalk version.
- criddell 1y ago
  > makes supporting client side applications so much easier I was thinking that supporting a Smalltalk application must be a nightmare because it is so malleable. Users can inspect and modify the entire system, no?
  - supportengineer 1y ago
    Correct, at least that was true when I was a Smalltalk developer.
  - Qem 1y ago
    > Users can inspect and modify the entire system, no? That should make the Smalltalk family popular with free software proponents. That makes me curious why that is not the case in history. The efforts of FSF on Smalltalk pale in comparison with those on C, Lisp and other languages.
    - pjmlp 1y ago
      C was only open until AT&T was allowed to charge for UNIX, and it became an international standard in 1989. It was thanks to GCC that most folks actually got a free C compiler after those events, coupled with Sun starting the trend among UNIX vendors that developer tools would be extra license, no longer available on a regular UNIX installation.
  - e12e 1y ago
    I used to think so, then watched as javascript in the browser rose to be the premium application platform - where the user has access to a console/repl, developer tools etc...
    - sethhochberg 1y ago
      I think many people would suggest that this was more of an accident due to the ubiquity of the browser, though. The transition from "websites" to "web apps" was well underway by the time the dev tools became a built-in browser feature - Chrome was notable for being the first browser to release with the console, inspectors, etc out of the box, but that came later. The developer experience was quite a bit rougher in the early days, and then better but still not native in the days of plugins like Firebug. The web becoming the premium app distribution platform was, firstly, because the web was the lowest-common-denominator distribution channel. Javascript was just the tool that was available where everyone wanted to run.
      - e12e 1y ago
        Yes, but maintaining a webapp isn't a nightmare due to the user being able to inspect css, edit html or access the javascript console?
        NetMageSCW 1y ago
        The difference is the changes the user can make don’t flow back to the original. If the user hits refresh they get your copy of the web app, not theirs.
  - igouy 1y ago
    > Users can inspect and modify the entire system, no? End users? Yes if you - want them to - let them; No if you - don't want them to - stop them.
  - ssdspoimdsjvv 1y ago
    Smalltalk being so malleable also makes it possible to completely disable source code inspection/execution.
    - igouy 1y ago
      And then what? Say you made the foreground text color the same as the background text color, so you could no longer see the source code. You can no longer do anything. You can no longer save those changes. And then what? Better, say you did that in a script file which additionally saved the image, so that image was now unusable. And then what?
      - ljm 1y ago
        Plenty opportunity in many languages or systems to lock yourself out by doing something silly.
      - ssdspoimdsjvv 1y ago
        The parent comment was talking about a deployed application, and making sure users can't modify the source code. In that case, your image hopefully was built using source code from a VCS and no such changes will have been applied. This is not so different from building an app by pulling the latest version of the code from Git. And if you did manage to commit changes that completely mess up your environment, you throw that image away, take a vanilla one and load your source code into it. Again, not so different from using Git.
        igouy 1y ago
        So "possible to completely disable source code inspection/execution" really doesn't matter.
  - hboon 1y ago
    In several implementations you can strip the image down (to remove the dev tools, etc). And some let you ship as single file executables
- Scubabear68 1y ago
  The image concept, in my opinion, is what really limited Smalltalk's appeal and distribution. The image meant you basically got whatever state the developer ended up with, frozen in time, with no indication really of how they got there. Think of today's modern systems and open source, with so many libraries easily downloadable and able to be incorporated in your system in a very reproducible way. Smalltalk folks derided this as a low tech, lowest-common-denominator approach. But in fact it gave us reusable components from disparate vendors and sources. The image concept was a huge strength of Smalltalk but, really in the end in my opinion, one of the major areas that held it back. Java in particular surged right past Smalltalk despite many shortcomings compared to it, partially because of this. The other part of course was being free at many levels. The other half of Smalltalk issues beyond the image one, was the cost of both developer licenses ($$$$!) and runtime licenses (ugh!).
  - fellowniusmonk 1y ago
    For this very reason I'm working on a development platform that makes all changes part of a cheaply stored crdt log. The log is part of the application, there are some types of simulations inside of this that we can only timestamp and replay but we can always derive the starting position with 100% accuracy.
    - joshmarinacci 1y ago
      Ooh. Tell us more.
  - lawlessone 1y ago
    Isn't this kinda where AI is now? Like with LLM's it seems impossible to separate the "reasoning" from data it has stored to learn that reasoning.
  - Barrin92 1y ago
    the entire philosophy of Smalltalk was to think of software artifacts as living entities. You can just find yourself in a piece of software, fully inspect everything and engage with it by way of a software archaeology. To do away with the distinction between interacting, running and writing software. They wanted to get away from syntax and files, like an inert recipe you have to rerun every time so I think if you do away with the image you do away with the core aspect of it. Computing just in general didn't go the direction they wanted it to go in many ways I think it was too ambitious of an idea for the time. Personally I've always hoped it comes back.
- shevy-java 1y ago
  That part is also cool. I'd like this in ruby too, e. g. where we could have tons of objects reflect on that state, and just resume work there. Everything is an object. Squeak everywhere, but to also retain the "scripting" (light) commandline approach. Nobody in smalltalk really understood why "scripting" is important. Python showed why.
  - igouy 1y ago
    > also retain the "scripting" (light) commandline approach Smalltalk developers preferred to do their scripting within the Smalltalk IDE, so they could use their familiar tools. And then save their "scripting" as a text file ("fact.st"). $ cat fact.st Stdio stdout nextPutAll: 100 factorial printString; nextPut: Character lf.! SmalltalkImage current snapshot: false andQuit: true! And then "run" that text file ("fact.st") from the commandline. $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
- isr 1y ago
  Adding to what you said. Squeak was a clean open source reimplementation (by the devs who did the original Smalltalk-80), so it's real history starts from there (ie: the 90s, not the 70s) One thing to keep in mind is that smalltalks all have the same ability to save & load code to & from disk, just as any other programming environment. But, they also have the option of just using the image to persist, and iterate on that. Squeak overdid that aspect of it, such that over time, it became hard to prune older side projects & and it just became increasingly bloated. Both Pharo & Cuis forked from squeak at about the same time. Pharo images are fully bootstrapped from a seed. Cuis is not quite there yet, but cuis from its inception went on a ruthless simplification drive (the number of classes in the system was reduced by about 500% !), so that it's base is effectively a "seed", and the rest of a cuis image is built up by importing projects (from disk & git) on demand. But yeah, curating a set of images over time is remarkably enticing & friction free. Even in cuis, I find I have to force myself to keep flushing changes to my own packages. Its not that the tools to use files are limited. In cuis, they're not. You can work on multiple different things WITHIN THE SAME IMAGE (changes to some builtins, a couple of your own projects, etc), and the system will keep track of what belongs where. So a couple of mouse clucks will fileout the relevant code to the relevant changesets & packages. And yet - just banging on the same image is just ... fun, easy, enticing.
  - mpweiher 1y ago
    > Squeak was a clean open source reimplementation Small correction: they actually cloned/converted the Apple Smalltalk image, so those bits remained. The VM was created from scratch by writing it in Slang, a Smalltalk dialect that was essentially equivalent to BCPL and could be translated to C. https://dl.acm.org/doi/10.1145/263698.263754 https://dl.acm.org/doi/10.1145/263698.263754
    - isr 1y ago
      I didn't know that. So they didn't bootstrap an image from scratch, when they created the new VM?
      - mpweiher 1y ago
- sandcat_ 1y ago
  Unless you are indeed the original author from StackOverflow, it would be polite to attribute your comment: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319
- mccoyb 1y ago
  Are you `robject` on Stack Overflow -- or perhaps you might explain why you copied verbatim their response to https://stackoverflow.com/questions/3561145/what-is-a-smalltalk-image https://stackoverflow.com/questions/3561145/what-is-a-smallt... without citing your source?
- aaronbrethorst 1y ago
  Bizarrely, this makes me think of sourdough starter.
  - hshdhdhehd 1y ago
    Anything like that. Dog breeds. Cultivations. Etc.
- znpy 1y ago
  Lisps have a similar concept: save-lisp-and-die: https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-lisp-and-die/ https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-... In the world of containers, I wonder if one could use this feature to interrupt the execution of some computation, save the state somewhere (disk or object storage) and once the workload has been rescheduled on some other node, basically you boot up from your image file, re-establish network connections (if necessary) and just resume computation as if nothing happened.
  - cben 11mo ago
    https://criu.org/ https://criu.org/ (Checkpoint/Restore In Userspace) is a long-running project (i remember the name over a decade ago) worth checking... Ooh, looks like they made progress in conveniently connecting it to containers.
- weakfish 1y ago
  Your comment is an uncredited quote of the following: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319
adamzwasserman 1y ago
thanks for this article. as a history of languages aficionado myself, I appreciate both the content and the style. thanks again for the good reading
goodthink 1y ago
If you love the keyword syntax of Smalltalk, the reflectivity, the incremental compilation, live debugging in the environment, check out https://newspeaklanguage.org https://newspeaklanguage.org for theSmalltalk experience in the web browser. This is my favorite video by Newspeak's creator Gilad Bracha: https://youtu.be/BDwlEJGP3Mk?si=Z0ud1yRqIjVvT4oO https://youtu.be/BDwlEJGP3Mk?si=Z0ud1yRqIjVvT4oO
- smj-edison 1y ago
  That talk is fantastic! Just a note for anyone who's interested in Newspeak, it's more of a spiritual successor than a direct descendant of smalltalk (in a good way imo). It has some really slick features like: * No global import/export namespace (all imports are dependency injected, meaning capability based security is already baked in) * Nested classes instead of modules * No variable assignment (everything is a method call) * Mixins instead of inheritance * Synchronization and code updates as near primitives * Support for foreign objects through aliens and proxies, and foreign code can call newspeak objects through expats * A native serialization to file format * support for multiple overlapping type systems
frou_dh 1y ago
Since Smalltalk is effectively an OS unto itself, when we hear about the days of commercial applications being written in Smalltalk, how did deployment to end-users work? Were the users running, say, Windows and then the Smalltalk "OS" would be running on top of that, but in a sort of "kiosk mode" where its full OS-ness was suppressed and it was dedicated to showing a single interface?
- pjmlp 1y ago
  Easy, you make use of tree-shaking, which is actually older concept than minifying JavaScript, and add glue it together with an executable header that boots the image.
  - uticus 1y ago
    I don't understand what "tree-shaking" means, can you point to a reference to give me a better understanding?
    - shrubble 1y ago
      Tree shaking in this context is not unlike a compiler: it looks at all the code and determines if it will ever run in the image, eliminating any unnecessary code and delivering the minimal image needed. The code is in a “tree” format like an AST, and you’re shaking the tree to test what can be removed.
    - nielsbot 1y ago
      You might know it as "dead code stripping": You remove all the things from the image that aren't used in your shipping app. Calling it "tree shaking" is web development term AFAIK.
      - munificent 1y ago
        > Calling it "tree shaking" is web development term AFAIK. I think that's backwards. Lars Bak and the other V8 folks came from the Smalltalk world and brought the "tree shaking" term with them as far as I know.
behnamoh 1y ago
Rants like this about languages which have little/no code snippets are the worst because they often sell you an idea w/o actually showing how it works in practice (because often times it doesn't work well in practice). talk is cheap, show me the fucking code, else don't waste my time.
- Philpax 1y ago
  The post is about the conceptual underpinnings of the system, not about the specifics of the code. It would be like judging the Linux kernel by the UI running atop it: it's largely immaterial to the discussion at hand.
- Jtsummers 1y ago
  > Rants like this What about this makes you think it's a rant? Is the author making an impassioned plea for people to use Smalltalk? Is he going off on a tirade about something?
- kragen 1y ago
  This article is more about the development environment than it is about the programming language, so it would be misleading to focus heavily on example code. A UI screencast video would be much more helpful.
kragen 1y ago
> You’ve likely used powerful coding editors and terminals. Smalltalk is just different. You are in the running environment. I've experienced this a few different times: with Microsoft BASIC-80 (and GW-BASIC), with SBCL and SLIME, with LOGO, with GForth, with OpenFirmware, with MS-DOS DEBUG.COM, with Jupyter, and of course with Squeak. It really is nice. It used to be the normal way of using computers; before memory protection, it was sort of the only way of using computers. There wasn't another memory space for the monitor to run in, and the monitor was what you used to do things like load programs and debug them. This approach continued as the default into many early timesharing systems like RT-11 and TENEX: there might be one virtual machine (memory space) per user, but the virtual machine you typed system commands into was the same one that ran your application. TENEX offered the alternative of running DDT (the debugger) in a different memory space so bugs in the application couldn't corrupt it, and that was the approach taken in ITS as well, where DDT was your normal shell user interface instead of an enhanced one. All this seems very weird from the Unix/VMS/Win32 perspective where obviously the shell is a different process from your text editor, and it's designed for launching black-box programs rather than inspecting their internal memory state, but evolutionarily it was sort of the natural progression from a computer operator single-stepping a computer (with no memory protection) through their program with a toggle switch as they attempted to figure out why it wasn't working. One of the nicest things about this way of working is halt-and-continue. Current versions of Microsoft Visual Studio offer sometimes halt and continue. In MBASIC you could always halt and continue. ^C halted the program, at which point you could examine variables, make arbitrary changes to the program, GOTO a line number, or just CONT to continue where you'd interrupted it. Smalltalk, SLIME, or ITS allows you to program in this way; if you like, you can refrain from defining each method (or function or subroutine) until the program tries to execute it, at which point it halts in the debugger, and you can write the code for the method and continue. This is an extremely machine-efficient approach; you never waste cycles on restarting the program from the beginning unless you're going to debug program initialization. And in Smalltalk there isn't really a beginning at all, or rather, the beginning was something like 50 years ago. Myself, though, I feel that the hard part of programming is debugging, which requires the experimental method. And the hard part of the experimental method is reproducibility. So I'm much more enthusiastic about making my program's execution reproducible so that I can debug faster, which conflicts with "you're in the running environment". (As Rappin says, "Code could depend on the state of the image in ways that were hard to replicate in deploys." I experience this today in Jupyter. It's annoying to spend a bunch of time trying to track down a bug that doesn't exist when you restart from scratch; worse is when the program works fine until you restart it from scratch.) So I'm much more excited about things like Hypothesis (https://news.ycombinator.com/item?id=45818562 https://news.ycombinator.com/item?id=45818562) than I am about edit-and-continue. Paul Graham wrote somewhere (I can't find it now) about how in Viaweb's early days he would often fix a bug while still on the phone with the customer who was experiencing it, because he could just tweak the running CLisp process. But you can do the same thing in PHP or with CGI without sacrificing much reproducibility—your system's durable data lives in MariaDB or SQLite, which is much more inspectable and snapshottable than a soup of Smalltalk objects pointing to each other. (#CoddWasRight!) Especially since the broad adoption of the Rails model of building your database schema out of a sequence of "migrations".
jaymce 1y ago
thank you for this great post. my nostalgia for the late 90's ParcPlace IDE is heavy.
jimbokun 1y ago
So Ruby is Smalltalk but amenable to modern development practices and tools like source control and off the shelf text editors, and usable for Unix scripts.
- sebastianconcpt 1y ago
  Basically yes.
- antod 1y ago
  Ruby is like Smalltalk, but with some Perl (for good or bad) mixed in too IMO.
- vinceguidry 1y ago
  Ruby isn't Smalltalk. The only thing Ruby inherited from it is the pure object model. Everything else was cribbed from other languages. Ruby doesn't have what makes Smalltalk great, the image-based development model. I'm making my own text editor in Ruby now, as I'm wishing for a more Smalltalk-like experience with it. There's just so much missing. Ruby has the reflective capability to enjoy a Smalltalk-like IDE, but Rails took over and drove Ruby in that direction long before anyone could cook one up. Which is a shame, IDEs that aren't Smalltalk / Lisp haven't graduated past the need for static analysis despite having 50 years to do so. Now it's the red-headed stepchild of languages due to no fault of its own.
  - pjmlp 1y ago
    As someone that used Smalltalk via Smalltalk/V back in the day, I would nonetheles vouch that dev environments with direct connection to Smalltalk, like Java and .NET, are the closest we get to it in mainstream languages.
  - dominicrose 1y ago
    It wouldn't be too hard to code a Smalltalk-like IDE for Ruby (compared to building a normal IDE), but the Ruby files would have to be structured in a specific way. It would not be possible to edit them using another IDE or text editor, unless you preserve the structure, but it would work well with Git. Another issue is that the developer would have to use two IDE's, one for Ruby and one for the rest. Everytime you access a class in the IDE, it could read the class's Ruby file into memory and split it into protocols (a protocol could just be a comment above the method name in the output Ruby file) and methods so that you can visualize them one by one the Smalltalk way. Or - I don't recommend it but - if you really want the Smalltalk experience then: - your code would be running in the same Ruby process as the IDE - any code change would be made in the live running process - store code in a database instead of files - version control from the database instead of git
sebastianconcpt 1y ago
Smalltalk is among the top most ergonomic ways to model concepts in a computer (capacity to model essential complexity) because the CPU got abstracted and compacted in the VM. But destiny made CPUs win and now we're using AI to chew their accidental complexity for us.
- pjmlp 1y ago
  The irony many of us used to joke about COBOL, and now we are entering book sized prompts into a little chat window.
  - sebastianconcpt 11mo ago
    Haahahah true! Well put.
shevy-java 1y ago
I kind of like Smalltalk. Unfortunately syntax-wise Smalltalk is a huge set back and step back compared to Ruby. But Alan Kay's ideas are still epic today. I still don't think any language came close to his vision either; smalltalk definitely not. Ruby got closer but also no dice. Elixir kind of got close too (prettier "erlang") - to have fault-tolerant mini-CPUs ("objects", aka similar to biological cells). The problem is that even people with grand ideas, such as Alan Kay, are not automatically great language designers. Matz is a better language designer than Alan Kay, for instance, whereas Alan Kay has the better ideas. It's a trade-off. Note: I myself would not know how a language should look like that would follow Alan Kay's vision closer. It is definitely not smalltalk; it is also not ruby, though ruby is very good. I know I would suck as language designer, but as an improvement I would have a language similar to ruby (no, not crystal - crystal is a worse "ruby"), with a stronger focus on speed (perhaps have a second language that can be as fast as C here and be similar) and with a much stronger focus on what erlang brought to the table; that would get us close to, say, around 85% or 90%. And then add the rest that could fulfil Alan Kay's vision. Of course we need a specification too, because just saying "90% of his vision" is also pointless. I would perhaps start from erlang, retain the good bits, make it a modern variant of OOP (and OOP is also defined differently in different programming languages, so we need to define that term too, in the specification).
- NetMageSCW 1y ago
  How is the syntax a step back? Smalltalk is the ultimate orthogonal language - everything is consistent. Famously the Smalltalk grammar fits on a postcard and tells you everything you need to know to understand the system from the source code.
  - travisgriggs 1y ago
    Yeah, I have no idea what shevy-java is talking about either. I would accept “huge step too far”, but not backwards. Unless your belief is that on the 8th day God gave mankind Algol syntax and said “let all languages look like this”. I’ll give that it can feel pretty foreign, like forth, lisp, erlang also do. These languages, imo, all use syntax where the form of the syntax binds nicely, reinforces even, with their computation models.
widikidiw 1y ago
[dead]
rbanffy 1y ago
> and I remember telling them that Smalltalk programmers were paid more. Also much happier. C++ back then is not the C++ you use today.
bowsamic 1y ago
I always found it too fragile. There’s a reason why smalltalk VMs have such good recovery features, it’s incredibly easy to brick your system when it’s all a network of objects, and I’m sure anyone who has worked in smalltalk has done so many times
- shwaj 1y ago
  I used to find it amusing that you could say `Smalltalk := nil` in the early days of Squeak, and poof! all the classes in your system are garbage collected. (I’m not sure that’s exactly what happened, probably the system crashed before garbage collection could happen. But it was definitely a guaranteed insta-crash).
- igouy 1y ago
  How can it be fragile if there are "such good recovery features"? Just restore unsaved changes when you launch the same image again. That's robust not fragile. https://drcuis.github.io/TheCuisBook/The-Change-Log.html https://drcuis.github.io/TheCuisBook/The-Change-Log.html
  - bowsamic 1y ago
    The recovery features are external, and exist to solve a problem that is specific to smalltalk You may as well claim that computers are robust because you can just buy a new one. It has nothing to do with computers Pretty sure ST-80 doesn’t even mandate recovery features, which is pretty scary
    - igouy 1y ago
      Huh? The recovery features are built-in to Smalltalk implementations.
endlessvoid94 1y ago
In 2013 I built a smalltalk-esque system browser using ruby and TCL. It was fun: https://www.youtube.com/watch?v=2xC5B5t5Rq8 https://www.youtube.com/watch?v=2xC5B5t5Rq8
ripe 1y ago
Smalltalk-80 was also good for graphics programming. Around 1990, I was a graduate student in Prof. Red Whittaker's field robotics group at Carnegie Mellon. In Porter Hall, I was fortunate to have a Sun 3/60 workstation on my desk. It had a Smalltalk-80. I learned to program it using Goldberg & Robson and other books from ParcPlace Systems. The programming environment was fantastic, better than anything I have seen before or since. You always ran it full screen, and it loaded up the Smalltalk image from disk. As the article says, you were in the actual live image. Editing, running, inspecting the run-time objects, or debugging: all these tasks were done in the exact same environment. When you came into the office in the morning, the entire environment booted up immediately to where you had left it the previous day. The image had objects representing everything, including your screen, keyboard, and mouse. Your code could respond to inputs and control every pixel on the screen. I did all my Computer Graphics assignments in Smalltalk. And of course, I wrote fast video games. I used the system to develop programs for my Ph.D thesis, which involved geometric task planning for robots. One of the programs ran and displayed a simulation of a robot moving in a workspace with obstacles and other things. I had to capture many successive screenshots for my papers and my thesis. Everybody at CMU then wrote their papers and theses in Scribe, the document generation system written by Brian Reid decades earlier. Scribe was a program that took your markup in a plain text file (sort of at a LaTeX level: @document, @section, etc.) and generated Postscript for the printer. I never had enough disk space to store so many full screen-size raster images. So, of course, instead of taking screenshots, I modified my program to emit Postscript code, and inserted it into my thesis. I had to hack the pictures into the Postscript generation process somehow. The resulting pictures were vector graphics using Postscript commands. They looked nice because they were much higher resolution than a screenshot could have been.
travisgriggs 1y ago
I did Smalltalk for ~20 years as my primary. I’m a polyglot now, maintaining/implementing in C, Python, Swift, Kotlin, and Elixir. The thing (for me) about Smalltalk was the thought to code ratio. It was awesome. It had a pretty good balance of less is more. Where working in Swift and Kotlin feel like trying to navigate the many nuances of American football or cricket, Smalltalk was like playing soccer/football-sans-america. The syntax is simple. And the computation model is straitforward and simple. Elixir is kind of like that, computationally, a few simple concepts and everything builds on that. The saddest part about Elixir is that it ran with the whole do/end syntax. Drives me nuts. But I love that computationally, though different than Smalltalk, it’s like Smalltalk in that it’s a simple consistent model.
nanna 1y ago
Anyone working with a Smalltalk implementation?
- z500 1y ago
  I played around with Squeak this summer and made a few demos of showing how inserts and removals work in binary search trees and B-trees. I also wrote a tree-walking Smalltalk interpreter in F# and an implementation of the game of life for it. It was a blast.
lukehalko 1y ago
24 year old Smalltalk developer here (lmao). Thanks for this.
wolfejam 1y ago
Thank you for taking the time to write about Smalltalk. I have never used it, but I love all the old stories, cheers!

229 points by jrochkind1 1y ago

What this blog omits to mention and I think the most impressive part of Smalltalk ecosystem is the structure of the image - the application's state that you can freeze and distribute and resume elsewhere (makes supporting client side applications so much easier). The Smalltalk image is a very interesting beast. Look at it as a kind of immortality. Many current Smalltalk systems, Pharo, Squeak, VisualWorks among them, share a common ancestor, that is, a Smalltalk image from Xerox PARC. This common ancestor however is not some remote thing, but actually still alive in those modern systems. The modern variants were produced by sending messages to the objects in that image. Some of those messages actually morphed the current objects. Classes are full-blown objects, and creating new classes is done by sending messages to class objects. Some of the objects in a Smalltalk image may date back to 1972, when the first Smalltalk image bootstrapped! Smalltalk images never die, they just fade into something potentially fundamentally different. You should view your application building as not fundamentally different from creating a new Smalltalk version.

criddell 1y ago
> makes supporting client side applications so much easier I was thinking that supporting a Smalltalk application must be a nightmare because it is so malleable. Users can inspect and modify the entire system, no?
- supportengineer 1y ago
  Correct, at least that was true when I was a Smalltalk developer.
- Qem 1y ago
  > Users can inspect and modify the entire system, no? That should make the Smalltalk family popular with free software proponents. That makes me curious why that is not the case in history. The efforts of FSF on Smalltalk pale in comparison with those on C, Lisp and other languages.
  - pjmlp 1y ago
    C was only open until AT&T was allowed to charge for UNIX, and it became an international standard in 1989. It was thanks to GCC that most folks actually got a free C compiler after those events, coupled with Sun starting the trend among UNIX vendors that developer tools would be extra license, no longer available on a regular UNIX installation.
- e12e 1y ago
  I used to think so, then watched as javascript in the browser rose to be the premium application platform - where the user has access to a console/repl, developer tools etc...
  - sethhochberg 1y ago
    I think many people would suggest that this was more of an accident due to the ubiquity of the browser, though. The transition from "websites" to "web apps" was well underway by the time the dev tools became a built-in browser feature - Chrome was notable for being the first browser to release with the console, inspectors, etc out of the box, but that came later. The developer experience was quite a bit rougher in the early days, and then better but still not native in the days of plugins like Firebug. The web becoming the premium app distribution platform was, firstly, because the web was the lowest-common-denominator distribution channel. Javascript was just the tool that was available where everyone wanted to run.
    - e12e 1y ago
      Yes, but maintaining a webapp isn't a nightmare due to the user being able to inspect css, edit html or access the javascript console?
      - NetMageSCW 1y ago
        The difference is the changes the user can make don’t flow back to the original. If the user hits refresh they get your copy of the web app, not theirs.
- igouy 1y ago
  > Users can inspect and modify the entire system, no? End users? Yes if you - want them to - let them; No if you - don't want them to - stop them.
- ssdspoimdsjvv 1y ago
  Smalltalk being so malleable also makes it possible to completely disable source code inspection/execution.
  - igouy 1y ago
    And then what? Say you made the foreground text color the same as the background text color, so you could no longer see the source code. You can no longer do anything. You can no longer save those changes. And then what? Better, say you did that in a script file which additionally saved the image, so that image was now unusable. And then what?
    - ljm 1y ago
      Plenty opportunity in many languages or systems to lock yourself out by doing something silly.
    - ssdspoimdsjvv 1y ago
      The parent comment was talking about a deployed application, and making sure users can't modify the source code. In that case, your image hopefully was built using source code from a VCS and no such changes will have been applied. This is not so different from building an app by pulling the latest version of the code from Git. And if you did manage to commit changes that completely mess up your environment, you throw that image away, take a vanilla one and load your source code into it. Again, not so different from using Git.
      - igouy 1y ago
        So "possible to completely disable source code inspection/execution" really doesn't matter.
- hboon 1y ago
  In several implementations you can strip the image down (to remove the dev tools, etc). And some let you ship as single file executables
Scubabear68 1y ago
The image concept, in my opinion, is what really limited Smalltalk's appeal and distribution. The image meant you basically got whatever state the developer ended up with, frozen in time, with no indication really of how they got there. Think of today's modern systems and open source, with so many libraries easily downloadable and able to be incorporated in your system in a very reproducible way. Smalltalk folks derided this as a low tech, lowest-common-denominator approach. But in fact it gave us reusable components from disparate vendors and sources. The image concept was a huge strength of Smalltalk but, really in the end in my opinion, one of the major areas that held it back. Java in particular surged right past Smalltalk despite many shortcomings compared to it, partially because of this. The other part of course was being free at many levels. The other half of Smalltalk issues beyond the image one, was the cost of both developer licenses ($$$$!) and runtime licenses (ugh!).
- fellowniusmonk 1y ago
  For this very reason I'm working on a development platform that makes all changes part of a cheaply stored crdt log. The log is part of the application, there are some types of simulations inside of this that we can only timestamp and replay but we can always derive the starting position with 100% accuracy.
  - joshmarinacci 1y ago
    Ooh. Tell us more.
- lawlessone 1y ago
  Isn't this kinda where AI is now? Like with LLM's it seems impossible to separate the "reasoning" from data it has stored to learn that reasoning.
- Barrin92 1y ago
  the entire philosophy of Smalltalk was to think of software artifacts as living entities. You can just find yourself in a piece of software, fully inspect everything and engage with it by way of a software archaeology. To do away with the distinction between interacting, running and writing software. They wanted to get away from syntax and files, like an inert recipe you have to rerun every time so I think if you do away with the image you do away with the core aspect of it. Computing just in general didn't go the direction they wanted it to go in many ways I think it was too ambitious of an idea for the time. Personally I've always hoped it comes back.
shevy-java 1y ago
That part is also cool. I'd like this in ruby too, e. g. where we could have tons of objects reflect on that state, and just resume work there. Everything is an object. Squeak everywhere, but to also retain the "scripting" (light) commandline approach. Nobody in smalltalk really understood why "scripting" is important. Python showed why.
- igouy 1y ago
  > also retain the "scripting" (light) commandline approach Smalltalk developers preferred to do their scripting within the Smalltalk IDE, so they could use their familiar tools. And then save their "scripting" as a text file ("fact.st"). $ cat fact.st Stdio stdout nextPutAll: 100 factorial printString; nextPut: Character lf.! SmalltalkImage current snapshot: false andQuit: true! And then "run" that text file ("fact.st") from the commandline. $ bin/pharo --headless Pharo10-SNAPSHOT-64bit-502addc.image fact.st 93326215443944152681699238856266700490715968264381621468592963895217599993229915608941463976156518286253697920827223758251185210916864000000000000000000000000
isr 1y ago
Adding to what you said. Squeak was a clean open source reimplementation (by the devs who did the original Smalltalk-80), so it's real history starts from there (ie: the 90s, not the 70s) One thing to keep in mind is that smalltalks all have the same ability to save & load code to & from disk, just as any other programming environment. But, they also have the option of just using the image to persist, and iterate on that. Squeak overdid that aspect of it, such that over time, it became hard to prune older side projects & and it just became increasingly bloated. Both Pharo & Cuis forked from squeak at about the same time. Pharo images are fully bootstrapped from a seed. Cuis is not quite there yet, but cuis from its inception went on a ruthless simplification drive (the number of classes in the system was reduced by about 500% !), so that it's base is effectively a "seed", and the rest of a cuis image is built up by importing projects (from disk & git) on demand. But yeah, curating a set of images over time is remarkably enticing & friction free. Even in cuis, I find I have to force myself to keep flushing changes to my own packages. Its not that the tools to use files are limited. In cuis, they're not. You can work on multiple different things WITHIN THE SAME IMAGE (changes to some builtins, a couple of your own projects, etc), and the system will keep track of what belongs where. So a couple of mouse clucks will fileout the relevant code to the relevant changesets & packages. And yet - just banging on the same image is just ... fun, easy, enticing.
- mpweiher 1y ago
  > Squeak was a clean open source reimplementation Small correction: they actually cloned/converted the Apple Smalltalk image, so those bits remained. The VM was created from scratch by writing it in Slang, a Smalltalk dialect that was essentially equivalent to BCPL and could be translated to C. https://dl.acm.org/doi/10.1145/263698.263754 https://dl.acm.org/doi/10.1145/263698.263754
  - isr 1y ago
    I didn't know that. So they didn't bootstrap an image from scratch, when they created the new VM?
    - mpweiher 1y ago
sandcat_ 1y ago
Unless you are indeed the original author from StackOverflow, it would be polite to attribute your comment: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319
mccoyb 1y ago
Are you `robject` on Stack Overflow -- or perhaps you might explain why you copied verbatim their response to https://stackoverflow.com/questions/3561145/what-is-a-smalltalk-image https://stackoverflow.com/questions/3561145/what-is-a-smallt... without citing your source?
aaronbrethorst 1y ago
Bizarrely, this makes me think of sourdough starter.
- hshdhdhehd 1y ago
  Anything like that. Dog breeds. Cultivations. Etc.
znpy 1y ago
Lisps have a similar concept: save-lisp-and-die: https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-lisp-and-die/ https://screwlisp.small-web.org/fundamental/sbcl-slime-eval-... In the world of containers, I wonder if one could use this feature to interrupt the execution of some computation, save the state somewhere (disk or object storage) and once the workload has been rescheduled on some other node, basically you boot up from your image file, re-establish network connections (if necessary) and just resume computation as if nothing happened.
- cben 11mo ago
  https://criu.org/ https://criu.org/ (Checkpoint/Restore In Userspace) is a long-running project (i remember the name over a decade ago) worth checking... Ooh, looks like they made progress in conveniently connecting it to containers.
weakfish 1y ago
Your comment is an uncredited quote of the following: https://stackoverflow.com/a/3617319 https://stackoverflow.com/a/3617319

adamzwasserman 1y ago

thanks for this article. as a history of languages aficionado myself, I appreciate both the content and the style. thanks again for the good reading

goodthink 1y ago

If you love the keyword syntax of Smalltalk, the reflectivity, the incremental compilation, live debugging in the environment, check out https://newspeaklanguage.org https://newspeaklanguage.org for theSmalltalk experience in the web browser. This is my favorite video by Newspeak's creator Gilad Bracha: https://youtu.be/BDwlEJGP3Mk?si=Z0ud1yRqIjVvT4oO https://youtu.be/BDwlEJGP3Mk?si=Z0ud1yRqIjVvT4oO

smj-edison 1y ago
That talk is fantastic! Just a note for anyone who's interested in Newspeak, it's more of a spiritual successor than a direct descendant of smalltalk (in a good way imo). It has some really slick features like: * No global import/export namespace (all imports are dependency injected, meaning capability based security is already baked in) * Nested classes instead of modules * No variable assignment (everything is a method call) * Mixins instead of inheritance * Synchronization and code updates as near primitives * Support for foreign objects through aliens and proxies, and foreign code can call newspeak objects through expats * A native serialization to file format * support for multiple overlapping type systems

frou_dh 1y ago

Since Smalltalk is effectively an OS unto itself, when we hear about the days of commercial applications being written in Smalltalk, how did deployment to end-users work? Were the users running, say, Windows and then the Smalltalk "OS" would be running on top of that, but in a sort of "kiosk mode" where its full OS-ness was suppressed and it was dedicated to showing a single interface?

pjmlp 1y ago
Easy, you make use of tree-shaking, which is actually older concept than minifying JavaScript, and add glue it together with an executable header that boots the image.
- uticus 1y ago
  I don't understand what "tree-shaking" means, can you point to a reference to give me a better understanding?
  - shrubble 1y ago
    Tree shaking in this context is not unlike a compiler: it looks at all the code and determines if it will ever run in the image, eliminating any unnecessary code and delivering the minimal image needed. The code is in a “tree” format like an AST, and you’re shaking the tree to test what can be removed.
  - nielsbot 1y ago
    You might know it as "dead code stripping": You remove all the things from the image that aren't used in your shipping app. Calling it "tree shaking" is web development term AFAIK.
    - munificent 1y ago
      > Calling it "tree shaking" is web development term AFAIK. I think that's backwards. Lars Bak and the other V8 folks came from the Smalltalk world and brought the "tree shaking" term with them as far as I know.

behnamoh 1y ago

Rants like this about languages which have little/no code snippets are the worst because they often sell you an idea w/o actually showing how it works in practice (because often times it doesn't work well in practice). talk is cheap, show me the fucking code, else don't waste my time.

Philpax 1y ago
The post is about the conceptual underpinnings of the system, not about the specifics of the code. It would be like judging the Linux kernel by the UI running atop it: it's largely immaterial to the discussion at hand.
Jtsummers 1y ago
> Rants like this What about this makes you think it's a rant? Is the author making an impassioned plea for people to use Smalltalk? Is he going off on a tirade about something?
kragen 1y ago
This article is more about the development environment than it is about the programming language, so it would be misleading to focus heavily on example code. A UI screencast video would be much more helpful.

kragen 1y ago

> You’ve likely used powerful coding editors and terminals. Smalltalk is just different. You are in the running environment. I've experienced this a few different times: with Microsoft BASIC-80 (and GW-BASIC), with SBCL and SLIME, with LOGO, with GForth, with OpenFirmware, with MS-DOS DEBUG.COM, with Jupyter, and of course with Squeak. It really is nice. It used to be the normal way of using computers; before memory protection, it was sort of the only way of using computers. There wasn't another memory space for the monitor to run in, and the monitor was what you used to do things like load programs and debug them. This approach continued as the default into many early timesharing systems like RT-11 and TENEX: there might be one virtual machine (memory space) per user, but the virtual machine you typed system commands into was the same one that ran your application. TENEX offered the alternative of running DDT (the debugger) in a different memory space so bugs in the application couldn't corrupt it, and that was the approach taken in ITS as well, where DDT was your normal shell user interface instead of an enhanced one. All this seems very weird from the Unix/VMS/Win32 perspective where obviously the shell is a different process from your text editor, and it's designed for launching black-box programs rather than inspecting their internal memory state, but evolutionarily it was sort of the natural progression from a computer operator single-stepping a computer (with no memory protection) through their program with a toggle switch as they attempted to figure out why it wasn't working. One of the nicest things about this way of working is halt-and-continue. Current versions of Microsoft Visual Studio offer sometimes halt and continue. In MBASIC you could always halt and continue. ^C halted the program, at which point you could examine variables, make arbitrary changes to the program, GOTO a line number, or just CONT to continue where you'd interrupted it. Smalltalk, SLIME, or ITS allows you to program in this way; if you like, you can refrain from defining each method (or function or subroutine) until the program tries to execute it, at which point it halts in the debugger, and you can write the code for the method and continue. This is an extremely machine-efficient approach; you never waste cycles on restarting the program from the beginning unless you're going to debug program initialization. And in Smalltalk there isn't really a beginning at all, or rather, the beginning was something like 50 years ago. Myself, though, I feel that the hard part of programming is debugging, which requires the experimental method. And the hard part of the experimental method is reproducibility. So I'm much more enthusiastic about making my program's execution reproducible so that I can debug faster, which conflicts with "you're in the running environment". (As Rappin says, "Code could depend on the state of the image in ways that were hard to replicate in deploys." I experience this today in Jupyter. It's annoying to spend a bunch of time trying to track down a bug that doesn't exist when you restart from scratch; worse is when the program works fine until you restart it from scratch.) So I'm much more excited about things like Hypothesis (https://news.ycombinator.com/item?id=45818562 https://news.ycombinator.com/item?id=45818562) than I am about edit-and-continue. Paul Graham wrote somewhere (I can't find it now) about how in Viaweb's early days he would often fix a bug while still on the phone with the customer who was experiencing it, because he could just tweak the running CLisp process. But you can do the same thing in PHP or with CGI without sacrificing much reproducibility—your system's durable data lives in MariaDB or SQLite, which is much more inspectable and snapshottable than a soup of Smalltalk objects pointing to each other. (#CoddWasRight!) Especially since the broad adoption of the Rails model of building your database schema out of a sequence of "migrations".

jaymce 1y ago

thank you for this great post. my nostalgia for the late 90's ParcPlace IDE is heavy.

jimbokun 1y ago

So Ruby is Smalltalk but amenable to modern development practices and tools like source control and off the shelf text editors, and usable for Unix scripts.

sebastianconcpt 1y ago
Basically yes.
antod 1y ago
Ruby is like Smalltalk, but with some Perl (for good or bad) mixed in too IMO.
vinceguidry 1y ago
Ruby isn't Smalltalk. The only thing Ruby inherited from it is the pure object model. Everything else was cribbed from other languages. Ruby doesn't have what makes Smalltalk great, the image-based development model. I'm making my own text editor in Ruby now, as I'm wishing for a more Smalltalk-like experience with it. There's just so much missing. Ruby has the reflective capability to enjoy a Smalltalk-like IDE, but Rails took over and drove Ruby in that direction long before anyone could cook one up. Which is a shame, IDEs that aren't Smalltalk / Lisp haven't graduated past the need for static analysis despite having 50 years to do so. Now it's the red-headed stepchild of languages due to no fault of its own.
- pjmlp 1y ago
  As someone that used Smalltalk via Smalltalk/V back in the day, I would nonetheles vouch that dev environments with direct connection to Smalltalk, like Java and .NET, are the closest we get to it in mainstream languages.
- dominicrose 1y ago
  It wouldn't be too hard to code a Smalltalk-like IDE for Ruby (compared to building a normal IDE), but the Ruby files would have to be structured in a specific way. It would not be possible to edit them using another IDE or text editor, unless you preserve the structure, but it would work well with Git. Another issue is that the developer would have to use two IDE's, one for Ruby and one for the rest. Everytime you access a class in the IDE, it could read the class's Ruby file into memory and split it into protocols (a protocol could just be a comment above the method name in the output Ruby file) and methods so that you can visualize them one by one the Smalltalk way. Or - I don't recommend it but - if you really want the Smalltalk experience then: - your code would be running in the same Ruby process as the IDE - any code change would be made in the live running process - store code in a database instead of files - version control from the database instead of git

sebastianconcpt 1y ago

Smalltalk is among the top most ergonomic ways to model concepts in a computer (capacity to model essential complexity) because the CPU got abstracted and compacted in the VM. But destiny made CPUs win and now we're using AI to chew their accidental complexity for us.

pjmlp 1y ago
The irony many of us used to joke about COBOL, and now we are entering book sized prompts into a little chat window.
- sebastianconcpt 11mo ago
  Haahahah true! Well put.

shevy-java 1y ago

I kind of like Smalltalk. Unfortunately syntax-wise Smalltalk is a huge set back and step back compared to Ruby. But Alan Kay's ideas are still epic today. I still don't think any language came close to his vision either; smalltalk definitely not. Ruby got closer but also no dice. Elixir kind of got close too (prettier "erlang") - to have fault-tolerant mini-CPUs ("objects", aka similar to biological cells). The problem is that even people with grand ideas, such as Alan Kay, are not automatically great language designers. Matz is a better language designer than Alan Kay, for instance, whereas Alan Kay has the better ideas. It's a trade-off. Note: I myself would not know how a language should look like that would follow Alan Kay's vision closer. It is definitely not smalltalk; it is also not ruby, though ruby is very good. I know I would suck as language designer, but as an improvement I would have a language similar to ruby (no, not crystal - crystal is a worse "ruby"), with a stronger focus on speed (perhaps have a second language that can be as fast as C here and be similar) and with a much stronger focus on what erlang brought to the table; that would get us close to, say, around 85% or 90%. And then add the rest that could fulfil Alan Kay's vision. Of course we need a specification too, because just saying "90% of his vision" is also pointless. I would perhaps start from erlang, retain the good bits, make it a modern variant of OOP (and OOP is also defined differently in different programming languages, so we need to define that term too, in the specification).

NetMageSCW 1y ago
How is the syntax a step back? Smalltalk is the ultimate orthogonal language - everything is consistent. Famously the Smalltalk grammar fits on a postcard and tells you everything you need to know to understand the system from the source code.
- travisgriggs 1y ago
  Yeah, I have no idea what shevy-java is talking about either. I would accept “huge step too far”, but not backwards. Unless your belief is that on the 8th day God gave mankind Algol syntax and said “let all languages look like this”. I’ll give that it can feel pretty foreign, like forth, lisp, erlang also do. These languages, imo, all use syntax where the form of the syntax binds nicely, reinforces even, with their computation models.

widikidiw 1y ago

[dead]

rbanffy 1y ago

> and I remember telling them that Smalltalk programmers were paid more. Also much happier. C++ back then is not the C++ you use today.

bowsamic 1y ago

I always found it too fragile. There’s a reason why smalltalk VMs have such good recovery features, it’s incredibly easy to brick your system when it’s all a network of objects, and I’m sure anyone who has worked in smalltalk has done so many times

shwaj 1y ago
I used to find it amusing that you could say `Smalltalk := nil` in the early days of Squeak, and poof! all the classes in your system are garbage collected. (I’m not sure that’s exactly what happened, probably the system crashed before garbage collection could happen. But it was definitely a guaranteed insta-crash).
igouy 1y ago
How can it be fragile if there are "such good recovery features"? Just restore unsaved changes when you launch the same image again. That's robust not fragile. https://drcuis.github.io/TheCuisBook/The-Change-Log.html https://drcuis.github.io/TheCuisBook/The-Change-Log.html
- bowsamic 1y ago
  The recovery features are external, and exist to solve a problem that is specific to smalltalk You may as well claim that computers are robust because you can just buy a new one. It has nothing to do with computers Pretty sure ST-80 doesn’t even mandate recovery features, which is pretty scary
  - igouy 1y ago
    Huh? The recovery features are built-in to Smalltalk implementations.

endlessvoid94 1y ago

In 2013 I built a smalltalk-esque system browser using ruby and TCL. It was fun: https://www.youtube.com/watch?v=2xC5B5t5Rq8 https://www.youtube.com/watch?v=2xC5B5t5Rq8

ripe 1y ago

Smalltalk-80 was also good for graphics programming. Around 1990, I was a graduate student in Prof. Red Whittaker's field robotics group at Carnegie Mellon. In Porter Hall, I was fortunate to have a Sun 3/60 workstation on my desk. It had a Smalltalk-80. I learned to program it using Goldberg & Robson and other books from ParcPlace Systems. The programming environment was fantastic, better than anything I have seen before or since. You always ran it full screen, and it loaded up the Smalltalk image from disk. As the article says, you were in the actual live image. Editing, running, inspecting the run-time objects, or debugging: all these tasks were done in the exact same environment. When you came into the office in the morning, the entire environment booted up immediately to where you had left it the previous day. The image had objects representing everything, including your screen, keyboard, and mouse. Your code could respond to inputs and control every pixel on the screen. I did all my Computer Graphics assignments in Smalltalk. And of course, I wrote fast video games. I used the system to develop programs for my Ph.D thesis, which involved geometric task planning for robots. One of the programs ran and displayed a simulation of a robot moving in a workspace with obstacles and other things. I had to capture many successive screenshots for my papers and my thesis. Everybody at CMU then wrote their papers and theses in Scribe, the document generation system written by Brian Reid decades earlier. Scribe was a program that took your markup in a plain text file (sort of at a LaTeX level: @document, @section, etc.) and generated Postscript for the printer. I never had enough disk space to store so many full screen-size raster images. So, of course, instead of taking screenshots, I modified my program to emit Postscript code, and inserted it into my thesis. I had to hack the pictures into the Postscript generation process somehow. The resulting pictures were vector graphics using Postscript commands. They looked nice because they were much higher resolution than a screenshot could have been.

travisgriggs 1y ago

I did Smalltalk for ~20 years as my primary. I’m a polyglot now, maintaining/implementing in C, Python, Swift, Kotlin, and Elixir. The thing (for me) about Smalltalk was the thought to code ratio. It was awesome. It had a pretty good balance of less is more. Where working in Swift and Kotlin feel like trying to navigate the many nuances of American football or cricket, Smalltalk was like playing soccer/football-sans-america. The syntax is simple. And the computation model is straitforward and simple. Elixir is kind of like that, computationally, a few simple concepts and everything builds on that. The saddest part about Elixir is that it ran with the whole do/end syntax. Drives me nuts. But I love that computationally, though different than Smalltalk, it’s like Smalltalk in that it’s a simple consistent model.

nanna 1y ago

Anyone working with a Smalltalk implementation?

z500 1y ago
I played around with Squeak this summer and made a few demos of showing how inserts and removals work in binary search trees and B-trees. I also wrote a tree-walking Smalltalk interpreter in F# and an implementation of the game of life for it. It was a blast.

lukehalko 1y ago

24 year old Smalltalk developer here (lmao). Thanks for this.

wolfejam 1y ago

Thank you for taking the time to write about Smalltalk. I have never used it, but I love all the old stories, cheers!