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