On Friday, 30 November 2018 at 19:34:58 UTC, Andrei Alexandrescu wrote:
> Over the past few months, Walter, Mike, and myself have been working on a draft submission for the HOPL 2020 conference (History of Programming Languages).
>
> The submission proceeds in several stages. Currently we've been through one round of preliminary review. Here is the current draft:
>
> http://erdani.com/hopl2020-draft.pdf
>
> We'd appreciate feedback and additional historical details.
>
>
> Thanks,
>
> Andrei (on behalf of Walter and Mike as well)

A final comment on historical details:

In the section on uniform function call syntax, the last sentence references recent proposals to add a uniform calling syntax to C++, but the wording suggests that this is currently a part of ISO C++, which it is not as the proposals have not been accepted yet.

Moreover, references to earlier proposals on this topic should be given. In particular Glassborow (2004), "N1585: Uniform Calling Syntax (Re-opening public interfaces)", was an early formal C++ proposal that identified the need for allowing free functions to be called with member function notation (albeit using a special annotation using "this" for such functions), and who first introduced (AFAIK) the term Uniform Calling Syntax (UCS) that this feature is now called. (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1585.pdf )

On Friday, 30 November 2018 at 19:34:58 UTC, Andrei Alexandrescu wrote:
> Over the past few months, Walter, Mike, and myself have been working on a draft submission for the HOPL 2020 conference (History of Programming Languages).
>
> The submission proceeds in several stages. Currently we've been through one round of preliminary review. Here is the current draft:
>
> http://erdani.com/hopl2020-draft.pdf
>
> We'd appreciate feedback and additional historical details.
>
>
> Thanks,
>
> Andrei (on behalf of Walter and Mike as well)

A comment on section 1.2, C & C++ connection:

When discussing the simplified template syntax used in D, as you would be aware, Stroustrup originally considered a simplified syntax with template arguments after the function name and using parentheses rather than angle brackets for C++.
He discusses his rationale for choosing the final design in section 15.7 of "The Design and Evolution of C++", 1994.
https://books.google.com/books?id=hS9mDwAAQBAJ&pg=PT418

IMO, this C++ rationale should be referenced and the D choices discussed relative to the C++ decisions of that time (which have become less relevant with increasing familiarity with template syntax).

On Tuesday, 18 December 2018 at 15:11:50 UTC, anon reviewer wrote:
> On Friday, 30 November 2018 at 19:34:58 UTC, Andrei Alexandrescu wrote:
>> Over the past few months, Walter, Mike, and myself have been working on a draft submission for the HOPL 2020 conference (History of Programming Languages).
>>
>> The submission proceeds in several stages. Currently we've been through one round of preliminary review. Here is the current draft:
>>
>> http://erdani.com/hopl2020-draft.pdf
>>
>> We'd appreciate feedback and additional historical details.
>>
>>
>> Thanks,
>>
>> Andrei (on behalf of Walter and Mike as well)
>
> A final comment on historical details:
>
> In the section on uniform function call syntax, the last sentence references recent proposals to add a uniform calling syntax to C++, but the wording suggests that this is currently a part of ISO C++, which it is not as the proposals have not been accepted yet.
>
> Moreover, references to earlier proposals on this topic should be given. In particular Glassborow (2004), "N1585: Uniform Calling Syntax (Re-opening public interfaces)", was an early formal C++ proposal that identified the need for allowing free functions to be called with member function notation (albeit using a special annotation using "this" for such functions), and who first introduced (AFAIK) the term Uniform Calling Syntax (UCS) that this feature is now called. (see http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1585.pdf )

very last comment on historical details:

inside the phase on uniform function call syntax, the final sentence references latest proposals to add a uniform calling syntax to C++, but the wording indicates that that is currently part of ISO C++, which it is not as the proposals have now not been usual but.

moreover, references to in advance proposals in this subject matter have to accept. particularly Glassborow (2004), "N1585: Uniform Calling Syntax (Re-opening public interfaces)", become an early formal C++ thought that identified the need for allowing loose capabilities to be known as with member characteristic notation (albeit the usage of a special annotation using "this" for such functions), and who first brought (AFAIK) the time period Uniform Calling Syntax (UCS) that this feature is now called.

On Friday, 30 November 2018 at 19:34:58 UTC, Andrei Alexandrescu wrote:
> Over the past few months, Walter, Mike, and myself have been working on a draft submission for the HOPL 2020 conference (History of Programming Languages).
>
> The submission proceeds in several stages. Currently we've been through one round of preliminary review. Here is the current draft:
>
> http://erdani.com/hopl2020-draft.pdf
>
> We'd appreciate feedback and additional historical details.
>
>
> Thanks,
>
> Andrei (on behalf of Walter and Mike as well)

