
Bits of History, Words of Advice - miki123211
https://gbracha.blogspot.com/2020/05/bits-of-history-words-of-advice.html
======
mikl
From my understanding, to adopt Smalltalk, I’d have to give up my editor, my
SCM, my code review practises, my deployment strategies, my whole way of
working. Learning a new language is already a big ask. If you then also
require the would-be adopter to change everything around the language,
everything about how they work, don’t be surprised if people choose something
else.

I think a modern parallel is darklang.com. It might be great, but it faces the
same resistance for the same reasons.

You can do some amazing things if you integrate everything into a big
monolith, but that also makes it impossible to adopt a technology part-way.

~~~
projektfu
I’m now curious about implementing a long running Smalltalk server that can be
accessed using command line tools and traditional editors, with some graphical
or web based tools to implement inspectors and other UI.

~~~
isr
FYI (hope this helps):

\-
[https://dmitrymatveev.co.uk/shampoo/](https://dmitrymatveev.co.uk/shampoo/)

\- [https://github.com/dmatveev/shampoo-
emacs](https://github.com/dmatveev/shampoo-emacs)

~~~
projektfu
Gorgeous, thanks.

------
cies
The article does not mention Smalltalk's uncommon syntax as a deal breaker.
Not many langs with uncommon (not C-like) syntaxes have managed to become
widely used. I think that that is known to those who ordered investment in
Java and C#.

To me Smalltalk feels too integrated, which is a problem for me. I like a
language that's small in it's (open source) core, with lots of (competing)
integrations (IDE, testing, profiling) available. It helps me not to feel
locked-in to an ecosystem.

~~~
skohan
Python is one of the most widely used languages out there and doesn't have
C-like syntax really

~~~
dahfizz
Python is not exceptionally C-like, but a typical python script is readily
understood by someone familiar with C. Smalltalk, on the other hand is not.
This LOC is from the wikipedia example page:

#($a #a "a" 1 1.0)

There's no way a C programmer can know what that means without looking it up.

~~~
skohan
Is that a typical line of smalltalk? I mean if this is representative I can
understand why C-like syntax won. Surely a language with descriptive names,
and a call syntax resembling:

    
    
        subject.verb(arguments)
    

Is more intuitive than the example you've given.

Of course it's also quite possible to write an equally cryptic line of C code.

~~~
scroot
No, this is not a typical line of Smalltalk. That would be considered a very
sloppy array indeed. I think it's just there to demonstrate the different
literal notations in the language.

Smalltalk is actually quite readable in practice, though the keyword syntax
seems to throw off experienced programmers from other languages. It's worth
noting that the language was originally tested on children, so it was also
designed to be easy to read and learn.

The equivalent of your C code above could be something like:

    
    
        MyObject doSomethingWith: anArgument

~~~
PaulDavisThe1st
aka Objective C

:)))

------
x87678r
It failed because it was too expensive. 25 years ago I was looking at job in
an elite project that ran smalltalk. I didn't get it but liked the language
enough to investigate using it in my next job. The cost was crazy, like 1-2
months wages which was hard to justify when hardly anyone else used it. If it
were the same price as C++ environments/libraries (yeah remember when you had
to pay for container libraries) it would have been a hugely successful
language.

~~~
Rochus
I don't think it's the main reason. I rather share these views:
[http://www.wirfs-brock.com/allen/posts/914](http://www.wirfs-
brock.com/allen/posts/914). Smalltalk beyond that suffers from the same issues
as any dynamically typed language. You quickly lose track when projects get
bigger and many problems that a compiler could easily find are discovered much
later. I used ST in the nineties and then switched completely to C++ and other
languages. Recently, I started using ST again, when I built the two
Smalltalk-80 interpreters; from my point of view, it feels quite similar to JS
or Lua, but is even more inefficient, since even control structures and loops
are dynamic objects.

------
taylodl
I worked for a firm that _tried_ to use Smalltalk to deliver commercial
software running on Windows in the early 90's. From a learning standpoint, I
learned _a lot._ From a business standpoint this is what we ran into compared
to this article:

Lack of a Standard. Didn't really bother us. FYI we were using Digitalk
Smalltalk. People in those days didn't have the expectation of changing their
toolset without incurring problems.

Business Model. At that time people paid for software. The free (as in beer)
software distribution model didn't yet exist. The tools were expensive but
they were justified by programmer productivity. To that end, the tools made
programmers very productive. It's one of the best environments I've ever
worked in - and that was over 25 years ago!

