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
--
https://mail.python.org/mailman/listinfo/python-list
