On Thursday, 13 March 2014 at 05:15:58 UTC, Sean Kelly wrote:
> 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.
>
> I find this a bit baffling.  Given the investment this customer must have in D, I can't imagine them switching to a new language over something like this.  I hate to say it, but this sounds like the instances you hear of when people call up customer service just to have someone to yell at.  Not that the code breakage is okay, but I do feel like this may be somewhat of an exaggeration.

And std.json is among the worst code I've ever seen. I'm a bit shocked that anyone would be using it in production code.

> Regarding this virtual by default issue.  I entirely support Manu's argument and wholeheartedly agree with it.  I even think that I'd be more likely to use D professionally if D worked this way, for many of the same reasons Manu has expressed.  There may even be a window for doing this, but the communication around the change would have to be perfect.
>
> 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.  As things stand, I'm worried that if I got a team to move to D we'd have stuff breaking unexpectedly and I'd end up feeling like an ass for recommending it.  I guess that's probably what prompted the "almost lost a major client" issue you mentioned above.  This JSON parser change was more the proverbial straw than a major issue in itself.

I agree completely.

Some things that really should be fixed, don't get fixed because of a paranoid fear of breaking code. And this tends to happen with the issues that can give nice warning messages and are easy to fix...

Yet there are still enough bugs that your code breaks every release anyway.
We need to lose the fantasy that there is legacy code which still compiles.
Anything more than a year or so old is broken already.

> As for the !virtual idea... I hate it.  Please don't add yet more ways for people to make their code confusing.

On 3/13/14, Peter Alexander <peter.alexander.au@gmail.com> wrote:
> If that library is no longer maintained then it just stops working

Which is a good thing. Why would you use an umaintained library? There is no such thing as a perfect library that has all of its bugs fixed. No maintenance => dead project.

> As for the release time and beta: most people aren't on the forums daily. They don't know this is happening. The people on this forum are not representative D users.

Those who wish to represent themselves should represent themselves. You want to represent the D clients who:

- Won't file bugs
- Won't disclose their names
- Won't disclose that they're using D
- Won't contribute to D

Exactly what makes them a worthwhile client to keep? Is it just in order to be able to privately brag about client X using your technology Z? I really don't understand how D "wins" with these ghost clients that do not represent themselves.

On 3/13/14, Daniele Vian <dontreply@example.com> wrote:
> I think you can do every changes you need / you want but you should allow some time for people to update to new versions. No problems if you want to set a function as "deprecated" (or even a whole library) but please don't break compatibility all of a sudden (and without warning even in the changelog).

As was said before this wasn't a planned API break, it was a regression. It will be fixed in the next point release, the fix for this has already been merged to the master branch.

But why didn't you simply file a bug report instead of report to Walter?

Don píše v Čt 13. 03. 2014 v 09:49 +0000:
> Yet there are still enough bugs that your code breaks every
> release anyway.
> We need to lose the fantasy that there is legacy code which still
> compiles.

+1000

> Anything more than a year or so old is broken already.
Even recent code does not compile with latest dmd.
With almost each dmd release I must rewrite plenty of my D code base.


> > As for the !virtual idea... I hate it.  Please don't add yet more ways for people to make their code confusing.
+1

On 3/13/14, Andrej Mitrovic <andrej.mitrovich@gmail.com> wrote:
> Those who wish to represent themselves should represent themselves.

Another important point to make: If client A says a specific changeset was bad, what gives client A priority over client B who says the same changeset is good? These clients need to  communicate directly with the community and the developers via the forums and by filing bugs/enhancement reports.

I believe clients (why are we calling them "clients" anyway?) should have to provide reasonable arguments for preferring one feature over another, beyond the simple "we're using D therefore we're important" argument.

Andrej Mitrovic:

> You want to represent the D clients who:
>
> - Won't file bugs
> - Won't disclose their names
> - Won't disclose that they're using D
> - Won't contribute to D
>
> Exactly what makes them a worthwhile client to keep?

They grow the community of the D users, that eventually could buy D-related products like IDEs or plug-ins or lints, etc. They could buy Andrei book and give a little of money to Andrei. They could create D apps that sometimes become known and give some more visibility to D, and generally D is an open source tool, so you create it for people, often people that don't contribute back. So it's right to respect such people and "clients". But all this can't justify to stop carefully planned changes of D.

Bye,
bearophile

To me it seems this whole debate highlights the problem in the release cycle, not in the development of the language. DMD needs a long-term stable point release, supported for at least a year. Everybody should expect possible breakage in the latest development release, even if unintended. The latest version should also be marked as development/experimental on the download page.

-- 
mk

+1

On Thursday, 13 March 2014 at 10:24:10 UTC, Martin Krejcirik wrote:
> To me it seems this whole debate highlights the problem in the release
> cycle, not in the development of the language. DMD needs a long-term
> stable point release, supported for at least a year. Everybody should
> expect possible breakage in the latest development release, even if
> unintended. The latest version should also be marked as
> development/experimental on the download page.

On Thursday, March 13, 2014 11:24:10 Martin Krejcirik wrote:
> To me it seems this whole debate highlights the problem in the release cycle, not in the development of the language. DMD needs a long-term stable point release, supported for at least a year. Everybody should expect possible breakage in the latest development release, even if unintended. The latest version should also be marked as development/experimental on the download page.

Considering that a lot of the breakage that occurs (most?) actually results from fixing bugs, I don't think that trying to maintain "bugfix" releases is really going to help much. There may ultimately still be some value in them, but most people who suggest this sort of solution seem to be under the impression that it would somehow stop accidental code breakage, and that isn't the case at all. Pretty much the only way to guarantee no accidental breakage is to make no changes at all - including bug fixes.

- Jonathan M Davis

A lot of people here are talking about C. They are saying that C almost do not have changes that had break compatibility and it's good. But people are forgot, that D is much more complex language then C is.

Look at C#, it's had a lot of changes and it's become from stupid clone of Java very powerful and modern language.

But also look at Python. Pythons are afraid about backward compatibility for a long time and as result we have 2 incompatibility version 2.x and 3.x. And 3.x version was released 6 years ago (!).

I understand that people do not like to fixing code, but it's better to fix most important things now, than to get pain in the future.

IMHO.