What is so special about Smalltalk?

In every technical publication, and on this site too, people are always comparing OO languages to Smalltalk. My experience is in Java: is Smalltalk so important that I should study it?

Smalltalk was one of the earliest object-oriented (OO) languages (with others like Simula and Eiffel) and can be said to be extremely "pure" in an OO sense:

• Everything is an object and objects are only communicated with via the sending of messages
• No primitives (no ints, booleans etc)
• No control structures (no for, while, if etc). Sounds impossible but it's true!
• No statics

It also pioneered some other, now common, stuff:

• the virtual machine (and JIT compilation)
• Debugging by inspection
• "Hotswapping" running code
• the modern IDE
• Closures
• Duck typing
• Model-View Controller (MVC) architecture for UIs
• Test-driven development (TDD) and agile methodology

And there are other things connected with Smalltalk which didn't really make it into the mainstream:

• "Image"-based system rather than file-based.
• Object-oriented databases

And it's fair to say that the Java collections API and the apache-commons collections API are heavily influenced by Smalltalk.

I wouldn't say that you should learn Smalltalk per se, but a familiarity with the fundamentals of these features (now present in many other languages) is surely advantageous to you.

Note that there are currently only 123 questions on here about the language, which was originally intended as an educational language (i.e. aimed at children) by its creator, Alan Kay. It is not particularly heavily used anymore. That's not to say it isn't used. JPMorgan, for example, has a large exotic derivatives risk-management system written in it.

Smalltalk has many brilliant innovations - things we're all taking for granted today, including:

• being the first ever IDE
• providing programmatic support for a GUI with a mouse If you learn Smalltalk GUI programming, you really will have understood MVC properly.
• being built out of a small number of powerful ideas that work together extremely well
• The Smalltalk way isn't to crash out on unexpected behaviour - it's to adapt. If you send a message to an object that doesn't understand it, the debugger comes up and invites you to write that method... so it provides excellent support for incremental development.
• The IDE, the app that you're writing and your data are all part of the same system - so you can write your own tools and debug instrumentation far more easily.
• The TDD toolset in Smalltalk is still better than any other language (see below).
• Squeak Smalltalk has quite a bit of cutting-edge design research:
  • the morphic UI - you can get familiar with the concept of "liveness"
  • the seaside web framework - learn what a continuation server is and how it's radically different
  • Squeak has a strong connection with the OLPC software (one laptop per child) project - and could yet have a big influence on the world.
  • Find out what a "trait" is...
  • Play with the radical 3D immersive environment called Open Croquet.
• Because Smalltalk is a smaller, simpler and more consistent language, with it's own built-in environment it's a much less confusing place to start teaching OOP. People who go this route end up being better Java, Ruby and C# programmers because they can learn basic OOP without all the messy inconsistencies of mainstream languages.
• Some commercial Smalltalks have amazing, multi-node distributed OO database environments. I'm thinking about Gemstone.
• Want to know the difference between Model-View-Controller and Model-View-Presenter - look at Dolphin Smalltalk...

The single most important reason to learn Smalltalk today is that extreme programming and scrum both got invented in the Smalltalk community... and the highly interactive style of programming you experience in Smalltalk is simpler, more powerful and direct than anything you can do with Java or C# or Ruby... and you can't really understand how well agile methods can work until you've tried to do extreme programming in Smalltalk. Few other languages (no mainstream ones anyway) have a comparable feature set.

... to really understand what TDD can be you need to use SUnit. JUnit just shows you where your tests failed. SUnit actually allows you click into the debugger at the point where the test failed and see the actual objects and how they're connected so you can see, live in the debugger how the code failed and fix it right there.

Yes, Smalltalk is so important you should study it. Why? You can understand object-oriented programming in pure, simple form. What people forget is that the Smalltalk-80 "Blue Book" has only about 90 pages devoted to the language—the language is just that simple. The other 300 pages talk about the predefined class hierarchy, which is a masterpiece of design for a class-based, object-oriented language that uses single inheritance. You will get a much deeper understanding of objects (e.g., classes are objects, and they have metaclasses, and so on off to infinity... except the knot is carefully tied to keep the system finite) than you would ever get from studying a hybrid language like Java or C++. Smalltalk matters not just because of its history but because of its simplicity:

