On Fri, Dec 12, 2008 at 06:17:43AM -0800, sturlamolden wrote:
> None of those projects addresses inefficacies in the CPython
> interpreter, except for psyco - which died of an overdose PyPy.

Bullshit. All that discussion about performance forgets that performance is a 
function of the whole system, not the language.

Worse you can measure it really badly.

E.g. it's relative simple to compare CPython versus IronPython versus Jython. 
For a given benchmark program.

As programs do not trivially translate from language A to language B, nor does 
fluency in language A make you automatically fluent in
language B after learning the syntax.



> 
> PyPy is interesting if they ever will be able to produce something
> useful. They have yet to prove that. Even if PyPy can come up with a
> Python JIT, they will still be decades behind the technologies of
> Strongtalk and Java. That is the problem with reinventing the wheel
> all over again.

Well, it's reinventing the wheel. The problem that Java is a different kind of 
wheel 
(boxed vs. unboxed objects, plus more static compile time bindings), Smalltalk 
is also different (e.g. multiple inheritence),
so you need to have a specific toolbox for the wheel, sorry. Keeping and 
enhancing the tribal wisdom
about toolbox design is what a subtribe of the Computer Scientists do.

Btw, Psyco is not a JIT like most JVMs had them, it's a specializing compiler. 
JVM JITs traditionally speeded up the unboxed data 
type operations. Psyco does something comparable, but it has to specialize 
first on data types. The end effect is similiar, but the 
background of what happens is quite different.

> 
> Not to forget LLVM and Parrot which also will support Python
> frontends.
When they do, they'll do. There have flown quite a bit of Python version since 
the time that it was announced that
Parrot will have a Python frontend.

Andreas
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to