On Wednesday, 24 September 2014 at 14:56:11 UTC, Don wrote:
>
> I agree completely. I would say that the #1 problem in D is the paranoid fear of breaking backwards compatibility. I said that in my 2013 talk. It is still true today.
>
> Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old design bugs while we still can.
>
> For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet?

Yep.  So long as the messaging is clear surrounding breaking changes I'm all for it.  In favor of it in fact, if it makes the language better in the long term.  Dealing with breakages between compiler releases simply isn't a problem if the issues are known beforehand, particularly if the old compiler can build the new style code.

D isn't unique in this respect anyway.  The C++ compiler our build team uses at work is sufficiently old that it can't compile certain parts of Boost, for example.  We've been pushing to get a newer compiler in place, and that comes hand in hand with code changes.  But we *want* the breaking change because it actually solves problems we have with the current compiler iteration.  Similarly, I want breaking changes in D if they solve problems I have with the way things currently work.

I kind of feel like D is stuck in prototype mode.  As in, you demo a prototype, people like what they see and say "ship it", and rather than take the time to make the real thing you *do* ship it and then immediately start working on new features, forever sticking yourself with all the warts you'd glossed over during the demo.  In this case we were prototyping new features to ourselves, but the same idea applies.

On Wednesday, 24 September 2014 at 14:56:11 UTC, Don wrote:
>
> I agree completely. I would say that the #1 problem in D is the paranoid fear of breaking backwards compatibility. I said that in my 2013 talk. It is still true today.
>
> Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old design bugs while we still can.
>
> For example: We agreed *years* ago to remove the NCEG operators. Why haven't they been removed yet?
>
> As I said earlier in the year, one of the biggest ever breaking changes was the fix for array stomping, but it wasn't even recognized as a breaking change!
> Breaking changes happen all the time, and the ones that break noisily are really not a problem.
>
> "Most D code is yet to be written."
>
>> What change in particular?
>
> I've got a nasty feeling that you misread what he wrote. Every time we say, "breaking changes are good", you seem to hear "breaking changes are bad"!
>
> The existing D corporate users are still sympathetic to breaking changes. We are giving the language an extraordinary opportunity. And it's incredibly frustrating to watch that opportunity being wasted due to paranoia.
>
> We are holding the door open. But we can't hold it open forever, the more corporate users we get, the harder it becomes.
> Break our code TODAY.
>
> "Most D code is yet to be written."

As the CTO of a company having the main selling products "powered by D", I totally agree with Don: break our code TODAY.

We are aiding ALS impaired people to have a better life with D products, so I can tell that we definitely care about SW quality...
But a planned breaking change, that improves the language overall, will always be welcomed here in SR Labs.

---
/Paolo

Don:

> I agree completely. I would say that the #1 problem in D is the paranoid fear of breaking backwards compatibility. I said that in my 2013 talk. It is still true today.
>
> Sociomantic says, PLEASE BREAK OUR CODE! Get rid of the old design bugs while we still can.

I keep a large amount of working D2 code, mostly for scientific-like usages (plus other code outside work, like almost one thousand of Rosettacode programs, a lot of lines of very carefully written good code). Most of such code is divided in many small programs. I have plenty of unittests and I also use contract programming. A planned breaking change, if it gives clear and nice error messages, allows me to fix the whole code base in a limited amount of time (1 hour, or 2 hours or a little more), and often it's an easy work that I can do late in the day when I am too tired to do more intelligent work anyway. Compared to the work to understand the problems, invent the problems, invent the solutions, and write working code, the amount of brain time & work to keep code updated is not significant for me.

So I suggest to deprecate the built-in sort, deprecate other things that are waiting for it since some time, do the other language updates that you think are good.

Bye,
bearophile

On 2014-09-24 08:57, Walter Bright wrote:

> Heck, the dmd release package build scripts break every single release
> cycle.

The it's obviously doing something wrong.

-- 
/Jacob Carlborg

On Tue, Sep 23, 2014 at 10:37:59PM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/23/2014 10:10 PM, H. S. Teoh via Digitalmars-d wrote:
> >Yeah, I wish that at least *some* attention would be paid to refining existing features so that problematic corner cases could be ironed out.
> 
> It's kinda maddening to hear statements like that. Just in 2.066:
> 
> 103 compiler regressions fixed
> 235 compiler bugs fixed
> 39 language enhancements
> 12 phobos regressions fixed
> 110 phobos bugs fixed
> 41 phobos enhancements
> 9 druntime regressions fixed
> 17 druntime bugs fixed
> 9 druntime enhancements
> 
> https://dlang.org/changelog.html#list2066
> 
> 
> >Like identifier lookup rules for local imports.
> 
> Suddenly this issue goes to a mountain overnight. Is it really the most critical, important problem, overshadowing everything else?

