Smalltalk Instead Of Python

PythonLanguage and SmalltalkLanguage 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 SmalltalkInsteadOfPython.

Syntax

If, like most programmers, you come from an AlgolFamily background, then Smalltalk syntax looks pretty obscure at first. Consider:

Python, on the other hand, is notoriously easy for an AlgolFamily 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 PythonWhiteSpaceDiscussion.) 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

JavaPython is the speed of JavaLanguage which is about as fast as SmalltalkLanguage. Are there any numbers on that claim? The professional Smalltalk vendors still claim that their VirtualMachines are faster than Java's. Regular PythonLanguage is as much as 2.5 times faster than Jython, according to the Jython faq. Some JustInTimeCompilers may bring Jython up to par with regular Python. Does this mean SmallTalk is slower? Jury's out Who cares: use AlternateHardAndSoftLayers. SmalltalkEmTee produces very fast compiled code on MicrosoftWindows--DLLs, ActivexTechnology controls, the lot.

The development of PythonLanguage has focused more on speed of development than speed of program execution. I certainly doubt that CPython is 2.5 times faster than JavaLanguage, 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. http://www.flat222.org/mac/bench/ http://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 SmallalkLanguage?...

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=vw&lang2=python measures Python implementations and Smalltalk implementations.

Is JavaPython really the speed of JavaLanguage? 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 JavaLanguage is entrenched or otherwise required.

Python performance is Good Enough, for nearly any definition of "Good Enough". Because it is easy to use CeeLanguage code with PythonLanguage, 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. -- IanBicking

Tools

Smalltalk: IDLE is some of the way there, but there's nothing comparable to the RefactoringBrowser, or even an object inspector.

Python: If you prefer an editor to an IDE, this is moot. A PythonRefactoringBrowser would be really nice though. Thank you, BicycleRepairMan!

But see more on this on IdeInsteadOfEditor.

GemStone

Once unique to the SmalltalkLanguage world, a JavaLanguage version (GemStonej) is evolving nicely. GemStone gives extraordinary power to develop large-scale applications, and is used in telecom, manufacturing, logistics, finance, and commerce. See also GemstoneProject. It's a high-performance server & scalable ObjectOrientedDatabaseManagementSystem, capable of supporting over 1 billion objects.

You can of course build a large scale python system over any RDBMS, but GemStone would likely trump that solution in flexibility. However, as JavaPython is able to do everything Java can do, use/aggregate/compose/derive from any JavaLanguage class, there's no difficulty using GemStone from PythonLanguage. You could also use JavaPython in combination with the Oracle JavaVirtualMachine.

Note that GemStone Smalltalk is in many ways more flexible than the Java/JavaPython route, primarily because it is more mature than GemStonej. It also benefits from Smalltalk's rich reflection & metaobject libraries when designing rich & adaptive frameworks.

ZoDb? (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 OpenSource. For a significant portion of the PythonLanguage community, software is not valuable if it is ClosedSource (a notable difference from SmalltalkLanguage circles), so an imaginary Gemstone/P would not matter much to us.

ZopeApplicationServer (Zope)

What's more Zope provides a free Python ObjectOrientedDatabase, and a nice one. Nevertheless, ZoDb?'s scaling attributes haven't been stressed or demonstrated. If you want to do data warehousing in PythonLanguage, you'll probably have to go the JavaPython/GemStonej route.

Zope may not be the ideal choice for mass storage / retrieval of arbitrary Foreign Objects. Still, why not put Zope / ZoDb? to the test by building a Web-Based Python Development Environment, complete with a PythonRefactoringBrowser?

ZoDb? 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 SmalltalkLanguage, 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 PythonLanguage (as opposed to JavaLanguage or CeeLanguage).

There's an excellent article on just this topic: http://starship.python.net/crew/amk/python/writing/zodb-zeo.html

Zope is made up of several modules, which when used together form a Web Application Development Environment, but each can be used separately. ZoDb? is a direct descendant of "Bobo", an OpenSource PythonLanguage module, that provides Persistence to Python Objects (an ODB). Typically ZoDb? 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 RelationalDataBaseManagementSystem such as OracleDatabase, PostgreSql). This is the realm of ColdFusion, ActiveServerPages, and PhpLanguage. Of these only PHP is OpenSource and cross-platform, and none are ObjectOriented. Unlike these, Zope has a powerful security model, and is a capable ContentManagementSystem.

