From comp.lang.smalltalk.dolphin, a familiar story [via Patrick Logan]:
...VisualWorks and VW/GemStone combinations are used in sectors such as cpu manufacture, container shipping and derivatives trading on a world scale (i.e. they handle a substantial fraction of the world's activities in these sectors). But for nearly two decades the corporations who have built these applications have viewed their use of Smalltalk as a strategic advantage, and hence prevented the vendors from using the applications in marketing material.
I wonder if Python will turn out, in fact, to be a strategic advantage in the way that Lisp and Smalltalk have been. Google seems to see it that way, though I'm a little skeptical. Maybe my skepticism is unfounded, and anecdotes about abysmal performance in Python apps (Mitch Kapor on Chandler, which is written in Python: “After setting up email account info, it took 30 seconds to respond after I tried to create a new mail message”, etc.) don't mean any more than the reports from novice programmers that Lisp is slow (after trying to build a long list by appending to the end, an element at a time).
Posted by jjwiseman at March 30, 2005 03:27 AMI just can't see it. Maybe when a JITted Parrot is underneath, but as things stand right now, Python feels like a significant step backwards, not forwards, despite my enormous respect for Norvig and others who are passionate about Python.
Now, if productivity and huge leverage of language features like reflection is what you're after, I think Ruby (DRb, Rinda, Ruby on Rails...) is the one to watch in the "scripting language" space.
Posted by: Paul Snively on March 30, 2005 08:01 AMThere are some rumors that Amazon uses Ruby internally now that we know that 43things.com (a loud proponent of Ruby and Ruby on Rails) is solely funded by Amazon.
Posted by: Swamp Justice on March 30, 2005 11:44 AMi wrote, and currently maintain, a medium-sized GUI desktop application using python and wxPython as the windowing library. the app does batch process runs for CVD systems.
it looks like chandler is using wxPython as the windowing library. i'm assuming this because the site-packages lib has wx and the table widget on the main screen looks alot like the table widget provided by wxPython.
i know from writing the app above that once there's alot of custom drawn widgets (non-native stuff like graphs, dials, decorating labels, etc) that the application can really slow down on the redraw. moving a separator in a split window, for example, can cause a redraw that takes a second or two to finish and return control to the user. this can be fixed by taking care of when things should get invalidated, or caching the widget image in a buffer.
so, it just seems like some things should be done in python and others, like custom drawn stuff is probably best reimplemented natively if possible. or just figure out some clever strategy for avoiding full redraws.
the major downside to me was the lack of debugger support for python+wxPython combo. the readily available python debuggers do not play nicely with the UI thread.
Posted by: robert cadena on March 30, 2005 04:50 PM