Smalltalk and Python

[Bjoern Giesler]

Hi,

since I'm considering to start working on a Python IDE that handles things
similarly to the Smalltalk IDEs I've seen (email me for more info), I'm very
interested in this debate. I'm not much of a Smalltalker -- the thing about
having to distribute entire system images that contain their very own GUI
etc. has always repelled me a bit, although I love the language for its
cleanness and the IDE for its efficiency.

Do you think that it would be possible to use Python as a Smalltalk
replacement if an IDE existed that hid some of Python's limitations? In the
following, I'm taking a look at each of the limitations that Russell
mentioned and try to examine if they could be remedied by a good IDE. Please
correct me if I'm wrong, a discussion of these points _before_ I start is
very important to my project.

In comp.lang.python Russell E. Owen <owen at astroNOJNK.washington.edu.invalid> wrote:
[snip]
: On the other hand, it is not as powerful, clean and regular as 
: smalltalk. Limitations include:
: - The language is somewhat cluttered and irregular because it has 
: procedures, functions and methods. Hence arbitrary decisions had to be 
: made in some areas as to how to implement things, which can lead to some 
: hunting through the manuals.

This refers to the standard Python library, I believe? I agree that it is
not as beautiful as it could be, but "hunting through manuals" fixes this.

: - It has lambda functions, but getting late binding behavior is too 
: difficult (though doable).

I'm not sure what you mean by this. Could you give me a short example?
(Python and/or ST.)

: - Only two scopes for variables: global (to a text file) or local (to a 
: function/method).

I can only think of two other scopes: local to an instance and local to a
class. The former can be remedied by assignment to self.something; the
latter can be simulated by text-file global variables. This could be hidden
by an IDE.

: - There are no class methods, though they can be faked reasonably well 
: with modules.

Same as the last -- this, also, could be hidden by an IDE.

: - Basic built in types (e.g. integers, floats and lists) are not 
: classes, in the sense that they do not have class methods.

Is this really a limitation, given Python's different control structures? Of
course, 0 to: 499 do: [:i|transcript put:i ]. doesn't work, but we have
for i in range(500): print i instead.

: - No boolean class; uses C's icky everything-is-a-logical idea.

This, too, is (perhaps) ugly, but not really a limitation IMHO.

: - I personally find not having to declare variables a negative (too 
: dangerous), though it's reasonable for simple scripting languages

Matter of taste, no? :-)

: - garbage collection is reference counted, though now enhanced in Python 
: 2.0 so it can handle most cases of circular references

This works really well in Python, and 2.0 has true GC, IIRC.

: - Collection classes are good, but no match for Smalltalk. (But then 
: what language comes close to ST in this area?). It does have 
: dictionaries and lists, both of which are great. But that's about it. It 
: also has "tuple", a minor and annoying (to me) variant of a list that is 
: immutable (more or less) and so can be used as a key in dictionaries.

Agreed, but could be remedied with a small addition to the Python standard
library.

: - Mediocre GUI support (a mediocre interface to Tk and a different 
: interface to wxWindows that isn't available on my platform--Mac)
: - Mediocre IDE. I hope this will be improved over time, along with the 
: GUI support.

Agreed. My work would address those two.

: - Rather ugly implementation of "package" (multi-file modules). This is 
: one of the few areas where I find the implementation to be ugly and 
: hastily done; generally it's a very clean language.

Agreed.

: - Like most languages, it uses text files to contain sets of code. I 
: really miss Smalltalk's more integrated approach.

Agreed, but this is another thing that I'd like to address.

Thanks for any and all input, and if anyone wants to participate or know
more, please email me.

Regards,
		--Björn