On Thu, 23 Oct 2014 07:47:00 +0000
via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:

> On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via Digitalmars-d-learn wrote:
> > besides, no "serious" language can live without "legacy". legacy is a sign of maturity. ;-)
> 
> So you are basically saying that D is a teenager for whom wearing ugly make-up is a sign of maturity?
exactly. it seems to me that some D developers have strange feeling that accumulating legacy will show D maturity and will help D to become more widespread. despite all "#breakourcode" requests from real D users.

On Thursday, 23 October 2014 at 07:54:05 UTC, ketmar via Digitalmars-d-learn wrote:
> On Thu, 23 Oct 2014 07:47:00 +0000
> via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com> wrote:
>
>> On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via Digitalmars-d-learn wrote:
>> > besides, no "serious" language can live without "legacy". legacy is a sign of maturity. ;-)
>> 
>> So you are basically saying that D is a teenager for whom wearing ugly make-up is a sign of maturity?
> exactly. it seems to me that some D developers have strange feeling
> that accumulating legacy will show D maturity and will help D to become
> more widespread. despite all "#breakourcode" requests from real D users.

I would be very surprised if anyone thinks that. It's a question of what breakage is worth making and the fact that every time we break people's code, we risk ticking users off and scaring them away. It doesn't work to become widespread - particularly in production - when you frequently break people's code (even with a good reason), and breakage needs a good reason even when it's rare. Deciding whether a particular change is worth making is always a subject of big debate. There _are_ cases where most everyone agrees and yet Walter won't make the change, but there are also plenty where there definitely isn't a consensus. For attributes, there's a consensus that the situation is not ideal, but there definitely isn't a consensus on what we should do about it or whether it's worth breaking code to fix it. And because it's pretty much an aesthetic thing, it's exactly the sort of thing where it would be very difficult to convince Walter or Andrei to make the change (especially Walter). Making the change won't fix any bugs and won't prevent any bugs, so it's a hard sell.

Regardless, no one is actually aruging that we want to leave any kind of legacy cruft in the language just so that we have legacy cruft and therefore look mature. It comes down to whether fixing that legacy cruft is worth it when everything else is taken into account, and because we are very much trying to make it so that D is mature enough to be used in production and gets wider adoption, the bar that something has to pass in order to be considered worth changing (particularly by Walter) is much, much higher than it would have been a few years ago.

- Jonathan M Davis

On Thu, 23 Oct 2014 21:33:00 +0000
Jonathan M Davis via Digitalmars-d-learn
<digitalmars-d-learn@puremagic.com> wrote:

> On Thursday, 23 October 2014 at 07:54:05 UTC, ketmar via Digitalmars-d-learn wrote:
> > On Thu, 23 Oct 2014 07:47:00 +0000
> > via Digitalmars-d-learn <digitalmars-d-learn@puremagic.com>
> > wrote:
> >
> >> On Thursday, 23 October 2014 at 06:59:16 UTC, ketmar via Digitalmars-d-learn wrote:
> >> > besides, no "serious" language can live without "legacy". legacy is a sign of maturity. ;-)
> >> 
> >> So you are basically saying that D is a teenager for whom wearing ugly make-up is a sign of maturity?
> > exactly. it seems to me that some D developers have strange
> > feeling
> > that accumulating legacy will show D maturity and will help D
> > to become
> > more widespread. despite all "#breakourcode" requests from real
> > D users.
> 
> I would be very surprised if anyone thinks that. It's a question of what breakage is worth making and the fact that every time we break people's code, we risk ticking users off and scaring them away. It doesn't work to become widespread - particularly in production - when you frequently break people's code (even with a good reason), and breakage needs a good reason even when it's rare.
and those poor souls who already commited to D often just can't run away, so they can stand alot annoying things, even if they praying to break their code. this is J. Random, The Reddit User who really matters. J. Random never used D for anything more complex than "hello, world", but maybe he will write another "hello, world", and if we'll change that inconsistent feature, which annoys alot of actual users, J. Random will scream in pain! even if "changing the feature" means at least one year of deprecation first, and J. Random's "hello, world" will work for this year, and compiler will guide him in fixing his code.

why can't i see that J. Random in recent discussion about deprecating prefix 'const'? the universal answer was: "yes, break our code NOW! PLEASE!" including people from the companies with big D codebases.

will it help if we'll start reddit campaigns instead of trying to talk in this NGs? seems that J. Random The Reddit User has much more influence on decisions like that.

> Deciding whether a particular change is worth making is always a subject of big debate.
...and then someone will come and say: "no, we won't do that despite anything you wrote here."

> There _are_ cases where most everyone agrees and yet Walter won't make the change, but there are also plenty where there definitely isn't a consensus. For attributes, there's a consensus that the situation is not ideal, but there definitely isn't a consensus on what we should do about it or whether it's worth breaking code to fix it.
i bet alot of people just tired of endless talking which leads nowhere. heh, the strongest argument that can stop almost any discussion is "well, try to convinve Walter". Walter is very talented person, he's great person, and he is open to discussion, but it seems to me that he has very solid picture of what he wants D to be and don't want to change small things that are OK for him, but annoying for others. but those "small issues that barely worth changing" tend to accumulate and hurt the whole language.

