Python future performance and speed

[Neuruss]

That's true. If that's what you'd said in the first place, nobody would

Hey, cut the boy/girl some slack. I suspect what s/he meant to say was:

It seems there are quite a few projects aimed to improve Python's
speed and, therefore, eliminate its main perceived limitation for
mainstream acceptance.

At least someone who got it right!!!
I thought this was the spanish inquisition...

 

[Neuruss]

OK guys.

Now that you've debated at length of the first question addressed by
Neuruss (Python limitations for mainstream acceptance), why not come
back to the other aspects addressed:

- dynamic languages getting closer to static languages in terms of
speed
- the future of Psyco, Pypy, Starkiller, Ironpython and other similar
projects.

( Thanks Arthur for getting this back on track... )

Regarding Starkiller, I'm eagerly waiting for its release.
I sent Mike Salib an email asking for the current state of the project
(this was by the end of june) and he kindly replied that he was
redoing some parts in an effort to make the code comprehendable and
maintainable.
According to him, it would be released in a few weeks.

IMHO, a static type inferencer with a c++ compiler for python would
completely change the position of python against other alternatives.
Just imagine having all the flexibility and dynamism of python with
near c speed.
Developers would start using it for problem domains that where
previously dominated by java, c++ or other static typed languages. And
all this without having to write any extension in C.
No more "python as a glue" language, or "python for quick on-time
scripts", this would stabilish it as a solid alternative for
performance critical applications (I know it's being already used for
many important projects--please don't start a flame war-- but still it
is considered by many as a language for simple things).
Mike Salib goes as far as stating than in two years, python will be
faster than C/C++.

I also have news about Ironpython. According to a comment posted by
Jim Hugunin in his new blog, he has high hopes about the combination
of static type inference and dynamic languages.

However, it is my impression that there's a little bit of distrust
about these claims (it's just my impression, I might be wrong).
I wonder what's the oppinion of the other participants of this mailing
list...

 

[Jacek Generowicz]

The last time I checked, Java and C++ (even C) were widely
considered to be high level languages.

The fact many people hold an erroneous belief, does not make said
belief any less erroneous.

Has someone been raising the bar while I wasn't looking?

The developers of all the truly high-level languages ?

There was a time when assembler was high-level.

 

[Jacek Generowicz]

(2) The Python approach to OOP is very different -- looser -- than
that of C++ and has less support for data hiding. For example, one can
add an attribute to an object anywhere, which seems like a dubious
freedom to me.

Seems like a damn useful freedom to me. But then I've worked with
people who refused to take the obvious clean, efficent, clear design
decision only because it violated some principle they were told about
in some OOA&D class ... only to insist on creating a program which was
slow, ugly, difficult to understand, difficult to maintain, and had a
few less useful features.

(3) The beginning of a Python function only tells you about the
arguments, not the result. I prefer not to scan the entire body of a
function to see what it returns. Compiled languages like C++, Fortran,
and Pascal put the argument and result info in one place.

And compiled lanugages like Lisp[1] and Python[2] don't. Oh, you meant
"explicitly statically typed", rather than "compiled", I see

But caring about the type to this extent is not a very productive way
of programming in Python. You should understand the purpose of the
function, and thereby understand the duck types it accepts and returns
.... and duck types are not expressible in a way that wouldn't make a
explicitly static compiler smoke.

Of course, those coming from the bondage school of programming (C++,
Java ...) will run screaming when confronted with duck typing, but
that's their loss.

(4) Python does not look like C++. Some programmers think that any
alternative to C++ must still look like it. I think this argument is
weak, but Java's cosmetic similarity to C++ probably has boosted its
popularity.

This is one of the greatest tragedies: C++ is accepted as the starting
point. We're doomed.



[1] Compiled to native machine code (usually).

[2] Compiled to bytecode (usually).

 

[Roy Smith]

Seems like a damn useful freedom to me. But then I've worked with
people who refused to take the obvious clean, efficent, clear design
decision only because it violated some principle they were told about
in some OOA&D class

Yeah, tell me about it. We had a really smart young guy who grew up on
C++ and was convinced that C++ was the be-all and end-all of OOP. He
told me flat out that Python was not an OOPL because it didn't have
private data. Of course, he never actually tried Python, because he
"just couldn't get past the whole indenting thing".

Then he quit and took a higher paying job with a big financial company
maintaining legacy Fortran code. Go figure.

 

[Peter Hansen]

The fact many people hold an erroneous belief, does not make said
belief any less erroneous.

Though if you are the only one who holds the "correct" belief,
and everyone else has the erroneous belief, it should suggest
a possible direction for you to look in resolving the conflict. ;-)

The developers of all the truly high-level languages ?

There was a time when assembler was high-level.

For those of us who still use assember from time to time,
C is definitely still a high level language...

-Peter