Wow this resulted in far more reactions than I had expected ...
[EMAIL PROTECTED] schreef:
On 19 mai, 15:30, Roel Schroeven <[EMAIL PROTECTED]>
wrote:
Bruno Desthuilliers schreef:
1/ being interpreted or compiled (for whatever definition of these
terms) is not a property of a language, but a property of an
implementation of a language.
2/ actually, all known Python implementations compile to byte-code.
You keep saying that, and in theory you're right.
"In theory" ??? Heck, both points above are mere facts. Well, I may
accept that the 2nd one is a bit overgeneralized, since IIRC there's
an experimental Python to javascript "compiler" in Pypy, but...
But I'm still inclined to disagree with it, since the practical reality is
different.
Do you mean that how source code written in a language (that is : a
grammar + a syntax) finally become a set of instructions executed by
a CPU depends on the language (I repeat : a grammer + a syntax), and
not on a piece of software turning the source code into something that
can actually be executed by the CPU ?
No, that's not what I said; what I said is that some languages where
designed with in the back of the head the idea that they were going to
be compiled to native code, others to be interpreted, and others to be
compiled to byte code.
Wikipedia says about C that "its design goals were for it to be compiled
using a relatively straightforward compiler, provide low-level access to
memory, provide language constructs that map efficiently to machine
instructions, and require minimal run-time support". To me, that very
strongly suggests that it was meant to be compiled to native code. It's
called "portable assembly" for a reason. You *can* make it work in
another way, and I suppose that it *is* done, but those implementations
are far in the minority.
As for Python, until the advent of PyPy all implementations I known used
a virtual machine (CPython, Jython, IronPython). And PyPy is still
experimental as far as I know.
So yes, the transformation method from source code to something that the
CPU understands depends on your tools. But if you want to get work done,
the most common method by far for C is to use a toolchain that compiles
to native code and for Python a byte code compiler + virtual machine.
With possibly a JIT compiler, that's true.
Python is
indeed compiled to byte code, but if you compare that byte code with
assembly code you'll see that there's a whole world of difference
between the two,
Obviously, yes - at least for all assembly language I've seen so far.
But whoever said otherwise ?
Whenever someone says that Python is interpreted, you respond saying
that that's not true, since it's compiled to byte code. Correct of
course, but somehow it appears to me that you imply that that makes
Python closer to a C-like language than to an interpreted language, and
that's not correct (IMO). If that's just a misinterpretation by me, I
apologize.
largely because of the dynamical nature of Python. Fact
is that Python was designed from the start to run on a virtual machine,
not on the native hardware.
Nope. The facts are that
1/ Python (the language) has *not* been designed with ease of
implementation of an optimizing native-code compiler in mind, and
2/ CPython (the first and reference implementation) has been designed
to use a byte-code + VM scheme
Isn't that more or less the same as what I said?
Maybe I don't make enough distinction between Python the language and
CPython the implementation, but Python development does happen on the
CPython implementation (Python 3.0 alpha releases are CPython releases,
for example).
C OTOH was designed to be compiled to assembly code (or directly to
machine code)
Note quite. C has been designed to make it as easy as possible to
write either a C to assembly or C to native binary code compiler.
I find it hard to believe that during the development of C Dennis
Ritchie was considering any other mode of operation than compilation to
assembly or machine code. I might be wrong of course.
and as a result there are no (or virtually) no
implementations that interpret C or compile it to bytecode.
There's at least one (possibly incomplete) C interpreter.
I'd like to call that the exception that confirms the rule.
There's a very naive belief we saw every here and then here, which is
that "Python would be faster if it was compiled to native code". The
point is that, given Python's (as a language) extrem dynamism,
compiling it to native code wouldn't buy you much in terms of raw
performances. The problem is not with writing a native-code
compiler[1}, but with writing an *optimising* native-code compiler.
I admit I'm guilty of that belief. I know it's true what you say, but I
do have the more-or-less unconscious reflex 'compiled to native code
== fast'.
I'm just getting fed up with
this "Python is an interpreted and therefore slow language" non-
sense. Python is a language, and as such is neither slow nor fast nor
interpreted nor compiled nor <insert any implementation related stuff
here>. And while CPython is not blazingly fast for computation-heavy
stuff, it's not because it is "interpreted" - which it is not for a
strict definition of "interpreted", but anyway... - but because
*optimizing* execution of an highly dynamic language is nothing,
well, err, trivial.
So you are saying that CPython is relatively slow because Python is a
highly dynamic language. I know that CPython is not Python and Python is
not CPython, but there is a very strong association between the two and
therefore I think it's not really that much wrong to simplify that to
'Python is slow because it is a highly dynamic language (until proven
wrong by PyPy or another fast implementation'.
--
The saddest aspect of life right now is that science gathers knowledge
faster than society gathers wisdom.
-- Isaac Asimov
Roel Schroeven
--
http://mail.python.org/mailman/listinfo/python-list