> And because it's pretty much an aesthetic thing, it's exactly the sort of thing where it would be very difficult to convince Walter or Andrei to make the change (especially Walter). Making the change won't fix any bugs and won't prevent any bugs, so it's a hard sell.
yes, that things just making life a little easier for D users. take me, for example: i still can't remember where i should put that '@' and where i shouldn't. it's not on top of my fingers and it has no logic behind, so trying to remeber such thing breaks me out of my "thinking stream". and this is so easy to fix that this annoys me each time. and while it left unfixed, we accumulating more and more D code, making fixing this thing in future close to impossible, 'cause it will really break huge codebases.

aestetic things matters alot.

> Regardless, no one is actually aruging that we want to leave any kind of legacy cruft in the language just so that we have legacy cruft and therefore look mature.
yes, i'm sarcastic when saying this, and when i'm saying that "existing D users are second-class citizens", but how else can i show that this issues *matters* *alot*?

> and because we are very much trying to make it so that D is mature enough to be used in production
people from companies which using D tells that it will be good to make some code-breaking change and this change will made their codebases easier to maintain and will make code from new developers less error-prone. and... they are mostly ignored. so it seems to me that having some useless legacy is the only way to sell D to some "enterprise production".

> the bar that something has to pass in order to be considered worth changing (particularly by Walter) is much, much higher than it would have been a few years ago.
that's where my sarcastic "legacy means maturity" was born.

i love D and i want D to be widespread, but what makes me love D is it's attitude to fixing stupid legacy we have in C and C++. and now it seems to me that someone should start "BetterD" project to fix legacy we already have in D. ain't the desire to fix legacy cruft was one of the big driving forces of D creation? it's a pity for me to see that D starting to follow some of the worst C++ aspects.

On Thursday, 23 October 2014 at 22:20:28 UTC, ketmar via Digitalmars-d-learn wrote:
> i love D and i want D to be widespread, but what makes me love D is
> it's attitude to fixing stupid legacy we have in C and C++. and now it
> seems to me that someone should start "BetterD" project to fix legacy
> we already have in D. ain't the desire to fix legacy cruft was one of
> the big driving forces of D creation? it's a pity for me to see that D
> starting to follow some of the worst C++ aspects.

_Every_ language ends up with legacy cruft if it ever gets any kind of widespread use in the real world. If you want a language that never has legacy cruft, I expect that you will be forever disappointed. The question is what is and is worth changing and at whether you ever reach the point that you're _never_ allowed to break code (which is pretty much where C++ is). I certainly hope that D never reaches the point that we'll never break code even when it truly makes sense to do so, but we _have_ reached the point where the reasons have to be much stronger.

Some stuff that could currently be considered legacy cruft will probably be changed, but it's generally a hard sell, particularly because Walter is _very_ paranoid about breaking people's code (arguably too much so). Though it should be noted that the vast majority of D users never post in the newsgroup, and many of them probably have never visited it, so basing anything on what's discussed in the newsgroup is basing it on the most dedicated users, which aren't necessarily representative of the user base sa a whole, which always makes it difficult to figure out which decisions that would break code are okay and which aren't and is probably part of why Walter overreacts to some of the comments on places like reddit.

Regardless, you can certainly try and lobby for the attribute names to be normalized, but I don't expect it to change, in this particular case, while I'd certainly be open to it if Walter want to get rid of all of the @s on all of the built-in attribute names, I also don't really care if they stay the way they are. It's a minor annoyance, but I never found it hard to learn which ones had @ on them and which didn't (just treat it like one extra letter to learn in the keyword), and I'm light years beyond the point where I memorized them all. The primary annoyance about it at this point is having to answer questions on it when yet another user tries to figure out why some have @ and some don't as if there's a discernable pattern to it, and there isn't. And that sucks, but it doesn't actually cause bugs (unlike allowing const on the left-hand side of a member function, which definitely should be deprecated), and it's actually pretty easy to explain.

- Jonathan M Davis

On 10/24/2014 7:20 AM, ketmar via Digitalmars-d-learn wrote:

>
> why can't i see that J. Random in recent discussion about deprecating
> prefix 'const'? the universal answer was: "yes, break our code NOW!
> PLEASE!" including people from the companies with big D codebases.
>

There are people out there using D who do not participate in the newsgroups. Walter has told us before that he gets emails from companies using D in production. He has to deal with complaints about code breakage that we aren't going to see here in the NG. Just keep in mind that no matter how many of us here agree on a breaking change, we are not the entirety of the D user base. And it has nothing to do with Reddit.

