Using Python for programming algorithms

[Roel Schroeven]

Wow this resulted in far more reactions than I had expected ...

bruno.desthuilliers at gmail.com schreef:
> 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 ?

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