www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Origins of the D Programming Language

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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)
Nov 30 2018
next sibling parent bauss <jj_1337 live.dk> writes:
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)


Just Wow! That's going to take some time to read.

Just skimmed through and it all looks well written and very 
informative.

Good job to the three of you!
Nov 30 2018
prev sibling next sibling parent reply Arun Chandrasekaran <aruncxy gmail.com> writes:
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)


D's default thread local is worth documenting (and may be 
concurrency by message passing doll supporting shared memory 
model).

std.parallelism is worth a mention too.
Nov 30 2018
parent Arun Chandrasekaran <aruncxy gmail.com> writes:
On Friday, 30 November 2018 at 21:54:17 UTC, Arun Chandrasekaran 
wrote:

 On Friday, 30 November 2018 at 19:34:58 UTC, Andrei concurrency 
 by message passing doll supporting shared memory model


s/doll/and also/
Nov 30 2018
prev sibling next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Fri, 30 Nov 2018 14:34:58 -0500, Andrei Alexandrescu wrote:

 We'd appreciate feedback and additional historical details.


The structure of the document doesn't reflect history. It also doesn't 
reflect the uniqueness of the described features; conditional compilation 
was present in C since time out of mind, for instance, and it's relatively 
high on the list.

Is there any logic to the order?

Line 658:

 mixin would just be an arcane way to write code, were it not for CTFE.


In point of fact, mixin predates CTFE. Templates could assemble strings at 
compile time. I used that technique in a couple ancient projects.

Line 698:

 In D, a user-defined attribute is a value of any type, as long as it is
 known during compilation.


Currently, a UDA is an *expression* that does not need to have a type. You 
can use a package or a module as a UDA. People commonly use a raw type as 
a UDA.

There is also a bug that lets you use non-compile-time-constants as UDAs 
as long as you insert a pragma(msg) in the right place, but that's 
probably not something you want to advertise in this document.

Line 708:

 To add one or more attributes to a declaration, the programmer uses the
 following syntax


The syntax demonstrated:

     ("Smith", 1.2, "2018-08-31") int myFunction(int x);

The implication I got from the text was that that was the only way to 
attach multiple annotations to a declaration. However, Java-style also 
works:

     ("Smith")  (1.2)  ("2018-08-31") int myFunction(int x);
Nov 30 2018
prev sibling next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
I'd point out under the version statement thing that setting 
versions (`version=identifier`) only works in one module. This 
avoids having to redo imports, like you have to with C's #define 
something followed by an #include. (this is page 12)

Fits in with the theme of D trying to avoid missteps of the past.


On page 18, you talk about VRP, but the only date given is 2017. 
As I recall, VRP was first added more like... 2008? I don't 
remember exactly, but it was definitely a long time before 2017.

When was unittest added? It has been there as long as I can 
remember. I kinda recall seeing "Design by contract" on the 
Digital Mars site as early as 2002, and I think D had those bits 
almost from the beginning. Might be good to confirm that - it is 
notable that D was ahead of the TDD fad. Downloading the oldest 
version of D source I can find, it proves it was indeed in the 
language from at least November 2002.

Also, `immutable` barely gets a reference at all, though I 
consider it to be one of the major turning points of the 
language! There was a LOT of talk about making thread safe stuff 
just work in 2007 and immutable was a big part of that... and one 
of the few that actually survived into general use (the unique 
stuff Bartosz was talking about was similarly big but we never 
did it).

I also like the history of immutable btw: remember when it was 
called "invariant" and why it changed?



And, it says early history is lost because of no version control. 
This is basically false - the changelog goes all the way back and 
contains zips of binaries and source of most those versions, the 
oldest being dmd 0.50 from Nov 20, 2002.

The backend source isn't there, but the frontend source is, along 
with compiled binaries. We can learn a lot from that if we want 
to dig a little.

https://digitalmars.com/d/1.0/changelog1.html#new038

it is kinda fun to pull an old version and see if any of your 
code still works on it :P
Nov 30 2018
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
Some good comments!

On 11/30/2018 2:23 PM, Adam D. Ruppe wrote:

 And, it says early history is lost because of no version control. This is 
 basically false - the changelog goes all the way back and contains zips of 
 binaries and source of most those versions, the oldest being dmd 0.50 from Nov 
 20, 2002.


By early history, I meant before 0.50.

A peculiar thing about my memory is I remember events and such, but do not 
recall when those events happened, unless there is some sort of anchor 
associated with it. In going through old emails, logs, etc., to attach dates to 
memories I was surprised at the actual order of things.

My father kept a diary of his WW2 experience. He told me that decades later, he 
read it and was shocked at how it contradicted his memories.

Github is such an indispensable tool. It's great for collaborative development, 
but nobody mentions how awesome it is to establish a provenance for when
changes 
were made and by whom. It ends the legal challenges I've had in the past trying 
to prove that someone had stolen code from me, when in fact they had stolen it 
from me.

(Just last month, having a registered copyright of the source code to Empire 
from 1978 saved my bacon yet again.)
Nov 30 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 30 November 2018 at 23:12:57 UTC, Walter Bright wrote:

 By early history, I meant before 0.50.


Oh, I see, early by your reckoning :P

I don't remember exactly when I first saw D, though I do know I 
first used dmc in either later 2000 or early 2001, and remember 
seeing D some time later when I went to download dmc again. I 
think it was 2003ish.

My first thought was "looks like Java, I'll pass" lol. Of course, 
I reevaluated that decision by 2006 and you know where that led :)


So yeah to me, early history is anything before 2005, but I can 
see how it is different to you.


 A peculiar thing about my memory is I remember events and such, 
 but do not recall when those events happened, unless there is 
 some sort of anchor associated with it. In going through old 
 emails, logs, etc., to attach dates to memories I was surprised 
 at the actual order of things.


Yes, indeed. I keep referencing times based on which church 
missionaries are here. They change every other month, whereas the 
rest of my life is similar. So I frequently am like "oh I made 
that when Kim and Kate were here..." then that anchors it. 
Probably sounds silly to the outside world, but it works fairly 
well for me.

Similarly, the reason I remember the dmc usage was because I had 
to use the high school's internet at the time, so being in that 
location adds to the memory. I never realized how recently my 
usage of it was compared to when Digital Mars was started though! 
wow.

My 2006 note is just because I pulled out my old hard drive and 
checked the last modify dates on some of those .d files! Before I 
did that though, I could have sworn I didn't use D until 2007.



 Github is such an indispensable tool.


Lemme slightly correct you here: it is git that tracks this stuff 
and distributes the history to several third parties who can 
corroborate you.

Github, of course, helps coordinate with those other people, and 
their brand name surely helps in recognition, but I don't wanna 
give it too much credit because I do think it is important that 
we remember that it can be replaced... and probably will replace 
them someday. (They would have recently gone under if not bailed 
out by Microsoft!) Specific companies come and go, but the 
underlying methodology outlives that.


 (Just last month, having a registered copyright of the source 
 code to Empire from 1978 saved my bacon yet again.)


awesome. I haven't played Empire for years. Maybe I should break 
it out again... but last time, I disappeared for a few whole days 
;)
Nov 30 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2018 3:55 PM, Adam D. Ruppe wrote:

 Github is such an indispensable tool.


 
 Lemme slightly correct you here: it is git that tracks this stuff and 
 distributes the history to several third parties who can corroborate you.
 
 Github, of course, helps coordinate with those other people, and their brand 
 name surely helps in recognition, but I don't wanna give it too much credit 
 because I do think it is important that we remember that it can be replaced... 
 and probably will replace them someday. (They would have recently gone under
if 
 not bailed out by Microsoft!) Specific companies come and go, but the
underlying 
 methodology outlives that.


I mentioned Github instead of just git because being a third party I think it 
would be very difficult to fake a Github provenance, while a git repository 
stored on your own disk would be fake-able.

As for switching to another repository, we imported to Github the data from the 
public repository we used at the time, and that would be done again were there
a 
better replacement for Github. So I'm not concerned about it.
Nov 30 2018
next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Fri, 30 Nov 2018 16:10:49 -0800, Walter Bright wrote:

 On 11/30/2018 3:55 PM, Adam D. Ruppe wrote:

 Github is such an indispensable tool.


 
 Lemme slightly correct you here: it is git that tracks this stuff and
 distributes the history to several third parties who can corroborate
 you.
 
 Github, of course, helps coordinate with those other people, and their
 brand name surely helps in recognition, but I don't wanna give it too
 much credit because I do think it is important that we remember that it
 can be replaced... and probably will replace them someday. (They would
 have recently gone under if not bailed out by Microsoft!) Specific
 companies come and go, but the underlying methodology outlives that.


 
 I mentioned Github instead of just git because being a third party I
 think it would be very difficult to fake a Github provenance, while a
 git repository stored on your own disk would be fake-able.


Github seems to trust whatever you give it. For example:

https://github.com/ldc-developers/ldc/commits/master?
after=fe76eeee4e17cc4df8fb08016f55fbad7ffe723c+419

Those commits are from before Github existed.
Nov 30 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 30, 2018 at 04:10:49PM -0800, Walter Bright via Digitalmars-d wrote:

 On 11/30/2018 3:55 PM, Adam D. Ruppe wrote:

 Github is such an indispensable tool.


 
 Lemme slightly correct you here: it is git that tracks this stuff
 and distributes the history to several third parties who can
 corroborate you.
 
 Github, of course, helps coordinate with those other people, and
 their brand name surely helps in recognition, but I don't wanna give
 it too much credit because I do think it is important that we
 remember that it can be replaced... and probably will replace them
 someday. (They would have recently gone under if not bailed out by
 Microsoft!) Specific companies come and go, but the underlying
 methodology outlives that.


 
 I mentioned Github instead of just git because being a third party I
 think it would be very difficult to fake a Github provenance, while a
 git repository stored on your own disk would be fake-able.


