Using Python for programming algorithms

[bruno.desthuilliers at gmail.com]

On 19 mai, 15:30, Roel Schroeven <rschroev_nospam... at fastmail.fm>
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.