On 13 March 2014 10:15, Walter Bright <newshound2@digitalmars.com> wrote:

> On 3/12/2014 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 D1 -> D2 transition very nearly destroyed D by sacrificing all the momentum it had.
>

To draw that as a comparison to the issue on topic is one of the biggest exaggerations I've seen in a while, and you're not usually prone to that sort of thing.

On Thursday, 13 March 2014 at 00:40:34 UTC, Vladimir Panteleev wrote:
>>
>> 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.
>
> Wasn't it here that I heard that a language which doesn't evolve is a dead language?
>

IMO, one of the reasons D exists is all the historical baggage C/C++ chose to carry instead of evolving.

I can cite a business case I had the displeasure of working on as well.  They chose not to evolve, and instead ended up spending $11 million years later to rewrite their infrastructure while maintaining the antiquated one so they could still function.  And the latter was never realized.  They're probably due for another large, time consuming, disruptive, expensive project in the near future.

Point is, it's in the best interest of both languages and businesses building on those languages to evolve, or they just end up paying the piper later (with interest).

Gradual, managed change is where it's at, IMNSHO.

On 13 March 2014 11:13, Walter Bright <newshound2@digitalmars.com> wrote:

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

It's not minor, and it's not achievable by other means though.
It's also not a very large breaking change. In relative terms, it's already
quantified - expected to be much smaller than override was; this only
affects bases, override affected all branches and leaves.

You and Andrei are the only resistance in this thread so far. Why don't you
ask 'temperamental client' what their opinion is? Give them a heads up,
perhaps they'll be more reasonable than you anticipate?
Both myself and Don have stated on behalf of industrial clients that we
embrace breaking changes that move the language forward, or correct clearly
identifiable mistakes.

One of the key advantages to D over other languages in my mind is precisely
it's fluidity. The idea that this is a weakness doesn't resonate with me in
any way (assuming that it's managed in a
sensible/predictable/well-communicated manner).
I *like* fixing my code when a breaking change fixes something that was
unsatisfactory, and it seems that most others present feel this way too.
I've used C++ for a long time, I know very well how much I hate carrying
language baggage to the end of my years.

That said, obviously there's a big difference between random breakage and
controlled deprecation.
The 2 need to stop being conflated. I don't think they are the same thing,
and can't reasonably be compared.
I've never heard anybody object to the latter if it's called for. The
std.json example you raise is a clear example of the former.

On Thursday, 13 March 2014 at 01:18:14 UTC, 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.
>
> 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.

If I'm a enterprise customer I would be very angry if my code breaks with each new release of compiler. I will be angry irrespective of whether I'm paying for the compiler or not. Because every time my code breaks, I will have to allocate resources to figure out the reason why a working production code is broken and then have to test new code and testing can take months to complete.

Languages are adopted by enterprises only when there is long term stability to it. C code written 30 years back in K&R style still compiles without any problem. Please enhance the language but don't break existing code.

Also if something has to be deprecated, it should exist in that deprecated state for at least for 5 years. Currently it is one year and for enterprise customers that is a very short period.

- Sarath

On 13 March 2014 12:48, Andrei Alexandrescu <SeeWebsiteForEmail@erdani.org>wrote:

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


Again, trivialising the importance of this change.

 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.


Are you suggesting that only we in this thread care about this, at the expense of that growing silent majority?

Many of the new user's I've noticed appearing are from my industry. There
are seemingly many new gamedevs or ambitious embedded/mobile users. The
recent flurry of activity on the cross-compilers, Obj-C, is a clear
demonstration of that interest.
I suspect they are a significant slice of the growing majority, and
certainly of the growing potential. They care about this, whether they know
it or not. Most users aren't low-level experts, even though it matters to
their projects.

I want to know what you think the potential or likely future breakdown of industrial application of D looks like?