[...]

Github provenance is only reliable if someone has forked your repository
before the date of contention, because you can `git push --force` to
rewrite history, if you were so inclined. I know for sure this works on
topic branches; don't know if they block the master branch (unlikely).

Well, a 3rd party forking your repo still doesn't guarantee provenance,
because one might be accused of corroborating to rewrite history over
multiple forks.  But it's so much harder (and tedious) to pull off (3rd
parties are unlikely to cooperate on such an obvious subversion attempt,
and on top of that they will REALLY HATE you for breaking their git
pulls), so I guess it could be "reliable enough".  And with the number
of forks the various D-related repos have, it's pretty much proven that
there's no funny business going on, if this should ever become a point
of doubt.


T

-- 
I am not young enough to know everything. -- Oscar Wilde
Nov 30 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2018 4:29 PM, H. S. Teoh wrote:

 Github provenance is only reliable if someone has forked your repository
 before the date of contention, because you can `git push --force` to
 rewrite history, if you were so inclined. I know for sure this works on
 topic branches; don't know if they block the master branch (unlikely).
 
 Well, a 3rd party forking your repo still doesn't guarantee provenance,
 because one might be accused of corroborating to rewrite history over
 multiple forks.  But it's so much harder (and tedious) to pull off (3rd
 parties are unlikely to cooperate on such an obvious subversion attempt,
 and on top of that they will REALLY HATE you for breaking their git
 pulls), so I guess it could be "reliable enough".  And with the number
 of forks the various D-related repos have, it's pretty much proven that
 there's no funny business going on, if this should ever become a point
 of doubt.


I've wanted to create a Github history out of 35 years of random backups of my 
compiler, but never have gotten around to it.
Nov 30 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 30, 2018 at 04:29:35PM -0800, H. S. Teoh via Digitalmars-d wrote:

 On Fri, Nov 30, 2018 at 04:10:49PM -0800, Walter Bright via Digitalmars-d
wrote:


[...]

 I mentioned Github instead of just git because being a third party I
 think it would be very difficult to fake a Github provenance, while
 a git repository stored on your own disk would be fake-able.


 [...]
 
 Github provenance is only reliable if someone has forked your
 repository before the date of contention, because you can `git push
 --force` to rewrite history, if you were so inclined. I know for sure
 this works on topic branches; don't know if they block the master
 branch (unlikely).


[...]

Also, this assumes that the original commits weren't fudged to begin
with, before pushing to Github.  After all, git *does* let you override
the date(s) stored in each commit.  And one could set the hardware clock
to a different time, etc..

So it's not a 100% guarantee by any means, but there's a sliding scale
of increasing unlikelihood that, past a certain point, would just have
to be taken on faith barring circumstantial evidence that indicate
otherwise.


T

-- 
One reason that few people are aware there are programs running the internet is
that they never crash in any significant way: the free software underlying the
internet is reliable to the point of invisibility. -- Glyn Moody, from the
article "Giving it all away"
Nov 30 2018
parent Walter Bright <newshound2 digitalmars.com> writes:
On 11/30/2018 4:42 PM, H. S. Teoh wrote:

 So it's not a 100% guarantee by any means, but there's a sliding scale
 of increasing unlikelihood that, past a certain point, would just have
 to be taken on faith barring circumstantial evidence that indicate
 otherwise.


That's right. And once people start forking a repository, it becomes nearly 
impossible.

I also bet that Github themselves have backups going back years, so they could 
produce evidence if the provenance has been tampered with.

All in all, it's infinitely better than "I have a copy from 1992 on this floppy 
disk".
Nov 30 2018
prev sibling parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Friday, 30 November 2018 at 22:23:33 UTC, Adam D. Ruppe wrote:


 Also, `immutable` barely gets a reference at all, though I 
 consider it to be one of the major turning points of the 
 language! There was a LOT of talk about making thread safe 
 stuff just work in 2007 and immutable was a big part of that... 
 and one of the few that actually survived into general use (the 
 unique stuff Bartosz was talking about was similarly big but we 
 never did it).


I think that thread local by default should be mentioned also...


 I also like the history of immutable btw: remember when it was 
 called "invariant" and why it changed?


It was renamed just for clarity, when someone got confused about 
it, the explanation was always something like "it's simple an 
immutable value, like ROM"
Dec 01 2018
next sibling parent reply Kagamin <spam here.lot> writes:
On Saturday, 1 December 2018 at 08:22:57 UTC, Paolo Invernizzi 
wrote:

 I also like the history of immutable btw: remember when it was 
 called "invariant" and why it changed?


 It was renamed just for clarity, when someone got confused 
 about it, the explanation was always something like "it's 
 simple an immutable value, like ROM"


AFAIK, it was renamed for consistency with unittests, otherwise 
invariant blocks required braces: invariant(){ ... } or it would 
be ambiguous with block attribute.
Dec 01 2018
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 1 December 2018 at 09:52:50 UTC, Kagamin wrote:

 On Saturday, 1 December 2018 at 08:22:57 UTC, Paolo Invernizzi 
 wrote:

 I also like the history of immutable btw: remember when it 
 was called "invariant" and why it changed?


 It was renamed just for clarity, when someone got confused 
 about it, the explanation was always something like "it's 
 simple an immutable value, like ROM"


 AFAIK, it was renamed for consistency with unittests, otherwise 
 invariant blocks required braces: invariant(){ ... } or it 
 would be ambiguous with block attribute.


Yes, invariant block used to have braces...
Or at least I think to remember a big code session devoted to 
"delete the invariant braces" in the codebase...

Oh well...
Dec 01 2018
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 December 2018 at 08:22:57 UTC, Paolo Invernizzi 
wrote:

 It was renamed just for clarity, when someone got confused 
 about it, the explanation was always something like "it's 
 simple an immutable value, like ROM"


Indeed. It was invariant to avoid making a new keyword, but since 
invariant() and invariant(stuff) ended up meaning something 
different, and people kept saying "what is an invariant variable" 
and the answer was "it is immutable"... they just changed it to 
immutable.

Now, the addition of this was not the split point of D1 and D2 
(though I would point out that split was more like a version 
forked off and called itself D1 while the language in general 
kept changing like it always had - the article there called it 
"arbitrary" which is totally true), but it was really close to 
it, like a couple months later, and I consider it to be the main 
breaking change of that "era" (in addition to a bunch of 
functions being renamed in Phobos, which was really annoying but 
less fundamental). Very little code before and after the addition 
of invariant would actually still work, since the type of string 
changed!

(Though again, invariant/immutable was actually added *before* 
the type of string actually changed; there were a few releases in 
this process.)



The other notable thing though was how all this stuff I think is 
so analogous to the memory safe talk of today. Thread safe by 
default was a huge talking point. For a couple years, everyone 
was throwing out fancy proposals, tons of major stuff was added 
(including several big breakages), the TDPL book was published 
promising more like `shared` meaning something. We were told this 
is the future of programming - multicore is the big thing, no 
more serial processors. If D is going to go anywhere it MUST 
capture this. Comparisons with Erlang all around.

But where are we now? Those features are there... but were they 
the revolution? I'd say no. In fact, most people seem to simply 
ignore them and carry on.


And now, memory safety is trumpted as the next big thing that D 
MUST capture. Comparison with Rust all around. (Never mind that D 
has basically already solved memory safety with a well-known, 
widely-implemented traditional solution: conservative garbage 
collection.) Many features being added.

But where do you think we'll be in five years? I know my guess.
Dec 01 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 01, 2018 at 04:13:20PM +0000, Adam D. Ruppe via Digitalmars-d wrote:
[...]

 The other notable thing though was how all this stuff I think is so
 analogous to the memory safe talk of today. Thread safe by default was
 a huge talking point. For a couple years, everyone was throwing out
 fancy proposals, tons of major stuff was added (including several big
 breakages), the TDPL book was published promising more like `shared`
 meaning something.  We were told this is the future of programming -
 multicore is the big thing, no more serial processors. If D is going
 to go anywhere it MUST capture this. Comparisons with Erlang all
 around.
 
 But where are we now? Those features are there... but were they the
 revolution? I'd say no. In fact, most people seem to simply ignore
 them and carry on.


IMO, one of the main reasons people ignore these features and carry on
as before is because of the lack of an abstraction that's easy to reason
about and apply in everyday programming.

Thread-safety, with the current abstractions, is exceptionally hard to
reason about, full of hidden gotchas, tricky semantics, and side-effects
that "leak" through the abstractions.  People have difficulty "thinking
in these terms", i.e., using these facilities in a pervasive way,
because it's just so counter-intuitive. It's like being forced to speak
in a foreign language. Some people may be able to throw down the
gauntlet, take the bull by the horns, and learn the idiom despite of the
difficulties, and become masters of it. But the majority of programmers
will simply resort to "learning just enough foreign words to get by"
(the bare minimum constructs needed to make threaded code work), and
revert to a more comfortable idiom (traditional serial programming) for
everything else.

It won't be until an abstraction is invented for threaded computation
that's (1) intuitive to write without feeling like you're walking on a
minefield, and (2) easy enough to reason about that you can reliably
predict the consequences of any arbitrary combination of threaded
constructs, that this kind of programming will be adopted by the general
programmer population.

The recent "nursery" idea from a Python library that somebody posted
here seemed to be a promising step in this direction. But still, it
doesn't seem to be quite there yet.



 And now, memory safety is trumpted as the next big thing that D MUST
 capture. Comparison with Rust all around. (Never mind that D has
 basically already solved memory safety with a well-known,
 widely-implemented traditional solution: conservative garbage
 collection.) Many features being added.
 
 But where do you think we'll be in five years? I know my guess.


