Why I chose D over Ada and Eiffel

[Ramon]

On Thursday, 22 August 2013 at 07:59:56 UTC, qznc wrote:
> On Wednesday, 21 August 2013 at 16:21:47 UTC, Ramon wrote:
>> As for generics, let me put it this way:
>> In Eiffel generics have been an integral part of the language 
>> design from the beginning. In D ways and mechanisms are 
>> provided to achieve what quite usually is the goal of 
>> generics, namely generic algorithms in way, i.e. by having to 
>> write code for an algorithm just once. That might seem to be a 
>> minor difference, in particular when looking from a "Huh? I 
>> can get it done, so what's the fuss all about, eh?" 
>> perspective.
>> Of course, there the C and successors worlds proponents are 
>> right, this incurs a price (which templates do, too ...) and, 
>> yes, in the end, somewhere someone or something must sort the 
>> types out anyway (because of the way CPUs work).
>
> There are basically two ways to implement generics. Type 
> erasure (Java,Haskell) or template instantiation (C++,D). 
> Instantiation provides better performance, but sacrifices error 
> messages (fixable?), binary code size, and compilation 
> modularity (template implementation must be available for 
> instantiation). Type safety is not a problem in either approach.
>
> Longer form: http://beza1e1.tuxen.de/articles/generics.html
>
> An interesting twist would be to use type erasure for reference 
> types and instantiation for value types. Another idea could be 
> to use instantiation selectively as an optimization and erasure 
> in general.
>
>> Another example is data types, concretely integers. Ada offers 
>> a nice way do precisely nail down precision/storage. If I want 
>> to store days_of_month I can have an integer type holding ints 
>> between 1 and 31 (which, due to the way they implemented it 
>> can be a PITA). Eiffel gives me something quite similar (in a 
>> more elegant way) and additionally a "dumb" INTEGER (32 or 64 
>> bit) and than a gazillion subtypes like "INTEGER_16". That's 
>> great because in a quick and dirty script a plain integer (max 
>> size of CPU) is good enough and keeps life simple. If I need 
>> days_of_month I can very easily have that as int type.
>
> In D you can use structs:
>
>   struct days_of_month {
>     int day;
>     /* fill in operator overloading etc */
>   }


Thank you.

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.

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.

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.

Last but not least, there simply isn't a either/or issue. Once 
can perfectly well have both. And no, that doesn't necessarily 
bring a performance penalty with it.

Another point of view that doesn't match precisely but may help 
to understand it is this:

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".

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.