Origins of the D Programming Language

[rjframe]

On Sat, 31 Aug 2019 20:03:20 -0400, Andrei Alexandrescu wrote:

> We have made good progress on our submission, in particular Mike got to
> use his literary gift some more. Our latest draft is here:
> 
> https://erdani.com/hopl2020-draft2.pdf
> 
> We would love some feedback, corrections, and historical details.
> Thanks!

I don't know the history (well, I do now), but am very opinionated; many 
of these are merely opinions; definite issues are prepended with "^" so 
you could skip to them easily if desired (I also didn't read the first 
draft or related NG posts so there could be repetitions from others in the 
past):


Unless the passive voice was requested, I'd recommend rewriting much of it 
in the active voice; instead of "these things happened because Walter", it 
should be "Walter did these things". Passive voice works well for stating 
objective facts or describing processes, but the active voice is better at 
expressing intent and actions.


Page 3, line 111: "[Walter] wasn't going to let a disagreement over API 
design render that history irrelevant."

We come to a climax, and leave it as a cliffhanger -- from here we step 
back in time and review elements of D's design for the next 22 pages (1080 
lines). Finally on page 25 (line 1191) we come back to the Phobos/Tango 
problem -- but wait, only one sentence in passing. One more page, then 
we're back to Tango (line 1243). It doesn't really resolve the climax; we 
go from Walter not willing to let library incompatibility kill the 
language to... somebody sets up a meeting, and they agree that something 
needs to change.

Final resolution comes on pages 29/30 when D2 makes it irrelevant.

Some possible ways to deal with this:
a: reduce the tension in the introduction
b: find a way to resolve the tension better (and earlier?)
c: try interweaving timelines (not an easy task to do well and would take 
time); go back and forth between the personal histories and technical 
history.


Depending on the context in which this will be published, I'd probably 
remove the introductory "As its name suggests" (line 7); only someone 
familiar with C/C++ or the history of programming languages would draw the 
link themselves. "The initial motivation for..." makes a decent starting 
place. It's also a little more forceful (which may not be desirable).

Line 8: s/those languages'/their/

Line 16: s/and to date only/and only/
Modern C++ is too complicated for one person to build a compiler for; the 
qualification is likely not necessary. "And only" is also more easily to 
interpret solely within the past -- unless Walter has a compiler 
conforming to modern C++, anything that could look like a challenge or 
modern comparison is disingenuous - but the historical claim is important.

Line 18: "Fittingly, D would use the by now..."
"The by now" is a bit awkward on the first reading; I'd simplify the 
sentence to: "D would use the Zortech C/C++ backend (optimizer and code 
generator) that had been..."

Line 23-24: History check (note: I was 11 in 1999, no personal memory here)
- IEEE floating-point: was the C/C++ backend always x86-based? If so, 
wasn't this decision more or less made for him?
- two's complement was pragmatically standard from the 70's forward, 
wasn't it?

^Line 25: s/transferrable/transferable/

Line 30: s/capability/its capabilities/, s/accretion/formation/ (?). 
End the sentence at "community"?

^Lines 32-33: s/open-source back ends/open-source compilers/
The compilers themselves and their respective backends have both been 
called "back ends" here.

Line 51: s/over/more than/

Lines 62-63: this reads like Andrei just sort of showed up and started 
doing stuff (i.e., he was not formally involved at this point). Would that 
be accurate? Changing to "who had joined the project" or something 
similar, that shows intent, would probably be better.

Line 67: remove "underlying the conference" and "at large"; it's somewhat 
repetitive and reduces the "oomph" of the sentence.

Lines 69: remove "in the community"; repetitive.

Lines 70-71: It's too passive. "Walter had been the sole developer and 
maintainer of the D language until Andrei joined in 2006; community 
contributions..."

^Line 81: s/good will/goodwill/

Line 104: s/as yet/as-yet/

Lines 110-111: This reads like it's rather dismissive of API design 
issues, which is a pretty big deal. I don't know what to do about it 
though.

"render that history irrelevant" might be better as some sort of "tear the 
language (community?) apart". The failure of the language wouldn't make 
his experience/knowledge/learning irrelevant.

Lines 121: s/one such/one such program/

Line 205: in what year? answered at #243 - 1999.

Line 270: So the GC IP belongs(ed) to someone else? At what point was it 
able to be Boost-licensed?

Line 303: s/ancestors/predecessors/

Line 309: s/syntax experienced/syntax that experienced/

^Line 324-325: not strictly true (see line 364)

Line 328: use the active voice: "D avoids common limitations and 
misfeatures such as the need for forward declarations..."

^341: s/D does not/as of 2019, D does not/
Limiting claims to the present can keep this accurate in the future, no 
matter what changes do or do not come to the language.


Lines 344-359: change to something like (mostly active voice) -

Although pointers are allowed, they are not encouraged; in many cases D 
provides memory-safe alternatives. For example, a pointer to an array does 
not tell you the length of the array, requiring that this information be 
kept elsewhere, either as a sentinel value or a length variable. History 
has shown that these methods are prone to human error, resulting in memory 
corruption and security vulnerabilities.

D's arrays are _fat pointers_, meaning they maintain the array's length 
behind the scenes. This means that D arrays could offer bounds-checked 
random access and subslicing (reducing the extent of the slice) “for 
free,” with no complex code instrumentation or type-checking cleverness. 
In contrast, C code using pointer/length or pointer/pointer pairs to 
represent arrays requires conventions to convey how pair elements are 
related and relies on the programmer to combine them correctly.


^Line 364: Contradicts lines 324-325.

Line 545-546: is it worth noting that D isn't the first to try bringing a 
GC to systems programming? e.g., Algol 68, Modula-3 -- well-known (at 
least by name) but unsuccessful languages, so I don't know if it helps to 
mention them or not.

Lines 702-712: needs active voice. e.g., -
Walter made stabilizing the core features a major priority, but did not 
let that stop him from introducing new features into the language.

Line 791: s/In D/In modern D/
Lines 782-799 seems to show that Walter defined "template" as what is now 
called an eponymous template utilizing a short-hand syntax (e.g., D 
templates were initially nothing more than cookie-cutter functions, but 
were later expanded). If so, we're conflating the original and current 
"template"s here.

^Lines 1128-1131: were two sentences merged here? I can't read this as a 
single thought.

Line 1220: s/hardcore//