I have a suspicion that when the cross compilers are robust and word gets
out, you will see a surge of game/realtime/mobile devs, and I don't think
it's unrealistic, or even unlikely, to imagine that this may be D's largest
developer audience at some time in the (not too distant?) future.
It's the largest native-code industry left by far, requirements are not
changing, and there are no other realistic alternatives I'm aware of on the
horizon. Every other facet of software development I can think of has
competition in the language space.

On Thu, Mar 13, 2014 at 03:17:39AM +0000, Vladimir Panteleev wrote:
> 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.

Just to add another data point, FWIW: recently due to being busy with other matters I haven't been able to keep up with this forum, or do very much with D, but I do still write D code every now and then, and I do have some existing D code that I use regularly. Not long ago, a subtle (or not-so-subtle!) change in File.ByLine caused my code to break in a major, visible way -- the code didn't fail to compile, but the semantics changed. I found this extremely upsetting, because things like file I/O are something one expects to be stable in the long term, not reinvented every other release. (In fact, I posted about this in another thread, as some of you may recall.)

The change in question was a Phobos refactoring that, arguably, improved the quality of the code by eliminating some ugly hacks that were ostensibly causing "buggy" behaviour.  However, my code had come to depend on that "buggy" behaviour, and having it break like that while I was trying to "get work done" was not a pleasant experience, in spite of the fact that I am generally sympathetic to those clamoring to gradual language refinement via deprecation and redesign. (I even pushed for such breakages at times.) I can only imagine the reaction of someone who doesn't frequent this forum experiencing something like this upon upgrading DMD.

So I'd say the cost of breakage is very real, and is not something to be lightly dismissed. If I found it hard to swallow in spite of being sympathetic to those who want the language to improve by occasionally breakage of deprecated features, how much more will "normal" D users feel when things break from under their existing code?

(Now of course I'm not saying we shouldn't ever introduce any breaking changes -- I know of at least one occasion where I was actually *pleased* by a particular breaking change -- but I'm saying that we need to weigh the costs carefully and tread very lightly, because this is just the kind of thing that will turn people away from D.)


T

-- 
They pretend to pay us, and we pretend to work. -- Russian saying

On 3/12/14, 8:35 PM, Manu wrote:
> On 13 March 2014 10:15, Walter Bright <newshound2@digitalmars.com
> <mailto:newshound2@digitalmars.com>> wrote:
>
>     On 3/12/2014 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 D1 -> D2 transition very nearly destroyed D by sacrificing all
>     the momentum it had.
>
>
> To draw that as a comparison to the issue on topic is one of the biggest
> exaggerations I've seen in a while, and you're not usually prone to that
> sort of thing.

Actually a lot of measurements (post statistics, downloads) and plenty of evidence (D-related posts on reddit) support that hypothesis. The transition was a shock of much higher magnitude than both Walter and I anticipated.

Andrei

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.
>
> We're past the point where we can break everyone's code. It's going to cost us far, far more than we'll gain. (And you all know that if we could do massive do-overs, I'd get rid of put's auto-decode.)
>
> Instead, one can write:
>
>    class C { final: ... }
>
> as a pattern, and everything in the class will be final. That leaves the "but what if I want a single virtual function?" There needs to be a way to locally turn off 'final'. Adding 'virtual' is one way to do that, but:
>
> 1. there are other attributes we might wish to turn off, like 'pure' and 'nothrow'.
>
> 2. it seems excessive to dedicate a keyword just for that.
>
> So, there's the solution that has been proposed before:
>
>    !final
>    !pure
>    !nothrow
>    etc.

Yes please.

On Thursday, 13 March 2014 at 00:40:34 UTC, 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.

It won't happen that way if we evolve D such that it won't break existing code. Or manages it with long deprecation cycles. In 1989, ANSI C had come up with new function style without breaking old function style. After a while the new style has become the standard and the compilers gave warning messages. In D, we can issue "deprecated" messages.

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

That is true if your code is under active development. What if you had a production code that was written 2 years back?

- Sarath

On Wednesday, 12 March 2014 at 23:00:26 UTC, Namespace wrote:
> Would it mean that we would deprecate "nothrow" and replace it with "!throw"?

I like that !