Python 2 times slower than Perl

[Patrick W.]

"Greg Jorgensen" <gregj at pdxperts.com> writes:

> "Patrick W." <hard2bsome1 at yahoo.com.au> wrote:
> 
> > To get a better understanding of which languages it benefits us to
> > learn and teach. Also to get a better understanding of which languages
> > are best used in the "real world", given a set of tradeoffs between
> > development time and program performance.
> >
> > Sounds reasonable enough to me.
> 
> Discussion of languages and their applications in teaching or professional
> work is fine, I'm all for that. But how does comparing benchmarks of Perl
> vs. Python help in that regard? 

OK, crossed purposes here.

I thought you were dismissing the potential usefulness of quantitative
language-comparative studies in general. You weren't.

> Serious programmers know that such discussions are often wrong,
> usually irrelevant, and about as useful as comparing the speed of a
> Toyota Camry vs. a Honda Accord.

Sure. If you're talking about the merits of comparing the speed of a
loop that doesn't do anything useful in any language, I agree totally.

I think there's a bigger issue though. (I know you don't disagree, I'm
just explaining what I had in mind).

We (the industry as a whole) are bogged down by the choices we've made
in the past. We used languages that may or may not have been the best
ones available at the time, and now we have huge systems that we can't
afford to abandon or rewrite. So you're right. Most programmers don't
get to choose the language they work with.

Going forward, the main value I see in comparative language studies is
that we have a chance of making smarter decisions for NEW
projects. Instead of rushing headlong into the next Java-like novelty,
we could take stock of what we know, put a few assumptions to the
test, and start improving what we already have and/or use it in better
ways.

To do that properly, it would be useful to have some *real*
benchmarks. Not timed loops, but real tasks performed by equivalently
experienced programmers in different languages, to see which ones (if
any) consistently lead to the most robust, timely and cost-efficient
solutions - in practice.

The results may not be consistent or repeatable (which is the whole
point of experimenting). But if they are, it will be a *major*
discovery.

Personally, I'd be very curious to find out whether my intuitions
are quantitatively verifiable. (As yet, I only have gut feeling to
judge by).

The way I see it, only three languages (or families of languages) are
really necessary :

1. A simple low level language, capable of generating code that
   extracts maximum efficiency from the CPU, suitable for space and
   memory constrained architectures, etc. C has stood the test of
   time. It works.

2. A Lisp-like language for higher level logic. Able to clearly and
   concisely represent any kind of data structure or
   algorithm. Extensible through the mechanisms of its own
   semantics. Able to generate code that generates code. Able to read
   its own code as data, and output data as code. Able to assimilate
   any programming paradigm without torturing its simple syntax.

3. Another language, similar to #2 in its expressive power, but with
   infix notation for convenience. (Hard to go past Python or Dylan).

A programmer who has these tools in his arsenal is capable of anything
his brain can handle. No single programmer is ever going to be able to
cover all the intellectual ground in terms of domain-specific
knowledge or specialist skill, but it should be possible for any
person to master the *means* to do so.

So, to me, these studies are potentially *very* valuable. (Value
measured in life-years, dollars and brain cells).

> The less-than-serious programmers apparently find deep meaning in
> these comparisons; apparently they believe they must find the "best"
> language because they can learn and use only one.

To be honest, I can empathise with that. I certainly wouldn't think
ONE language can solve all problems, but I think the industry is
fragmenting into too many special-purpose hacks instead of trying to
identify the core linguistic / conceptual factors that enhance
productivity the most, without costing too much in hardware power.

> The increasing number of postings comparing Python to language X is I
> suppose a good thing: lots of people are kicking the tires and taking Python
> for a spin. I think we should encourage that, but not by comparing execution
> times of loops. We need to discourage the amateur programmer obsession with
> "performance" and "efficiency" as if those attributes are all that matter.

Totally agree. But Alex's article (the one you responded to) was about
the tradeoff between machine efficiency and programmer
efficiency. (Actually, Erann Gatt's followup re Lisp showed it to be a
correlation rather than a tradeoff).

I don't think advocates of higher level languages have any reason to
shy away from benchmarks on *that* level. 

Regards,
P.