I'm sad to say that it has nothing at all to do with Smalltalk.
Its topic is an attempt to make all programs that run in Linux (and similar systems) able to access each others' data structures, including each others' functions, using new work built on the debugging facilities that unixes already have. The big picture is that so-called static languages actually provide enough information (via debugging mechanisms) so that OTHER languages can treat them as if they were dynamic languages, and (really fun big picture stuff) can potentially automate discovery of their structure to the extent that all languages can interoperate without FFIs.
This sounds like the kind of interoperability that I have been looking for ever since I started programming fifty years ago. I wonder if anything will ever come of it.
Smalltalk was originally a language for children, similar to Logo.
It is unfortunate that its youth was not thus preserved.
"Smalltalk was created to investigate teaching programming to children. Understandably, it's a very small and simple language, the simplest of the major programming languages."
Having read the book Dealers of Lightning about Xerox PARC and Kay,I think Smalltalk 72 was the original smaller simple language, with which children were taught.
Then others at Xerox added more professional stuff, the kind programmers would want, which resulted in Smalltalk 76 and so on. These were not as approachable for children anymore allegedly.
Nowadays there's Squeak which is a Smalltalk implementation, which influenced Scratch I think (first version of Scratch was written in Squeak).
Search the internet for Adam Kay's documents on Squeak and educating children, helps to put on context what he had in mind (if you, like me, just install Squeak and expect a stunning tutorial... it's not like that, at least I didn't find).
Kay also said, having an IDE only takes you to the 70s from the 60s too... So there's work to be done yet.
There's even a pretty fun documentary on the Squeak project, with Seymour Papert, Alan, and Jerome Bruner. [0] Or, if you want to go further back, read the original "Personal Dynamic Media" papers.
Smalltalk only has 6 keywords and everything is done via sending messages to objects. How many language constructs and keywords does Lisp have?
Ultimately different philosophies are at work. Smalltalk makes many objects and has the power to introspect on them (classes are also objects), Lisp has facilities to introspect and do meta programming using macros, making new keywords, so of course the language will grow. That is the whole point. Growing a language for solving specific problems. Smalltalk makes new objects instead.
If we’re counting small numbers, Lisp also has a small number of “keywords”, nine:
quote atom eq
cons car cdr
lambda label define
Others put this number at five or seven. I guess you can express define as a function of label and lambda, so you drop to eight, but I don’t know how you get to seven, let alone five.
Not sure how Smalltalk measures up in that regard, but wouldn't one also need to count things like define-syntax and all things, which are built-in for defining macros? I guess that would only be fair, because that gets Lisps up to the same power level as Smalltalk with its introspection and ability to create classes at runtime, since they are objects as well.
Then there are things like "What is the syntax for a vector?" and all kinds of reader syntax with "# + something", depending on the dialect/specific lisp language, I guess.
Digitalk's Smalltalk V was pretty good at this. You got a nearly empty v.exe file which called a bunch of .dll files which contained the various parts of the standard image. Anything you did yourself would be added to v.exe so when you were ready to ship you just had to send the client that plus a subset of the .dll files (enough for your application to run, but not the development environment).
For a short while in the 1990s Smalltalk V/Win was available at no cost with the name Smalltalk Express.
I'm sad to say that it has nothing at all to do with Smalltalk.
Its topic is an attempt to make all programs that run in Linux (and similar systems) able to access each others' data structures, including each others' functions, using new work built on the debugging facilities that unixes already have. The big picture is that so-called static languages actually provide enough information (via debugging mechanisms) so that OTHER languages can treat them as if they were dynamic languages, and (really fun big picture stuff) can potentially automate discovery of their structure to the extent that all languages can interoperate without FFIs.