Memory safety is much more than merely having a GC instead of doing
malloc/free by hand.

There's also the pervasive design mistake of C, carried over to C++ and
some other C derivatives, of conflating arrays with pointers (with no
bounds), leading to buffer overruns everywhere.  Having worked with
C/C++ code for more than a decade, I'd hazard a guess that your average
C codebase is probably full of hidden buffer overflows that you just
haven't realized are there yet, and with more looming on the horizon
because it's just so easy to pass the wrong length with the pointer to
your array, or, in bad cases, passing just a bare pointer with no
guarantees that the function receiving the pointer won't write beyond
the end of the buffer.  D solved this major hole from day 1 by making
arrays always carry length around, thus freeing the programmer from the
mental burden of keeping track of array sizes and passing the right
sizes with the right pointers.

These two probably constitute the underlying causes of the majority of
memory unsafety bugs in software. But there are others, like casting
untyped memory (or memory of a different type) to/from typed memory
correctly. This is partially addressed by various small but important
details, like T[] converting to void[] with implicit length adjustment
(implemented in druntime), APIs like std.stdio's rawRead/rawWrite that
use templates to retain type information (with underlying void[]
conversions that benefit from implicit length adjustment), etc.. The
remainder, like returning references to local variables, have still to
be fully addressed by things like the oft-maligned DIP1000.

Essentially, D has already taken care of two of the biggest causes of
memory corruption, and solved a good number of the other causes. But
there are still holes that remain that need to be fixed before we are
100% memory safe.

But if you're expecting a "revolution" from this, don't be surprised at
disappointment, because at the end of the day, what we're doing is
simply to take care of these issues "under the hood", so that your
average D coder doesn't even need to think about memory safety issues
and they can reap its benefits more-or-less implicitly.  It goes along
with Walter's philosophy from airplane design: the intuitive way to
write code will be the correct (memory-safe) way; it will be either
impossible or require actual effort to write memory-unsafe code.  We
want to avoid C++'s mistake, where due to legacy issues the
straightforward way to write code is almost always the wrong way, and
writing correct C++ code requires a lot of effort and care on the part
of the programmer. D's goal is to make the straightforward way correct
by default, and to make incorrect code stick out like a sore thumb.
(Whether it achieved / will achieve this, of course, is a different
discussion.)

So in this sense your bet is right on: in 5 years (and IMO, that's
pretty optimistic) nobody will even notice memory safety because it will
already be there by default, and will be (mostly) implicit, so you reap
the benefits even without necessarily being aware of it. That would be
the sign of our success. But OTOH if in 5 years people are still talking
about memory safe issues in their D code, that's a sign that  safe has
failed.


T

-- 
Живёшь только однажды.
Dec 01 2018
prev sibling next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Nov 30, 2018 at 02:34:58PM -0500, Andrei Alexandrescu via Digitalmars-d
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.


[...]

Lines 1049-1050: I wasn't there at the time, so this may be inaccurate,
but I clearly remember someone mentioning that Tango has been ported to
D2 and is quite usable, at least as of a few years ago.  But I haven't
tried it myself, so I can't for sure whether this is actually the case.
But it's worth checking so that the HOPL document is factually accurate.


T

-- 
Не дорог подарок, дорога любовь.
Nov 30 2018
next sibling parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 1 December 2018 at 01:00:00 UTC, H. S. Teoh wrote:

 On Fri, Nov 30, 2018 at 02:34:58PM -0500, Andrei Alexandrescu 
 via Digitalmars-d wrote:

 [...]


 [...]

 Lines 1049-1050: I wasn't there at the time, so this may be 
 inaccurate, but I clearly remember someone mentioning that 
 Tango has been ported to D2 and is quite usable, at least as of 
 a few years ago.  But I haven't tried it myself, so I can't for 
 sure whether this is actually the case. But it's worth checking 
 so that the HOPL document is factually accurate.


 T


I'm pretty sure thats ocean, or at least ocean is descended from 
Tango

https://github.com/sociomantic-tsunami/ocean/
Nov 30 2018
parent Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Saturday, 1 December 2018 at 01:13:14 UTC, Nicholas Wilson 
wrote:

 I'm pretty sure thats ocean, or at least ocean is descended 
 from Tango

 https://github.com/sociomantic-tsunami/ocean/


Ahh, right there in the readme.


 Ocean began life as an extension of Tango, some elements of 
 which were eventually merged into Ocean.
Nov 30 2018
prev sibling next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
On Fri, 30 Nov 2018 17:00:00 -0800, H. S. Teoh wrote:

 Lines 1049-1050: I wasn't there at the time, so this may be inaccurate,
 but I clearly remember someone mentioning that Tango has been ported to
 D2 and is quite usable, at least as of a few years ago.  But I haven't
 tried it myself, so I can't for sure whether this is actually the case.
 But it's worth checking so that the HOPL document is factually accurate.


It's updated to roughly 2.068, I think, and doesn't really compile beyond 
that.

I tried to update it to the most recent DMD, but that was painful. If I 
try in the future, I'll probably go one major release at a time.
Nov 30 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 01, 2018 at 01:14:58AM +0000, Neia Neutuladh via Digitalmars-d
wrote:

 On Fri, 30 Nov 2018 17:00:00 -0800, H. S. Teoh wrote:

 Lines 1049-1050: I wasn't there at the time, so this may be
 inaccurate, but I clearly remember someone mentioning that Tango has
 been ported to D2 and is quite usable, at least as of a few years
 ago.  But I haven't tried it myself, so I can't for sure whether
 this is actually the case.  But it's worth checking so that the HOPL
 document is factually accurate.


 
 It's updated to roughly 2.068, I think, and doesn't really compile
 beyond that.
 
 I tried to update it to the most recent DMD, but that was painful. If
 I try in the future, I'll probably go one major release at a time.


So I'm guessing that other than Sociomantic(?), there aren't any other
major codebases out there that use Tango?


T

-- 
My program has no bugs! Only undocumented features...
Nov 30 2018
next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Fri, 30 Nov 2018 17:23:33 -0800, H. S. Teoh wrote:

 So I'm guessing that other than Sociomantic(?), there aren't any other
 major codebases out there that use Tango?


Probably nothing that's currently maintained. But if you're porting 
something ancient, it's handy to have around.
Nov 30 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-12-01 02:23, H. S. Teoh wrote:


 So I'm guessing that other than Sociomantic(?), there aren't any other
 major codebases out there that use Tango?


I'm using it in DVM [1], but I wouldn't say the code base is that big. 
DWT [2] also used to support D1 using Tango alongside the D2 support. 
The D1 code is still there but I don't know if it still works. DWT is 
quite a big code base 400k lines of code, IIRC.

[1] https://github.com/jacob-carlborg/dvm
[2] https://github.com/d-widget-toolkit/dwt

-- 
/Jacob Carlborg
Dec 01 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 30, 2018 6:23:33 PM MST H. S. Teoh via Digitalmars-d 
wrote:

 On Sat, Dec 01, 2018 at 01:14:58AM +0000, Neia Neutuladh via Digitalmars-d 


wrote:

 On Fri, 30 Nov 2018 17:00:00 -0800, H. S. Teoh wrote:

 Lines 1049-1050: I wasn't there at the time, so this may be
 inaccurate, but I clearly remember someone mentioning that Tango has
 been ported to D2 and is quite usable, at least as of a few years
 ago.  But I haven't tried it myself, so I can't for sure whether
 this is actually the case.  But it's worth checking so that the HOPL
 document is factually accurate.


 It's updated to roughly 2.068, I think, and doesn't really compile
 beyond that.

 I tried to update it to the most recent DMD, but that was painful. If
 I try in the future, I'll probably go one major release at a time.


 So I'm guessing that other than Sociomantic(?), there aren't any other
 major codebases out there that use Tango?


Likely not, and Sociomantic uses their own fork of it, so I don't know how
different it is to what Tango was. As I understand it, the core Tango folks
mostly abandoned it as D1 started dying off, and they were uninterested in
D2. As a result, it was quite a while before Tango was ported to D2, and so
any projects that used it would either have been stuck using D1 or had to be
rewritten to not use D2 for Tango anyway. So, I think that the combination
of Tango not being ported to D2 very quickly and the fact that many of the
folks heavily into D1 did not like D2 resulted in very few D2 projects using
Tango. And since at this point, it doesn't even compile anymore, no projects
really can be using it even if someone wanted to. Sociomantic's Ocean is the
closest that anyone could be using right now without putting in a lot of
work to fix up Tango.

- Jonathan M Davis
Dec 02 2018
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2018-12-01 02:00, H. S. Teoh wrote:


 Lines 1049-1050: I wasn't there at the time, so this may be inaccurate,
 but I clearly remember someone mentioning that Tango has been ported to
 D2 and is quite usable, at least as of a few years ago.  But I haven't
 tried it myself, so I can't for sure whether this is actually the case.
 But it's worth checking so that the HOPL document is factually accurate.


The D2 port of Tango is available here [1]. It's pretty easy to find by 
googling for "Tango D2" or searching in code.dlang.org.

[1] https://github.com/SiegeLord/Tango-D2

-- 
/Jacob Carlborg
Dec 01 2018
prev sibling next sibling parent Michelle Long <HappyDance321 gmail.com> writes:
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)


Might as well, D isn't going anywhere(and hence will be left 
behind). That is what happens when you fail to please your user 
base and build enough tooling to make it useful to the population 
at large.
Nov 30 2018
prev sibling next sibling parent reply Tony <tonytdominguez aol.com> writes:
"This interest materialized into a C compiler, followed by 
compilers for C++, Java, and Javascript."