• Simple enough so you can understand the entire language and the libraries

• Shows one idea (objects are all you need) pushed to its logical extreme

Everybody has something to learn from Smalltalk!

Smalltalk is one of the first two original OOP languages, the other being Simula-67. Consequently, there are two large families - the statically typed model centered around method invocation, pioneered by Simula (C++, Java, C# all belong here), and the dynamically typed model centered around message passing, pioneered by Smalltalk (Python, Ruby belong here).

Today, Smalltalk isn't particularly important on its own - there are some people still using it to write stuff, but it's definitely not mainstream. Learning it will give you some insight in how and why OOP evolved, however.

I spent about 5 minutes in a presentation at a conference last month on Smalltalk's history and influence. See Image-based development with Smalltalk. One of the more foreign concepts to today's programmers is the "image-based" development. There are some good analogies, including a DBMS and a spreadsheet.

Yes. Download the seaside one-click image, start using it with the tutorial from James Foster and you will learn at least:

• how web applications should be build

• how debugging is supposed to work

Not only was it one of the first, Smalltalk remains to this day a paragon of OO language design. The more popular languages that came later — C++, Java, even Objective-C — all have more primitive object-orientation and are more restrictive than good old Smalltalk. Smalltalk had pervasive first-class objects, great support for runtime introspection, very natural use of duck typing and closures that worked better than I've seen in any non-functional language. I mean, we're talking about a language that had no native control structures (if, while, etc.) but was able to create them out of its object system in a way that worked seamlessly. How cool is that?

I wouldn't recommend Smalltalk for any intensive desktop app development these days (there just isn't a viable implementation IMO), but if you want to see how OO was meant to be and maybe pick up some ideas you can use in your apps, Smalltalk is a great place to look.

I agree with the others. I'm not sure if it's important per se, but it is COOL (imho).

I love that there are no loops or conditionals in the language. If-then-else is a message sent to a boolean object. Objects of type True do one thing, objects of type False do another. (Yes, True and False are subtypes of Boolean, with a single value each, true and false respectively).

It starts out being kind of counter-intuitive, but it does give you a very interesting, and deep, view of how OO programming should work...

If you only know one object-oriented language you should consider learning a second and a third and a fourth in order to gain a broader perspective on programming with objects. Learning Smalltalk will stretch your brain because a lot of the familiar concepts we're used to in other languages (e.g. if-then-else, for(;;), while(), etc) are not there in Smalltalk. There are equivalents, obviously, but Smalltalk does things differently, and learning about different ways to do things is always a good idea.

Good luck.

I've just started to revive my interest in Smalltalk, and in my opinion, there are a few compelling things that are special about Smalltalk:

• Highly productive development environment
• Built-in support for Agile/Extreme programming methodologies
• "Pure" object model
• Easy to use graphics framework

None of these make it especially useful for people who are not in the software development business. My first exposure to it was when I saw a user interface for an embedded device prototyped on a PC using Smalltalk. This allowed the user interface to be modified and tested very quickly, and when completed, provided the embedded developers an "executable specification" that was far more precise than any document. I'm surprised I haven't seen this technique used far more often than I've observed in my travels during the last 20 years.

Using Smalltalk as a prototyping tool is where my interest lies: I think that given a new problem, different approaches to solving it can be tried and validated very quickly and easily in a Smalltalk environment, and once the desired solution is found it should be relatively mechanical to convert it to Java/C++/C# etc. etc. In fact, for repetitive sorts of things, it might well be possible to use Smalltalk to generate code for parts of the solution in some other target language.

The other thing about SmallTalk is that its alumni include Kent Beck and Ward Cunningham. Their work with SmallTalk spawned automated xUnit testing, software design patterns, CRC Cards and other practices which ed into XP/Agile, etc. So it could be argued that SmallTalk has been a major contributor to the modern programming landscape.

Just two comments:

1. Smalltalk is not object "oriented", is real objects, only objects and messages in the environment.

2. Smalltalk is not a language, is an environment that has a language (of the same name), but most of the "magic" here is thanks to the environment (the image).