scripting languages vs statically compiled ones

Cameron Laird claird at lairds.us
Thu Oct 28 23:08:09 CEST 2004


In article <mailman.5625.1098987033.5135.python-list at python.org>,
kosh  <kosh at aesaeion.com> wrote:
>On Thursday 28 October 2004 11:04 am, beliavsky at aol.com wrote:
			.
			.
			.
>My experience has been is that while c,c++ etc are faster then python in 
>regular applications I work with python is almost always a good deal faster. 
			.
			.
			.
>I agree that replacing a single function with c and give an increase in speed 
>and that there are classes of things that we have libraries for which give 
>large increases in speed however the point is that all of those things can be 
>called from python easily. So why write an entire program in a lower level 
>language like c,c++, java, c# etc when you can write it in python in far less 
>time? One the python version is done you can profile it, fix speed problems, 
>debug it etc using far less resources. Once you have done all of that you can 
>first use libraries if they exist to speed up  your program if still needed, 
>code parts in a lower level language now that  you know exactly where the 
>speed issues are or use something like psyco. Overall your programs will be 
>far shorter, easier to read, easier to maintain, easier to debug, and just as 
>fast if not faster. In my view just about anything other then a kernel or a 
>device driver is premature optimization to write in a low level language 
>barring other contraints.
>

Me, too.

I recognize the original questioner wants authoritative answers,
preferably from prestigious sources.  Let me assume for a moment
we've accomodated that need.

I want to reinforce one of Kosh's observations:  for real-world
applications, Python is often FASTER than C.  Not at least a 
hundredth as fast, or at least a tenth as fast, but the-customers-
complain-about-the-C-coded-version-but-love-the-Python-based-one:
FASTER.  

Also, I probably have an obligation to remind readers that an
opposition such as "C or Python?" is false in at least one more
way:  we need to think, as Kosh hints, not whether to use one or
the other, but how much of each.  In commercial practice and 
academe, decision-makers will push you to settle on one language.
This is a mistake they make.  Be prepared for it, and understand
how to respond.  Even without heroic polyglotticism, you're
realistically likely to be more successful in your development
when you're ready to combine at least a couple of distinct 
languages judiciously.



More information about the Python-list mailing list