I remember a previous comment by Walter about having done a Java 
compiler but discovering that no one wanted it. But this was 
before OpenJDK; did the compiler come with the Java standard 
class library of the day?
Nov 30 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Saturday, 1 December 2018 at 03:25:49 UTC, Tony wrote:

 "This interest materialized into a C compiler, followed by 
 compilers for C++, Java, and Javascript."

 I remember a previous comment by Walter about having done a 
 Java compiler but discovering that no one wanted it. But this 
 was before OpenJDK; did the compiler come with the Java 
 standard class library of the day?


Seems like it:

http://www.drdobbs.com/symantecs-cafe/184415536
Nov 30 2018
parent Tony <tonytdominguez aol.com> writes:
On Saturday, 1 December 2018 at 03:43:26 UTC, Joakim wrote:

 On Saturday, 1 December 2018 at 03:25:49 UTC, Tony wrote:

 "This interest materialized into a C compiler, followed by 
 compilers for C++, Java, and Javascript."

 I remember a previous comment by Walter about having done a 
 Java compiler but discovering that no one wanted it. But this 
 was before OpenJDK; did the compiler come with the Java 
 standard class library of the day?


 Seems like it:

 http://www.drdobbs.com/symantecs-cafe/184415536


Thanks. I misunderstood. I thought it was Java source code 
compiled to object-code then linked to an executable.
Nov 30 2018
prev sibling next sibling parent rikki cattermole <rikki cattermole.co.nz> writes:
Some Lisp (based and implementations) languages offer access to compiler 
at CTFE with AST manipulation. But it is pretty cludgy.

#D freenode was created: [18:29:43] Channel was created at Sun Nov 26 
19:42:43 2006
We normally sit around 110 but pre spam was around ~160 people (although 
most are inactive).

Another mistake, dmd-fe wasn't a library from day one. This has hurt us 
a lot.

Lastly, good D code is what I would call ML family not C. Even if the 
syntax is C based. Which makes D a combination of ML and C families.
Nov 30 2018
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
I'd say alias this and mixin templates are interesting too, in 
general D is a lot of small features that add up, e.g. DbI is not 
enabled by a single feature, but by a combination of.

Ugh, purity shouldn't be a default. Purity by default results in 
a monadic joke language, consequences are immense as you can see 
by the haskell example, effectively kills scripting and system 
programming. Immutability by default requires shadowing to 
emulate mutability, so isn't without shortcomings, also kills 
ranges. Safety is still a prototype, too early to deploy it in 
production. Combined they destroy convenience and to an extent 
performance and restrict language to haskell niche, which is 
nothing to be proud of.
Dec 01 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via Digitalmars-d wrote:
[...]

 Ugh, purity shouldn't be a default. Purity by default results in a
 monadic joke language, consequences are immense as you can see by the
 haskell example, effectively kills scripting and system programming.


I think you misunderstand the intent here.  Purity by default doesn't
mean everything must be pure with no way out except awkward periphrases
like monads.  It means you opt out of purity by specifying impure,
rather than start with impure and opt into purity by specifying pure.
I.e., an undecorated function will be implicitly pure, but if you want
impure code, you add an `impure` attribute to the function.



 Immutability by default requires shadowing to emulate mutability, so
 isn't without shortcomings, also kills ranges.


Again, the idea here isn't to force everything to be immutable; rather,
it's to make variables immutable by default, but if you want them to be
mutable, you specify them as mutable. Cf. Rust's var/val.



 Safety is still a prototype, too early to deploy it in production.
 Combined they destroy convenience and to an extent performance and
 restrict language to haskell niche, which is nothing to be proud of.


It's true that  safe isn't completely implemented yet (and IMO the
implementation suffers from the inherent incompleteness of using a
blacklist rather than a whitelist), but I think the idea here is again
that functions would be  safe by default, and you can opt out by
specifying  system when you need to.  This would mean  safe checks will
apply by default to general D code, except for the few exceptions when
you need to do something  system. The two can still interface via
 trusted, as they do today.

Basically, the language would pretty much remain the same as it is,
except with some attributes negated by default, i.e., an undecorated
function would be pure  safe, but you can opt out by specifying impure /
 system.  Variables would be immutable by default, but you specify
mutable when they need to mutate.  This would encourage the coder to
write cleaner code, but doesn't stop you from "getting your hands dirty"
with low-level impure/unsafe/etc. code when you need to, e.g. to
implement low-level primitives or squeeze out performance.  (Note also
that by being pure/immutable by default is likely also to afford the
optimizer more opportunities for optimization, so it may not be the
performance hit you seem to think it is, it could be quite the
opposite.)


T

-- 
You have to expect the unexpected. -- RL
Dec 01 2018
parent reply Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 1 December 2018 at 16:07:28 UTC, H. S. Teoh wrote:

 On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via 
 Digitalmars-d wrote: [...]

 [...]


 I think you misunderstand the intent here.  Purity by default 
 doesn't mean everything must be pure with no way out except 
 awkward periphrases like monads.  It means you opt out of 
 purity by specifying impure, rather than start with impure and 
 opt into purity by specifying pure. I.e., an undecorated 
 function will be implicitly pure, but if you want impure code, 
 you add an `impure` attribute to the function.

 [...]


And maybe, class methods final by default?

:-P

P
Dec 01 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Sat, Dec 01, 2018 at 05:32:44PM +0000, Paolo Invernizzi via Digitalmars-d
wrote:

 On Saturday, 1 December 2018 at 16:07:28 UTC, H. S. Teoh wrote:

 On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via Digitalmars-d
 wrote: [...]

 [...]


 
 I think you misunderstand the intent here.  Purity by default
 doesn't mean everything must be pure with no way out except awkward
 periphrases like monads.  It means you opt out of purity by
 specifying impure, rather than start with impure and opt into purity
 by specifying pure.  I.e., an undecorated function will be
 implicitly pure, but if you want impure code, you add an `impure`
 attribute to the function.
 
 [...]


 
 And maybe, class methods final by default?


[...]

This one is a toss-up.  Based on Walter's airplane design philosophy,
the idea is to make the default behaviour the correct / good one, and
require effort to write incorrect / bad code.  Purity by default is good
because pure code has no side-effects, which makes it easier to reason
about (and in some cases, easier for the optimizer to optimize).
Immutable by default is good because it provides more optimization
opportunities (if something doesn't need to change, it shouldn't be
mutable, then the optimizer can eliminate redundant loads where it would
otherwise be unsure whether intervening code may have changed the
original value, if it was mutable), and also prevents common errors like
accidentally changing a value that's not expected to change, or code
smells like reusing variables for something completely unrelated to the
original use.

But for class methods, it's less clear what's the better default.
Especially in D, where structs and compile-time template polymorphism
tend to be preferred where possible, and it almost feels like the raison
d'etre of classes is OO-style runtime polymorphism, so it would make
sense for methods to be virtual by default. OTOH, making them final by
default would also mean you don't incur runtime costs except when you
explicitly ask for virtual.  But then you'd have to specify virtual
everywhere in a construct that seems to be intended precisely for such a
use in the first place. So I'm tempted to say virtual by default makes
more sense (code correctness / clarity / less boilerplate come first,
performance comes later), but I can see how it can be argued both ways.


T

-- 
Do not reason with the unreasonable; you lose by definition.
Dec 01 2018
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Saturday, 1 December 2018 at 18:28:14 UTC, H. S. Teoh wrote:

 On Sat, Dec 01, 2018 at 05:32:44PM +0000, Paolo Invernizzi via 
 Digitalmars-d wrote:

 On Saturday, 1 December 2018 at 16:07:28 UTC, H. S. Teoh wrote:

 On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via 
 Digitalmars-d wrote: [...]

 [...]


 
 I think you misunderstand the intent here.  Purity by 
 default doesn't mean everything must be pure with no way out 
 except awkward periphrases like monads.  It means you opt 
 out of purity by specifying impure, rather than start with 
 impure and opt into purity by specifying pure.  I.e., an 
 undecorated function will be implicitly pure, but if you 
 want impure code, you add an `impure` attribute to the 
 function.
 
 [...]


 
 And maybe, class methods final by default?


 [...]

 This one is a toss-up.  Based on Walter's airplane design 
 philosophy, the idea is to make the default behaviour the 
 correct / good one, and require effort to write incorrect / bad 
 code.  Purity by default is good because pure code has no 
 side-effects, which makes it easier to reason about (and in 
 some cases, easier for the optimizer to optimize). Immutable by 
 default is good because it provides more optimization 
 opportunities (if something doesn't need to change, it 
 shouldn't be mutable, then the optimizer can eliminate 
 redundant loads where it would otherwise be unsure whether 
 intervening code may have changed the original value, if it was 
 mutable), and also prevents common errors like accidentally 
 changing a value that's not expected to change, or code smells 
 like reusing variables for something completely unrelated to 
 the original use.

 But for class methods, it's less clear what's the better 
 default. Especially in D, where structs and compile-time 
 template polymorphism tend to be preferred where possible, and 
 it almost feels like the raison d'etre of classes is OO-style 
 runtime polymorphism, so it would make sense for methods to be 
 virtual by default. OTOH, making them final by default would 
 also mean you don't incur runtime costs except when you 
 explicitly ask for virtual.  But then you'd have to specify 
 virtual everywhere in a construct that seems to be intended 
 precisely for such a use in the first place. So I'm tempted to 
 say virtual by default makes more sense (code correctness / 
 clarity / less boilerplate come first, performance comes 
 later), but I can see how it can be argued both ways.


 T


"virtual is a one-way trip. It can't be undone without risking 
breaking
code once released to the wild. How can that state be a sensible 
default?"
(Cit. Manu)

Some years ago, that was debated for long time, and final by 
default was almost landed into D, with the approval of both 
W&A.[1][2], see rationale here [3]

