March 13, 2014
On 3/12/2014 5:40 PM, Vladimir Panteleev wrote:
> Doesn't this sort of seal the language's fate in the long run, though?
> Eventually, new programming languages will appear which will learn from D's
> mistakes, and no new projects will be written in D.
>
> Wasn't it here that I heard that a language which doesn't evolve is a dead
> language?
>
>  From looking at the atmosphere in this newsgroup, at least to me it appears
> obvious that there are, in fact, D users who would be glad to have their D code
> broken if it means that it will end up being written in a better programming
> language. (I'm one of them, for the record; I regularly break my own code anyway
> when refactoring my library.) Although I'm not advocating forking off a D3 here
> and now, the list of things we wish we could fix is only going to grow.

There are costs and benefits:

Benefits:

1. attracting new people with better features

Costs:

2. losing existing users by breaking their code, losing new people because of a reputation for instability

There aren't clearcut answers. It's a judgement call. The final-by-default has very large breakage costs, and its improvement is minor and achievable by other means.
March 13, 2014
On Thursday, 13 March 2014 at 00:48:15 UTC, Walter Bright wrote:
> On 3/12/2014 5:18 PM, Andrei Alexandrescu wrote:
>> We are opposed to having compiler flags define language semantics.
>
> Yeah, that's one of those things that always seems like a reasonable idea, but experience with it isn't happy.

I would imagine that the reasons for this goal are 1) to keep the compiler and language sane, and 2) insufficient personel to maintain legacy variants.

I think the answer to #1 is to not introduce such changes lightly nor frequently.

For #2, since the codebase is now open sourced and, I presume, your "clients" pay you to perform specific tasks, legacy compilation features will end up being maintained either by random people who fix it themselves, or a client who based his code on an older version pays you to go into the legacy branch/build target code. This is the way most open sourced software works. Linux, GCC, emacs, etc. are all constantly moving targets that only through people paying Red Hat and others like them to make the insanity go away are able to work together as a single whole.
March 13, 2014
On Wednesday, 12 March 2014 at 22:50:00 UTC, Walter Bright wrote:
> The argument for final by default, as eloquently expressed by Manu, is a good one. Even Andrei agrees with it (!).
>
> The trouble, however, was illuminated most recently by the std.json regression that broke existing code. The breakage wasn't even intentional; it was a mistake. The user fix was also simple, just a tweak here and there to user code, and the compiler pointed out where each change needed to be made.
>
> But we nearly lost a major client over it.

Was this because of a breaking change itself or because of the lack of warning and nature of the change?

The final by default change should not be something that catches anyone by surprise. There would be lots of time to prepare for it, warnings would be made, and an entire deprecation process gone through. It would not be a random compiler change that breaks code by surprise for no end-user benefit. When warnings start occurring, the compiler can quite clearly tell you *exactly* what you need to change to make your code up-to-date. And in the end, there is a net benefit to the user in the form of less error-prone, faster, code.

I used to get frustrated when my code would randomly break every compiler update (and it shows how much D has progressed that regressions in my own code are now a rare occurrence), but unexpected regressions such as the std.json regression are much different from intended changes with plenty of time and warning that provide an overall (even if slight in many cases) benefit to the end-user.
March 13, 2014
On 3/12/14, 5:40 PM, Vladimir Panteleev wrote:
> On Thursday, 13 March 2014 at 00:18:06 UTC, Andrei Alexandrescu wrote:
>> On 3/12/14, 5:02 PM, Chris Williams wrote:
>>> As someone who would like to be able to use D as a language,
>>> professionally, it's more important to me that D gain future clients
>>> than that it maintains the ones that it has. Even more important is that
>>> it does both of those things.
>>
>> The saying goes, "you can't make a bucket of yogurt without a spoonful
>> of rennet". The pattern of resetting customer code into the next
>> version must end. It's the one thing that both current and future
>> users want: a pattern of stability and reliability.
>
> Doesn't this sort of seal the language's fate in the long run, though?
> Eventually, new programming languages will appear which will learn from
> D's mistakes, and no new projects will be written in D.

Let's get to the point where we need to worry about that :o).

> Wasn't it here that I heard that a language which doesn't evolve is a
> dead language?

Evolving is different from incessantly changing.

> From looking at the atmosphere in this newsgroup, at least to me it
> appears obvious that there are, in fact, D users who would be glad to
> have their D code broken if it means that it will end up being written
> in a better programming language.

This is not my first gig. Due to simple social dynamics, forum participation saturates. In their heydays, forums like comp.lang.c++.moderated, comp.lang.tex, and comp.lang.perl had traffic comparable to ours, although their community was 1-2 orders of magnitude larger. Although it seems things are business as usual in our little hood here, there is a growing silent majority of D users who aren't on the forum.