On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote:
>
> There are people out there using D who do not participate in the newsgroups. Walter has told us before that he gets emails from companies using D in production. He has to deal with complaints about code breakage that we aren't going to see here in the NG. Just keep in mind that no matter how many of us here agree on a breaking change, we are not the entirety of the D user base. And it has nothing to do with Reddit.

I think that Walter talked about emails complaining about "silent breakage" or "regressions", and that's a totally different matter.

To be honest, I only remember that he talked about one single case, but maybe I'm wrong.
And I don't remember any complain about code deprecations.
---
/Paolo

On Friday, October 24, 2014 08:19:48 Paolo Invernizzi via Digitalmars-d-learn wrote:
> On Friday, 24 October 2014 at 00:37:26 UTC, Mike Parker wrote:
> > There are people out there using D who do not participate in the newsgroups. Walter has told us before that he gets emails from companies using D in production. He has to deal with complaints about code breakage that we aren't going to see here in the NG. Just keep in mind that no matter how many of us here agree on a breaking change, we are not the entirety of the D user base. And it has nothing to do with Reddit.
>
> I think that Walter talked about emails complaining about "silent breakage" or "regressions", and that's a totally different matter.
>
> To be honest, I only remember that he talked about one single
> case, but maybe I'm wrong.
> And I don't remember any complain about code deprecations.

Walter doesn't seem to understand that unintended breakage and planned, communicated breakage via a proper deprecation process are two totally different issues. He's definitely had folks complain about regressions, and the response to that has sometimes been that changes that we were considering got axed, because he'd just had someone complain about (unintended) code breakage, and for him, that meant that pretty much _anything_ which would eventually result in code breakage was bad and therefore raised the bar on changes that much more (IIRC, that happened just after the virtual keyword had been introduced, and the result was that it was removed, and the plans to switch to final by default were axed).

So no, I don't think that folks have complained to him about deprecations (though they could have, and he just never said anything about it), but they have complained often enough about other stuff, and he doesn't seem to distinguish between planned breakage and unintentional breakage in the same way that many of the rest of us do.

- Jonathan M Davis

Hi people and thanks for weighing in. It's nice to note that there's already a DIP on this. I hope it's refined and implemented in a future version in a meaningful manner. Is it OK to edit the wiki to add one's opinions?

And in this case, personally I'm not sure why people are talking about code *breakage*, which is a big word IMO. It's after all removing or adding @ in a few cases. It's relatively straightforward a fix to automate. If there can be a dfix to relocate the const from before to after the function name, then this should be much easier, no? It wouldn't even need a D3, but could be done in a future D2 point release. And as someone else said, there's a difference between outright breakage and planned deprecation.

As for the cases when serious changes to the grammar are needed, I feel the Py2 to Py3 transition is a good example to emulate. Lots of cleanup happened in Py3, Py2 is still supported, and there exists tools like 2to3 and six (https://pypi.python.org/pypi/six) to help people bridge the gap.

Finally in general I'd also like to suggest that rather than saying something like "you won't be able to convince Walter of this because it's not important", which IMHO tends to somewhat put off newbies who are excited by the language and want to contribute, and tends to put the project masters in an autocratic light (which people won't like to hear), one might consider saying something like "D 2 is now aiming for stability so we are trying to minimize the number of grammar changes".

Thanks again, all!

-- 
Shriramana Sharma ஶ்ரீரமணஶர்மா श्रीरमणशर्मा

On Friday, 24 October 2014 at 14:23:04 UTC, Shriramana Sharma via Digitalmars-d-learn wrote:
> As for the cases when serious changes to the grammar are needed, I
> feel the Py2 to Py3 transition is a good example to emulate. Lots of
> cleanup happened in Py3, Py2 is still supported, and there exists
> tools like 2to3 and six (https://pypi.python.org/pypi/six) to help
> people bridge the gap.

I agree that "@"-stuff is trivial, but I don't think Python sets a good example. The codebase is basically divided in two, libraries have to support both, and I think they should have changed more if going to the trouble.

In essence you should either change so little that upgrading is trivial or you should improve the language enough to ensure that all new projects choose the improved language.

However, Python is in widespread use on a fairly massive scale and is dynamic, which makes breaking very serious as it happens at runtime.

D could with little trouble undergo a massive change where the static type system catch the issues and call it D3.

The real problem is that there is no design for a D3 rooted in a semantic model that is clean. Such a transition would require a solid formal specification where you eliminate all weird aspects.

But I don't think anyone is working on a new spec? I am willing to help out if other people are interested.

On Friday, 24 October 2014 at 15:06:25 UTC, Ola Fosheim Grøstad wrote:
> I agree that "@"-stuff is trivial, but I don't think Python sets a good example. The codebase is basically divided in two, libraries have to support both, and I think they should have changed more if going to the trouble.

Yes, Python has a real problem with this.

I would like to see a proper deprecation path implemented in D. I don't want my code breaking but i'm willing to accept *informed* deprecation, followed by removal. Even if this process takes place over a few years.