Why I chose D over Ada and Eiffel

[Ramon]

On Monday, 19 August 2013 at 21:19:05 UTC, H. S. Teoh wrote:
> 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, ...

Nope, I don't belong to the OOP fanatics in the sense of 
"everything must be a class"; actually that's one of my critical 
remarks on Eiffel.
But, no doubt, OOP is an absolute must have. I remember my (seen 
from today pathetic) desperate attempts to use C at least in a 
somewhat OO way (abusing structs).

> ... C++ tries to do OO but fails
> miserably because it insisted on backward-compatibility with C.

I'm not sure that I can agree on that. I'll elaborate somewhat on 
this issue for reasons that directly touch D.

Actually C backward compatibility *could* have been implemented 
in D, too, if at quite some cost for the implementers; after all 
it's no coincidence that D feel pretty much "at home" for a C 
programmer - although the D people probably came to the 
conclusion that being similar enough was enough or even better 
than to go for full C compatibility (= capable to compile C code) 
and rightly so. I'm sure that basically every C programmer 
looking at another language doesn't look for another C but rather 
for something he can quickly master to a useable degree; 
otherwise he wouldn't be looking for another language in the 
first place.

As far as I'm concerned D's superiority over C++ has another 
reason: D was conceived from a _pragmatic approach_.

While it's a great thing to have scientists to design new 
paradigms and concepts it's, I'm convinced, a bad idea to have 
them actually go to the end; the perspectives, weighting of 
criteria and other issues usually happen to be a very different 
mix from what practical use would suggest.

Just look at C. We didn't miss so much new concepts and paradigms 
(except maybe OO) but rather were swearing at quite pragmatic 
aspects like lots of housekeeping overhead for resizing an array 
and many other things and at stupid problems related to pointers 
(like array being automatically being passed as pointers).
I remember quite well that when wanting proper error handling, 
some logging and maybe message strings in 2 languages one quickly 
ended up with most code not related to the algorithm or problem 
at hand but to those housekeeping chores and alike.

In summary my impression is that C++ was created by scientists 
who somehow shoehorned a set of (what they considered) concepts 
and paradigms into a language that looked good in lectures - but 
they didn't care sh*t about compiler writers and actual users who 
had to solve actual problems.
While many considered STL a breakthrough milestone for mankind I 
personally, Pardon me, always considered it a) a weird mess and 
b) a confession that C++ was f*cked up.


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

See my point above and: I couldn't care less what's the current 
hype in Dr.Dobbs or Computer Language (anyone remembers that?) or 
for that matter the "word on the street".

Actually I tought C at that time and I remember to comment 
students remarks concerning OO, C++ and the like along this line 
"C basically is a - pretty well done - attempt to create a cross 
platform assembler with quite some comfort". After all, this 
shouldn't be forgotten, C was created to use the wonderful new 
PDP11 (by brilliant men who had understood that a) there would be 
other architectures and systems to follow and b) one shouldn't 
have to learn 10 assemblers for 10 systems.
C++'s proponents stating that C++ was meant to be an better C 
with OO on top never had any credibility considering the 
background and origin and raison d'etre of C as far as I'm 
concerned.


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

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.

As for generics I still need to learn more about D but from first 
impressions and comments I'm not sure that D has reached a final 
and polished state there; possibly there might be even a point 
where the D guys decide to chose a completely new approach in D3. 
One thing is clear (well, to me at least), doing generics simply 
like templates will turn out to be a major limitation and 
sometimes even more of a problem than a solution; one ugly issue 
coming to mind is having "filled in" code spread all over the 
place.
Maybe I'm stubborn here but I do not agree with the usual 
approach of seing generics = templates = saving typing effort. 
Typing efforts are to be addressed by editors not by language 
designers. Generics are about implementing algorithms (that are 
not type dependent anyway).
Needing a min(), say for strings, ints and floats in a program 
one shouldn't end up with 3 times code but with code dealing with 
e.g. "any scalar" or even "anything comparable".

But again, I'm too fresh at D and, for instance, have to first 
learn a whole lot more (like interface mechanisms) before coming 
to a well based assessment.

>> - DBC? Check
>>   ...
>
> 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.

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.

The trouble with 3rd party libs, I don't see it. The lib provides 
contract terms along wih the API and that's it.

I do agree though (*if* I got that right in the docs so far) that 
there shouldn't simply be a "debugging - DBC on" or "production - 
DBC off". There should also be some direct mechanism for the 
developer to have certain contracts active even in production 
mode.

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

Can't follow there. If, for instance, I open a file I want to 
make sure that it's properly closed. That's nothing to do with 
the language but with the world our code runs in, no?

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

Well, while I'd be glad to contribute I'm afraid that's a dog 
biting his own tail problem. I need good doc to understand before 
I can explain to others ...

I'm afraid I'll have to fall on the nerves of the creators for 
that.