I dare to say that this specific episode was the beginning of all 
the "break/non break" code debate [4] that still persist, and 
that I hope we will tame in the next future...

/P

[1] https://forum.dlang.org/post/koo65g$1nqs$2 digitalmars.com
[2] https://forum.dlang.org/post/koqkhc$4nn$1 digitalmars.com
[3] https://www.artima.com/intv/nonvirtualP.html
[4] https://forum.dlang.org/post/lfqoan$5qq$1 digitalmars.com
Dec 01 2018
prev sibling parent Q. Schroll <qs.il.paperinik gmail.com> writes:
On Saturday, 1 December 2018 at 17:32:44 UTC, Paolo Invernizzi 
wrote:

 On Saturday, 1 December 2018 at 16:07:28 UTC, H. S. Teoh wrote:

 On Sat, Dec 01, 2018 at 11:02:51AM +0000, Kagamin via 
 Digitalmars-d wrote: [...]

 [...]


 I think you misunderstand the intent here.  Purity by default 
 doesn't mean everything must be pure with no way out except 
 awkward periphrases like monads.  It means you opt out of 
 purity by specifying impure, rather than start with impure and 
 opt into purity by specifying pure. I.e., an undecorated 
 function will be implicitly pure, but if you want impure code, 
 you add an `impure` attribute to the function.

 [...]


 And maybe, class methods final by default?


When both options roughly have the same level of justification 
for being the default, make none the default. Require the user to 
decide. In D, this is really easy. If you're writing a class with 
mostly virtual functions, use " virtual:" (or whatever the 
attribute would be named) at the beginning and you're good; same 
with "final:". You can always opt-out method-wise or even 
block-wise.
None of them should be the default. Period. Not specifying any of 
them will be an error.
Reading your post, I assume methods are virtual by default; in 
fact . The transition of slapping " virtual:" at the beginning of 
each class is not very difficult, in fact, it can be automated 
easily.
Dec 07 2018
prev sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 1 December 2018 at 11:02:51 UTC, Kagamin wrote:

 Ugh, purity shouldn't be a default.


You'd just put "impure" on functions that need to access more.

And keep in mind too that D's pure basically means "no 
non-immutable globals". So if you need to access one of those, 
you just slap impure on it and go your merry way. So it isn't 
very restrictive at all and the slight hassle of saying "impure" 
might even lead to encouraging better design.

I'm about as traditional as D coders come, but I'd welcome that. 
(In fact, I'm of the opinion that these attributes are 
near-useless because they aren't default - there's nothing to 
gain for library writers to use them right now, whereas if it was 
swapped, you would have something to gain: your design would 
work.)
Dec 01 2018
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
Also string as just a plain immutable slice of utf8 text is a 
distinct feature too. Nobody else did it. Swift only recently 
adopted utf8 encoding, I thought it always worked that way, at 
least NSString in gnustep did.
Dec 01 2018
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 12/1/2018 3:12 AM, Kagamin wrote:

 Also string as just a plain immutable slice of utf8 text is a distinct feature 
 too. Nobody else did it. Swift only recently adopted utf8 encoding, I thought
it 
 always worked that way, at least NSString in gnustep did.


In other languages, strings were always "special". I tried hard to make them
not 
special in D, they were just arrays. (Unfortunately, autodecode broke that.)
Dec 01 2018
parent Kagamin <spam here.lot> writes:
On Saturday, 1 December 2018 at 21:53:00 UTC, Walter Bright wrote:

 I tried hard to make them not special in D, they were just 
 arrays.


Yeah, a very elegant design, like it a lot.
Dec 04 2018
prev sibling next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 30.11.18 20:34, 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)


Great write-up!

Comments:

110-111: UB on assertion failure is still terrible even if it is 
considered to be a bug and a non-recoverable error. Those things have 
nothing to do with each other. The airplane analogy would be roughly: 
"Components that are about to fail may start to arbitrarily violate the 
laws of physics."

169: Potentially confusing language. An associative operator op usually 
is taken to be an operator that satisfies (a op b) op c = a op (b op c).

175: ergnomic -> ergonomic

482: I don't think it is true that array slices are an enabler for CTFE. 
It is easy to write a safe and complete enough interpreter for code that 
uses pointer indexing.

499: "Built-in tuple". This terminology is not very forward-compatible. 
Typically, tuples in programming languages do not auto-expand. Also, 
before this point, it is not discussed what a "built-in tuple" is.

544: Boolean expresions -> Boolean expressions

753: Something is missing here. Maybe add a sentence that explains that 
pure has been changed from its initial definition or rewrite in another way.
Dec 01 2018
parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Saturday, December 1, 2018 8:00:35 AM MST Timon Gehr via Digitalmars-d 
wrote:

 On 30.11.18 20:34, 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)


 Great write-up!

 Comments:

 110-111: UB on assertion failure is still terrible even if it is
 considered to be a bug and a non-recoverable error. Those things have
 nothing to do with each other. The airplane analogy would be roughly:
 "Components that are about to fail may start to arbitrarily violate the
 laws of physics."


UB on assertion failure fundamentally breaks the guarantees of  safe.  safe
is supposed to guarantee that invalid memory accesses cannot occur (assuming
that  trusted code was properly vetted anyway), whereas allowing UB on
assertion failure violates that, because it makes it so that memory safety
is not guaranteed if an assertion every fails. IIRC, the spec even
specfically states that  safe code is not allowed to have UB, and as I
understand it, if it's allowed to have UB, then the optimizer can make the
code  system in spite of it being marked as  safe, because the optimizer can
assume pretty much whatever it wants about code which is UB (e.g. as I
understand it, that currently happens with ldc if it ever detects that a
pointer or reference is null and is then dereferenced, because it treats
dereferencing null as UB - I don't know if dmd has a similar problem). If
assertion failures are allowed to introduce UB, then assertions should be
treated as  system, not  safe.

Really, at minimum, assertions should not be allowed to introduce UB in
 safe code, and even allowing it in  system code gets iffy, because UB makes
it extremely difficult for the programmer to properly vet the code for
memory safety so that that they can properly mark the code as  trusted. I
don't think that optimizing based on assertions is necessarily bad, but the
optimizations need to be restricted such that they're not allowed to make it
so that the code is not memory safe if the assertion fails. Without that, I
don't see how we could reasonably argue that  safe code is memory safe if it
contains assertions.

- Jonathan M Davis
Dec 02 2018
prev sibling next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Friday, 30 November 2018 at 19:34:58 UTC, Andrei Alexandrescu 
wrote:

 We'd appreciate feedback and additional historical details.



I just remembered "The D Programming Language", your book! I 
don't think it got a mention in there either...
Dec 01 2018
prev sibling next sibling parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Friday, November 30, 2018 6:00:00 PM MST H. S. Teoh via Digitalmars-d 
wrote:

 On Fri, Nov 30, 2018 at 02:34:58PM -0500, Andrei Alexandrescu via 


Digitalmars-d 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.


 [...]

 Lines 1049-1050: I wasn't there at the time, so this may be inaccurate,
 but I clearly remember someone mentioning that Tango has been ported to
 D2 and is quite usable, at least as of a few years ago.  But I haven't
 tried it myself, so I can't for sure whether this is actually the case.
 But it's worth checking so that the HOPL document is factually accurate.


Tango was eventually ported to D2, but it hasn't been maintained. I tried to
compile it to benchmark its XML parser against dxml when preparing my dconf
talk this year, and Tango wouldn't compile anymore.

- Jonathan M Davis
Dec 02 2018
parent reply Jacob Carlborg <doob me.com> writes:
On 2018-12-02 16:21, Jonathan M Davis wrote:


 Tango was eventually ported to D2, but it hasn't been maintained. I tried to
 compile it to benchmark its XML parser against dxml when preparing my dconf
 talk this year, and Tango wouldn't compile anymore.


The latest tested version of DMD which compiles Tango is supposed to be 
2.068.

-- 
/Jacob Carlborg
Dec 04 2018
parent reply Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Tuesday, December 4, 2018 12:18:22 PM MST Jacob Carlborg via Digitalmars-
d wrote:

 On 2018-12-02 16:21, Jonathan M Davis wrote:

 Tango was eventually ported to D2, but it hasn't been maintained. I
 tried to compile it to benchmark its XML parser against dxml when
 preparing my dconf talk this year, and Tango wouldn't compile anymore.


 The latest tested version of DMD which compiles Tango is supposed to be
 2.068.


Well, then that would be a clear indicator that it's unmaintained at this
point. That's not even close to the current version of dmd, and it's
certainly nowhere near the version that it would need to work with for me to
be able to compare its XML parser with dxml like I was trying to do.

- Jonathan M Davis
Dec 04 2018
parent reply Nemanja Boric <dlang nemanjaboric.com> writes:
On Wednesday, 5 December 2018 at 04:04:31 UTC, Jonathan M Davis 
wrote:

 On Tuesday, December 4, 2018 12:18:22 PM MST Jacob Carlborg via 
 Digitalmars- d wrote:

 On 2018-12-02 16:21, Jonathan M Davis wrote:

 Tango was eventually ported to D2, but it hasn't been 
 maintained. I tried to compile it to benchmark its XML 
 parser against dxml when preparing my dconf talk this year, 
 and Tango wouldn't compile anymore.


 The latest tested version of DMD which compiles Tango is 
 supposed to be 2.068.


 Well, then that would be a clear indicator that it's 
 unmaintained at this point. That's not even close to the 
 current version of dmd, and it's certainly nowhere near the 
 version that it would need to work with for me to be able to 
 compare its XML parser with dxml like I was trying to do.

 - Jonathan M Davis


Ocean's XML parser should be a fork of Tango's one and ocean 
compiles officially with DMD up to 2.078 and I know some parts 
are compiling with newer compilers (new major should support 
newer compilers officially):

https://github.com/sociomantic-tsunami/ocean/tree/v4.x.x/src/ocean/text/xml
Dec 05 2018
next sibling parent Nemanja Boric <dlang nemanjaboric.com> writes:
On Wednesday, 5 December 2018 at 11:20:37 UTC, Nemanja Boric 
wrote:

 On Wednesday, 5 December 2018 at 04:04:31 UTC, Jonathan M Davis 
 wrote:

 [...]


 Ocean's XML parser should be a fork of Tango's one and ocean 
 compiles officially with DMD up to 2.078 and I know some parts 
 are compiling with newer compilers (new major should support 
 newer compilers officially):

 https://github.com/sociomantic-tsunami/ocean/tree/v4.x.x/src/ocean/text/xml


By the way, I'm just going to leave this issue here :-)

https://github.com/sociomantic-tsunami/ocean/issues/613
Dec 05 2018
prev sibling parent Jonathan M Davis <newsgroup.d jmdavisprog.com> writes:
On Wednesday, December 5, 2018 4:20:37 AM MST Nemanja Boric via Digitalmars-
d wrote:

 On Wednesday, 5 December 2018 at 04:04:31 UTC, Jonathan M Davis

 wrote:

 On Tuesday, December 4, 2018 12:18:22 PM MST Jacob Carlborg via

 Digitalmars- d wrote:

 On 2018-12-02 16:21, Jonathan M Davis wrote:

 Tango was eventually ported to D2, but it hasn't been
 maintained. I tried to compile it to benchmark its XML
 parser against dxml when preparing my dconf talk this year,
 and Tango wouldn't compile anymore.


 The latest tested version of DMD which compiles Tango is
 supposed to be 2.068.


 Well, then that would be a clear indicator that it's
 unmaintained at this point. That's not even close to the
 current version of dmd, and it's certainly nowhere near the
 version that it would need to work with for me to be able to
 compare its XML parser with dxml like I was trying to do.

 - Jonathan M Davis


 Ocean's XML parser should be a fork of Tango's one and ocean
 compiles officially with DMD up to 2.078 and I know some parts
 are compiling with newer compilers (new major should support
 newer compilers officially):

 https://github.com/sociomantic-tsunami/ocean/tree/v4.x.x/src/ocean/text/xm
 l


Yeah, Don pointed that out during my talk. When preparing my talk, I'd
considered checking out Ocean to see if it had Tango's XML parser after
Tango failed to compile, but I was in a hurry, and my laptop was running
FreeBSD, whereas the Ocean documentation said that it was Linux-only. So, it
didn't make sense to test it at that point, and benchmarking dxml against
other XML libraries hasn't been a high enough priority since then for me to
get around to it.

- Jonathan M Davis
Dec 05 2018
prev sibling next sibling parent Martin Tschierschke <mt smartdolphin.de> writes:
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 have tried to assemble some of these data here:

https://wiki.dlang.org/Language_History_and_Future

There are some important events inside.

dub, the number of packages, GDC and some other points might be 
worth to get included.

Regards mt.
Dec 03 2018
prev sibling next sibling parent Iain Buclaw <ibuclaw gdcproject.org> writes:
On Fri, 30 Nov 2018 at 20:35, Andrei Alexandrescu via Digitalmars-d
<digitalmars-d puremagic.com> 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)


