Why I chose D over Ada and Eiffel

[deadalnix]

On Thursday, 22 August 2013 at 12:37:50 UTC, Ramon wrote:
> Well in an OO language the actual type(s) is/are known. So real 
> genericity boils done to whether an object has the required 
> functions or not.
>

Polymorphism say no, you don't know the actual type, and this is 
the whole point of OOP : being able to interact with object of 
various type as long as they provide the needed interface to 
interact with.

> D has, obviously piously following the C++ way (which can be a 
> good thing), chosen to go the template way, that is, to handle 
> it compile time. Other languages have chosen to do it runtime 
> which is no worse or better per se but happens to be more 
> consistent with OO.
>

D recognize that OO isn't the only paradigm on earth. And generic 
won't work with non OO code.

> Some here argued that, well, in the end, say, a simple int and 
> a bank account, need different data types and operations 
> because it matters to CPUs whether it does sth. with a DWORD or 
> a char[]. And, so they argued, therefore you have to pay a 
> runtime penalty for real generics. I don't think so.
> Sure, one evidently pays a penalty for OO in general (as 
> opposed to simple scalars). But it's not the genericity that 
> costs.
>

Indirections, opaque calls, and heap allocation are probably the 
3 first performance killers on modern architecture. OO embrace 
the 3 of them.

> True OOP is basically about "It's the *data*!" while systems 
> programming understandably is closer to "it's the *code*!"
> Where the former has data "carrying the operations with them" 
> the latter has data as something that is fed in and processed 
> and spit out by the machinery. And it's that what brings up the 
> question "Well, but how would the CPU know what kind of data 
> it's working on? That requires expensive extra steps".
>

No true OOP is about behavioral abstraction. See Liskov's 
substitution principle. Data is merely a tool and OOP promote its 
encapsulation. In other term, data is an implementation detail in 
OOP.

> Again, for systems programming that's just fine. But the whole 
> penalty assumption largely stems from looking at true OOP 
> through the C/C++ model.

The whole penalty assumptions come from how actual compilers and 
CPU works. If you have new idea to revolution both and change the 
deal, great, but I highly doubt so.