On 3/12/2014 10:30 PM, Manu wrote:
> Again, this is conflating random breakage with controlled deprecation.
> A clear message with a file:line that says "virtual-by-default is deprecated,
> add 'virtual' _right here_." is not comparable to the behaviour of byLine()
> silently changing from release to release and creating some bugs, or std.json
> breaking unexpectedly with no warning.

In the case I experienced, I got a clear compiler message. I knew what to fix. It still sucked. It was "fixing" non-buggy code that was intentionally written that way.

I don't have as much of a problem breaking things that were already broken and happened to work out of luck, but that isn't the case here.

On 3/12/2014 8:40 PM, Vladimir Panteleev wrote:
> On Thursday, 13 March 2014 at 00:18:06 UTC, Andrei Alexandrescu 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?

Keep in mind this isn't an all-or-nothing matter of "From now on, D will never evolve and never correct past mistakes". It's just a matter of "What's the right thing for D at this point in time?" Right now, the answer is "mature and stabilize".

*After* we've gotten there, that's when we'll face a choice of "Ok, so what now?" Maybe the answer will be "Yes, at this point we have the resources, userbase, stability, etc such that we can manage doing a branch to break out of the x, y and z corners we've painted ourselves into." Or maybe it'll be "Problems x, y and z have either become mitigated because of a, b and c, or we now have previously-unseen ways to deal with them non-destructively."

Right now: mature and stabilize. *Then* worry about where to go from there, breaking vs stagnating.

> Eventually, new programming languages will appear which will learn from
> D's mistakes, and no new projects will be written in D.
>

Sure. That's inevitable anyway. The trick is for D to prosper enough for D-next to be that new language, instead of something unrelated.

On Thursday, 13 March 2014 at 00:18:06 UTC, Andrei Alexandrescu 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.

One thing we can do is to have a better version scheme. Currently (breaking) language changes, (breaking) library changes and bug fixes all occur in the same release. There's no way to tell on the version number if a specific release was only a bug fix release (if we would do that).

--
/Jacob Carlborg

On Thursday, 13 March 2014 at 06:02:27 UTC, Walter Bright wrote:
>> 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.
>
> Breaking changes has been a huge barrier to Don's company being able to move from D1 to D2. I still support D1 specifically for Don's company.

Which has resulted in awkward situation where some of D2 feaures are really wanted but doing transition "at once" it too much of an effort to be managed easily.

D1 -> D2 had one huge breaking change that made the most difference - const qualifier system. This change did not have an obvious migration path, was not backed by compiler help and had lot of not so obvious consequences to language semantics.

There is no harm in doing small breaking changes if good transition path is provided.

I personally believe that far more damaging factor is that users often expect DMD versions to be minor version releases while those are in fact always major releases (which implies some possibility of breakage by definition).

Also while C/C++ itself is pretty stable, real compilers are not. I can't imagine anyone suddenly upgrading gcc version on production scale and expecting stuff to "just work". So it is wrong example to refer to.

On Thursday, 13 March 2014 at 05:15:58 UTC, Sean Kelly wrote:
> Regarding user retention... I've spent the past N months beginning the process of selling D at work.  The language and library are at a point of maturity where I think it might have a chance when evaluated simply on the merits of the language itself.  However, what has me really hesitant to put my shoulder behind D and really push isn't that changes occur sometimes.  Even big changes.  It's how they're handled.  Issues come up in the newsgroup and are discussed back and forth for ages.  Seriously considered.  And then maybe a decision is apparently reached (as with this virtual by default thing) and so I expect that action will be taken.  And then nothing happens.  And other times big changes occur with seemingly little warning.  Personally, I don't really require perfect compatibility between released, but I do want to see things moving decisively in a clearly communicated direction.  I want to know where we're going and how we're going to get there, and if that means that I have to hold on moving to a new compiler release for a while while I sort out changes that's fine.  But I want to be able to prepare for it.

I agree with this, in particular issues where a conclusion is reached that are then ignored for months or years. This is something that the preapproved Bugzilla tag should be able to help with, but I'm not sure how much it's being used in situations like this. In this example, Walter mentioned that he was essentially convinced to the change, then the thread faded off and the issue was ignored. This was over 9 months ago. There was no mention of whether this is something that would be done (or accepted if the community implements the change), it just reached a conclusion that made it seem like the change was likely and then it got set aside like many similar issues. In this case, eventually a pull request was made to begin the change process, which then sat there for over three months until it was merged, at which point Andrei mentioned his disapproval / rejection. Had this pull not gotten merged (whether it goes into an actual release or not), it would be just another topic that's discussed, seems like it's accepted, then is completely ignored.

On Thursday, 13 March 2014 at 04:13:42 UTC, Mike wrote:
> 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 would say to ignore as well, given that Modula-2 was created in 1978 just as an example of better alternatives.

On 3/13/14, Walter Bright <newshound2@digitalmars.com> wrote:
> On 3/12/2014 4:01 PM, luka8088 wrote:
>> How do you nearly lose a client over a change in a development branch which was never a part of any release? (or am I mistaken?)
>
> The change went into a release.

Couldn't the client just file a bug? We've already agreed we'd make point releases for regression fixes. Client files bug, we fix it, upload the new compiler, everybody is happy. In the meantime the client could have continued to use the previous release.

On Thursday, 13 March 2014 at 05:51:05 UTC, Walter Bright wrote:
> I'd like to address, in general, the issue of, what I term, "performance by default" which is part of the argument for final by default.
>
> C, C++, and D are billed as languages for writing high performance apps. And this is true. What is not true, or at least has not been true in my experience, is that an application is high performance merely because it is written in C, C++ or D.
>
> Let me emphasize, code is not fast just because it is written using a high performance language.
>
> High performance code does not happen by accident, it has to be intentionally written that way. Furthermore, I can pretty much guarantee you that if an application has never been profiled, its speed can be doubled by using a profiler. And if you really, really want high performance code, you're going to have to spend time looking at the assembler dumps of the code and tweaking the source code to get things right.
>
> High performance code is not going to emanate from those programmers who are not skilled in the art, it is not going to happen by accident, it is not going to happen by following best practices, it is not going to happen just because you're writing in C/C++/D.
>
> D certainly provides what is necessary to write code that blows away conventional C or C++ code.
>
> It reminds me of when I worked in a machine shop in college. I'd toil for hours cutting parts, and the parts were not round, the holes were off center, heck, the surfaces weren't that smooth. There was an older machinist there who'd take pity on me. He'd look at what I was doing, cluck cluck, he'd touch the bit with a grinder, he'd tweak the feed speed, he'd make arcane adjustments to the machine tool, and out would come perfect parts. I am an awe to this day of his skill - I still don't know how he did it. The point is, he and I were using the same tools. He knew how to make them sing, I didn't.
>
> I still cannot drill a goddam hole and get it where I measured it should be.

Fully agree with you. That is how we get around writing distributed applications in JVM/.NET with comparable performance to the C++ ones being replaced.

--
Paulo

On 3/13/14, Sean Kelly <sean@invisibleduck.org> wrote:
> As for the !virtual idea... I hate it.  Please don't add yet more ways for people to make their code confusing.

Also this needlessly invents new language for a language that's supposed to be familiar with C/C++ programmers. The "virtual" keyword has been known for decades, "!final" is the special-case which has to be thought. It also looks ugly and could easily be misread.

On 13.3.2014. 0:48, Walter Bright wrote:
> On 3/12/2014 4:01 PM, luka8088 wrote:
>> How do you nearly lose a client over a change in a development branch which was never a part of any release? (or am I mistaken?)
> 
> The change went into a release.
I see, that indeed is an issue.