Wrong accreditation, lines 1118-1119.


 2002, May: David Friedman began creation of another D compiler by adapting the
D front
 end sources for use with gcc, calling it the BrightD Compiler project


It was our resident Jan Knepper who did this, not David.  The codename
was BrightD, under the OpenD umbrella project.

Citation: https://web.archive.org/web/20180324145631/http://www.opend.org/

It's a shame that this site has now been sniped by what looks to be a
domain shark, according to the registrar information, shortly after
Burton's apparent passing earlier this year too.

--
Iain
Dec 03 2018
prev sibling next sibling parent reply Q. Schroll <qs.il.paperinik gmail.com> writes:
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)


ulong factorial(ulong n) {
   ulong result = 1;
   foreach (i; 0 .. n) result *= i; // off by one.
   return result;
}

Even the best make mistake ;)
Dec 03 2018
next sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Mon, Dec 03, 2018 at 11:42:40PM +0000, Q. Schroll via Digitalmars-d wrote:
[...]

 ulong factorial(ulong n) {
   ulong result = 1;
   foreach (i; 0 .. n) result *= i; // off by one.
   return result;
 }
 
 Even the best make mistake ;)


Optimizer output:

	ulong factorial(n) { return 0; }

:-D

Where are the unittests that would have caught this?? ;-)

Furthermore, it's not just off by 1, since i=1 is a redundant case. The
loop really ought to start with 2.


T

-- 
In theory, software is implemented according to the design that has been
carefully worked out beforehand. In practice, design documents are written
after the fact to describe the sorry mess that has gone on before.
Dec 03 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Mon, 03 Dec 2018 16:02:30 -0800, H. S. Teoh wrote:

 Furthermore, it's not just off by 1, since i=1 is a redundant case. The
 loop really ought to start with 2.


factorial(0) is 1 because it's the product of an empty sequence.
Dec 03 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 04, 2018 at 12:59:00AM +0000, Neia Neutuladh via Digitalmars-d
wrote:

 On Mon, 03 Dec 2018 16:02:30 -0800, H. S. Teoh wrote:

 Furthermore, it's not just off by 1, since i=1 is a redundant case.
 The loop really ought to start with 2.


 
 factorial(0) is 1 because it's the product of an empty sequence.


No doubt, but the loop should start at 2 because the first two elements
of the sequence are 1, and it's a waste of computation to multiply that
by 1 yet again.


T

-- 
Without geometry, life would be pointless. -- VS
Dec 03 2018
prev sibling next sibling parent Russel Winder <russel winder.org.uk> writes:
On Mon, 2018-12-03 at 23:42 +0000, Q. Schroll via Digitalmars-d wrote:

 [=E2=80=A6]
=20
 ulong factorial(ulong n) {
    ulong result =3D 1;
    foreach (i; 0 .. n) result *=3D i; // off by one.
    return result;
 }
=20
 Even the best make mistake ;)


Being serious for a moment: anyone implementing factorial using ulong is do=
ing
it wrong.  std.bigint.BigInt is the only type that makes sense in a D
implementation of factorial =E2=80=93 also fibonacci.

And remember, these calculations are actually required in many bioinformati=
cs
and hedge fund models. Trust me on this, I found out the hard way presentin=
g
Python workshops to such folk. Fortunately, in Python int means either
hardware int or software "big integer" depending on value. Except when usin=
g
NumPy which is when things get tricky.
 =20
--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Dec 03 2018
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 04, 2018 at 07:31:28AM +0000, Russel Winder via Digitalmars-d wrote:

 On Mon, 2018-12-03 at 23:42 +0000, Q. Schroll via Digitalmars-d wrote:

 […]
 
 ulong factorial(ulong n) {
    ulong result = 1;
    foreach (i; 0 .. n) result *= i; // off by one.
    return result;
 }
 
 Even the best make mistake ;)


 
 Being serious for a moment: anyone implementing factorial using ulong
 is doing it wrong.  std.bigint.BigInt is the only type that makes
 sense in a D implementation of factorial – also fibonacci.


[...]

And this is where a simple code example explodes into a hairy
over-engineered mess. Totally correct, mind you, but totally missing the
point of being an example of D code. :-P


T

-- 
What's an anagram of "BANACH-TARSKI"?  BANACH-TARSKI BANACH-TARSKI.
Dec 04 2018
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.com> writes:
On 12/3/18 6:42 PM, Q. Schroll 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)


 
 ulong factorial(ulong n) {
    ulong result = 1;
    foreach (i; 0 .. n) result *= i; // off by one.
    return result;
 }
 
 Even the best make mistake ;)


Ouch, thanks.
Dec 04 2018
prev sibling parent Russel Winder <russel winder.org.uk> writes:
On Tue, 2018-12-04 at 09:07 -0800, H. S. Teoh via Digitalmars-d wrote:

=20


[=E2=80=A6]

 And this is where a simple code example explodes into a hairy
 over-engineered mess. Totally correct, mind you, but totally missing the
 point of being an example of D code. :-P


Actually not so hairy, and not so over-engineered: most programming languag=
es,
including D, make it fairly straightforward. However, missing the point, is
not untrue. Except that bad examples of real world used code has a drip-dri=
p
effect of giving people the wrong ideas.

--=20
Russel.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk
Dec 06 2018
prev sibling next sibling parent reply jmh530 <john.michael.hall gmail.com> writes:
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)


The timeline does not have when work started on D 2.0 and when 
the first release was or what have you.
Dec 04 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 4 December 2018 at 19:04:35 UTC, jmh530 wrote:

 The timeline does not have when work started on D 2.0 and when 
 the first release was or what have you.


D 2.0 started in 1999.

