
The Early History Of Smalltalk (1993) - ohjeez
http://worrydream.com/EarlyHistoryOfSmalltalk/
======
goatlover
I really wonder what the software world would look like today if the Smalltalk
environment had predominated. It seems like various ideas from the Kay's group
get reinvented from time to time, but we it's not really mainstream. Even the
RAD tools from the 90s somewhat fell out of favor, partially due to the rise
of the web, which meant reinventing everything in the browser.

From hearing several talks by Alan Kay since then, it doesn't sound like
software quite turned out the way he envisioned it, but he still thinks
there's a better way to do things that's related to what he was thinking in
the 70s with a living environment of little computers sending messages to one
another. He's talked of the idea of modeling biological cells since then.

~~~
ttflee
Kay found the web distasteful.

“his conception of the World Wide Web was infinitely tinier and weaker and
terrible. His thing was simple enough with other unsophisticated people to
wind up becoming a de facto standard, which we’re still suffering from. You
know, [HTML is] terrible and most people can’t see it.”

[https://www.fastcompany.com/40435064/what-alan-kay-thinks-
ab...](https://www.fastcompany.com/40435064/what-alan-kay-thinks-about-the-
iphone-and-technology-now)

~~~
gambler
I assume you're posting this to show that Kay "doesn't get it"?

The more I learn about cutting-edge technologies of the 60s, 70s and 80s, the
more I'm convinced that he's entirely correct about the web and mobile. Most
developers today are obsessed with tooling and features. Almost no one seems
to care whether those tools and features have some kind of fundamentally valid
idea behind them.

Just look at the proliferation of HTTP security headers for a clear-cut
example of how this works out in the long run.

~~~
protomyth
Considering a whole Smalltalk VM is smaller than a lot of hero images on
websites, I get the feeling that Kay is correct. I would imagine a
containerized / sandboxed environment would have developed. I cannot see how
it could be worse than today.

~~~
TeMPOraL
> _I cannot see how it could be worse than today._

I fear it would turn out equivalent. The starting stack might have been
better, but the promise of money to be made and competitive pressures would be
the same. We would "worse-is-better" ourselves to roughly the same spot we're
in today. Bloat, tracking and clickbait.

Whenever I implore people to cut down on software bloat, I know what I'm
really asking is, "fight against the market, slow the decay down just a little
bit".

~~~
woadwarrior01
> I fear it would turn out equivalent.

Only some 30 or so years earlier, and who knows what we'd have come up with,
given such an early head start?

I work in the space of dynamic language runtimes, and it hurts me to see how
ideas pioneered by SmallTalk and subsequently the Self language[1] runtimes
haven't yet been adopted by some of the more popular dynamic languages today.