I am getting back to stalking the D forum after a brief hiatus.

It was nice to see this article.  I will most certainly read it!
This coming Spring, I am once again going to use D in the Programming Languages course at Vassar.  I am assuming that it would be okay to circulate the version of this article, at the time, among the students.

Happy New Year D-ders!

--
Sameer

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!


Andrei

On 11/30/18 2:34 PM, Andrei Alexandrescu wrote:
> Over the past few months, Walter, Mike, and myself have been working on a draft submission for the HOPL 2020 conference (History of Programming Languages).
> 
> The submission proceeds in several stages. Currently we've been through one round of preliminary review. Here is the current draft:
> 
> http://erdani.com/hopl2020-draft.pdf
> 
> We'd appreciate feedback and additional historical details.
> 
> 
> Thanks,
> 
> Andrei (on behalf of Walter and Mike as well)

On Sunday, 1 September 2019 at 00:03:20 UTC, 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!
>
>
> Andrei
>
> On 11/30/18 2:34 PM, Andrei Alexandrescu wrote:
>> Over the past few months, Walter, Mike, and myself have been working on a draft submission for the HOPL 2020 conference (History of Programming Languages).
>> 
>> The submission proceeds in several stages. Currently we've been through one round of preliminary review. Here is the current draft:
>> 
>> http://erdani.com/hopl2020-draft.pdf
>> 
>> We'd appreciate feedback and additional historical details.
>> 
>> 
>> Thanks,
>> 
>> Andrei (on behalf of Walter and Mike as well)

Ranges are mentioned a few times, but I don't think what they are is explained. If there is space it would be worth defining the basic ranges and explaining the evolution from iterators to ranges

On Sunday, 1 September 2019 at 00:20:11 UTC, Max Haughton wrote:

>
> Ranges are mentioned a few times, but I don't think what they are is explained. If there is space it would be worth defining the basic ranges and explaining the evolution from iterators to ranges

I suppose some background is in order, not just for you Max, but for everyone looking to provide feedback.

This draft is significantly different in structure and scope from the first draft linked in the first post of this thread (where we did include a section on ranges, among other D2 features). When we were accepted to Round 2, it was conditional on the part of three of our reviewers. One of the things we got dinged on was that the paper was half a history and half a technical description of the language, which isn't what a HOPL paper should look like.

For round 2, they provided us a document that gave some examples of the sort of thing they're looking for, and it isn't technical writing. With that as a starting point and with inspiration from certain modern history authors, we restructured the paper into a coherent timeline with a focus on how some of the language features came together. We also kept the content inline with the title (the *origins* of D) and focused on the development of the language up to 1.00.

So descriptions of D2 features, and any features added to D1 after 1.00, are out of scope. We mention some of them in passing solely as a device to tie off some sections by referencing how a feature evolved or affected other future features, but they are never the focus. To the same purpose, we summarize some major D2 features at the end to tie off the paper.

Another point is that we want to avoid broader discussions of the language features we do cover. We've tried to keep them in context. For example, the section on mixin templates (which I'm still not entirely happy with) provides a description of the feature that's intended to a) contrast it with standard templates and b) show how it serves to cover a particular use case of the C preprocessor. The C preprocessor is established early on as something Walter wanted to avoid, and features that cover a particular use case are presented in that context. In other words, the details of a feature aren't as important to the document as how it came into being and, where appropriate, how it fits in to the original vision.

On Sunday, 1 September 2019 at 00:03:20 UTC, 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!

Line 829 should say `haystack.length` instead of `needle.length`.
Again on line 837 (or 838?).

Nitpicking a little, but maybe use D style for the code examples
(spaces after control keywords, Allman brace style, etc.)?

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//

On 2019-09-01 02:03, 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 found a few issues:

* Line 803. There's a typo in the code snippet. It should be "struct Point(T)" instead of "struct(T) Point". Unless this is some pre 2006 template syntax I'm not aware of.

* Lines 810-811. The parentheses less template instantiation syntax is a D2 feature. This has been explicitly noted for other D2 features

* Lines 983-1014. The "mixin template" syntax is D2 only, which has has been explicitly noted for other D2 features.

* Lines 1036-1039. String mixins is a feature that exists in D1 as well. During the D1 to D2 transition it was common to use a string mixin and a version statement to either mix in D1 code or D2 code for code bases that wanted to be compatible with both. It was necessary to use a string mixin in cases where the D2 code was not syntactically valid in D1.

I've verified this with a D1 compiler.

-- 
/Jacob Carlborg