
Smalltalk-72 Instruction Manual (1976) [pdf] - mpweiher
https://pdfs.semanticscholar.org/442f/0f5205c7d4674612204ecc8357367dabbf45.pdf
======
woadwarrior01
While I was working on optimizing the Python runtime (internally, at a FAANG
company), an unexpected resource that I learnt a ton from was the SmallTalk
Blue Book[1]. A lot of the lessons learnt from implementing Smalltalk and Self
runtimes in resource constrained computing environments available back in the
70s and 80s are still very relevant today.

One of my former colleagues from that team used to often joke about how the
Self[2] team was effectively cheating with hidden classes and inline caching
in the late 80s, because they had workstations with 64 megs of RAM whilst
almost everyone else had to contend with a megabyte or less of RAM.

[1]:
[http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook....](http://stephane.ducasse.free.fr/FreeBooks/BlueBook/Bluebook.pdf)

[2]: [http://bibliography.selflanguage.org/_static/self-
power.pdf](http://bibliography.selflanguage.org/_static/self-power.pdf)

------
methehack
I have the orange (the envirnoment) and purple (the langauge) Smalltalk-80
books. They're really lovely and immensely thoughtful. I know everything is
all functional right now, but I still feel Smalltalk never got it's day in
court. I don't think most devs realize what's actually there. It's amazing
tech that's never been widely enough appreciated. I think old Smalltalkers who
know are just sad about it.

------
thelazydogsback
I tried writing a ST for the Z-80 and then the first PC, but I bit off a bit
more than I could chew considering I wasn't taking the minimal language
approach (like "A little Smalltalk") but was trying for the self-bootstrapped
whole VM and I had no image available so I had to try and wire everything up
in a magical state -- still a great exercise though. I've tried ST on
Tektronix and the Apple Lisa.

A GUI dev. environment ahead of its time, though "image save"-based
development with classes strewn around everywhere isn't the best model for
development, nevermind delivery where you never know what your code is going
to be running next to. ST is also largely to "blame" for single receiver
dispatch, and to a less extent the overuse of implementation inheritance, as
most languages for performance don't have messages as first-class objects
meaning that delegation becomes harder so inheritance was used over
composition in most OO languages following. (Though you can use monkey-
patching in langs that support it.)

~~~
igouy
> …though "image save"-based development with classes strewn around everywhere
> isn't the best model for development…

What do you mean "classes strewn around everywhere" ?

"Smalltalk-80 The Interactive Programming Environment" chapter 23 explains the
different ways class definitions, comments and methods could be saved to text
files; and filed into a vanilla image in a standard build process.

[http://sdmeta.gforge.inria.fr/FreeBooks/TheInteractiveProgra...](http://sdmeta.gforge.inria.fr/FreeBooks/TheInteractiveProgrammingEnv/TheInteractiveProgrammingEnv.pdf)

> …nevermind delivery where you never know what your code is going to be
> running next to.

Do you mean you never know what non-smalltalk code would be running on the
same machine as the smalltalk code ?

Why would that be a problem ?

Why would that be more of a problem with a Smalltalk image than with .pyo ?

~~~
monocasa
The issue on Smalltalk 80 was that diffing and combining images was a huge
pain. There wasn't a clear seperation between the system itself and whatever
you were working on. On top of that, Smalltalk VMs generally assumed that they
were the only Smalltalk VM running on a given system so it's not like you
could run the different apps like different containers or processes, or
whatever. Additionally Smalltalk pretty heavily encouraged making
modifications to the system classes as part of the porting process.

So, not the OP, but my answers to your questions:

>What do you mean "classes strewn around everywhere" ?

It was rarely clear where your classes ended, and the system ones began, which
got in the way of distribution, particularly if you wanted to run on different
hardware. It was surmountable, but a pain in the ass compared to Unix (which
is not really the world's highest bar, particularly at the time).

> Do you mean you never know what non-smalltalk code would be running on the
> same machine as the smalltalk code ?

> Why would that be a problem ?

It's what's versus running in the same VM image, including modifications to
the system classes themselves. There's no good boundary between apps other
than they don't have references to eachother.

>Why would that be more of a problem with a Smalltalk image than with .pyo ?

Because a .pyo only has the classes that pertain to what it's trying to do,
and doesn't stop you from running other python instances at the same time.
Imagine if there was only one python vm allowed to run at once, the source was
an afterthought (and considered not idiomatic), and pyos were basically just
memory dumps each with their own unique monkey patching of system classes.

There's a good chance that squeak/pharo have done work to address this, but
that was the state of the world for Smalltalk 80. It was designed right at the
cusp of collaboration on design of personal computer apps, and it shows in the
overall design.

~~~
ljw1001
> There wasn't a clear seperation between the system itself and whatever you
> were working on.

Another serious issues is that people routinely modified the system classes.
Once you had imported a few large libraries there would be any number of
changes to classes like Object that would cause the libraries to mis-behave if
they went missing or were changed. As nice as it was to be able to mod
anything, I think it hurt reliability.

~~~
igouy
_> …people routinely modified the system classes._

People!

What can be done?

— reject libraries that change system classes?

— accept that library version G is said to work with system version F, and may
not work with system version Q?

— accept that along with library source code comes the burden of resolving
library conflicts?

------
JCoder58
Here is a long list of free online Smalltalk books

[http://stephane.ducasse.free.fr/FreeBooks.html](http://stephane.ducasse.free.fr/FreeBooks.html)

------
apaprocki
Dan Ingalls himself presenting his continued work in the browser at JSConf US
2012 (whole conf was packed in, standing-room only):
[https://youtu.be/QTJRwKOFddc](https://youtu.be/QTJRwKOFddc)

Surprised that video has so few views!

~~~
sumim
Here is his Smalltalk-72 implementation on the Alto/Nova emulator on the
LivelyWeb!

[https://lively-web.org/users/Dan/ALTO-Smalltalk-72.html](https://lively-
web.org/users/Dan/ALTO-Smalltalk-72.html)

------
anton96
Oh cool, I will compare with my smalltalk-80 book that just arrived today!!

