views:

436

answers:

4

I'm studying Smalltalk right now. It looks very similar to python (actually, the opposite, python is very similar to Smalltalk), so I was wondering, as a python enthusiast, if it's really worth for me to study it.

Apart from message passing, what are other notable conceptual differences between Smalltalk and python which could allow me to see new programming horizons ?

+8  A: 

In Python, the "basic" constructs such as if/else, short-circuiting boolean operators, and loops are part of the language itself. In Smalltalk, they are all just messages. In that sense, while both Python and Smalltalk agree that "everything is an object", Smalltalk goes further in that it also asserts that "everything is a message".

[EDIT] Some examples.

Conditional statement in Smalltalk:

((x > y) and: [x > z])
  ifTrue: [ ... ]
  ifFalse: [ ... ]

Note how and: is just a message on Boolean (itself produced as a result of passing message > to x), and the second argument of and: is not a plain expression, but a block, enabling lazy (i.e. short-circuiting) evaluation. This produces another Boolean object, which also supports the message ifTrue:ifFalse:, taking two more blocks (i.e. lambdas) as arguments, and running one or the other depending on the value of the Boolean.

Pavel Minaev
everything-is-a-mutable-everything meta-madness ... I like it alot.
Aiden Bell
oh... this is cool. So even an if is a message to a code block? mind blowing...
Stefano Borini
Look at the Viewpoints research ... that will blow your mind.
Aiden Bell
Pretty close. `ifTrue:` is a message to Boolean that takes a block as an argument.
Chuck
*head explodes* :)
Stefano Borini
+4  A: 

Smalltalk historically has had an amazing IDE built in. I have missed this IDE on many languages.

Smalltalk also has the lovely property that it is typically in a living system. You start up clean and start modifying things. This is basically an object persistent storage system. That being said, this is both good and bad. What you run is part of your system and part of what you ship. The system can be setup quite nicely before being distributed. The down side, is that the system has everything you run as part of what you ship. You need to be very careful packaging for redistribution.

Now, that being said, it has been a while since I have worked with Smalltalk (about 20 years). Yes, I know, fun times for those who do the math. Smalltalk is a nice language, fun to program in, fun to learn, but I have found it a little hard to ship things in.

Enjoy playing with it if you do. I have been playing with Python and loving it.

Jacob

TheJacobTaylor
The IDE looks quite cute indeed. Now if I could get to see some code... it would be even better..
Stefano Borini
+2  A: 

The language aspect often isn't that important, and many languages are quite samey,

From what I see, Python and Smalltalk share OOP ideals ... but are very different in their implementation and the power in the presented language interface.

the real value comes in what the subtle differences in the syntax allows in terms of implementation. Take a look at Self and other meta-heavy languages.

Look past the syntax and immediate semantics to what the subtle differences allow the implementation to do.

For example:

Everything in Smalltalk-80 is available for modification from within a running program

What differences between Python and Smalltalk allow deeper maniplation if any? How does the language enable the implementation of the compiler/runtime?

Aiden Bell
+4  A: 

As someone new to smalltalk, the two things that really strike me are the image-based system, and that reflection is everywhere. These two simple facts appear to give rise to everything else cool in the system:

  • The image means that you do everything by manipulating objects, including writing and compiling code
  • Reflection allows you to inspect the state of any object. Since classes are objects and their sources are objects, you can inspect and manipulate code
  • You have access to the current execution context, so you can have a look at the stack, and from there, compiled code and the source of that code and so on
  • The stack is an object, so you can save it away and then resume later. Bingo, continuations!

All of the above starts to come together in cool ways:

  • The browser lets you explore the source of literally everything, including the VM in Squeak
  • You can make changes that affect your live program, so there's no need to restart and navigate your way through to whatever you're working on
  • Even better, when your program throws an exception you can debug the live code. You fix the bug, update the state if it's become inconsistent and then have your program continue.
  • The browser will tell you if it thinks you've made a typo
  • It's absurdly easy to browse up and down the class hierarchy, or find out what messages a object responds to, or which code sends a given message, or which objects can receive a given message
  • You can inspect and manipulate the state of any object in the system
  • You can make any two objects literally switch places with become:, which lets you do crazy stuff like stub out any object and then lazily pull it in from elsewhere if it's sent a message.

The image system and reflection has made all of these perfectly natural and normal things for a smalltalker for about thirty years.

Dial Z