[1]:
[http://bibliography.selflanguage.org/_static/implementation....](http://bibliography.selflanguage.org/_static/implementation.pdf)

~~~
pjmlp
The worse part is the insistence of Ruby and Python to keep JITs away from
their canonical implementations.

Sure there is PyPy and the "C JIT" on upcoming Ruby, but they don't seem to be
widely deployed.

Maybe with Graal and J9 focus on increasing support for dynamic languages,
that will eventually change.

------
da02
I'm no programmer, but I remember back when Ruby 1.8.7 got really popular
because of Rails even though Ruby 1.8.7 was not that secure or stable compared
to other environments. (Yes, I know Ruby is better now.) But, I was wondering
why someone didn't take Smalltalk (or Squeak or Pharo) and find a way to make
it more popular? We have Node, Electron, Java, etc. So why not Smalltalk?
Wouldn't it be easier to develop, run faster, and be more cross-platform than
those popular environments? Is there something in Squeak or Pharo holding it
back?

Maybe the next Tim-Bernes Lee could use it to develop new protocols + a
browser and create a safer and secure WWW-alternative?

~~~
hboon
The short answer is it's different and unfamiliar to most newcomers:

1\. The image-based paradigm [1] holds it back. Using Smalltalk, there's quite
a change in development style, the existing development tools (text editors,
version etc) mostly don't work [2], and deployment is at least slightly
different.

2\. The unfamiliar UI (mostly Morphic) looked very different.

3\. The different (but incredibly simple) syntax looks strange to newcomers.

There are paid tools that fix some of these, but they never quite caught on
with lots of momentum, and they were used mostly in bigger enterprise shops.
The biggest might have been IBM VisualAge (for Smalltalk), which later morphed
into IBM VisualAge for Java and then Eclipse.

[1] The image-based paradigm is really really great. If you haven't
experienced it before, give it a go. It's worth it even if you are never going
to use Smalltalk. [2] There's been effort to get git to work. I haven't been
tracking it, but this was only in the recent few years.

~~~
int_19h
How exactly does the image-based approach mesh with version control like git?
I'm trying to picture a possible approach, but failing.

~~~
hboon
Smalltalk has a concept of changesets. They can approximate diffs/patches.

And while the code is exposed in code browsers (some kind of IDE/text editor
window) in the image, and not exposed as text files, they certainly can be. So
I'd imagine it's just a matter of exposing those into files (or still classes
and methods as separate "entities") and commit those into git with a bit of
markup.

~~~
int_19h
But the whole point of the image approach is that it's not just code, but also
data, no? It would seem that it'd require some multiple-file text-based
serialization format for images that would include both code and data, and
would split it into files in a way reflecting the typical change patterns...

~~~
hboon
Code + data + live instances of the code/objects. Like I said, I haven't been
tracking how they do it, but I'm guessing that they only track code. If you
want to be able to deploy an image directly, you either have to write scripts
(and check those in too, either standalone "scripts" or class-side
initialisation) or save the entire image and deploy that.

Saving the development image and deploying it directly is also not done that
often because the development image contains things that can stripped off,
e.g. development tools or object instances you use during development. Squeak
and Pharo is usually distributed in various flavours, loosely — full and
minimal images (I might not get the names right). So you take the former and
install packages for development and the latter + packages for deployment, or
you can build your own from the minimal image.

But through this you can see how different it is and while it's great in many
ways, some of the differences make it harder for newcomers to start and harder
for everyone to use it in production.

I forgot to mention Dolphin Smalltalk [http://www.object-
arts.com](http://www.object-arts.com). It used to be a paid product, running
on Windows. It has been open source for a few years now. I think product sales
wasn't sustainable for the owners. But for several years, it is was the best
Windows thick client development tool. It's a great example of Smalltalk well-
done. You have the same image-based approach, but the windows are all native
and familiar looking, so basically a multi-window development IDE. There's a
deployment tool that helps you to strip down your image and build it into an
exe (which was basically the Dolphin Smalltalk image + the shrunk image). It
might still run, maybe it looks a bit outdated, it was actively developed
until 2004 or so. If it still works, it's a wonderful way to experience
Smalltalk.

------
z3phyr
I installed pharo to see what this smalltalk was all about. At first, I was
confused with what I saw. I was expecting to set up a compiler build pipeline
and an emacs mode, but it booted into some kind of operating system graphical
shell. I realised then that smalltalk is more than a programming language, its
a full IDE + OS

A shame that I couldn't continue toying with it (that was before my computer
got reformatted)

~~~
huntie
I had the same reaction. Once I realized what it was, I had no idea what to do
with it though. Anyone know of something that shows you how to get started or
shows off its capabilities?

~~~
krylon
[http://books.pharo.org/](http://books.pharo.org/) has a bunch of books. Pharo
By Example is a nice starting point.

------
shalabhc
To get another taste of the kinds of systems possible in the 70s, in spite of
the constraints, see Kay's demo of a revived Smalltalk-78 system:
[https://youtu.be/AnrlSqtpOkw?t=3m3s](https://youtu.be/AnrlSqtpOkw?t=3m3s) (I
believe this system is about 10-20K LOC software in total)

Notes about the the revival are here:
[https://freudenbergs.de/bert/publications/Ingalls-2014-Small...](https://freudenbergs.de/bert/publications/Ingalls-2014-Smalltalk78.pdf)

------
AdmiralAsshat
Smalltalk is one of those things I want to learn, but resources seem sparse
and everyone seems to be pushing their own particular flavor of Smalltalk. Do
I go with Amber Smalltalk? Squeak? Pharo? Are they all sufficiently similar
that I can move from one to the other without re-learning everything?

I'm honestly considering just going through the GNU Smalltalk manual on the
terminal and worrying about all the graphical VM's later.

~~~
arnsholt
I'd just go with Pharo. _Pharo by Example_ is a good intro book, and it's
still under development. Also, I would strongly suggest that you go with
something like Pharo where you run the image on your desktop. Part of the
reason I really, really like Smalltalk is how working in the image changes
your workflow. As I understand it, GNU Smalltalk is still write file-compile-
run, which is not at all how you work in Smalltalk (or at least not I or my
colleagues do), instead I find that Smalltalk encourages a very iterative
style since you're generally working directly on a running instance of your
program.

It takes a bit of getting used to the development environment in the image
(and setting breakpoints by inserting `self halt` directly into a method feels
really dirty initially), but now that I've been working in Smalltalk for a
while I find I prefer it to "normal" development, which is still very much
"hand in your stack of punch cards and wait for the result to come back"-way
of development.

------
machinecoffee
Never realized how much Smalltalk influenced Objective C until I looked a bit
more into it.

See e.g. object initialization here:
[https://www.gnu.org/software/smalltalk/manual/html_node/Inst...](https://www.gnu.org/software/smalltalk/manual/html_node/Instance-
methods.html#Instance-methods)

And the notion of passing messages to an object.

------
dang
Plenty of submissions but only a few short discussions:

[https://hn.algolia.com/?query=The%20Early%20History%20Of%20S...](https://hn.algolia.com/?query=The%20Early%20History%20Of%20Smalltalk&sort=byDate&dateRange=all&type=story&storyText=false&prefix&page=0)

~~~
protomyth
I get the feeling it slips off the front page by the time folks have read the
whole thing.

~~~
teddyh
Maybe the front page algorithm should be adjusted to take this into account?

