is it possible to learn D(2)?

[Jeff Nowakowski]

On 12/19/2010 01:44 AM, Andrei Alexandrescu wrote:
>
> I don't think it's worth investigating this, but at any rate my
> thinking has been that finalizing TDPL would finalize the
> specification of D2. Of course, ideally the compiler would follow
> the specification as closely as possible, but with the number of
> extant issues it has always been pretty clear that conformance will
> be trailing.

Always? It became clear at some point, but did you really not expect all 
the features to be fully implemented when you started the book?

How about this statement from you:

May 15, 2009: Re: Please Vote: Exercises in TDPL?

"One nice thing is I've written (in D!) a little script that extracts 
the code from all of my examples, compiles it, and runs it comparing the 
output with the expected output. The book will definitely have a number 
of faults, but code that doesn't work will not be one of them. [..] 
There's still stuff that doesn't compile (Walter is working on that)"

> The book hasn't been released quietly at all; I've sent numerous
> updates to this group (just search for TDPL in the title) and my
> website has made the event as prominent as it could.

I agree and retract my statement: the release wasn't quiet. What
stuck out in my mind was that there was talk of an imminent release, and
then weeks went by before somebody reported receiving the book. I guess 
that's just lag time in the publication process.

> Well I didn't give away "a lot" of books, I gave three, and
> specifically for the three most embarrassing questions.

It was 6. You mentioned the number at the very beginning of your talk. 
It is nice that you prodded for embarrassing questions.

> Another thing would be that I tend to focus on language power,
> because that's perennial, and consider implementation bugs something
> transitory.

People who hear a talk about something and want to try it out will very
much care about implementation bugs. You should warn them in advance,
especially for major bugs and unimplemented features.

> As of today I can't offhand think of a feature in TDPL that we don't
> know how to implement in D, and that topic is important.

Problems with theoretical designs are often found after implementation 
and usage. It's certainly been the case with D and immutability + 
concurrency. I sure hope you give an honest review at the next D talk. 
This is what you said about a Go programming talk on this newsgroup:

   "I'm surprised you found the talk compelling, as I'm sure you know 
better. The talk uses a common technique - cherry-picking examples and 
avoiding to discuss costs and tradeoffs - to make the language look good."

Maybe you can talk about all the problems that have been exposed with 
D's model of immutability. I think these statements from you would be a 
good starting point:

Aug 16, 2010: Re: The Status of Const

   "Const and immutable will be used less often than in C++. This might 
seem a weakness to those coming from C++ where const can and should be 
sprinkled often, but it is a natural consequence of the relative 
restrictions imposed by const in C++ vs. D. D's const is more 
restrictive, and as such will find its way in fewer idioms than C++'s."

Sep 17, 2010: Re: QtD is suspended

   "But by and large I think the matter could gave have be settled in a 
different manner: by not catering for const in the first release. D has 
a lot to offer besides const, and its const subsystem is a good bit more 
restrictive than e.g. C++'s, mainly to help with concurrency."