Why I chose D over Ada and Eiffel

[Ramon]

On Wednesday, 21 August 2013 at 14:38:41 UTC, Jesse Phillips 
wrote:
> On Wednesday, 21 August 2013 at 13:54:59 UTC, Ramon wrote:
>>> So D's generics may be lacking, the ability to write generic 
>>> algorithms is still there.
>>
>> As long as I can have "generics" and not merely a very smart
>> fill-in template system - or, even better, both - I'm content
>> enough.
>
> This is the statement which throws me. Templates are generic, 
> there is this feature called "generics" which is an 
> implementation to provide generic functions/classes (D does not 
> have). But the concept of making things generic is perfectly 
> achievable with templates.
>
> Since I don't know Eiffel I don't know the exact approach to 
> generics you're interested in, but D provides Templates to 
> handle generics.
>
> D also provides Interfaces and Inheritance for polymorphism, 
> which may be what is of interest to you, but those aren't 
> generics.
>
> I hope D does what you want well enough, but which how you talk 
> of generics I just don't know what you mean. And I don't write 
> this as an attack, only to try and explain my confusion. (maybe 
> others can correct my understanding).

Last thing first: Yes, it seems that I can achieve a quite 
comfortable compromise with D.

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

Actually, this point shows quite nicely what I consider the 
*real* issue behind it. In C/C++/D it's all about performance and 
other technical criteria. That is one valid was to look at 
things, no doubts. But there are others, too.
In Eiffel (and to a degree others) it's not about technical 
issues and details about about design and humans. It's simply a 
very different approach putting less weight on performance (which 
is not lousy, anyway) and more on reliability, proper design etc.

Would I use Eiffel for an RTOS on a 16bit CPU? No way. Would I 
use C++ for a critical application, say a medical ventilator? No 
way!

Actually, D, no matter how much one might fight me for saying 
that, goes a considerable distance to languages like Ada or 
Eiffel. The main difference is that the D people are maniac on 
performance (and staying C/C++-like enough) and implement those 
important mechanisms (so it seems to me) for very much different 
reasons than Ichbiah (Ada) or Meyer (Eiffel) and much as 
"extensions to C/C++/D" where Meyer et al. arrived from a very 
different point of interest.

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.

Which (what is another important paradigm/philosophy issue) also 
touches the question "Is it all about data or about code?". A 
question that might seem very philosophical (and with C kind 
programmers tending to answer "code, of course!") but can get 
quickly get very pragmatic and stinking ugly when you find 
yourself f*cked by having to open a (e.g.) Microsoft spreadsheet 
created with thecurrent software version and you only have an 
older version ...

Again, D (and even C++) *already has understood* those problems 
and created e.g. generics (such going a major step toward Eiffel 
and Co). They just implemented it "C style" with yet another 
cludge grafted on the maniacally protected C heritage and 
philosophy. Which, seen from another point of view can be an 
advantage (e.g. to C++ programmers wanting to feel home right 
away).

Looking at it from a long term perspective ( I think) both sides 
will give in somewhat. Eiffel will be less ivory tower and "D++" 
or "E" (or possibly "F") will be less machine room minded, taking 
in a whole lot of Eiffel (and others) stuff, yet not forgetting 
embedded systems and the like.
Such a step would, btw, not be a first. It has already happened 
to a large degree and here in D for another "world", namely 
functional mechanisms and fatures.