January 22, 2002
Why Python For AIMA
Peter Norvig's rationale for why the next edition of AI: A Modern Approach will include Python code as well as Lisp code:
- Python is easier to support cross-platform; there is one standard,
implementation that runs on Windows, MacOS, Linux, and most other Unix versions.
With Lisp, you need to support several different implementations to hit all
the platforms. This has proven to be a (minor) maintainence problem.
- Python has standard libraries for http, html, xml, regexs, database
persistent storage, interfacing to C, threads, etc. Lisp has most
of these things in particular implementations, but they are not standard.
(The Lisp standard was a marvel in 1992, but it froze then,
and other languages have leaped ahead.)
- Python has a cross-platform GUI toolkit; Lisp does not.
- Of all the established languages in the world, Python is closest
to the pseudo-code that we developed (independently) for the book.
- Python has an active, visible community. The Lisp community is
active too, but not as visible: in the last month there were 28,000 news posts
to *.python.*, and 10,000 to *.lisp.*. Partly this is because the Lispers
already know things and don't need to ask, while Python is aimed more
at beginning programmers, but these numbers do indicate some measure
- Some people are parenphobic and just don't like Lisp. For them,
and for the sake of variety in general, it's good to have a choice.
- See my [Norvig's] Lisp vs. Python comparison for more rationale on using Python.
Most of these I can at least sympathize with. The lack of standard libraries is definitely a pain. And while most of the cross-implementation issues are relatively minor, they exist. (Don't tell me that everything will be OK if you just write ANSI conforming code. I try to, and it just brings into relief the fact that no Lisp implementation is perfectly conforming, and that conformance bug fixes can take a long time to be released.)
The rest I think are more relevant to a textbook author than to an application developer. Maybe I am sheltered, but does anyone really use cross-platform GUI kits for commercial code?
Posted by jjwiseman at January 22, 2002 02:29 PM
The folks at the U of Oregon (Matt Ginsberg, et al.) who were writing the Best Bridge Program in the World were doing it in Java, because Swing, though slow, was cross-platform. I don't know if they stuck with Java for a GUI or gave it up eventually.
For a student or amateur programmer -- or anyone who wants to easily share code with friends -- a cross-platform GUI would be a really nice feature. If Python has it, and for free, that's actually pretty amazing.
The main problem I have with cross-platform GUI libraries like Swing is that they rarely give the native platform look-and-feel, which is important, especially for a commercial application. Limewire looks the same on every platform, which means it looks at home in none.
Swing can render its UI in a native look, but I think that might be a hack; It used to be able to display a Windows-style UI on a Mac, which would mean that it is just drawing graphics that look like Windows widgets instead of using the underlying native widgets. And that will look strange as soon as Microsoft tweaks the OS, or a user installs an enhanced version of a control. (I haven't used Swing in a while, so I could be wrong about this.)
I think the situation you described, people wanting to easily share code (like the code associated with a textbook), is the most compelling case for a cross-platform GUI. And definitely an important reason to have one.
I did a cursory search, but wasn't able to determine what the canonical cross-platform GUI for Python looks like.
Where I work we actually have a Java GUI and it works fine. Any slowdown in our's is due to the network communication and I don't think language choice has much influence over that:) OTOH our app is one of those "enterprise" things so we're not trying to sell in CompUSA, and as the backend is J2EE there is little point in trying to bolt a MFC or VB front end onto it.