Closures

Python: has FirstClassFunctions that can be used just like SmalltalkBlocksAndClosures (as far as I know). The LambdaCalculus functions are just SyntacticSugar for one liners. They compile down to first class AnonymousFunctions.

Smalltalk: Something that I love to do in SmalltalkLanguage, RubyLanguage and LispLanguage but find frustrating in PythonLanguage 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 ListComprehension 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 ListComprehensions: 

  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 PythonLanguage 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 AnonymousFunctions 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 ClosureInsteadOfObject?

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 HigherOrderFunction's, and allows a more FunctionalProgramming style. The entire Smalltalk CollectionHierarchies [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 FunctionalProgramming 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 PythonLanguage (any more than I would count SmalltalkLanguage's non-AlgolFamily syntax against it).]

Okay, so StacklessPython seems to make this a non-issue. Is there anything else to recommend Smalltalk over Python?

So StacklessPython adds CoRoutines. I fail to see how that provides me with the flexibility of a closure/block. This is one of my problems with JavaLanguage: AnonymousInnerClasses are a poor & clunky substitute.

See also PythonVsRuby, BlocksInRuby, BlocksInPython, BlocksInManyLanguages.

Books and Portability

SmalltalkLanguage has more books than PythonLanguage, 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 JavaPython, both free), and those two implementations are available an many platforms. Smalltalk is also available on many platforms (SunSolaris, MicrosoftWindows, AppleMacintosh, LinuxOs, etc.)

Smalltalk has a book by KentBeck (ISBN 013476904X ). Python doesn't.

Actually, Python now has part of a book by KentBeck (ISBN 0321146530 ).

Python has several AnimalBooks (ISBN 1565924649 , ISBN 1565921976 , ISBN 1565926218 , ISBN 1565925009 ). Smalltalk doesn't.

Standards and Bindings

Python's JavaLanguage, CeePlusPlus (via the SimplifiedWrapperAndInterfaceGenerator), XML, RDB and COM bindings are all excellent. Smalltalk (VisualWorks and VisualAge) supports Java, C++, COM and Windows DLL bindings, though it lacks the auto-generated APIs of the SimplifiedWrapperAndInterfaceGenerator. DistributedSmalltalk is a CORBA 2.x ORB. SqueakSmalltalk can translate a subset of itself into CeeLanguage. And PythonLanguage and SqueakSmalltalk are both OpenSource.

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 PythonLanguage 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 SmalltalkLanguage implementations do).

Two versions of Smalltalk are supported by large corporations (IbmSmalltalk and CincomSmalltalk), and others are supported by smaller for-profit organizations. IbmCorporation supports its products forever, and Smalltalk seems to have settled in a stable, respectable niche. SqueakSmalltalk provides an OpenSource alternative.

Reflection and MetaProgramming

SmalltalkLanguage is known to have a very rich, reflective nature, second only to CommonLisp. How does Python fare?

PythonLanguage 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 MetaClasses? 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 MetaClasses, but if you are interested, here's an article with code samples showing use of MetaClasses in Python: http://www2.linuxjournal.com/lj-issues/issue73/3882.html

PythonLanguage has supported MetaClass programming since version 2.2 or so. DavidMertz's site also has a few articles on this.

By my understanding of ObjectSwizzling?, 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}
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.

AlternateHardAndSoftLayers

PythonLanguage is trivial to integrate with CeeLanguage or other native languages: just build a SharedLibrary, 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 ScriptingLanguage. 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 SmalltalkBigot? (and a KnightOfTheSquareBracket?). Python meets my bare minimum usability requirements: LateBinding and GarbageCollection. And it has a 1970's hacker community feel to it. And I'm really enjoying using it. --AnthonyLander

[Comments on file orientation moved to PythonRefactoringBrowser]

I'm very impressed with RubyLanguage. Does anyone have any ideas on SmalltalkInsteadOfRuby or RubyInsteadOfPython?? (See PythonVsRuby) 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 RubyInsteadOfSmalltalk :-) Would be a good starting point for further discussion and comparisons.

One thing going for Python is that it does or can resemble the AlgolLanguage-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. VisualWorks is free for development. Smalltalk/X (SmalltalkEcks) is even free for commercial users.

CategoryProgrammingLanguageComparisons CategorySmalltalk CategoryPython

EditText of this page (last edited November 24, 2009) or FindPage with title or text search