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 ? Or that there exists a (working and usable) implementation of the Python language that does not use an intermediate byte-code compilation ? If the latest, I'd happly recognize my error if proven wrong. But on the first point, I'm afraid that, well, a fact is a fact is a fact. > 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 ? > 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 > 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. > 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. FWIW, it would not be harder (and possibly simpler) to write a byte-code+VM based C implementation than it is to write CPython, Jython or IronPython. The point is that it's just useless - C is a (very) low- level language, and the only reason to use C is that you'll find a pretty good optimizing native-code compiler on almost any platform - sometimes even before the CPU physically exists. > I love Python, but IMHO it's a bit silly to maintain that the fact that > Python compiles to byte code instead of assembly code/machine code is > purely a matter of implementation; on the contrary, I believe it's a > result of its design. 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. FWIW, even Java with it's brain-dead static type-system gained more from JIT compilation in the VM than from being directly compiled to native code. [1] not that I would personnaly be able to do so in a reasonable amount of time, but given how many talented programmers have been and are still working on making as fast as possible Python implementions, it seems obvious that such a thing would already exists if there was any point working on it. > I also think that there's a large difference > between byte code and machine code No ? Really ? Now *this* is a scoop, you know ? <g> > (in Python's case; I haven't looked > at other languages), and that it's a bit silly to try to trivialize that > difference. I'm not trying to "trivialize" anything. 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. -- http://mail.python.org/mailman/listinfo/python-list