No, I just named it as a representative case of many such wrinkles within existing language features. The fact of the matter is, wherever you turn, there's always something else that hasn't been fully ironed out yet. Features that interact with each other in unexpected ways. Corner cases that weren't considered / are hard to fix due to the nature of the features involved. Fixes that require a decision -- which are often neglected because there are too many other things being worked on.

Sometimes I wish there were less features in D, but far more refined. I'd rather go without the myriad of awesome features in D if I can only have a small set of features that have been fully worked out such that there are no nasty corner cases, deep-seated compiler bugs, or surprising gotchas that lurk around the corner as soon as you start writing non-trivial code.


> >And what to do about dtors. And so many little niggling details that seem minor, but added together, can form a pretty big mountain of frustration sometimes.
> 
> So help out!

I am, as you yourself point out later. But it's frustrating when pull requests sit in the queue for weeks (sometimes months, or, in the case of dmd pulls, *years*) without any indication of whether it's on the right track, and dismaying when your PR is just one of, oh, 100+ others that also all need attention, many of which are just languishing there for lack of attention even though there is nothing obviously blocking them, except perhaps the reviewers' / committers' time / interest.

The situation with Phobos has improved dramatically, thanks to a well-timed rant some months ago, which triggered a coordinated effort of aggressive merging, pinging, reviewing, etc. -- we've managed to cut the Phobos PR queue from around 90+ to around 29 as of last night (from 4+ pages on github to only barely 2 pages). For that, I applaud my fellow Phobos reviewers, and I hope the trend will continue until the Phobos PR queue is firmly back at 1 page (<=25 open PRs).

Unfortunately, the problem persists in druntime, dlang.org, and dmd. It feels like there's a forest fire raging and only a handful of firefighters, and now we want to add more fires (new development directions) without adding more people. What about reviewing and merging / rejecting the 100+ PRs in the dmd queue, most of which contain fixes and language improvements that people have been waiting for, for a long time, before we think about new directions? Some PRs appear to fix bugs opened *years* ago, and yet nothing is done about them. Some PRs are at an impasse due to decisions that need to be made, yet nobody is making said decisions or even discussing them, and the PRs just continue to rot there. There are already a *ton* of new features / fixes / language improvements that are waiting to be decided upon (and, given the size of the dmd PR queue, I submit this is no exaggeration), and yet we are indifferent and instead look away to new directions.

Many of us are indeed ready to help, but it would *really* be nice if our help is received more readily, or, at the very least, *some* indication is shown that more effort will be put into reviewing said help before more energy is expended in new directions. The dramatic shortening of the Phobos PR queue over the last 2-3 months proves that this is not only possible, but also beneficial (more fixes are making it into Phobos than ever before) and improves morale (people are more likely to contribute if they don't have to wait 3 weeks before getting any feedback for their contribution) -- if we would only put our efforts into it. So here's to hoping that the other PR queues will shorten quickly in the near future. ;-)

And mind you, the lengths of the PR queues are only the tip of the iceberg of stuff we ought to finish doing before embarking on the next new direction. There are a ton of old bugs that need attention, and a ton of language features that need improvement / refinement. We could at least pay those *some* heed even if we absolutely have to start something new right now at this moment. It would be a great tragedy if D goes down in history as the project that had so many great ideas, none of them carried out to completion.


T

-- 
Debian GNU/Linux: Cray on your desktop.

On 9/24/2014 11:42 AM, Jacob Carlborg wrote:
> On 2014-09-24 08:57, Walter Bright wrote:
>
>> Heck, the dmd release package build scripts break every single release
>> cycle.
>
> The it's obviously doing something wrong.

See my reply to Vladimir.

On Wednesday, 24 September 2014 at 08:53:51 UTC, user wrote:
> On Wednesday, 24 September 2014 at 06:28:21 UTC, Manu via
> Digitalmars-d wrote:
>> On 20 September 2014 22:39, Tofu Ninja via Digitalmars-d
>> <digitalmars-d@puremagic.com> wrote:

> i couldn't agree more. i would like to add, that coming from D1's
> clean and nice syntax - D2 becomes a syntactic monster

You are a bit right, it is about on the edge and dragging all those undecisions with it only makes things worse.