Andrei

March 13, 2014
On 3/12/2014 6:18 PM, Chris Williams wrote:
> On Thursday, 13 March 2014 at 00:48:15 UTC, Walter Bright wrote:
>> On 3/12/2014 5:18 PM, Andrei Alexandrescu wrote:
>>> We are opposed to having compiler flags define language semantics.
>>
>> Yeah, that's one of those things that always seems like a reasonable idea, but
>> experience with it isn't happy.
>
> I would imagine that the reasons for this goal are 1) to keep the compiler and
> language sane, and 2) insufficient personel to maintain legacy variants.

Maybe surprisingly, it isn't either.

It's because every one of those switches splits the language into two languages. 8 switches means 256 languages. When you're a library vendor, which of those 256 languages are you writing for? What happens when you mix code for language #63 with language #121? It's a nightmare - confusing to people trying to understand it, and frustrating for those who do.

The combinatorics alone are daunting - 256 times through the test suite. You have to add introspection so the program can tell which language it is today.

The punishment goes on and on.

March 13, 2014
On 3/12/2014 6:30 PM, Kapps wrote:
> I used to get frustrated when my code would randomly break every compiler update
> (and it shows how much D has progressed that regressions in my own code are now
> a rare occurrence), but unexpected regressions such as the std.json regression
> are much different from intended changes with plenty of time and warning that
> provide an overall (even if slight in many cases) benefit to the end-user.

I got caught by breaking changes myself. I even approved the changes. But they unexpectedly broke projects of mine, and I had to go through updating & fixing them, supplying updates, etc.

It sux.

And it's much, much, much worse if you've got lots of legacy code with only a vague idea of how it works because the engineers who wrote it have moved on, etc.
March 13, 2014
On Thursday, 13 March 2014 at 02:48:14 UTC, Andrei Alexandrescu wrote:
> On 3/12/14, 5:40 PM, Vladimir Panteleev wrote:
>> From looking at the atmosphere in this newsgroup, at least to me it
>> appears obvious that there are, in fact, D users who would be glad to
>> have their D code broken if it means that it will end up being written
>> in a better programming language.
>
> This is not my first gig. Due to simple social dynamics, forum participation saturates. In their heydays, forums like comp.lang.c++.moderated, comp.lang.tex, and comp.lang.perl had traffic comparable to ours, although their community was 1-2 orders of magnitude larger. Although it seems things are business as usual in our little hood here, there is a growing silent majority of D users who aren't on the forum.

So are you saying that the users who participate on the forum are not representative of the entire D user base? I.e. the % of users who wouldn't mind breaking changes is higher on the forum?
March 13, 2014
On Thursday, 13 March 2014 at 03:05:07 UTC, Vladimir Panteleev wrote:
> So are you saying that the users who participate on the forum are not representative of the entire D user base? I.e. the % of users who wouldn't mind breaking changes is higher on the forum?

The 1% rules suggests this forum is a small minority amongst D users.

http://en.wikipedia.org/wiki/1%25_rule_%28Internet_culture%29
March 13, 2014
On 3/12/14, 8:05 PM, Vladimir Panteleev wrote:
> On Thursday, 13 March 2014 at 02:48:14 UTC, Andrei Alexandrescu wrote:
>> On 3/12/14, 5:40 PM, Vladimir Panteleev wrote:
>>> From looking at the atmosphere in this newsgroup, at least to me it
>>> appears obvious that there are, in fact, D users who would be glad to
>>> have their D code broken if it means that it will end up being written
>>> in a better programming language.
>>
>> This is not my first gig. Due to simple social dynamics, forum
>> participation saturates. In their heydays, forums like
>> comp.lang.c++.moderated, comp.lang.tex, and comp.lang.perl had traffic
>> comparable to ours, although their community was 1-2 orders of
>> magnitude larger. Although it seems things are business as usual in
>> our little hood here, there is a growing silent majority of D users
>> who aren't on the forum.
>
> So are you saying that the users who participate on the forum are not
> representative of the entire D user base?

They are representative in the sense they're among the most passionate, competent, and influential of the user base. For the same reasons they are a couple of standard deviations away in certain respects from the majority.

> I.e. the % of users who
> wouldn't mind breaking changes is higher on the forum?

I believe so, and I have many examples. Most people who don't hang out in the forum just want to get work done without minding every single language advocacy subtlety, and breakages prevent them from getting work done.


Andrei

March 13, 2014
On Thursday, 13 March 2014 at 03:15:25 UTC, Andrei Alexandrescu wrote:
> I believe so, and I have many examples. Most people who don't hang out in the forum just want to get work done without minding every single language advocacy subtlety, and breakages prevent them from getting work done.

I see. That's quite insightful, thanks.