
Design Principles Behind Smalltalk (1981) - joubert
https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html
======
jasim
If you're tired of hearing about the virtues of Smalltalk (like I was at one
point) and ask "if it is so good, why isn't it popular?", then watch @deech's
talk (Aditya Siram) - "What FP can learn from SmallTalk" \-
[https://www.youtube.com/watch?v=baxtyeFVn3w](https://www.youtube.com/watch?v=baxtyeFVn3w)

I think it is the most accessible explanation of the marvel of Smalltalk, for
those who were not lucky to work with it during the late 80-90s.

Also I think Ruby is the mainstream language that is closest to Smalltalk
today, with the idea that everything is an object and late-binding as much as
possible.

One thing I can't help point out is that Smalltalk / Alan Kay's vision of
interconnected objects forming a recursive computing system is not the only
"true" vision of OO out there. From Simula thru C++ and then Java and C# also
are object-oriented (or class-oriented for those who care about the
distinction), but they are statically typed. It is also OO because OO is a
word, not a mathematical definition, and when people talk about OO, there is
enough similarity between all these variations that we consider all of them to
be in the same camp. Plus with the growing move towards strict static typing
even in interpreted languages, which I think is driven by actual industry
needs and programmer preferences than external marketing, it is becoming a
disservice to think of statically typed OO languages as being somehow inferior
to the true ideal of object-oriented programming.

~~~
AdmiralAsshat
I'd be much happier if someone could instead just provide a version of
Smalltalk that everyone can agree on.

"Use Squeak!"

"No, Squeak is old! Use Pharo!"

"Pharo doesn't adhere to the Smalltalk standard. Just use gnu-smalltalk in a
terminal!"

Never have I seen such a self-defeating community. If the Smalltalk community
wants it to be anything more than a historical curiosity, I beg it to form
some kind of standards committee and agree on a common implementation so that
I can _learn_ Smalltalk without worrying that I'm studying a dialect that is
not mutually intelligible to the other implementations.

~~~
cxr
Gilad Bracha gave an interesting talk (or in his words, "[maybe] the best talk
I ever gave") called "Utopia and Dystopia: Smalltalk And The Wider World",
where he posits a universe where the Smalltalk community has recognized and
proactively fixed this problem, along with some other problems that outsiders
see when they look at Smalltalk.

[https://www.youtube.com/watch?v=BDwlEJGP3Mk](https://www.youtube.com/watch?v=BDwlEJGP3Mk)

His blog is also great to follow as a general programming blog, and as it
turns out, he wrote a post just two weeks ago where he rehashes some of the
content.

[https://gbracha.blogspot.com/2020/05/bits-of-history-
words-o...](https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-
advice.html)

~~~
pjmlp
I loved the talk, thanks for sharing it.

------
madmaniak
Principle 1 "If a system is to serve the creative spirit, it must be entirely
comprehensible to a single individual."

Globally we go in every aspect against this principle going into narrow
specialisations. Such a movement is made on a purpose by the flow of money of
central printers/powers, and the result is according to the principle - luck
of creative spirit of single individuals. The tools which we are learning and
the way we are trained is against creativity.

In last 10y perspective is visible how the industry is mislead in wrong
directions by the biggest players. So don't ask why we don't use Smalltak-like
technology in 40y.

~~~
coliveira
To expand on your comment, the reason why we don't use simple and
understandable tools like Smalltalk is that the industry is not interested on
this kind of simplicity. For them it is much better to pay thousands of people
to work on different, unrelated things and them put these things together at
all levels: hardware, OS, software, etc. The resulting system is impossible to
understand by a single person, and works only because of the continuous
struggle of thousands of people to make it work. But this is positive for the
industry behind this architecture: every year they will create new components
to fix flaws, introduce new ones, and keep the wheel of the technology
industry running.

------
codr7
To me Smalltalk has the same kind of beauty to it as C, it's pure and simple.
They both allow me to keep the entire language in my head, which means I can
spend all my energy on solving real problems.

And the interactivity is awesome once you wrap your head around it. If you
haven't experienced it, you most likely won't see the point since you assume
much of what it enables is impossible.

I'm still not sold on the image-based dev cycle, Common Lisp allows the same
level of interactivity and even more power without giving up files.

They killed it by trying to keep selling it for profit at a time when free
alternatives started appearing.

------
mucholove
The best Smalltalk is Objective-Smalltalk.

It's a beautiful way to go up and down the ladder of inference.

Basically—Objective-Smalltalk is based on Objective-C which is a superset of
C. It's like having the two worlds coming together at the same time.

Does it miss some of the beauty of a totally integrated system like Squeak?
Sure. But that's kind of the beauty too. Can we make an Objective-Smalltalk
takeover?

[http://objective.st](http://objective.st)

~~~
cxr
I was recently re-watching the old demo of 280 North's Atlas, an Interface
Builder-inspired tool. And when I think about it, it also seems a little
strange that object lovers and all today's disaffected Mac fans could pick up
the pieces of GNUStep and start building out a usable replacement for
themselves as a reaction against the deterioration and inevitable demise of
the Mac, but that isn't materializing. There's something, I think, in the Mac
developer psyche that says they're responsible for building their own discrete
little apps and doing a lot of polishing on them, but they're completely
uninvolved in shaping or otherwise working on the environment/platform itself.
This is the difference between Mac folks and Smalltalkers.

[https://vimeo.com/11486446](https://vimeo.com/11486446)

~~~
mucholove
Necessity is the mother of invention! If the demise of the Mac / Cocoa API's
is nigh—expect there to be some work on it.

This guy is doing some interesting work: [https://mulle-
objc.github.io](https://mulle-objc.github.io)

One more factor: my guess is that GNUstep picked the LGPL—which although more
permissive than the GPL—turns away the money / status seeking Mac folks.

~~~
cxr
GNUstep being LGPL has as much adverse impact on developers as Apple's
implementation being proprietary. (I.e., none.) It's the _LGPL_ after all, not
the GPL.

GNUstep has also moved to GitHub and seems to favor the the MIT license
nowadays where possible (e.g., libobjc2)[1][2].

1\. [https://github.com/gnustep/libobjc2](https://github.com/gnustep/libobjc2)

2\. [http://etoileos.com/dev/licensing/](http://etoileos.com/dev/licensing/)

------
coliveira
Smalltalk can be described concisely as a graphical UNIX: a small set of
computational mechanisms, designed to be general and interoperate for the
construction of larger systems. Unfortunately, the GUI industry was inspired
but never decided to use smalltalk itself as its foundation since C/UNIX
already existed, providing higher performance for the hardware available at
the time.

~~~
mpweiher
> Smalltalk can be described concisely as a graphical UNIX

Or Unix as a closet Smalltalk...

"Liberating the Smalltalk lurking in C and Unix" by Stephen Kell

[https://www.youtube.com/watch?v=LwicN2u6Dro](https://www.youtube.com/watch?v=LwicN2u6Dro)

------
jbverschoor
What I miss these days is interaction with applications. Yes, rest-APIs are
fun and all. And both Apple and Microsoft have their component model out
there, but other developers don’t take the time.

That, combined with the Superbad tools of patching things together make it
almost useless these days.

It’s unfortunate, because there’s so much you can do with good
interoperability.

------
saadalem
What if all Smalltalk objects had an URL? It could provide simple (and
complex) network services to any computer on the Internet. There is a profound
lack of ambition around software and Operating Systems.

~~~
tgbugs
Work on this has been done. See Polymorphic Identifiers: Uniform Resource
Access in Objective-Smalltalk [1].

1\. [https://www.hpi.uni-
potsdam.de/hirschfeld/publications/media...](https://www.hpi.uni-
potsdam.de/hirschfeld/publications/media/WeiherHirschfeld_2013_PolymorphicIdentifiersUniformResourceAccessInObjectiveSmalltalk_AcmDL.pdf)

~~~
mpweiher
In fact, the Objective-Smalltalk site
([http://objective.st](http://objective.st)) is served by an Objective-
Smalltalk web server, with the incoming URLs converted the PIs and then
dispatched via nested Storage Combinators. (
[https://dl.acm.org/doi/10.1145/3359591.3359729](https://dl.acm.org/doi/10.1145/3359591.3359729)).

:-)

------
Viliam1234
> No component in a complex system should depend on the internal details of
> any other component.

Unfortunately, the internal details of other components are important for
performance. It is not enough to know that something is e.g. an ordered
collection; I also need to know whether accessing items randomly has an O(1)
or O(n) cost. Increasing the complexity from linear to quadratic is not a
minor detail that a faster processor would solve.

But when you start caring about performance, suddenly you don't deal with
ordered collections, but with arrays, linked lists, red-black trees, and
whatever. Then you also get unspecified ordered collections returned from
other modules, and you wonder whether it is okay to use them as they are, or
whether you should pay a one-time price to convert them to a more efficient
collection. And somewhere, a new programmer is crying: "I just wanted to
create a list containing dozen numbers, why do I have to deal with all this
complexity?"

------
e12e
Always thought the ideas behind lively kernel was interesting - web browser/js
engine as the run time, webdav as the persistence layer.

[https://lively-kernel.org/](https://lively-kernel.org/)

Looks like they are on the third iteration now:

[https://github.com/LivelyKernel/lively4-core](https://github.com/LivelyKernel/lively4-core)

[https://lively-kernel.org/lively4/lively4-core/start.html](https://lively-
kernel.org/lively4/lively4-core/start.html)

Apparently now using git for persistence.

------
johndoe42377
Boy, I love this stuff.

Two subtle but necessary and principal clarifications.

1\. A reference is not "from that time on". The notion of time must be
irrelevant here. The reference is immutable until the process (scope) ends,
not in time, just ends.

2\. Objects are unnecessary. References and the abstraction principle are
necessary and sufficient. Duck-typing is abstraction without an object.

This is what Haskell type-classes captured - to be a _____ is to be able to
______.

Greeks and Platonism plagued OO minds.

------
d3ckard
Very interesting read, though it hurts me to see optimism in this paper mostly
unwarranted from today’s perspective.

~~~
shawnz
Was it unwarranted?

> While the presentation frequently touches on Smalltalk "motherhood", the
> principles themselves are more general and should prove useful in evaluating
> other systems and in guiding future work.

Indeed the principles of Smalltalk went on to guide the design of many future
languages

------
PeterStuer
I liked Smalltalk for some aspects, but I never liked the 'Message to Object'
restriction. It dispatches based on the receiver's Class.

I always preferred the Generic Functions of CLOS, that allows capturing the
semantics of an operation outside the stranglehold of the Single Object
pattern.

~~~
jecel
If you don't mind dealing with dead projects, you might enjoy Slate as a
Smalltalk with multimethods:

[https://github.com/briantrice/slate-
language](https://github.com/briantrice/slate-language)

------
boshomi
Memento from Internet Archive as of 2007-01-01 16:04:21

[http://web.archive.org/web/20070101160421/http://users.ipa.n...](http://web.archive.org/web/20070101160421/http://users.ipa.net/~dwighth/smalltalk/byte_aug81/design_principles_behind_smalltalk.html)

------
mlang23
I have never worked with a true Smalltalk. However, I am using a Smalltalk-
inspired language pretty extensively, SuperCollider.

I never really dived into a comparison, since I am lacking real Smalltalk
knowledge. However, I'd be interested what someone who knows both languages
things about SC compared to Smalltalk.

~~~
escales
As a specialised music-programming language and audio server, Supercollider
outclasses Smalltalk — and most, if not all, other music computing systems. As
a high-productivity general-purpose programming language, Smalltalk is
considerably more sophisticated and capable.

Supercollider has two distinct components – a backend software synthesizer
(audio server) and a frontend combining an IDE and an interpreted language
which draws strongly on Smalltalk, but is written in a C-like syntax. The
front and back ends (typically, but not always, running on the same machine)
communicate using the lightweight OSC protocol. It is perfectly possible to
use Smalltalk or indeed any other language as an alternative front end to
Supercollider audio synthesis engine.

The Supercollider language (sclang) mirrors Smalltalk very closely in some
respects, but also has major differences. As in Smalltalk, Supercollider has a
metaclass structure and closures which are used to implement control
structures. Supercollider makes extensive use of continuations to flexibly
sequence musical materials, but is file-based rather than image-based.
Smalltalk has far more sophisticated support for refactoring, debugging and
programming. For example, it is possible to inspect, manipulate and restart
using live objects in the stack after any exception. Smalltalk has a much
simpler syntax, a rich IDE, and a wide variety of specialised tools for
browsing, refactoring and inspection. In Smalltalk, the complete source code
for the whole system is available at all times. Smalltalk has powerful and
well documented tools for reflection and modifying the system or changing the
model of computation (such as selectively modifying the doNotUnderstand method
- though in fairness this is also technically possible in Supercollider). More
generally, Smalltalk parsimoniously exploits a small number of principles with
ruthless consistency and clarity, making it relatively easy to learn,
understand, and if desired modify, any part of the system. Supercollider has a
different aim, to provide the maximum power and flexibility for carrying out
music purposes to the highest quality. This sometimes leads to trade-offs
between clarity and power, and some frameworks whose details are hard to
understand. In their contrasting ways, both are outstandingly engineered,
seminal languages.

~~~
mlang23
Wow, thanks for such a detailed answer. I was actually only refering to
sclang. I am well aware that the rest (scsynth, and OSC communication) is very
much related to audio synthesis. What you tell about SmallTalk somehow reminds
me of Common Lisp or even the stories you hear about Lisp Machines. THanks
again for taking the time to write up such a verbose reply, I really
appreciate that.

------
ChrisMarshallNY
Smalltalk became Objective-C.

Objective-C has informed Swift.

Long live Smalltalk.

~~~
ibiza
Each link in this lineage is tenuous. Objective-C took Smalltalk's call
syntax, its class def (in a sense?), and its late fn binding, but little else.
It certainly didn't take what made Smalltalk, Smalltalk. Full disclosure: I
really like _both_ languages.

I struggle to find the mapping between Objective-C and Swift, other than "same
company" and must preserve backwards compatibility.

Smalltalk became Squeak. Long live Squeak. :)

~~~
ChrisMarshallNY
I think that Swift got a lot of its "philosophical" structure from ObjC.

After Swift was released, I understood why ObjC 2.0 was written the way that
it was. It was modified to allow the standard libraries and SDKs to transition
to Swift.

I remember coming from C++ (CodeWarrior/PowerPlant), and encountering ObjC,
and going "Whiskey Tango Foxtrot?".

After a while, though, I got used to it, and actually started to enjoy ObjC,
in a way that C++ never got me.

I enjoy Swift, even more.

After years of writing code in languages I didn't really like (C++/PHP), Swift
is something that I actually enjoy. I suspect that Smalltalk, and its affect,
are responsible for the "enjoyment" factor of Swift.

I consider most of the lineage to be "in spirit," more than "in detail."

It's quite easy to shoot holes, if we get particular.

