Python vs C++

[Christian Gollwitzer]

Am 22.08.14 11:29, schrieb Marko Rauhamaa:
> So my advise is, use as high-level programming language as you can. If
> you can't, deal with it, but often you can break your system into parts
> where only a small corner needs to be implemented at the low level.

Agreed. This is called Ousterhout's dichotomy.

> Remember, too, that there is a whole sliding scale of programming
> languages:
>
>     assembly
>         C
>            C++
>                Go
>                   Java/C#
>                       Python
>                           Scheme
>                               Bash


My point is that this picture is incomplete: it shows the programming 
languages as *points* on the complexity line, whereas they are rather 
*intervals*. And these intervals have large overlaps.

My picture:
as     |--|
c       |------------|
c++       |---------------------------|
java         |-------------------------|
python        |--------------------------------|


  * Assembly is really narrow: tiny loops, compiler output snippets, 
firmware for really small embedded devices - anything beyond should be 
written in higher languages.

* C has a much broader scope: you can do most of the tiny loops and 
firmware stuff, unless the device is too small or you are bootstrapping 
a kernel. But it also scales up until command line tools such as sort 
and even can do moderately complex programs like the CPython interpreter 
- even if that would be much easier to write in C++. I guess the only 
reason for CPython instead of C++Python is the better portability of C.

* C++ embraces all of C, and by that definition reaches from the low end 
up to GUI applications  - most modern everyday programs are written in 
C++ in large parts. At the low end, it looses some device driver stuff, 
because exceptions, RTTI and such features are incompatible with code 
running in the kernel of an OS. But it still can make good use of memory 
(class and struct have the same memory layout). On the high end, you can 
write programs managing high-level data structures without a single 
explicit pointer or "new" and "delete" in your code.

* Java: I don't see that it is much higher level than C++. It has a GC, 
but that's all, and you can have that in C++, too, if you want. On the 
other hand, you loose the metaprogramming facilities provided by C++ 
templates (needs a guru to make a library, but can be handy and easy to 
use, e.g. everything in Boost). You loose direct memory access, gaining 
what? no idea.

* Python: On the low end almost on par with Java, slower because of 
dynamic typing, no direct memory access. On the high end manages complex 
libraries with single few invocations, good support for functional-style 
programming (generators, list comprehensions), the first in this list 
with an acceptable REPL in the standard distribution - imagine assembly, 
C++ or even Java with a REPL

Scheme - only played with it some time ago, seems to me like the 
assembly of functional languages. Compare that to Haskell, which is an 
elaborate high-level language. I wouldn't claim that it is higher-level 
than Python.

> I think Python's abstraction level is excellent for most needs. C++ is
> squeezed from all sides. Its downfall is that it is trying to cover
> everything instead of just ceding the high-level turf to other
> languages. Thus, it is too elaborate for the nimble stuff, and you will
> often simply use C where you need nimble.

Ousterhout's dichotomy. It's a good paradigm in many cases, but 
sometimes it might be preferable to have everything in a single 
language. And this is a good domain for C++.

> C is readily supported by all extension APIs. Its calling conventions
> are stable and well-understood. Its runtime requirements are trivial.
> Plus, you don't have to be a Medieval Scholar to program in it.

I'm currently implementing a numpy-like library for another language in 
C. I choosed C for the ABI/portability reason, but I am really missing 
C++ in many, many places. The code is an awful mess of macros to get 
simple metaprogramming facilities, i.e. to support different data types 
and operations. This is a domain where C++ would be the best choice, and 
only the stupid reason of possible runtime dependency guided the 
decision to use C.

Everything which needs string processing, but still has to run fast, is 
another good candidate. Compilers are certainly less painful to write in 
C++ than in C, and could still run with native speed. For sure it is 
much easier to do a compiler in Python, but this will come with a speed 
penalty (of the compilation, not the code, as evidenced by PyPy).

	Christian