Which D features to emphasize for academic review article

[Jakob Ovrum]

On Sunday, 12 August 2012 at 10:39:01 UTC, Walter Bright wrote:
> No, it is not easier to understand, because there's no way to 
> determine if the intent is to:
>
> 1. initialize to a valid value -or-
> 2. initialize to get the compiler to stop complaining
>

If there is an explicit initializer, it means that the intent is 
either of those two. The latter case is probably quite rare, and 
might suggest a problem with the code - if the compiler can't 
prove your variable to be initialized, then the programmer 
probably has to spend some time figuring out the real answer. 
Legitimate cases of the compiler being too conservative can be 
annotated with a comment to eliminate the ambiguity.

The interesting part is that you can be sure that variables 
*without* initializers are guaranteed to be initialized at a 
later point, or the program won't compile. Without the guarantee, 
the default value could be intended as a valid initializer or 
there could be a bug in the program.

The current situation is not bad, I just think the one that 
allows for catching more errors at compile-time is much, much 
better.

> Of course they are capable of it. But experience shows they 
> simply don't.

If they do it for contagious attributes like const, immutable and 
pure, I'm sure they'll do it for a simple fix like using explicit 
'float.nan' in the rare case the compiler can't prove 
initialization before use.

> A better design would be to have pure be the default and impure 
> would require annotation. The same for const/immutable. 
> Unfortunately, it's too late for that now. My fault.

I agree, but on the flip side it was easier to port D1 code to D2 
this way, and that might have saved D2 from even further 
alienation by some D1 users during its early stages. The most 
common complaints I remember from the IRC channel were complaints 
about const and immutable which was now forced on D programs to 
some degree due to string literals. This made some people really 
apprehensive about moving their code to D2, and I can imagine the 
fallout would be a lot worse if they had to annotate all their 
impure functions etc.

> I believe there's a lot more potential for success when you 
> have a design where the easiest way is the correct way, and 
> you've got to make some effort to do it wrong. Much of my 
> attitude on that goes back to my experience at Boeing on 
> designing things (yes, my boring Boeing anecdotes again), and 
> Boeing's long experience with pilots and mechanics and what 
> they actually do vs what they're trained to do. (And not only 
> are these people professionals, not fools, but their lives 
> depend on doing it right.)
>
> Over and over and over again, the easy way had better be the 
> correct way. I could bore you even more with the aviation 
> horror stories I heard that justified that attitude.

Problem is, we've pointed out the easy way has issues and is not 
necessarily correct.