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