On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:
> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>> I agree, and if I remember previous discussions on the subject
>> correctly, it seems like only Walter is in favor of upholding the
>> current restrictions of "alias" parameters to symbols. I simply do not
>> see a point in pushing compiler implementation details on the user like
>> that – for the programmer, a type is a type is a type…
>>
>> Walter, do you have an example of a situation where the alias parameter
>> restriction would be beneficial?  (for the D code involved, I don't mean
>> the few lines of code avoided in the compiler)
>
> In any case, it will break a great deal of existing code to change  that behavior.

Please stop repeating that "will break lots of code" mantra. D user base is very small and it doesn't grow *because* issues like the one discussed do not get fixed. When they are fixed people may start using the language. And *then* you would have to worry about backward compatibility. Look at the recent Manu's complaints and see what people who would really use the language have wanted from it for years.

On Tuesday, 27 November 2012 at 18:10:51 UTC, Manu wrote:
> I feel this sentiment every day.
> I'm more than happy to receive breaking changes that make the language
> tidier and more consistent. I'll happily take the time to keep our codebase
> up to date.

I agree more than 100%. I've been struggling with inconsistency issues right from the get go, and it's very frustrating, esp when you see the brilliant potential that should be there but just quite isn't.

A suggested improvement written up here, solves at least some of it
http://forum.dlang.org/thread/xxenmxyshhscjhqjibkr@forum.dlang.org

--rt

On 11/28/2012 5:25 AM, Max Samukha wrote:
> Please stop repeating that "will break lots of code" mantra. D user base
> is very small and it doesn't grow *because* issues like the one
> discussed do not get fixed. When they are fixed people may start using
> the language. And *then* you would have to worry about backward
> compatibility. Look at the recent Manu's complaints and see what people
> who would really use the language have wanted from it for years.

I understand what you're saying, but the counterpoint is we lost half the D community when D2 broke D1 code. We still have at least one major D1 user that still finds it impractical to upgrade to D2.

It is unbelievably frustrating for people to have their code break with each new release, have older projects all invalidated, with few willing to do the maintenance work to bring them back on line.

On 11/28/2012 8:23 AM, Walter Bright wrote:
> It is unbelievably frustrating for people to have their code break with
> each new release, have older projects all invalidated, with few willing
> to do the maintenance work to bring them back on line.


Note the thread next to this one: "Errors compiling DSSS", and the advice to abandon it.

On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:
>
> I understand what you're saying, but the counterpoint is we lost half the D community when D2 broke D1 code. We still have at least one major D1 user that still finds it impractical to upgrade to D2.
>
> It is unbelievably frustrating for people to have their code break with each new release, have older projects all invalidated, with few willing to do the maintenance work to bring them back on line.

It may not be my place to say, but the unwillingness to maintain the D1 code seems to go well past just breakage issues.

Anyway, I figure D at this time is attracting mostly "early adopters" who don't always mind the odd breakage here and there so long as it's for the greater good. Once the D base expands beyond the early adopter phase, change will become much more difficult than it is right now, so whatever is being done today better be done well before it's too late.

My only suggestion is to re-think how a programming language can remain reasonably stable, yet at the same time evolve forward in significant ways over the long term. There must be plenty of real-world examples of this being done successfully that can be emulated with D.

If D is not allowed to change in significant ways, then it will slowly but surely become another C/C++, with "significant" updates once every 10 years or so which are mediocre and leave the root design defects in place.

--rt

Walter Bright:

> It is unbelievably frustrating for people to have their code break with each new release, have older projects all invalidated, with few willing to do the maintenance work to bring them back on line.

I am still converting some of my D1 code to D2, plus I have lot of D2 code. Since many months I have stopped downloading official dmd releases because the amount of breakages in my D2 code between a version and the successive one was too much large. DMD 2.061 has so many changes and improvements that it will require several changes in everyone D2 code.

To avoid performing such large amount of changes I now compile dmd every two or three days, and I have scripts that compile all my D2 programs and report the breakages. This way I fix a small amount of breakages at a time in my D2 code, this is simpler.

Most of those breakages are caused by bug fixings that reveal bugs in my D2 code (example: since recently throwing constructors accepted a nothrow tag, and I have many more examples). But I am willing to perform this maintenance work because they improve my future D2 programming and code.

If we add to those bug-fixing-changes some breakage caused by design changes, this is not going to make my live significantly worse, it's just one more breakage among several others.

Bye,
bearophile

On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:
> On 11/28/2012 5:25 AM, Max Samukha wrote:
>> Please stop repeating that "will break lots of code" mantra. D user base
>> is very small and it doesn't grow *because* issues like the one
>> discussed do not get fixed. When they are fixed people may start using
>> the language. And *then* you would have to worry about backward
>> compatibility. Look at the recent Manu's complaints and see what people
>> who would really use the language have wanted from it for years.
>
> I understand what you're saying, but the counterpoint is we lost half the D community when D2 broke D1 code. We still have at least one major D1 user that still finds it impractical to upgrade to D2.
>

