Why I chose D over Ada and Eiffel

[H. S. Teoh]

On Mon, Aug 19, 2013 at 10:18:04PM +0200, Ramon wrote:
[...]
> 25+ years ago I started with C. I loved it. But then I had a hacker
> attitude, considering "raw and tough" the only choice for a real man
> *g.

That was me about 20 years ago too. :)


> It took me more than 10 years to recognize (or allow myself to
> realize) that something was quite unsatisfying about C and that, as
> much as I understood the necessity of OO and strongly desired io
> employ it,  C++ was not a solution but rather pretty much all
> disadvantages of C repeated and then a major nightmare added or,
> excuse my french, a major pain in the a**.

Honestly, while OO definitely has many things to offer, I think its
proponents have a tendency to push things a little too far. There are
things for which OO isn't appropriate, but in languages like Java, you
have to shoehorn *everything* into the OO mold, no matter what. This
leads to ridiculous verbosity like:

	// Everything has to be a class, even if there's absolutely
	// nothing about main() that acts like a class!
	class MyLousyJavaProgram {

		// Are you serious? All this boilerplate just to declare
		// the main program?!
		public static void main(String[] args)
		throws IOException
		{
			// What, this long incantation just to print
			// "Hello, world!"??
			System.err.println("Hello world!");
		}
	}

The signal-to-noise ratio in this code is about 1 : 6 (1 line of code
that actually does the real work, 6 lines of boilerplate). Compare the
equivalent D program:

	import std.stdio;
	void main() {
		writeln("Hello world!");
	}

Even C isn't as bad as the Java in this case.

But I digress. Coming back to the point, C++ tries to do OO but fails
miserably because it insisted on backward-compatibility with C. This was
a smart move in the short term, since it helped C++ adoption from the
hordes of C coders at the time, but in the long run, this has hurt C++
so much by making it impossible to fix some of the fundamental design
mistakes that leads to C++ being the ugly monstrosity it is today.


[...]
> By coincidence (or fate?) I found myself confronted with a project
> demanding extreme reliability and reusability requirements. As much
> as I tried, C++ just couldn't cut it. One major reason might be
> interesting (or well known) to some of you: You basically can't rely
> in third party C++ code. Not meaning to talk bad about anyone but
> it's my bloody experience. Maybe it's because C++ makes it so hard
> to actually develop and engineer software (rather than hacking),
> maybe because C++ attracts guys like my earlier self (the cool C/C++
> hacker), whatever the reason may be, that's what I experienced.

Y'know, out on the street the word is that C is outdated and dangerous
and hard to maintain, and that C++ is better.  But my experience -- and
yours -- seems to show otherwise. You're not the first one that found
C++ lacking. At my day job, we actually migrated a largish system from
C++ back into C because the C++ codebase was overengineered and suffered
from a lot of the flaws of C++ that only become evident once you move
beyond textbook examples. (C++ actually looks rather nice in textbooks,
I have to admit, but real-life code is sadly a whole 'nother story.)


[...]
> So, I desperately looked for something that would offer at least
> some major goodies lik DBC and would otherwise at least not stand in
> the way of proper software engineering.
> 
> Well, that single feature, Design By Contract, led me toward D.
> 
> - practically useable modern Arrays? Check.
>   And ranges, too. And very smartly thought up and designed. Great.

Time will tell, but I believe ranges may be one of the most significant
innovations of D. It makes writing generic algorithms possible, and even
pleasant, and inches us closer to the ideal of perfect code reuse than
ever before.


> - Strings? Check
>   Plus UTF, too. Even UTF-8, 16 (a very practical compromise in my
> minds eye because with 16 bits one can deal with *every* language
> while still not wasting memory).

Yeah, in this day and age, not having native Unicode support is simply
unacceptable. The world has simply moved past the era of ASCII (and the
associated gratuitously incompatible locale encodings). Neither is the
lack of built-in strings (*cough*C++*cough*).


> - DBC? Check
>   And once more the creators of D don't simply address one issue but
> do it elegantly and, even better, sonsistently by throwing in a nice
> use cases solution, too. Great!

Hmm. I hate to burst your bubble, but I do have to warn you that DbC in
D isn't as perfect as it could be. The *language* has a pretty good
design of it, to be sure, but the current implementation leaves some
things to be desired. Such as the fact that contracts are run inside the
function rather than on the caller's end, which leads to trouble when
you're writing libraries to be used by 3rd party code -- if the library
is closed-source, there's no way to enforce the contracts in the API.


[...]
> - Some of the major GUI(s)? Check.
>   Well, I couldn't care less about Java (Is t possible to repeat all
> C problems creating yet another "C++" and invent a whole new slew of
> burdensome and weird sh*t? Sure, look at java!) but there seems to
> be a GTK binding.

This is one area that people complain about from time to time, though.
But I'm no GUI programmer so I can't say too much about this.


> - "defer mechanism"? Check.
>    I'm pondering about some smart defer mechanism since years. Et
> voilà, D offers the "scope" mechanism. Brilliant, just f*cking
> brilliant and well made, too!

The irony is that the rest of D is so well designed that scope guards
are hardly ever used in practice. :) At my work I have to deal with C
(and occasionally C++) code, and you cannot imagine how much I miss D's
scope guards. If I were granted a wish for how to lessen the pain of
coding in C, one of the first things I'd ask for is scope.


> - Genericity? Check
>   Genericity is a must, it's one of those things I'm just not
> willing to even discuss making compromises. Frankly, I like Eiffel's
> solution better but hey, D's solution is getting pretty close to
> what I consider excellent.

The lack of genericity is what kept me away from things like Java. Sure,
Java added their so-called generics after the fact, but it still leaves
much to be desired. Java's generics lack the power of C++ templates, and
that's a big minus for me (even though C++ templates are, frankly, an
utter mess, which gave templates the unfortunate reputation of being
hard to understand, when in fact, if they were done right like in D,
they're actually very natural to work with and extremely powerful).

Couple D's templates with other D innovations like signature constraints
and CTFE (compile-time function evaluation), and you have a system that
could trump C++ templates any day with one hand. This is one of the
areas where D really shines. You can write truly reusable code that
isn't straitjacketed or otherwise crippled.

Throw in UFCS (uniform function call syntax) into the mix, and you have
something where you can write functional-style code in D and still have
the efficiency of native compilation. :) Admittedly, this area of D is
still somewhat rough in some parts, but what's there is already pretty
impressive, and I believe will only get better as we iron out those
wrinkles.


[...]
> Criticism:
> 
> OK, I'm biased and spoiled by Eiffel but not having multiple
> inheritance is a major minus with me. D seems to compensate quite
> nicely by supporting interfaces. But: I'd like more documentation on
> that. "Go and read at wikipedia" just doesn't cut it. Please,
> kindly, work on some extensive documentation on that.
[...]

It would be great if you could contribute to the docs. Documentation is
one area where D doesn't quite shine -- which is a pity, because we have
such a great language in our hands yet people's first impression of it
may not be that great when they see the sorry state of our docs. Pull
requests to improve docs are greatly welcomed here. :)


T

-- 
I am a consultant. My job is to make your job redundant. -- Mr Tom