The truth is D has just been constantly evolving from the 
beginning. All D1 is was an arbitrary snapshot on the path, which 
briefly branched off with just bug fixes (of course, one user's 
bug fix is another user's breaking change).

Then, the D language continued evolving the same has it has the 
last 8 years, just now that one random snapshot got labeled D1, 
the ongoing evolution got rebranded D2, since it would sound 
silly is D 0.xxx was considered newer than 1.0.


The officially labeled 2.0 came out in July 2007, six months 
after the officially labeled 1.0, but really that is just because 
of a brief freeze to focus more on bugs than any real "it's done" 
materializing.
Dec 04 2018
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/4/18 2:23 PM, Adam D. Ruppe wrote:

 On Tuesday, 4 December 2018 at 19:04:35 UTC, jmh530 wrote:

 The timeline does not have when work started on D 2.0 and when the 
 first release was or what have you.


 
 D 2.0 started in 1999.
 
 The truth is D has just been constantly evolving from the beginning. All 
 D1 is was an arbitrary snapshot on the path, which briefly branched off 
 with just bug fixes (of course, one user's bug fix is another user's 
 breaking change).
 
 Then, the D language continued evolving the same has it has the last 8 
 years, just now that one random snapshot got labeled D1, the ongoing 
 evolution got rebranded D2, since it would sound silly is D 0.xxx was 
 considered newer than 1.0.
 
 
 The officially labeled 2.0 came out in July 2007, six months after the 
 officially labeled 1.0, but really that is just because of a brief 
 freeze to focus more on bugs than any real "it's done" materializing.


 From my memory, I remember the big thing of D 2.0 was immutable/const. 
Essentially there was no way to shoehorn immutable (then called 
invariant) and const into the D compiler without breaking everything 
(and as one who tried to port Tango to D2, I experienced this 
first-hand), so the fork was made. I'm sure there was a definitive point 
at which this was decided. Unfortunately, I don't think DMD was even 
using subversion back then, so the code history may be hard to construct.

-Steve
Dec 04 2018
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 4 December 2018 at 19:37:04 UTC, Steven Schveighoffer 
wrote:

 From my memory, I remember the big thing of D 2.0 was 
 immutable/const.


Well, it is certainly the most definitive change of the era, but 
if not that, it would have just been something else - D has 
always been evolving and that wasn't going to actually stop.

D1 wasn't some designed end point that reached completion... it 
was just a random spot along the path.


 Unfortunately, I don't think DMD was even using subversion back 
 then, so the code history may be hard to construct.


The changelog can help piece it together.
Dec 04 2018
prev sibling parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 04, 2018 at 02:37:04PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:
[...]

 From my memory, I remember the big thing of D 2.0 was immutable/const.
 Essentially there was no way to shoehorn immutable (then called
 invariant) and const into the D compiler without breaking everything
 (and as one who tried to port Tango to D2, I experienced this
 first-hand), so the fork was made. I'm sure there was a definitive
 point at which this was decided.  Unfortunately, I don't think DMD was
 even using subversion back then, so the code history may be hard to
 construct.


[...]

This is also the version of D's history that I've heard before. D2 was
more-or-less "officially" started with the introduction of the const
system that broke basically all prior code. In order to keep existing
code working, D1 was forked from the main compiler and maintained for a
number of years.  IIRC it was also around that time that Andrei came on
board.

Not using version control was a very unwise thing to do, though I do
sympathise that back in the day, there weren't many good version control
systems out there, plus the awareness of the benefits of version control
wasn't that widespread.

(I've had the misfortune of having to deal with CVS, which was OK for
smallish projects but was so painful to work with for real-world-scale
projects that it effectively acted as a deterrent against using version
control.  When subversion first came out, it was revolutionary to many
CVS users ("What, you can make a branch in just a few seconds, as
opposed to waiting 45 mins while CVS chews through your hard drive
updating all those RCS files?!").  Git took this to whole new levels by
making branches and history navigation local, avoiding network
roundtrips altogether, and really streamlining the checkin / checkout /
branch operations such that today, it's practically an embarrassment not
to use version control.  Years ago I started using version control for
*everything*, not just code, and haven't regretted it since. It's saved
my life more than a few times, not to mention the piece of mind that
backups are readily available should something horrible go wrong with
your precious files.)


T

-- 
First Rule of History: History doesn't repeat itself -- historians merely
repeat each other.
Dec 04 2018
parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/4/18 2:58 PM, H. S. Teoh wrote:

 Not using version control was a very unwise thing to do, though I do
 sympathise that back in the day, there weren't many good version control
 systems out there, plus the awareness of the benefits of version control
 wasn't that widespread.


I think it was just that the sole (or few?) maintainer didn't need to 
have it to get stuff done.

Just for fun I went back and looked, dsource.org shows 0.50 as the first 
first put into (at least public) source control: 
http://dsource.org/projects/dmd/browser/trunk/src?rev=5

Of course, that's just the front end. Phobos may have had earlier 
history as I think it was more of a distributed effort.

-Steve
Dec 04 2018
next sibling parent reply Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/4/18 3:43 PM, Steven Schveighoffer wrote:

 On 12/4/18 2:58 PM, H. S. Teoh wrote:

 Not using version control was a very unwise thing to do, though I do
 sympathise that back in the day, there weren't many good version control
 systems out there, plus the awareness of the benefits of version control
 wasn't that widespread.


 
 I think it was just that the sole (or few?) maintainer didn't need to 
 have it to get stuff done.
 
 Just for fun I went back and looked, dsource.org shows 0.50 as the first 
 first put into (at least public) source control: 
 http://dsource.org/projects/dmd/browser/trunk/src?rev=5
 
 Of course, that's just the front end. Phobos may have had earlier 
 history as I think it was more of a distributed effort.



Hm... looks like that source tree is reconstructed, as it seems 0.50 was 
released in 2002!

https://forum.dlang.org/thread/arfoqu$4q6$1 digitaldaemon.com

So there actually is history before 2009 available publicly.

It's then probably possible to find the point at which D2 was forked, 
but I'm not about to dig that much :)

-Steve
Dec 04 2018
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 4 December 2018 at 20:56:43 UTC, Steven Schveighoffer 
wrote:

 So there actually is history before 2009 available publicly.


Yes, you can simply look at the changelog.

http://dlang.org/changelog

It goes all the way to the beginning if you make a few clicks 
(first to 1.0, then to "even older versions"). It also includes 
downloads for most the releases from 0.50 and up.


 It's then probably possible to find the point at which D2 was 
 forked, but I'm not about to dig that much :)


Version D 1.001 Jan 23, 2007 (notable: tail recursion works 
again, New type aware GC. lol how monumental, a regression got 
fixed)


2.000 released Jun 17, 2007 (notable: Added const, invariant, and 
final.)

It is about 6 months later, and yes, const was the 
differentiating feature there... though it didn't actually break 
any existing code until D 2.006, released Oct 16, 2007: 
"Transformed all of string, wstring, and dstring into invariant 
definitions.")

2.006 was the release that majorly broke code, not 2.0. In fact, 
1.0 16 maintained some compatibility:

  Version D 1.016 Jun 14, 2007, "Added aliases string, wstring, 
and dstring to ease compatiblity with 2.0."

And 1.0 wasn't entirely afraid of evolving code... at least for a 
while:

Version D 1.005 Feb 5, 2007
New/Changed Features

     -v now emits pragma library statements and imported file names
     deprecated ===, and !==, tokens no longer recognized
     length can no longer shadow other length declarations
     Added MixinStatements, MixinExpressions, and 
MixinDeclarations.
     Added ImportExpressions.
     Added std.metastrings


(seriously, 1.005 is far more monumental than 1.000 - it added 
mixins!!!)


1.006 added CTFE and the -J switch.



But what I'm trying to say is that 2.0 was not really forked off 
of 1.0! It was 1.0 that got forked off (around D 1.016, Jun 14, 
2007) and only got some selective patches applied while D, now 
rebranded as 2.0, continued down the same path it has always been 
on.


Look at what happened to the D1 fork around the time D2 continued 
the evolution: there was extern(System) after the D2 release 
(1.021 and 2.003, released simultaneously)... but mostly, it was 
stuff under bug fixes, and very rare new features, even rarer 
changed features.


For many years before and after June 2007, D has evolved. The 
anomaly is that there was a branch of it kinda frozen in time 
which we now call D1. And as you can see from the kinda random 
version numbers quoted above, it really was totally arbitrary. It 
was totally arbitrary to call one of them 1.0 (whose only notable 
changes were a regression fix and a GC implementation detail), 
and totally arbitrary to call the bug fix release D 1.017 and the 
feature release D 2.0 instead of calling the feature release D 
1.017 and the bug fix release D 1.016.1 (which is probably what 
we'd call it if using today's system!)
Dec 04 2018
parent reply Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 4 December 2018 at 22:27:06 UTC, Adam D. Ruppe wrote:

 On Tuesday, 4 December 2018 at 20:56:43 UTC, Steven 
 Schveighoffer wrote:

 [...]


 Yes, you can simply look at the changelog.

 [...]


This shows the importance of perception managment. Had you called 
D1 at that time D LTS and D2 contined with the 1.x versions. 
There wouldn't have been this negative image associated with the 
"language split". It would have been technically exactly the 
same, but due to the naming, the perception from third parties 
would not have been so negative.
Dec 05 2018
parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Wed, Dec 05, 2018 at 08:02:13PM +0000, Patrick Schluter via Digitalmars-d
wrote:

 On Tuesday, 4 December 2018 at 22:27:06 UTC, Adam D. Ruppe wrote:

 On Tuesday, 4 December 2018 at 20:56:43 UTC, Steven Schveighoffer wrote:

 [...]


 
 Yes, you can simply look at the changelog.
 
 [...]


 
 This shows the importance of perception managment. Had you called D1
 at that time D LTS and D2 contined with the 1.x versions. There
 wouldn't have been this negative image associated with the "language
 split". It would have been technically exactly the same, but due to
 the naming, the perception from third parties would not have been so
 negative.


In principle I agree, but the Tango/Phobos split was very real, and
produced a lot of bitterness and resentment that even today continue to
tarnish our reputation (though it has gotten much better now that we've
been actively working on PR).  Being able to point to D2 and say we
started with a clean slate does help to distance ourselves from the PR
nightmare associated with D1 and its "two standard libraries".


T

-- 
May you live all the days of your life. -- Jonathan Swift
Dec 05 2018
prev sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Dec 04, 2018 at 03:43:57PM -0500, Steven Schveighoffer via
Digitalmars-d wrote:

 On 12/4/18 2:58 PM, H. S. Teoh wrote:

 Not using version control was a very unwise thing to do, though I do
 sympathise that back in the day, there weren't many good version
 control systems out there, plus the awareness of the benefits of
 version control wasn't that widespread.


 
 I think it was just that the sole (or few?) maintainer didn't need to
 have it to get stuff done.


[...]

Still unwise.  I use version control for all of my projects (and not
just D ones, even stuff like websites, POVRay scene files, music, and
configuration files).  People seem to have this idea that version
control is only for code, but in reality, it's extremely useful for
anything that changes over time that you might conceivably want to
retrieve prior versions of (even if just for comparison).  And in this
day and age, with the ease of use of git, there's really no excuse not
to use version control for anything of value.


T

-- 
The best way to destroy a cause is to defend it poorly.
Dec 04 2018
prev sibling next sibling parent Guillaume Piolat <first.last gmail.com> writes:
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 see no mention of array ops. I think they deserve more credit 
that they do.

Arrays ops, now that they are fixed in DMD, are a very convenient 
way to ensure that an operation is written in a way that can be 
auto-vectorized.

Or at least it gives the perception that it will be 
auto-vectorized, dunno.
Dec 04 2018
prev sibling next sibling parent reply Dmitry Olshansky <dmitry.olsh gmail.com> writes:
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.


Maybe already pointed out in the thread but just in case

line 449 has bogus factorial implementation:

foreach (i; 0 .. n) result *= i;

should probably be

foreach (i; 1 .. n) result *= i;


 Thanks,

 Andrei (on behalf of Walter and Mike as well)
Dec 07 2018
parent reply Nicholas Wilson <iamthewilsonator hotmail.com> writes:
On Friday, 7 December 2018 at 10:08:04 UTC, Dmitry Olshansky 
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.


 Maybe already pointed out in the thread but just in case

 line 449 has bogus factorial implementation:

 foreach (i; 0 .. n) result *= i;

 should probably be

 foreach (i; 1 .. n) result *= i;


It has, it also bought up the need for unit tests(!) ;)
Dec 07 2018
parent reply mate <aiueo aiueo.aiueo> writes:
On Friday, 7 December 2018 at 10:34:54 UTC, Nicholas Wilson wrote:

 On Friday, 7 December 2018 at 10:08:04 UTC, Dmitry Olshansky 
 wrote:

 On Friday, 30 November 2018 at 19:34:58 UTC, Andrei 
 Alexandrescu wrote:

 [...]


 Maybe already pointed out in the thread but just in case

 line 449 has bogus factorial implementation:

 foreach (i; 0 .. n) result *= i;

 should probably be

 foreach (i; 1 .. n) result *= i;


 It has, it also bought up the need for unit tests(!) ;)


