Roel Schroeven a écrit :
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.
I'd put it more simply : some languages were designed with low-level
access and raw performances in mind, and some were'nt. Roel, I'm totally
aware of these issues - on which you're of course right -, but that
doesn't change the fact that a language and it's implementation *are*
distinct things.
(snip)
So yes, the transformation method from source code to something that the
CPU understands depends on your tools.
And you can have different tools using different solutions for a same
language.
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.
Whenever someone says that Python is interpreted, I respond saying that
being interpeted or compiled is not a feature of a language, and that
CPython compiles to byte-code.
Correct of
course,
And that's the point : being correct.
but somehow it appears to me that you imply
I don't imply anything - except eventually that the person I'm
correcting should know better.
that that makes
Python closer to a C-like language than to an interpreted language,
Strange enough, no one calls Java or C# 'interpreted languages', while
they (or, to be more exact, their reference implementations) both use
the same byte-code/VM scheme[1]. You know, the commonly accepted
definition of "byte-code" is "something that is going to be passed to a
virtual machine", not "native binary executable code", so I don't think
this could be really misleading.
Now what you don't seem to get is the difference between pure
interpretation - where each and every statement is parsed and
interpreted again and again - and intermediate byte-code compilation.
Believe me, *this* can make a huge difference wrt/ performances.
Also and FWIW, there are quite a lot of "C-like languages" that are - in
their only or reference implementation - interpreted or compiled to
byte-code. For a definition of "C-like" being "close to the C language's
syntax and grammar" !-)
[1] Oh, and before some nut-case jump in : no, this doesn't imply that
the CPython VM is 'equivalent' to Sun's Java VM or MS CLI/.NET VM.
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?
Can't you tell the difference ???
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.
I'm not talking about "development" (which implies implementation), but
about the design of the *language*. Roel, can you define "language" ?
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.
Which rule ?
Oh, and yes - as a couple persons pointed out, there are actually more
than "one (possibly incomplete) C interpreter" - there are also the
llvm byte-code compiler+VM and the MS CLI C/C++ compiler.
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'.
So make a simple test : write a very Q&D cat-like program in Python, C
and Perl, and benchmark the three implementations. The results might
surprise you.
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.
And therefore difficult to optimize.
I know that CPython is not Python and Python is
not CPython, but there is a very strong association between the two
Indeed. CPython is the reference implementation of Python. Like GCC is
the reference implementation of C on linux platforms. etc...
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'
It is definitively wrong. How could a *language* be 'slow' or 'fast' ?
(until proven
wrong by PyPy or another fast implementation'.
You know, Common Lisp is also an highly dynamic language, and there are
now some optimizing native-code Common Lisp compilers that generate very
efficient binary code. It only tooks about 30 years and way more
ressources than CPython ever had to get there...
--
http://mail.python.org/mailman/listinfo/python-list