Should we talk about phobos and tango here ? I'm pretty sure you can attribute most of that departure from that event.

> It is unbelievably frustrating for people to have their code break with each new release, have older projects all invalidated, with few willing to do the maintenance work to bring them back on line.

I have also bunch of code broken in the current release and find myself writing workaround for quirk in the language even for simple monomodule programs.

We have a project management issue here in the first place.

On Tuesday, 27 November 2012 at 21:23:12 UTC, Walter Bright wrote:
> On 11/28/2012 5:25 AM, Max Samukha wrote:
>> Please stop repeating that "will break lots of code" mantra. D user base
>> is very small and it doesn't grow *because* issues like the one
>> discussed do not get fixed. When they are fixed people may start using
>> the language. And *then* you would have to worry about backward
>> compatibility. Look at the recent Manu's complaints and see what people
>> who would really use the language have wanted from it for years.
>
> I understand what you're saying, but the counterpoint is we lost half the D community when D2 broke D1 code. We still have at least one major D1 user that still finds it impractical to upgrade to D2.

That was more than a breaking change. That was a massive paradigm shift. All the drama going on back then was rooted more in philosophical differences and the Phobos/Tango divide, than changes to the language. What's being discussed here is breakage on a much smaller scale.

I've always said that it's the little things in aggregate that make D such a wonderful language to work with. But the flipside of that is the little annoyances in aggregate can make it frustrating to work with. New users coming to a language often have little patience. IMO, their encountering these little annoyances before the good stuff takes hold is a far more pressing issue than a few minor breaking changes.

I've no idea what sort of commercial interests are using D in production, but I'd still confidently make the bet that a few breaking changes now (for issues that people find frustrating) would do more good than harm in the long run. Especially if they are introduced gradually and with time to understand their ramifications.

On Wednesday, 28 November 2012 at 00:07:42 UTC, bearophile wrote:
> Walter Bright:
>
>> It is unbelievably frustrating for people to have their code break with each new release, have older projects all invalidated, with few willing to do the maintenance work to bring them back on line.
>
> I am still converting some of my D1 code to D2, plus I have lot of D2 code. Since many months I have stopped downloading official dmd releases because the amount of breakages in my D2 code between a version and the successive one was too much large. DMD 2.061 has so many changes and improvements that it will require several changes in everyone D2 code.
>
> To avoid performing such large amount of changes I now compile dmd every two or three days, and I have scripts that compile all my D2 programs and report the breakages. This way I fix a small amount of breakages at a time in my D2 code, this is simpler.
>
> Most of those breakages are caused by bug fixings that reveal bugs in my D2 code (example: since recently throwing constructors accepted a nothrow tag, and I have many more examples). But I am willing to perform this maintenance work because they improve my future D2 programming and code.
>
> If we add to those bug-fixing-changes some breakage caused by design changes, this is not going to make my live significantly worse, it's just one more breakage among several others.
>

Don't you think that this whole situation is due to adding feature after feature in an unstabilized mess ?

I mean, how the fact that a nothrow constructor can throw can be explained in another way (to use your example) ? A feature in that state should have reached any release, ever !

Am 27.11.2012 18:47, schrieb Eldar Insafutdinov:
> On Monday, 26 November 2012 at 19:59:42 UTC, Walter Bright wrote:
>> On 11/27/2012 5:52 AM, David Nadlinger wrote:
>>> I agree, and if I remember previous discussions on the subject correctly, it seems like only Walter is in favor of upholding the current restrictions of "alias" parameters to symbols. I simply do not see a point in pushing compiler implementation details on the user like that – for the programmer, a type is a type is a type…
>>>
>>> Walter, do you have an example of a situation where the alias parameter restriction would be beneficial?  (for the D code involved, I don't mean the few lines of code avoided in the compiler)
>>
>> In any case, it will break a great deal of existing code to change  that behavior.
> 
> The discussed issue is one of those inconsistencies that make people struggle when using D. D's main selling point is rich meta programming. Others are rapidly catching up in the field of expressive native languages. If we set these early design decisions in stone, it means we will not be able to compete with them. And besides, are there many big proprietary D2 codebases that you afraid? I doubt there are. And Manu actually represents people who are willing to work on one, but are held off by these issues. Open source projects however will be easily fixable, and people using D will actually welcome these positive changes.

We do have a largish code base that is also gradually used commercially (200k+ lines of library code, when including vibe.d plus any applications that are built on top of it). My former employee now has a smaller code base along the lines of 80k+ LOC). So I guess such code bases are in fact a reality.

... and still I very much prefer to have "good" breakage that cleans up the language. It's just things that break code for nothing (most of the time bugs) that are really annoying.

And I fully agree, we should better collect warts of the language and fix them as early as possible. This may set up a few people now, but will make all the future users of the language + a lot of the current users much more happy.

Realistically, the current approach with one branch that is not supposed to get breaking changes, but gets them anyway as soon as it _has to_, just extends the period of time in which things get broken and also in which the language still has those issues.