Why I chose D over Ada and Eiffel

[QAston]

On Tuesday, 20 August 2013 at 16:40:21 UTC, Ramon wrote:
> Yes and no.
> While UTF-8 almost always is the most memory efficient 
> representation of anything beyond ASCII it does have a property 
> that can be troublesome a times, the difference between length 
> and size of a string, i.e. the number of "characters" vs. the 
> number of bytes used.
>
> ---
>
> As for another issue I'm getting more and more disappointed: 
> generics.
>
> To put (my mind) bluntly, D does *not* support generics but 
> rather went into the same ugly trap C++ went into, albeit D 
> handles the situation way more elegantly.
>
> Forgive me seeming harsh here but I just wrote it in the D gui 
> thread: Any really great solution needs a solid philosophy and 
> very profound thinking and consistency - and here D failed 
> bluntly (in my minds eye).
>
> With all due respect: Templates are an editors job, not a 
> compilers.
> Yes, templates offer some gadgets beyond simple replacement but 
> basically they are just a comfort thingy, relieving the 
> programmer from typing.
>
> That, however, was *not* the point about generics. They are 
> about implementing algorithms independent of data types (as far 
> as possible).
>
> Now, I'm looking around at mixins and interfaces in order to 
> somehow makeshift some kind of a halfway reasonable generics 
> mechanism. Yuck!
>
> Well, maybe it's my fault. Maybe I was foolish to hope for 
> something like Eiffel but more pragmatically useful and 
> useable, more C style and way better documented. What I seem to 
> have found with D is a *very nice* and *way better* and 
> considerably more useful kind of C++.
>
> Why aren't real generics there? I mean it's not that high tech 
> or hard to implement (leaving aside macho bla bla like "It'd 
> break the ranges system").
>
> why not something like
>
> generic min(T:comparable) { // works only with comparable 
> types/classes
>   // min magic
> }
>
> This could then at *run time* work with anything that met the 
> spec for "comparable" which basically came down to anything 
> that offers "equ" and "gt" (and "not").

Interfaces offer runtime resolution:

interface Comparable
{

}
void doStuff(Comparable c)
{
}
will work with anything that meets the specs for comparable.

For compile time resolution you can do this