D vs C++

[Andrei Alexandrescu]

On 12/27/10 2:57 AM, bearophile wrote:
> Je'rome M. Berger:
>
>> I have almost never used inline assembler even in languages that support it. Of course, this is only a sub-point of your point 6: using inline assembly in a language as slow as Python would be completely pointless.<
>
> For scientific computing this is better than D inline asm:
> http://www.corepy.org/
>
>
>> I would not count them as advantages per se. Some of their consequences might be seen as advantages once we have enough experience with them.<
>
> In Python frozensets, tuples, namedtuples and strings are built-in immutables. And it's easy to find frozendicts too. They cover many usages. (They are head-const, sometimes).
>
> And in the end Python design is based on different principles. If you look at Python and all you see is it lacking "const", "private" and "protected" then you miss the most important thing. A language doesn't fail because it lacks a feature, a language is like an old ecology, its parts are adapted to each other. This means that the lack of const is covered by other qualities of the language or its Zen. In practice I still create less bugs in Python than D. Google builds many systems using Python, and they work.
>
>
>> Python has it too (since 2.6 IIRC, see the "with" keyword). Moreover, Python makes it clear that RAII is happening by requiring a special syntax at the call point.<
>
> CPython GC is a reference counter (+ cycle breaker), so deallocations are often deterministic.
>
>
>> Cython gives it too: it is as easy to write a Cython interface module as to write a D interface file for a C library.<
>
> This is built-in:
> http://docs.python.org/library/ctypes.html
> It's not hard to embed or extend Python in C.
> Plus there are tens of ways of bridging the two, like SWIG, PIL, Boost Python, etc, plus there is ShedSkin, Cython, etc etc.
>
> -------------------
>
> Walter:
>
>> Templates are far more than just generics.
>
> But an army of people argue that using templates for more than generics is bad. In C++ you use templates for generic data structures and classes, for metaprogramming, for type-level computing, and probably for other things. For metaprogramming even D doesn't use templates much any more (after the introduction of CTFE), most other ways to perform metaprogramming are better than doing it with C++ templates. Type level computing is better done with staged compilation, a type to represent a type, more flexible type sytems, etc. See modern functional languages.
>
>
>> That happens at compile time.
>> That happens at run time. D's happens at compile time.
>
> Python has a wonderful advantage over D: there is no compilation! You write your code and you run it! So no need to let things happen at compile-time. If you want to pre-compute things you can just split your program in two levels and run a level before another, or use eval/exec. So Python is better here.
> No compilation, no problems :-) Generative programming in Python is way better than D :-)

With rdmd I have the feeling that you can say the same about D.

> Generally I don't post a message in a sub-thread like this. In the end what's the purpose of this sub thread? Is Python better than D? Who cares? They are very different languages, for different people doing different things. Even if D is ten times better than Python, the world will not stop using Python tomorrow. In future compiled languages, especially system languages that don't run on a VM will be just a small percentage of the whole computing world. They will not go away, but for any program written in C++ or D, in the next years people will write 1000 or more programs in JavaScript, Python, Ruby, PHP, VB, (and Java, C#). System languages are now a niche.

It's currently a growing niche as sequential speed doesn't scale anymore 
by Moore's law. Depending on the interplay of discoveries in the coming 
years, I believe it's not impossible that serial languages that spend 
CPU cycles on dynamic interpretation might become a historical curiosity 
caused by a fleeting context: (a) serial speed is large enough to allow 
wasting some of it, (b) I/O is much slower than CPU and dominates the 
performance profile of many programs, (c) many of today's computing 
needs are materially covered with relatively little CPU effort. Any and 
all such conditions may change in the future.


Andrei