What is so special about Smalltalk? [closed]

Question

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?

Answer 1

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.

Answer 2

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.