Ask HN: Is it worth learning SmallTalk?

19 points by gsaga ↗ HN
I've looked at this article titled [Design Principles Behind Smalltalk](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. 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?

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.

11 comments

[ 37.5 ms ] story [ 31.4 ms ] thread
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.

>An object-oriented operating system, to boot

Isn't that what android runtime is?

Smalltalk's OO and Java's OO are pretty different. If you get a chance to play w/ Smalltalk's (say Pharo) you should try it out!
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).
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.
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

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.
>I've looked at this article titled [Design Principles Behind Smalltalk](http://www.cs.virginia.edu/~evans/cs655/readings/smalltalk.h...), 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.

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

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.

Learning for fun, yes.