Performance. Ah - this is where we started having problems. At that time
Smalltalk hadn't yet optimized integer arithmetic and as a result simple
numerical operations were _slow_. The garbage collector was also difficult -
when it ran it would essentially hang your machine _for several minutes_. That
would improve over the years but it was bad early on. Performance was the
deciding factor in our not using Smalltalk.

Interaction with the outside world. Digitalk took care of this. It was
workable, i.e. this isn't where we had problems or concerns.

Deployment. Digitalk was capable of producing a Windows executable file. There
were two problems though: 1) it made a guess as to which classes should be
included in the executable artifact (you could manually adjust), this made
automated testing _extremely_ important because you would need to test a
release candidate and 2) it employed it's own windowing system which it would
embed in the executable. It never looked like a native Windows application.
The marketing folks and product line managers didn't like that aspect of
Smalltalk.

Bottom line - poor performance and a poor end-user experience killed Smalltalk
for us as it did for many others at the time. You know the saying you only get
one chance to make a first impression? That goes for programming languages as
well. A LOT of developers gave Smalltalk a go in the early 90's and ran into
these issues. Though these issues would later be resolved by then the
perception damage had been done and everyone had moved on.

It's interesting that Smalltalk is one of the most influential languages that
never caught on.

~~~
projektfu
Dolphin Smalltalk was beautiful in this regard. Reasonably fast, native
windows, easy deployment.

~~~
taylodl
That sounds awesome! How was its garbage collection?

~~~
projektfu
Never noticed a pause. But I don’t think I exercised it with lots of ephemeral
creation

------
projektfu
It never forced anyone to use it. C was forced into use by the popularity of
unix. Java by its association with the browser at the time. Nobody would have
used objective C if Mac OS X had been based on C++ (BeOS). Ruby would be a
niche if it weren’t for rails. Javascript, obviously, is necessitated by the
browser.

~~~
k__
I had th impression Java really had something going for it.

It used OOP and was leaning heavier on the code-side than Smalltalk, which had
this in-place modification of a already running system.

I think Java went a step back so people would understand it better.

~~~
projektfu
It had a lot of hype. I think a big part of the hype at the time was web
related, but it was also immediately popular with schools. Schools liked that
it was easy enough to spend less time teaching the language and more on the
concepts. It also helped that it was going to be industrially important.

------
grandinj
Languages are more than just syntax and ideology. The entire ecosystem of the
language and how it interacts with surrounding software is important.

You can have an awesome language with lousy interaction, and it's dead in the
water.

Conversely, you can have a mediocre language with a great ecosystem, and it
takes over the world.

~~~
leoc
But Smalltalk was likely the king of language ecosystem, and even more so of
language interaction, at around the time when Java first appeared. And
probably its only serious rivals for that crown were even more high-end and
even more now-dead, like Lisp-machine Lisps. It didn't have great integration
with native OS environments, but early Java wasn't spectacular in that
department either.

------
mellosouls
As the article itself points out, Smalltalk may not have succeeded as an
active language in the sense of market share, but its influence (and that of
the environment from which it came) on later languages and development
paradigms seems very significant and it's still regularly fondly referenced in
many coding blogs and articles.

In spirit at least, it seems a resounding success.

~~~
Rochus
The influence is generally overestimated. C++ and Java were mostly inspired by
Simula 67, which actually was also an inspiration for Smalltalk. Although
there had been a few articles before, a broader public did not have access to
Smalltalk until the mid-1980s.

------
travisgriggs
Smalltalk enthusiast for twenty years here. I jumped out of the balloon almost
ten years ago now and sold my soul to the mediocrity of pragmatic polyglotism.

