
Ask HN: Is it worth learning SmallTalk? - gsaga
I&#x27;ve looked at this article titled [Design Principles Behind Smalltalk](http:&#x2F;&#x2F;www.cs.virginia.edu&#x2F;~evans&#x2F;cs655&#x2F;readings&#x2F;smalltalk.html), and I can&#x27;t see anything in Smalltalk that&#x27;s not available in Java or Kotlin as well. I understand that Smalltalk is where the OOP ideas originated, but is it worth learning Smalltalk in 2019, even if just as a side project, for an amateur programmer reasonably familiar with OOP principles and techniques?<p>The idea that Smalltalk is a fully featured system which provides you with everything you might want to do with a computer reminds me of Emacs and Temple OS.
Also, the blog I mentioned above seems to present Smalltalk as the perfect programming language.
======
tonyg
Smalltalk is three things in one. It is a _language_ ; it embodies a language
_design idea_ ; and it is an _operating system_.

Learning Smalltalk gives you three things:

1\. An understanding of Smalltalk, the language. This is least essential. It's
also the kind of thing you can pick up in a single 30-minute session. The
language is tiny and simple.

2\. An understanding of the design idea, _uniformly object-oriented
programming_. This is crucial and will connect with other styles of
programming including Actor-based and pure-functional. This is something you
will never get from Java, which is not a uniformly object-oriented language.

3\. An understanding of a completely different and (these days) unusual way of
designing an operating system. An object-oriented operating system, to boot.
The IDE, the debugger, and the other tooling all integrates to give a level of
manageability in many ways far superior to e.g. Unix or Windows.

After a while, you may find yourself discovering subtle things about the
interplay between the three aspects of Smalltalk that you can then apply in
your own designs. For example, Smalltalk is a "dynamic" language, but the way
classes and methods are arranged is very rigid, giving a lot of static
structure to the system organisation. This static structure is what unlocks
the powerful tooling, and is what simplifies the programmer's mental model to
make the system understandable. Comparable OO and almost-OO languages, such as
Python, have a more "dynamic" system organisation, making it harder to write
tools for automatically manipulating Python systems and making it harder for
programmers to understand how Python code, data, state, and processes come
together to form a running program image.

~~~
eggy
You have just explained to me why I keep returning to Pharo over the years. I
play with it, and always seem to walk away with a more connected, deeper
understanding or sense of deep organization that I have not experienced with
other languages/environments. The only thing is I have not been able to go
beyond toy programs in Smalltalk, or utilities for work (I use Storyboard to
keep track of my projects at work, since the company's system Vision by Deltek
is too complicated, and we don't have full access to its utilities).

~~~
scroot
I think the new graphics layer (Bloc) will help with this. It's already a huge
mental leap to understand what's going on when someone first boots up a
Smalltalk environment. The current look of the system doesn't help things.

~~~
eggy
I thought Bloc was low level like Morphic. If not, I'll have to look into
Bloc. I have been using Moose for my data viz needs, and playing with Pharo. I
love GT (the Glamorous Toolkit)[1]. Will that be affected by Bloc? Smalltalk,
Pharo in my case, is always refreshing and surprising. I have just not learned
it enough to build anything complex yet, but that's on me. It's a great
environment.

[1]
[https://github.com/feenkcom/gtoolkit](https://github.com/feenkcom/gtoolkit)

~~~
scroot
Yes it's a replacement for Morphic, but it also allows for more modern 2D
graphics. The new GToolkit alpha is actually built in Bloc.

------
coldtea
> _I 've looked at this article titled [Design Principles Behind
> Smalltalk]([http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.h...](http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.html)),
> and I can't see anything in Smalltalk that's not available in Java or Kotlin
> as well._

There are several things in Smalltalk not available in Java or Kotlin, and
more importantly, a lot more not available in an equally convenient and
elegant way. Because the main thing behind a language is how features are laid
out and play together, not whether a feature is merely available or can be
achieved with some workaround.

(And of course, Smalltalk was created 20+ years before Java, so there's that).

In Smalltalk for example everything is an object. In Java you have int and co,
and the resulting non-uniform behavior that requires boxing.

In Smalltalk you write code in a live image, and this means you can save state
and resume your programming and program from where you left, give it to
someone else to run from where you suspended it, and so on.

In Smalltalk the programming environment and the compiler are one, so the
language is part of the IDE. You have total visibility of all objects, can
edit them, query them based on their types, and so on -- and not just through
some "ctags" type indexing.

In Smalltalk you can edit any part of the program, or IDE, and continue
working with your changes.

What in Java would be a built-in operator like "if", in Smalltalk is
accessible to the program to create, add variations, etc.

------
lucozade
This depends on what you want to achieve.

If you want to broaden your understanding of programming [0] then learning
Smalltalk is worthwhile. A lot of ideas from Smalltalk have bled into the
mainstream but it's interesting to see how a live image, integrated system
functions.

If you think Smalltalk will be the next mainstream language, and you want to
be ahead of the curve, then I wouldn't bother. That's highly unlikely. It's
most suited for limited, self-contained and presentation heavy use cases.
These still exist but they're not where the industry is or is likely to go.
And it's hard to see pure OO coming back into fashion any time soon.

And as to perfection, well, as with all these things, it depends on what your
building. It takes an inordinate amount of discipline to write a system that
works well at scale. Even worse if you want to run distributed. It's really
not suited for that. But if you keep in its sweet spot, it can be very
pleasant to develop in.

[0] I'm assuming from your question you've had mostly mainstream language
experience. If you're an expert Common Lisp programmer then this probably
doesn't apply so much.

------
yesenadam
I downloaded Squeak last year, played with it for a while. It's extremely
cool. I felt like I grokked OOP for the first time. (And it's much more OOPy
than what is usually called OOP) It was the easiest thing I've ever tried to
install and use, everything just worked. Most interesting were the design
decisions just _different_ (and better, cooler) to what is universal these
days. (And a lot of the things that _are_ familiar and universal these days,
originated with Smalltalk!) A lot of stuff you can't do between windows or
programs nowadays (the stuff Ted Nelson, Alan Kay etc complain about), is
natural and easy in Squeak/Smalltalk. Or how it saves the whole state of the
system and everything you had open, where you had it, and you can have many of
those.. Too many things to mention, but it's a delight.

[https://en.wikipedia.org/wiki/Squeak](https://en.wikipedia.org/wiki/Squeak)

------
vkaku
Learning for fun, yes.

