[OT] Python like lanugages [was Re: After C++, what with Python?]

[Tim Harig]

On 2011-01-18, Stefan Behnel <stefan_ml at behnel.de> wrote:
> Tim Harig, 17.01.2011 20:41:
>> One of the arguments for Python has always made is that you can optimize
>> it by writing the most important parts in C.  Perhaps that is a crutch
>> that has held the communty back from seeking higher performance solutions
>> in the language itself.
>
> The good news with Cython is that you no longer need to "write the most 
> important parts in C". Instead, you type them statically and compile them. 
> You don't even need to sacrifice Python source compatibility for that. So 
> you get the best of Python at the speed of C (or 'c', as some would say ;).

Well not quite.  The fact that you still need a Python interpeter should
tell you that the end result is not really just C.  Effectively, you get
the same thing that you might get from writing C modules for your
performance sensitive loops.  Cython just makes it a little easier to
generate the C modules; but, there is still a lot of Python operating under
the hood.

>> I prefer a single language as opposed to a creolization of two.
>
> With the possible exception of Lisp, I find it hard to think of a language 
> that's still alive and not the creolisation of (at least) two other 
> languages. They all inherited from each other, sometimes right from the 
> start ("lessons learned") and always during their subsequent life time.

I am not talking about language influences.  Cython effectively requires
two separate languages that interoperate.  The end result is a mix
of two code written in two separate langauges.  That is not a single
language solution.

>> I certainly don't need to require anybody who
>> wants to use a program I have compiled to install an interpreter.
>
> You will be happy to hear that you can link Cython programs against 
> libpython (even statically) to build an executable that embeds the 
> interpreter for you. Besides, on most operating systems, installing a 

Which means that you effectively end up with a py2exe style frozen binary.
While that is a nice hack for solving some problems, it is hardly an
elegant solution.  It still effectively means that I have to package a
redundant Python installation with every binary that I distribute.  I 
just don't have to write installation routines that check for, and
potentially install, a compatable version of Python.

> interpreter for you. Besides, on most operating systems, installing a 
> dependency is done automatically, and Go code doesn't run natively on 
> Windows either, without first installing and running the compiler over it.

Go works like C.  If I compile my code on Windows, then I can give the
binary to another Windows user and they can execute it without having to
install any additional software (gcgo currently compiles everything using
static binaries.  Since the linker only includes the fuctions you actually
use, you don't end up with the bloat of embedding entire libraries.
I am not sure about gccgo.).  The same holds true for Linux, BSD, OS X,
and any other supported OS.  Every go program includes a runtime componet
that provides the garbage collection; but, all of that is included as 100%
processor native code.  That is quite a bit different from having to
include an interpreter to run non-native code.