Python Language and Smalltalk Language seem comparable in many ways, but their origins and styles are very different. On this page we're trying to figure out when to use Smalltalk Instead Of Python.
Syntax
If, like most programmers, you come from an Algol Family background, then Smalltalk syntax looks pretty obscure at first. Consider:
One of the Smalltalk Tutorials
The short-but-sweet book:
On To Smalltalk
Python, on the other hand, is notoriously easy for an Algol Family programmer to learn, and comes with several truly excellent tutorials. The main difference you'll find is that Python uses indentation rather than braces to control scope. (See Python White Space Discussion.) It's not too much to expect any competent programmer to learn most of the Python syntax in a day, and to become fluent in a couple of weeks.
Speed
Java Python is the speed of Java Language which is about as fast as Smalltalk Language. Are there any numbers on that claim? The professional Smalltalk vendors still claim that their Virtual Machines are faster than Java's. Regular Python Language is as much as 2.5 times faster than Jython, according to the Jython faq. Some Just In Time Compilers may bring Jython up to par with regular Python. Does this mean Small Talk is slower? Jury's out Who cares: use Alternate Hard And Soft Layers. Smalltalk Em Tee produces very fast compiled code on Microsoft Windows--DLLs, Activex Technology controls, the lot.
The development of Python Language has focused more on speed of development than speed of program execution. I certainly doubt that CPython is 2.5 times faster than Java Language, which is suggested above. But as you know, benchmarks only tell us how fast the actually benchmarked code is. There are some references to Python performance on the web. www.flat222.org 
shootout.alioth.debian.org As usual, these tests focus on tiny, meaningless programs, so I'd take them with a pinch of salt. And they don't compare with Smallalk Language...
shootout.alioth.debian.org measures Python implementations and Smalltalk implementations.
Is Java Python really the speed of Java Language? Sure, Jython can be compiled into Java bytecode, but will it look just as the bytecode of a comparable Java program? I think the dynamic nature of Python/Jython will lead to more complex bytecode.
No, Jython is not the speed of Java. I think it's like 10x slower than Java, because many portions are interpreted. (10x slower for what kind of code? Numbers lie...) CPython is faster than Jython. I personally consider Jython to be niche, useful for environments where Java Language is entrenched or otherwise required.
Python performance is Good Enough, for nearly any definition of "Good Enough". Because it is easy to use Cee Language code with Python Language, portions of your code can be refactored to speed up your program. Of course, C is harder than Python, so you only do this as necessary, but there is always at least a path out. Also, you can use C libraries that are created and packaged by other people (which is what I do), and eventually the whole community benefits. -- Ian Bicking
Tools
Smalltalk: IDLE is some of the way there, but there's nothing comparable to the Refactoring Browser, or even an object inspector.
Python: If you prefer an editor to an IDE, this is moot. A Python Refactoring Browser would be really nice though. Thank you, Bicycle Repair Man!
But see more on this on Ide Instead Of Editor.
Once unique to the Smalltalk Language world, a Java Language version (Gem Stonej) is evolving nicely. Gem Stone gives extraordinary power to develop large-scale applications, and is used in telecom, manufacturing, logistics, finance, and commerce. See also Gemstone Project. It's a high-performance server & scalable Object Oriented Database Management System, capable of supporting over 1 billion objects.
You can of course build a large scale python system over any RDBMS, but Gem Stone would likely trump that solution in flexibility. However, as Java Python is able to do everything Java can do, use/aggregate/compose/derive from any Java Language class, there's no difficulty using Gem Stone from Python Language. You could also use Java Python in combination with the Oracle Java Virtual Machine.
Note that Gem Stone Smalltalk is in many ways more flexible than the Java/Java Python route, primarily because it is more mature than Gem Stonej. It also benefits from Smalltalk's rich reflection & metaobject libraries when designing rich & adaptive frameworks.
Zo Db (The Zope Object Database) is a (not-quite orthogonal) persistent store with transactional support, as well as other features. It is available separate from Zope, and many people use it as such. And it's Open Source. For a significant portion of the Python Language community, software is not valuable if it is Closed Source (a notable difference from Smalltalk Language circles), so an imaginary Gemstone/P would not matter much to us.
Zope Application Server (Zope)
What's more Zope provides a free Python Object Oriented Database, and a nice one. Nevertheless, Zo Db's scaling attributes haven't been stressed or demonstrated. If you want to do data warehousing in Python Language, you'll probably have to go the Java Python/Gem Stonej route.
Zope may not be the ideal choice for mass storage / retrieval of arbitrary Foreign Objects. Still, why not put Zope / Zo Db to the test by building a Web-Based Python Development Environment, complete with a Python Refactoring Browser?
Zo Db isn't really meant to be separated from Zope and used with other projects though, is it? I'm not asking this as an argument for Smalltalk Language, but rather because I have other projects that I could use a good object store for, and I'm thinking of doing those projects in Python Language (as opposed to Java Language or Cee Language).
There's an excellent article on just this topic: starship.python.net
Zope is made up of several modules, which when used together form a Web Application Development Environment, but each can be used separately. Zo Db is a direct descendant of "Bobo", an Open Source Python Language module, that provides Persistence to Python Objects (an ODB). Typically Zo Db is used in conjunction with the Filestorage module, but the actual storage medium is abstracted, and there are existing alternatives.
Perhaps the reference to data warehousing (above) is intended to caution against using the Zope native Object Database (ZODB) as an Object Data Warehouse. This is very different than using Zope as a Web Development Environment for building systems to access a "traditional" Data Warehouse. In this sense, Zope is very capable of managing the Python Objects that make up Zope itself, components of Web Applications created within Zope, as well as data held in external systems, which are "objectified" within the Zope context.
If you're looking at a Zope solution, you'll quickly notice that the interfaces to back-end datastores are quite mature and flexible. Zope is very adequate for accessing any traditional "backend" (tabular data, any Relational Data Base Management System such as Oracle Database, Postgre Sql). This is the realm of Cold Fusion, Active Server Pages, and Php Language. Of these only PHP is Open Source and cross-platform, and none are Object Oriented. Unlike these, Zope has a powerful security model, and is a capable Content Management System.
Closures
Python: has First Class Functions that can be used just like Smalltalk Blocks And Closures (as far as I know). The Lambda Calculus functions are just Syntactic Sugar for one liners. They compile down to first class Anonymous Functions.
Smalltalk: Something that I love to do in Smalltalk Language, Ruby Language and Lisp Language but find frustrating in Python Language because of the lambdas:
^ anArray collect:
[ :each | each transform ]
goes to
map(lambda x:x.transform(), anArray)
in Python. Fine, if a mite yucky. Unfortunately...
^ anArray collect:
[ :each | self transform: each ]
goes to
map(lambda x, self=self:
self.transform(x), anArray)
which is yucky as all get out when the list of objects you need to use inside the lambda gets at all long. Python 3000 offers some hope, but the semantics aren't the only problem with doing this kind of mapping in Python (But see Python's nifty List Comprehension syntax below!); the syntax is surprisingly klugey. Plus, you don't get the really cool stuff the Collection protocol gives you in Smalltalk: no includes, no isEmpty... you do have a select, but it has the same problems the map does, etc.
Note: the second map example can actually be rewritten like this, which is far more readable:
map( self.transform, anArray )
However, code that would use blocks in Smalltalk is less readable when written with functions in Python because code that should belong together is written in two separate places. Also, functions need to be named, which often leads to the auxiliary functions having awkward names or names that carry little useful information.
Python: In recent versions of Python (2.0 upwards) you can use List Comprehensions:
return [x.transform() for x in anArray] return [self.transform(x) for x in anArray]
Versions 2.1 and up have properly nesting scopes (in 2.1 you need to do a little magic dance to enable them, but that will goes away in 2.2), so the "foo=foo" hack is no longer needed.
There are two forces here: one is that the built-ins in Python Language tend not to have methods; int('foo') instead of 'foo' asNumber. (As of Python 2.0, strings have methods; though there is still no method for converting to a number.) The other is that Anonymous Functions are unpleasant in Python (though less so as of 2.1).
Who cares about closures? I practically never use 'em, nor lambdas neither. When would you use Closure Instead Of Object?
A closure does two things: It avoids giving a name to a block of code that doesn't need it, and it keeps the block of code as close as possible to where it is being used.
It does more than that, and just because you never use them doesn't mean they aren't extremely useful to those who do. Anonymous closures allow easy and clean use of Higher Order Function's, and allows a more Functional Programming style. The entire Smalltalk Collection Hierarchies [sic, sorry] is based upon higher-order functions and closures, so being able to create closures with an extremely light syntax is a huge, huge boon.
[It's a matter of preference, not a huge boon. I generally prefer named functions, purely as a stylistic and aesthetic matter. It's also slightly easier to refactor. Anonymous blocks are not required for Functional Programming or the use of HOFs. Reasonable people can agree to disagree about this, but I wouldn't call it a failing on the part of Python Language (any more than I would count Smalltalk Language's non-Algol Family syntax against it).]
Okay, so Stackless Python seems to make this a non-issue. Is there anything else to recommend Smalltalk over Python?
So Stackless Python adds Co Routines. I fail to see how that provides me with the flexibility of a closure/block. This is one of my problems with Java Language: Anonymous Inner Classes are a poor & clunky substitute.
Books and Portability
Smalltalk Language has more books than Python Language, but more Python books are coming out. Some Smalltalk books are specialized to a particular vendor's implementation. This may cause minor problems of applicability, but overall most Smalltalk flavors are quite similar. Python essentially has only two mainstream implementations (Python and Java Python, both free), and those two implementations are available an many platforms. Smalltalk is also available on many platforms (Sun Solaris, Microsoft Windows, Apple Macintosh, Linux Os, etc.)
Smalltalk has a book by Kent Beck ([ISBN 013476904X]). Python doesn't.
Actually, Python now has part of a book by Kent Beck ([ISBN 0321146530]).
Python has several Animal Books ([ISBN 1565924649], [ISBN 1565921976], [ISBN 1565926218], [ISBN 1565925009]). Smalltalk doesn't.
Standards and Bindings
Python's Java Language, Cee Plus Plus (via the Simplified Wrapper And Interface Generator), XML, RDB and COM bindings are all excellent. Smalltalk (Visual Works and Visual Age) supports Java, C++, COM and Windows DLL bindings, though it lacks the auto-generated APIs of the Simplified Wrapper And Interface Generator. Distributed Smalltalk is a CORBA 2.x ORB. Squeak Smalltalk can translate a subset of itself into Cee Language. And Python Language and Squeak Smalltalk are both Open Source.
Python is far less insular than Smalltalk, as a language in general, and the implementations specifically. Python makes extensive use of libraries and programs not written for Python, and does not insulate the programmer from the system.
Marketability and Lifespan
Neither language is terribly marketable compared with the corporate-supported languages, but Python Language is younger, livelier, and easily combined with/evolved from development with other languages, so it seems the more likely to proliferate. Python has strong community participation at all levels of development, including the core language development. The community is transparent and does not depend on commercial success (as the corporate-sponsored or owned Smalltalk Language implementations do).
Two versions of Smalltalk are supported by large corporations (Ibm Smalltalk and Cincom Smalltalk), and others are supported by smaller for-profit organizations. Ibm Corporation supports its products forever, and Smalltalk seems to have settled in a stable, respectable niche. Squeak Smalltalk provides an Open Source alternative.
Reflection and Meta Programming
Smalltalk Language is known to have a very rich, reflective nature, second only to Common Lisp. How does Python fare?
Python Language is very reflective. Everything in the language, including classes, namespaces and functions, is an object whose properties can be got and set. Python programs can construct and compile Python programs on the fly. Python objects can be serialized and deserialized with a single statement. There are some limitations - see the discussion on Closures - but it's difficult to see where they'd bite you.
Okay, but how about Meta Classes? I was surfing around Python.org, and only got the impression that it was a work-in-progress.
[My disclaimer, I don't know beans about Smalltalk.] Perhaps you are accustomed to an automated tool for implementing Meta Classes, but if you are interested, here's an article with code samples showing use of Meta Classes in Python: www2.linuxjournal.com
Python Language has supported Meta Class programming since version 2.2 or so. David Mertz's site also has a few articles on this.
Does Python allow object swizzling? By this I mean that Smalltalk has a method called become: that effectively replaces one instance with another instance, changing all references in the system. No, Python does not have this.
By my understanding of Object Swizzling, it does:
class foo: def __init__(self, datum): self.datum = datum def __str__(self): return "This is a foo with datum %s" % self.datum
class bar: def __init__(self, thing): self.thing = thing def __str__(self): return "This is a bar; contents: %s" % (self.__dict__, )
>>> x = bar(123) >>> print x This is a bar; contents: {'thing': 123} >>> x = foo(123) >>> print x This is a foo with datum 123 >>> x.__class__ <class __main__.foo at 0x00CF3AB0> >>> x.__class__ = bar >>> x <__main__.bar instance at 0x00D64F30> >>> print x This is a bar; contents: {'datum': 123}
Does Python allow me to call methods through reflection? (i.e., like Java's Method Objects or Smalltalk's perform: ) Yes, everything is available through reflection, including modifying class objects, adding methods, etc., at runtime.
There are several aspects to relation. One is that we can look things up by name:
>>> import string >>> string.__dict__['uppercase'] 'ABCDEFGHIJKLMNOPQRSTUVWXYZ'
Another is that we can evaluate code at runtime:
>>> eval('"Hello" + "Wiki"') 'HelloWiki'
Et cetera. Evaluation is usually not necessary for reflection.
Python Language is trivial to integrate with Cee Language or other native languages: just build a Shared Library, import it, and start calling.
Just starting with Python, so I don't know: Does Python have Senders/Implementors? Inspectors? Editing in the debugger with restart? ENVY and similar tools to show editions of methods and replace them? Reflection? Hierarchy Browsers? Window drawing and event linking tools?
bit of a mixed collection of requirements here... Python doesn't have the nice environment that has always been part of Smalltalk -- after all it started life as a Scripting Language. It does have several user interface toolkits of which I believe the TK port is most popular. It does have reflection, although maybe not quite as much as Smalltalk. It also has, at least for now, one version, there are no vendor wars to lose.
''Python's design actually makes on-the-fly editing difficult or impossible. Classes are created by execution, not defined. So:
>>> class A:
... def answer(self):
return "YES!"
>>> a = A() >>> class A: ... def answer(self): return "NO!" >>> a.answer() YES!
As you may see, the a object is still bound to the old definition of A. You can do some funny tricks with this, but for the most part it causes problems.''
--
But the effect is achievable with:
>>> class A: ... def answer(self): return "YES!" >>> a = A() >>> class A: ... def answer(self): return "NO!" >>> a.answer() 'YES!' >>> a.__class__ = A #reload class >>> a.answer() 'NO!'
or for a single function:
>>> class A: ... def answer(self): return "YES!" >>> a = A() >>> def just_say_no(self): ... return "NO!" >>> A.answer = just_say_no >>> a.answer() NO!
This happens to work in Ruby:
irb(main):001:0> class A irb(main):002:1> def answer; return "YES!"; end irb(main):003:1> end => nil irb(main):004:0> a = A.new => #<A:0x298a510> irb(main):005:0> a.answer => "YES!" irb(main):006:0> class A irb(main):007:1> def answer; return "NO!"; end irb(main):008:1> end => nil irb(main):009:0> a.answer => "NO!" irb(main):010:0>
I guess that's not too surprising, given the way Ruby is modeled after Smalltalk.
Comments
Dammit, I like 'em both. Which says a lot for Python, because I'm a die-hard Smalltalk Bigot (and a Knight Of The Square Bracket). Python meets my bare minimum usability requirements: Late Binding and Garbage Collection. And it has a 1970's hacker community feel to it. And I'm really enjoying using it. --Anthony Lander
[Comments on file orientation moved to Python Refactoring Browser]
I'm very impressed with Ruby Language. Does anyone have any ideas on Smalltalk Instead Of Ruby or Ruby Instead Of Python? (See Python Vs Ruby) The only real drawback of Ruby that I see is that it is so young, but that will improve with time, of course, and by definition.
Since it looks like you have some experience with that, perhaps you could write something at Ruby Instead Of Smalltalk :-) Would be a good starting point for further discussion and comparisons.
One thing going for Python is that it does or can resemble the Algol Language-roots style that is so common. One can more easily gradually transition instead of doing a mental 180.
At this point (March 2005), Python also has a much larger community and library. It also has high quality free/Free implementations, which (as I understand it), Smalltalk does not. Personally, I wouldn't recommend using smalltalk unless you've already got experienced smalltalk developers and/or existing smalltalk code you need to work from.
Squeak is both high quality and free. Visual Works is free for development. Smalltalk/X (Smalltalk Ecks) is even free for commercial users.
See original on c2.com