Using Python for programming algorithms

[Bruno Desthuilliers]

Roel Schroeven a écrit :
> 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.

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...