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.

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

On Tue, 2018-12-04 at 09:07 -0800, H. S. Teoh via Digitalmars-d wrote:
> 
[…]
> 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 languages, 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-drip effect of giving people the wrong ideas.

-- 
Russel.
===========================================
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

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)

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(!) ;)

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;

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

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.

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.

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 .