People usually say that complexity is not that bad, because you only use what you know (but what about maintenance?). Still, people criticize C++ for being too complex.

http://abstrusegoose.com/strips/ars_longa_vita_brevis.PNG

80 percents of C++ programmers know only 20% of the language. However, not *the same* 20% percents...

On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote:
> On 9/24/2014 2:56 AM, Vladimir Panteleev wrote:
> >On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright wrote:
> >>On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
> >>>On 24/09/14 06:31, Walter Bright wrote:
> >>>
> >>>>But it is a bit unreasonable to expect large project maintainers to rebuild and check for bugs every day. It's why we have a beta test program.
> >>>
> >>>The solution is to make it automatic.
> >>
> >>
> >>There's no such thing as automatic testing of someone's moving target large project with another moving compiler target.
> >
> >It doesn't exist because no one has created it yet :)
> 
> I've never heard of a non-trivial project that didn't have constant breakage of its build system. All kinds of reasons - add a file, forget to add it to the manifest. Change the file contents, neglect to update dependencies. Add new dependencies on some script, script fails to run on one configuration.  And on and on.

Most (all?) of these issues are solved by using a modern build system.
(No, make is not a modern build system.)


> >>Heck, the dmd release package build scripts break every single release cycle.
> >
> >Digger succeeds in building all D versions in the last few years. It doesn't build a complete package like the packaging scripts, but the process of just building the compiler and standard library is fairly stable.
> 
> Building of the compiler/library itself is stable because the autotester won't pass it if they won't build. That isn't the problem - the problem is the package scripts fail. (This is why I want the package building to be part of the autotester.)

That's a good idea. Packaging the compiler toolchain should be automated so that we don't have a packaging crisis every other release when inevitably some script fails to do what we thought it would, or git got itself into one of those wonderful obscure strange states that only an expert can untangle.


T

-- 
Trying to define yourself is like trying to bite your own teeth. -- Alan Watts

On 2014-09-24 12:16, Walter Bright wrote:

> I've never heard of a non-trivial project that didn't have constant
> breakage of its build system. All kinds of reasons - add a file, forget
> to add it to the manifest. Change the file contents, neglect to update
> dependencies. Add new dependencies on some script, script fails to run
> on one configuration. And on and on.

Again, if changing the file contents breaks the build system you're doing it very, very wrong.

-- 
/Jacob Carlborg

On 9/24/14, 12:20 PM, H. S. Teoh via Digitalmars-d wrote:
> On Wed, Sep 24, 2014 at 03:16:58AM -0700, Walter Bright via Digitalmars-d wrote:
>> On 9/24/2014 2:56 AM, Vladimir Panteleev wrote:
>>> On Wednesday, 24 September 2014 at 06:57:14 UTC, Walter Bright
>>> wrote:
>>>> On 9/23/2014 11:24 PM, Jacob Carlborg wrote:
>>>>> On 24/09/14 06:31, Walter Bright wrote:
>>>>>
>>>>>> But it is a bit unreasonable to expect large project maintainers
>>>>>> to rebuild and check for bugs every day. It's why we have a beta
>>>>>> test program.
>>>>>
>>>>> The solution is to make it automatic.
>>>>
>>>>
>>>> There's no such thing as automatic testing of someone's moving
>>>> target large project with another moving compiler target.
>>>
>>> It doesn't exist because no one has created it yet :)
>>
>> I've never heard of a non-trivial project that didn't have constant
>> breakage of its build system. All kinds of reasons - add a file,
>> forget to add it to the manifest. Change the file contents, neglect to
>> update dependencies. Add new dependencies on some script, script fails
>> to run on one configuration.  And on and on.
>
> Most (all?) of these issues are solved by using a modern build system.
> (No, make is not a modern build system.)
>
>
>>>> Heck, the dmd release package build scripts break every single
>>>> release cycle.
>>>
>>> Digger succeeds in building all D versions in the last few years.
>>> It doesn't build a complete package like the packaging scripts,
>>> but the process of just building the compiler and standard
>>> library is fairly stable.
>>
>> Building of the compiler/library itself is stable because the
>> autotester won't pass it if they won't build. That isn't the problem -
>> the problem is the package scripts fail. (This is why I want the
>> package building to be part of the autotester.)
>
> That's a good idea. Packaging the compiler toolchain should be automated
> so that we don't have a packaging crisis every other release when
> inevitably some script fails to do what we thought it would, or git got
> itself into one of those wonderful obscure strange states that only an
> expert can untangle.

We of course agree on all these good things but it's all vacuous unless somebody champions it.

Andrei