Indeed, because it should be:
foreach (i; 2 .. n+1) result *= i;
Dec 07 2018
parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 12/7/18 8:28 AM, mate wrote:

 On Friday, 7 December 2018 at 10:34:54 UTC, Nicholas Wilson wrote:

 On Friday, 7 December 2018 at 10:08:04 UTC, Dmitry Olshansky wrote:

 On Friday, 30 November 2018 at 19:34:58 UTC, Andrei Alexandrescu wrote:

 [...]


 Maybe already pointed out in the thread but just in case

 line 449 has bogus factorial implementation:

 foreach (i; 0 .. n) result *= i;

 should probably be

 foreach (i; 1 .. n) result *= i;


 It has, it also bought up the need for unit tests(!) ;)


 
 Indeed, because it should be:
 foreach (i; 2 .. n+1) result *= i;


Funny, it was pointed out that the error was an "off by one", but there 
were really 2 errors that were off by one.

Get the unittests done already! ;)

-Steve
Dec 07 2018
prev sibling next sibling parent anon reviewer <noreply noreply.org> writes:
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)


The manuscript leaves out several relevant references to prior 
work:

(1) The use of ranges (pairs of iterators) as the interface to 
algorithms was a fundamental and unique concept of the STL from 
its initial conception.
"Most of the library’s algorithmic templates that operate on data 
structures have interfaces that use ranges. A range is a pair of 
iterators that designate the beginning and end of the 
computation. A range[i, i) is an empty range; in general, a range 
[i, j) refers to the elements in the data structure starting with 
the one pointed to by i and up to but not including the one 
pointed to by j. Range[i, j) is valid if and only if j is 
reachable from i. The result of the application of the algorithms 
in the library to invalid ranges is undefined."  Alexander 
Stepanov and Meng Lee (October 31, 1995). "The Standard Template 
Library" (http://stepanovpapers.com/STL/DOC.PDF) and as defined 
in the ISO C++ standard.

(2) The pure keyword from Fortran 95 already distinguished 
between pure procedures and pure functions, with pure procedures 
allowing local mutation described as "relaxed functional purity" 
in the manuscript. (see 
https://en.wikipedia.org/wiki/Pure_function and 
https://www.ibm.com/support/knowledgecenter/SSGH4D_13.1.0/com.ibm.xlf131.aix.doc/language_ref/pure.html).

(3) The section of CTFE fails to cite the earlier research on 
this area in C++ by Daveed Vandevoorde, Edison Design Group 
(April 18, 2003). "Reflective Metaprogramming in C++", and 
others, which was widely discussed in news groups at the time.
(see 
https://en.wikipedia.org/wiki/Compile_time_function_execution).

In the section on mistakes made, it would be interesting to 
discuss the more recent efforts to re-introduce C++ style copy 
constructors.
Dec 16 2018
prev sibling next sibling parent anon reviewer <noreply noreply.org> writes:
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 have completed a more thorough reading and here are additional 
comments that would strengthen the manuscript:

On the topic of slices as a built-in type in D, these were of 
course well-studied in the literature aka as fat pointers- 
combining a pointer with its bounds- and in particular have been 
well studied and implemented in C, with the most well-known 
example being the influential cyclone language with its  fat 
pointers, which should be referenced (see 
https://cyclone.thelanguage.org/wiki/Pointers/ ).

The manuscript in several places uses well-known terms in 
programming language theory but is written in a way suggesting 
that these terms originated in D. This is misleading for readers 
with insufficient background in comparative programming 
languages. In particular, the term "slice" is of course the 
standard term used for a reference to a part of a contiguous 
block of memory in array languages, including Fortran 95. In C++ 
such slices into contiguous blocks of dynamically-allocated 
memory have been available as library types, as opposed to a 
built-in type, since initial standardization, e.g. see 
valarray::slice and slice_array, or as third party array classes 
such as Blitz++ ca. 2005 (see 
http://physik.uni-graz.at/~crg/Programmierkurs1112/pdfs/blitz.pdf), for which
subarrays and slices to a block of memory have their memory-management handled
automatically through reference-counting, and which can be attached to raw
memory pointers- essentially the same functionality as the the built-in D slice
but as a separate library type, which fits more closely with the C++ design
principle of preferring library solutions over built-in types.

Also, the use of the keyword "trait" in D clearly comes from the 
use of the well-known term "trait" in C++ for a similar purpose 
of compile-time lookup of type information e.g. the C++ 
std::type_traits header. So the original publication by Meyers 
introducing the term "traits" should be referenced (Traits: a new 
and useful template technique by Nathan C. Myers C++ Report, June 
1995).

Other points:
Matthew Wilson's rangelib is mentioned but without citation. A 
reference to his and his colleagues' original publication on 
their range library is needed ("Ranges, part 1: Concepts and 
Implementation", Matthew Wilson and John Torjo, C/C++ User's 
Journal, Volume 22 Number 10, October 2004).

In the section on mistakes made, it would be interesting to 
expand the discussion:
(i) on the broader topic of built-in types versus library 
classes, it was noted in the manuscript that having a built-in 
complex number was a mistake versus a library type. What of other 
built-in types such as associative arrays and slices which are 
built-in in D? Some insight into when built-in types are 
preferable could be a useful contribution of the manuscript (ii) 
on the topic of garbage collection it is mentioned that reference 
counting is planned.  Is gc now considered a mistake to be fully 
removed in the future or is it considered a success, and how did 
it impact library design?

Also, to clarify further on the Fortran 95 pure keyword discussed 
in the previous comment: in Fortran 95 pure procedures include 
both (i) pure functions and (ii) pure subroutines. For both 
types, iteration and local variable are allowed, as long as the 
mutation is local to the function- what is termed  "relaxed 
functional purity" in the manuscript. The distinction between 
pure functions and pure subroutines is that pure subroutines can 
also mutate arguments passed by reference (a distinction not 
discussed in the manuscript but referred to as "weak" and 
"strong" purity in the D broader D documentation). See 
http://earth.uni-muenster.de/~joergs/doc/f90/lrm/lrm0157.htm .
Dec 17 2018
prev sibling next sibling parent reply anon reviewer <noreply noreply.org> writes:
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 
)
Dec 18 2018
parent fouad2400 <radford08 ksframem.com> writes:
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.
Dec 24 2018
prev sibling next sibling parent anon reviewer <noreply noreply.org> writes:
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).
Dec 22 2018
prev sibling next sibling parent Sameer Pradhan <pradhan cemantix.org> writes:
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
Jan 03 2019
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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)
Aug 31 2019
next sibling parent reply Max Haughton <maxhaton gmail.com> writes:
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
Aug 31 2019
parent Mike Parker <aldacron gmail.com> writes:
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.
Aug 31 2019
prev sibling next sibling parent Les De Ridder <les lesderid.net> writes:
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.)?
Sep 01 2019
prev sibling next sibling parent rjframe <dlang ryanjframe.com> writes:
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 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//
Sep 01 2019
prev sibling parent Jacob Carlborg <doob me.com> writes:
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
Sep 08 2019