I miss Smalltalk. I miss it's clean syntax. Were there times when keyword
syntax got odd, yes. But less so than list base call syntax (and even weirder
with the hybrid list(keyword) keyword messages.

Was everything's done via messages all the way down always the bees knees.
There were some edge cases (zip?) were it was difficult to figure out where
the behavior really should be bound. But the trade off was simplicity and
consistency. None of this why is len() a function and upper() a method
nonsense.

I miss the simple syntax and pervasive use of Smalltalk closures.

I miss the tooling. The RefactoringBrowser was one of the most amazing code
environments out there. I found code faster. I authored code faster. I changed
code faster.

What have I appreciated as I've wandered through the wreckage of modern in use
systems?

Namespaces. There were some Smalltalk experiments here, but they were late and
varied. My favorite was probably that of Smalltalk/X. I mostly like pythons
namespaces: "we should do more of those". Not a fan of pythons shadowing rules
though and have never decided whether it's namespaces and shadowing are
codependent or independent.

I kind of like typing. I remember I was skeptical of Strongtalk typing at
first, but I've come to appreciate that style of annotation. Where typing
always seems to break down for me is containers. I am just not a fan of
generics. They are to typing what preprocessers end up becoming, a sort of
"deep state Illuminati" of the program. Gilad hinted at a proposed solution to
this a while back, but I never saw a follow up.

And of course cheep tooling. I don't mind paying for things. But Smalltalk
business model was about platform entrapment. There was no incremental. No
choice. You had to choose the whole party up front.

------
Rochus
Here is the worth reading response by Allen Wirfs-Brock who "was there pretty
much at the beginning": [http://www.wirfs-
brock.com/allen/posts/914](http://www.wirfs-brock.com/allen/posts/914)

------
PeterStuer
Smalltalk environments felt too much like a 'boil the ocean' approach in a
world that was just starting to produce software that was distributed to and
operated by non-programmers.

Most of its adherents developed on Apple's early Macintosh line. One of the
core tenants of the Mac was intuitive usability. The Mac developer's 'Bible'
was the Inside Macintosh series that featured Object Pascal (Think Pascal was
a realy good IDE for it's time) and the MacApp library and resources that made
it fairly easy to produce software that adhered to Apple's then state-of-the-
art UX guidelines.

Smalltalk at that crucial point in time was of in it's own (academic) world,
with its own windows and menus that didn't feel at all like the rest of the
Mac's software. While this would soon be possible, it was too late and did not
offer enough of an advantage to get the Macintosh developer community to turn
away from Object Pascal. That would only be achieved by years of C/C++
programmers pushing for that language's adoption across all platforms.

------
cmrdporcupine
The author seems to know (well, was involved in) the history of Self and
Strongtalk but seems disappointed that the people involved went on to work on
and perfect what they see as inferior technology (Java, JavaScript).

In reality I think if we do an honest accounting of the situation we can see
that these have been the more pragmatic engineering solutions for their times,
and so that's where the $$ was. I worked in Java for years, but didn't
particularly like it, but it is, I think, what the marketplace needed and
could handle at the time.

And I think JS/ECMAScript etc. is a reasonable practical solution for the
imperfect world that evolved out of Internet/browser tech.

Unlike the author I don't think Sun's fortunes would have been any different
if Self/Strongtalk or some other Smalltalk-world inspired/derived tech had
been pushed hard. The market didn't need or want it.

IBM did a similar pivot with their VisualAge line, and they did it for
pragmatic reasons.

Finally, let's look at the bigger picture: in the end, what we have with the
browser + modern JS on V8/SpiderMonkey etc. is a dynamic object oriented
programming language that allows for dynamic manipulation of its environment,
is accessible to any user, can be edited and inspected live, can present
interactive media to users, and has a large community of authors.

Is this really that far off from what Alan Kay and Dan Ingalls originally
wanted? Purists will gag, but I think as much as I hate front end dev in JS
that there's actually a lot here that is Smalltalk inspired.

EDIT: I spent much of the 90s and early 2000s cringing at what was evolving. I
was really into PL research and really liked the Self-inspired world of
prototype OO languages. I really dug LambdaMOO and spent time writing my own
shared-world multi-author persistent-world object oriented virtual machine
type systems. But there's no way any of that would pay the bills. I still
avoid JS work really, but I can see the niche that this filled. It's imperfect
... but that's the world. I'm grateful to V8 & friends for making it suck a
lot less. And that work in V8 is a direct descendant of some of the really
neat pioneering stuff in the 80s&90s.

There's a good response the original article here: [http://www.wirfs-
brock.com/allen/posts/914](http://www.wirfs-brock.com/allen/posts/914)

------
darksaints
I have always noticed the fondness with which some people talk about
smalltalk. For a language that practically doesn't exist anymore, I find that
odd...especially considering the number of languages that people despise but
still exist and are regularly used.

I don't really have much love for the combination of dynamic types and object
orientation in general, but could someone explain what they got from smalltalk
that they don't currently have via Ruby, Python, or other currently popular
languages of similar discipline? I've seen lots of explanations as to why it
failed...but why do people still talk about it like they miss it?

~~~
travisgriggs
* The IDE/Debugger rocked. It was the killer app. You could explore/understand code in a way that I have yet to see rivaled in any other environment. I have used PyCharm/XCode/Studio/VSCode/Emacs/Vim at regular levels.

* BlockClosures. Reified and used ubiquitously. Did I mention reified? Since the language had no control flow builtins/keywords, it was all done in the library. And since Closures were fully first class objects that you could explore, understand, and extend, you could write control flow to your hearts content.

* Simplicity. You didn't have to have a PHD in parsing to deal with the AST for Smalltalk. Building your own AST walker was a mid level exercise. I once saw a comparison between the Ruby AST and the Smalltalk AST. The Ruby one was like 10 times more complex to deal with all of the edge cases. I added a goto implementation for a lark in an afternoon. I wouldn't even know where to start to add goto to Python. An absurd example of course, but it highlights that you didn't feel like Dan Ingalls and the other inventors of Smalltalk controlled your destiny. They wanted you to go places with it.

------
ChrisMarshallNY
I enjoyed his prose. Mr. Bracha is an opinionated chap that is not afraid to
back up his [well-informed] opinions in a rather pithy manner.

I think that SmallTalk's contribution to ObjC was nice. It was weird to
encounter, at first, but I got used to it.

He has a point about the people charging for it. The same thing happened to
XSLT.

XSLT 1.5 is the free version; supported by many languages and libraries.

XSLT 2.0, however, is where the action is at, and that is only supported by
Saxon, a paid library.

I'm not sure if that has changed, as I haven't messed with that Pandora's Box
in a number of years.

------
geophile
In the mid 90s I was at an OO database company, and we were expanding into
tools. The decision was made to produce a Smalltalk binding and build tools
for that language.

That was well underway when Java was released. And you could hear the air go
out of the Smalltalk tires. Java was another OO language, it was designed for
“applets” that would run in the browser, and it was created by Sun
Microsystems, who built the most popular computers of the day. Nearly everyone
who was interested in Smalltalk turned to Java and never looked back.

------
mcguire
" _And yet, today Smalltalk is relegated to a small niche of true believers.
Whenever two or more Smalltalkers gather over drinks, the question is debated:
Why?_ "

" _...Interaction with the outside world._ "

This. So. Much. This.

I was a (junior) member of the team that made (part of) the prototype for the
OS/2 Workplace shell, in (IIRC) Digitalk Smalltalk. Doing anything outside the
Smalltalk image was incredibly painful.

Want to share your work with the team? File it out (and make sure you get all
of it) and give the file to the Keeper of the Golden Image, who will file it
in to the image. Then pass the image around.

Want to send the prototype to someone who didn't have a license for a (rather
useless) support library from the trainers who taught the team Smalltalk? File
our code out, file it into a virgin image, run through the test suite to make
sure you had everything, reimplementing anything that used that library.
Shouldn't take you more than a couple of days.

Did I mention this was a prototype of a GUI? Make those FFI calls using the
really sketchy api. When I started, there was a bug that would randomly cause
the prototype to crash. No one could ever figure out what caused it, beyond
the FFI interface. At some point, it escaped the prototype and would cause the
image to crash without running the prototype.

Sure, Strongtalk and Newspeak may have improved some or all of everything, but
by that point the bridge had been burned. Their one opportunity had been
wasted. I never saw or heard of either in the wild.

" _The Smalltalk image provided a much better Docker than Docker._ "

And then there's that kind of thing.

------
zerr
Complexity associated with those stateful images contributed as well, I
believe.

------
indymike
Smalltalk never evolved towards practical. It did so much on it's own because
it had to: there were no windowing graphical operating systems, so it was
invented and included. There was no SCM, and so it was invented and included.
There were no object oriented IDEs with object inspectors, so it was invented
and included. The problem is, the first implementation of an idea is rarely
the best, or the one that wins in the market. There's entire parts of our
industry that just peeled off a piece invented by Smalltalk and made a better
general purpose one. Great article.

------
jrochkind1
I love ruby. Which happens to be a smalltalk-inspired language, although
different enough that the particular analysis in the OP doens't apply, I don't
think. (ObjC is also a smalltalk-inspired language, but also same I think).

I am worried that rubyists are gonna end up talking about what happened so
ruby shrank for decades too. :(

------
kuharich
Prior comments:
[https://news.ycombinator.com/item?id=23301722](https://news.ycombinator.com/item?id=23301722)

------
Razengan
The formatting of this page is weird; some lines wrap, others don’t.

Even in Reader Mode there’s spurious line breaks.

~~~
frou_dh
Third from bottom says you shouldn't do this:
[https://news.ycombinator.com/newsguidelines.html](https://news.ycombinator.com/newsguidelines.html)

~~~
programmer_dude
This is not helpful. It's good to know if it's just me or others have the same
issue.

------
aliswe
The article may be good, but the website, mobile adapted, it was not.

