Frontup warning: Some of what I'll write is opinionated, not so much in the sense of being pro or anti (whatever) but rather based on experience and needs.

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.

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

Even worse, software development had grown from an obsessive hobby (I was an electronics engineer floating more and more toward software) to a profession and suddenly ugly real world factors like efficiency and productivity entered the equation.
While tools like CodeBuilder (a C++ "Delphi") seemed to promise a better life they didn't deliver that much; not because they were bad tool but because of C++.

- big jump -

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.

One obious (or seemingly obvious) solution was Ada. Well, no, it wasn't. Maybe, even probably, if I had to develop low level stuff for embedded stuff but not for a large application. And, that was a killer for me, Ada does not really support easily resizable arrays. To make things worse, while there nowadays is Gnat, a nice modern IDE, there is a major lack of libraries.

Falling over the famous Ariane 5 article I looked at Eiffel. I have to confess that I almost feel in love. Eiffel felt just right and Prof. Meyers books convinced me again and again - Yesss, that's the way I'd like to work and develop software.
Unfortunately, though, Prof Meyer and ISE (the Eiffel company) made some errors, too, and in a major way.
For a starter that whole Eiffel world is pretty much a large beautiful castle ... inmidst a desert. Theoretically there are different compilers, factually, however, ISE's Eiffelstudio is the only one; the others are either brutally outdated or non-conforming or weird niche thingies or eternally in alpha, or a mixture of those. And Eiffelstudio costs north of 5.000 us$. Sure there is a GPL version but that is available only for GPL'ed programs.
Next issue: Eiffels documentation is plain lousy. Yes, there are some 5 or so books but those are either purely theoretical or very outdated or both. Yes there is lots of documentation online but most of it basically is luring sales driven "Look how easy it is with Eiffel" stuff. And there is a doxygen like API doc which is pretty worthless for learning how to practically use the language.
Furthermore, while Eiffel comes with a lot on board there still is much missing; just as an example there are no SSL sockets which nowadays is a killer.

--- jump ---

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.
- 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).
- 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!
- some kind of reasonable support for modern concurrency? Check
  And again, not something thrown in that the creators of D religously consider right (like in Eiffel where Meyer basically force feeds his personal religious belief, although the "seperate" solution is elegant). Great!
- 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.
- "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!
- 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.

An added major plus is D's bluntly straight interface to C. And a vital one, too, because let's face it, not being one of the major players in languages basically means to either not have a whole lot of major and important libraries or else to (usually painfully) bind them. D offers an excellent solution and gives me the peace of mind to not paranoically care about *every* important library coming with it.


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.
(Probably there are some more not so great points but coming from a strong C background, D looks 95% "natural"; sure there are major differences but the creators of D have very nicely managed to offer an extremely comfortable approach for anyone with solid C experience. Probably it's more troublesome for newbies but that's something they should write down.).

Summary: 9 out of 10 points (using int; using double I'd make it 9.5 *g)

Sorry, this is a long and big post. But then, so too is my way that led me here; long, big, troublesome. And I thought that my (probably not everyday) set of needs and experiences might be interesting or useful for some others, too.
And, of course, I confess it, I just feel like throwing a very big "THANK YOU" at D's creators and makers. Thank you!

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

Ramon:

> not having multiple inheritance is a major minus with me. D seems to compensate quite nicely by supporting interfaces.

D is also supposed to gain multiple "alias this", currently only one is supported.

Bye,
bearophile

On 8/19/2013 2:17 PM, H. S. Teoh wrote:
> 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.

While not unique to D, I believe that ranges will become a killer feature - killer enough that languages that don't support pipeline programming will start looking like propeller driven airliners.

We still have a ways to go yet - Phobos support for ranges is not ubiquitous - but ranges are the future.

On Monday, 19 August 2013 at 22:00:17 UTC, Walter Bright wrote:
> On 8/19/2013 2:17 PM, H. S. Teoh wrote:
>> 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.
>
> While not unique to D, I believe that ranges will become a killer feature - killer enough that languages that don't support pipeline programming will start looking like propeller driven airliners.
>
> We still have a ways to go yet - Phobos support for ranges is not ubiquitous - but ranges are the future.

Is there an official "everything that sensibly can provide a range, should do" policy for phobos? If so, there's quite a bit of low-hanging fruit.

On 8/19/2013 3:10 PM, John Colvin wrote:
> On Monday, 19 August 2013 at 22:00:17 UTC, Walter Bright wrote:
>> We still have a ways to go yet - Phobos support for ranges is not ubiquitous -
>> but ranges are the future.
>
> Is there an official "everything that sensibly can provide a range, should do"
> policy for phobos? If so, there's quite a bit of low-hanging fruit.

There is as far as I'm concerned.

Note the holding back of std.serialization until it has full support for ranges.

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.

On 20/08/13 06:18, Ramon wrote:
> Falling over the famous Ariane 5 article I looked at Eiffel. I have to
> confess that I almost feel in love. Eiffel felt just right and Prof.
> Meyers books convinced me again and again - Yesss, that's the way I'd
> like to work and develop software.
> Unfortunately, though, Prof Meyer and ISE (the Eiffel company) made some
> errors, too, and in a major way.
> For a starter that whole Eiffel world is pretty much a large beautiful
> castle ... inmidst a desert. Theoretically there are different
> compilers, factually, however, ISE's Eiffelstudio is the only one; the
> others are either brutally outdated or non-conforming or weird niche
> thingies or eternally in alpha, or a mixture of those. And Eiffelstudio
> costs north of 5.000 us$. Sure there is a GPL version but that is
> available only for GPL'ed programs.
> Next issue: Eiffels documentation is plain lousy. Yes, there are some 5
> or so books but those are either purely theoretical or very outdated or
> both. Yes there is lots of documentation online but most of it basically
> is luring sales driven "Look how easy it is with Eiffel" stuff. And
> there is a doxygen like API doc which is pretty worthless for learning
> how to practically use the language.
> Furthermore, while Eiffel comes with a lot on board there still is much
> missing; just as an example there are no SSL sockets which nowadays is a
> killer.

I found similar issues with Eiffel plus I was turned off by the OOP only factor.  Programming needs to be more flexible than that.

BTW using Eiffel was where I first realized that contracts would never be as useful as I hoped.  They're still useful and I still use them but they're not as expressive as I'd hoped for (neither are D's).  In reality, they're just highly targeted unit tests.  I think my disappointment stems from the fact I used to write Z specifications and I would liked to have contracts that were the equivalent.

Peter

On 2013-08-19 23:17, H. S. Teoh wrote:

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

Oh, what I wish that was true. We're still struggling with encoding problems at work due to browsers and third party services and tools not being able to handle Unicode.

-- 
/Jacob Carlborg

On 2013-08-20 00:14, Walter Bright wrote:

> Note the holding back of std.serialization until it has full support for
> ranges.

I guess we won't see any std.serialization then. It cannot fully support ranges until the backend does, in this case std.xml.

-- 
/Jacob Carlborg