>> 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,
I don't see any points. I see words.
> whereas they are rather *intervals*. And these intervals have large
> overlaps.
Add line segments as wide as you'd like.
> 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++.
I tend to think the opposite: C++ barely has a niche left. I definitely
wouldn't want to use C++ very far from its (very narrow) sweet spot.
> 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.
C++'s "gift" to programming was to take static typing to its utmost
limits -- to the detriment of usability, learnability and
intelligibility. STL and Boost have been turned into totems that
supposedly turn a dire necessity into a virtue.
C's give to programming is the void pointer. It's the antithesis of C++,
but damn does it get you out of every bind -- no fuss, no semantic
handwringing.
My disillusionment with C++ came from the language's inability to
represent callbacks. C can do it (void *), C# can do it (delegates),
Java can do it (anonymous inner classes), Python can do it (methods),
Scheme can do it (closures).
Qt needs callbacks ("signals" IIRC). It doesn't use C++ to express them.
It uses a fricking metacompiler for them.
And Stroustrup's thick book didn't even seem to be aware of callbacks as
a paradigm and thus didn't show any examples of dealing with them. Too
bad Stroustrup wasn't aware of C#'s delegates; C++ should have defined
function pointers as delegates.
> 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).
There is one big advantage C++ has over C: virtual method dispatching.
However, I have been able to come up with C idioms that make practical
method dispatching relatively painless.
Marko
--
https://mail.python.org/mailman/listinfo/python-list
