On Fri, 30 May 2003, Volker Kuhlmann wrote: > > > responsive. Python is known to be much more efficient (actually close > > > to/same as C++, there's a paper on that). This is end-user relevant, > > > indirectly maybe. > > > > Python is known to be much more efficient? At what? I'd like to see > > some proof of that, and in a form other than contrived benchmarks. > > Published in a peer-reviewed reputable journal. I'd be interested to > read your published comments on the issue ;) > > The journal is this: http://www.computer.org/computer/ > > I came across it because it was mentioned in that Sun memo. > > @Article{prechelt:empirical, > author = {Lutz Prechelt}, > title = {An empirical comparison of seven programming languages}, On this issue I would like to side with Volker :-)
However I would dare to suggest the problem of runtime speed is largely irrelevant as I suspect in most cases it is cheaper to throw more hardware at the problem rather than more programmer-hours, of course if this is possible but please consider that a reasonable top end CPU+accessories may cost only 1-2 programmer-months (I mean here CPU+accessories = blade/cluster/standalone/etc-server, I hope you get the idea :-) Efficiency boils down eventually to the economic aspect (of course there are exceptions like everywhere but very few). E.g.: If I develop a program to interact between my web server and my database then is efficient if it is fast enough to keep my customers happy (they don't get bored waiting at the other end) and is cheap/fast to develop and even cheaper to maintain (readability, etc.). If it runs 0.5s slower than the C++ equivalent, who cares as long as it took me 1 programmer-hour instead of 5 days (nevermind the maintenance). Runtime speed is not the Holy Grail. In fact it has become a non-issue. Why do you think Java took off so well ? Because of speed ? ;-) An enterprise may very well develop software for in-house use which may be in service for decades (remember the y2k problem) while the current speed and hardware will be irrelevant within the next 3-5 years. IMHO: the Python code looks clean and reads easily (which to me means elegance) which I suspect that leads to better maintainability and scalability than many other. AFAIK most of the coding is in-house so these things matter. As for the occasional "give me all the speed you can get" these parts alone could be delegated to a low level library without much fuss (of course I don't talk here about special cases). The only think I don't like is the forced indentation, based on the "make" experience I still think it was a mistake .. but well, nothing is perfect :-) (I would like also a expect package in the "standard lib" but well ... :-) Cheers, -- Ryurick M. Hristev mailto:[EMAIL PROTECTED] Computer Systems Manager University of Canterbury, Physics & Astronomy Dept., New Zealand
