Why I chose D over Ada and Eiffel

[Jesse Phillips]

Shuffling your reply.

On Tuesday, 20 August 2013 at 00:08:31 UTC, Ramon wrote:
> Huh? Of course contracts are *in* the functions/methods. 
> Typically (and reasonably) you have some kind of "in" contract 
> and an "out" contract, the former ensuring the function to work 
> on agreed and reasonable entry grounds, the letter ensuring 
> that the function exits in an "O.K." state. Plus, of course 
> invariants.

He is referring to where the compiler generates the code. When 
compiling a library it is at that point the contracts part of the 
code or not. In reality the user of the library should decide 
when the contracts are included (normally a debug build of a 
program would link a release build of the library, thus contracts 
would not be checked).

> I'm afraid I can't follow your "ranges making generic 
> algorithms possible" but I do agree that ranges are among the 
> more important strengths of D, greatly contributing to 
> useability and productivity.

I don't think anyone takes your criticism of D generics harshly, 
but many, like me, may feel confused on your issue with using 
templates for generics.

Personally I'm not familiar with Eiffel or some of the more 
eccentric polymorphic functions. I know my templates, Java/C# 
generics and object base polymorphic behavior.

You are correct, D documentation does not touch on how to use or 
structure code with interfaces or classes. While I couldn't take 
issue with having such documentation for D, this is a subject 
generally left to a text book or third party article (I would 
expect equal difficulty learning the subject from Java 
documentation).

Evidence for the statement, "ranges making generic algorithms 
possible" can be found in std.algorithms. This module provides 
many algorithms to perform against data and most (all?) make use 
of Ranges, keeping the algorithm generic from the data type being 
manipulated and even the container storing that data. The library 
also is mostly (100%?) templated.

In D it tends to be idiomatic to specify what you will use and 
not why structure you expect. So instead of:

     void foo(IComparable[] data)...

We write:

     void foo(Range)(Range data) 
if(isComparable!(ElementType!Range))...

Where isComparable would need to be defined and ElementType can 
be found in std.range.

So D's generics may be lacking, the ability to write generic 
algorithms is still there.