On 3/31/19 8:01 PM, Mike Franklin wrote:
> On Sunday, 31 March 2019 at 16:18:35 UTC, Rubn wrote:
> 
>> Look at this comment as someone pointed out before:
>>
>> https://github.com/dlang/dmd/pull/8557#pullrequestreview-149952733
> 
> Yes, Andrei's review was a bit too strong but he did change course later in that thread.  Also recognize that the original author did not provide much motivation or justification (though, I'm guilty of that too).

Those were unnecessarily strong words.

Allow me to give a bit more context whilst clarifying I am not defending or condoning that attitude.

That comment came after a few phone conversations whereby Walter mentioned he has a deluge of pull requests to review. He said if he's to spend due time on all of those, he'd be unable to do any work of his own. Those pull requests that have these things in common (note that some may not apply to the pragma pull request, I'd just wrongly put it in the same bin):

* they are large
* the improvement they bring needs arguing
* their quality could be improved so they need careful review and a couple of passes of changes

This is what I call Good Work.

Good Work is often sizable in quantity, and is visibly the result of concerted effort by a competent person. Those unfamiliar with a codebase and with the subtleties of the task at hand cannot produce Good Work.

(Contrast that with Bad Work: by definition, it is easy to inspect and reject. It does not create a major slowdown in a project.)

Good Work is more often than not complex. Complexity is misrecognized as evidence of the complexity of the problem; the task was hard, the reasoning goes, because the solution is difficult in proportion.

Good Work begets more Good Work. Typically Good Work produces context, opportunity, and precedent for more of the same. The same reviewer who rubber stamped a piece of Good Work will have an idea how to produce more Good Work derived from it. The kind of environment where Good Work is revered encourages its creation, in a cycle that creates the illusion of progress. Because Good Work is complex, it produces "bug ripples" whereby increasingly complex Good Work fixes one bug but is liable to introduce others.

Good Work is difficult to argue against. The main argument in favor, which is very difficult to counter, is that Good Work is better than Bad Work and better than No Work. It is easy to create an opinion trend in favor of this or that Good Work.

However, there are problems with Good Work. The first one is scale: an accumulation of Good Work does not add up to Great Work. More often, the increasing entropy leads to the thermal death of the project.

An accumulation of Good Work is what leads to six nested calls in an advanced library to convert a string to an integer. Even if they are inlined away in execution, their smell persists.

An accumulation of Good Work is what leads to a multitude of "is this kinda sorta almost like-a string hey I really mean it this time quite like a string" tests, or "we must to add @trusted every five lines of code".

The other problem of Good Work is that it takes the air out of the room, causing Great Work to suffocate. Good Work takes great effort to author, debate, review, debug, and maintain. All that takes away time and mental share that should go into Great Work instead.

Which brings us to Great Work.

Great Work solves difficult problems with a paucity of means; it is quintessentially and surprisingly /not/ proportional response. Because of that, it is often deceptively simple, but always in a way that is impossible to anticipate yet obvious in afterthought. Scala's implicits and D's static if are great work.

Great Work often reformulates an entire challenge to reveal false choices or artificial constraints. Alexander the Great figured it doesn't matter how to get rid of the Gordian knot, so he cut it. While philosophers were still puzzling over The Ship of Theseus, Richard Feynman pointed out that the very notion of identity is ill-defined because a philosopher wouldn't even be able to tell which atoms belong to a chair, and which don't. Replacing complex type-based metaprogramming with trivial compile-time evaluation is great work.

Great Work is often recognizable to out-of-domain people, the person on the street. In contrast, Good Work has high-brow expertise as a prerequisite. Beethoven's Fourth Symphony is a respectable repertoire piece for any Philharmonic, one that music aficionados would listen to with respect. I once saw a janitor, a little old lady with no previous exposure to classical music, crying when she heard Bach's Air for the first time. Using the same programming language on the client and server, or at compile-time and run-time, or for computation and its constraints, is great work clear as rain. You don't need to be an expert to appreciate that.

Great Work is what we should all aspire to. Great Work is the cure for Good Work.

This, however, brings up a question: it seems that Great Work is not really easy to do on a regular basis. What to do, therefore, on a "regular" day when inspiration doesn't strike?

This brings us to Right Work.

Right Work is work that is undeniably, pound-on-the-table good, however unexciting or trivial.

Right Work will be silently appreciated by one's peers as the incontestably right thing to do. Paying your rent, debts, and other bills is Right Work.

Right Work is not necessarily simple. Becoming a better spouse or teaching your kids that lying is not a good policy - that's also Right Work.

In a software project, reducing the number of global variables is Right Work.

Making public data private is Right Work. (Careful, perversions are always possible. This is not Right work:

public int percent;

==>

private int _percent;
int percent() { return _percent; }
void percent(int p) { _percent = p; }

The obscure word "phronesis" - thanks Laeeth - should be a buzzword in software engineering circles.)

Reducing state and mutation is Right Work. That means adding the "immutable" qualifier to variables and the "pure" attribute to functions.

Making unsafe code safe is Right Work. That means inserting "@safe" wherever possible, and identifying the smallest "@trusted" primitives.

Replacing legacy pointer-and-length ad-hoc pairs with slices is Right Work. So is replacing a complicated unstructured loop with a structured foreach loop.

Most refactorings that meaningfully reduce the number of lines of code are Right Work. Of course, that could be perverted, too. I'm not talking more statements per line of code. I'm talking more /work/ per line of code.

Much Right work paradoxically requires less virtuosity than complicated artifacts of Good Work.

A successful software system is a construction of Great Work on a foundation of Right Work, with the inevitable Good Work here and there.

That's where we want to be.

On 4/1/19 5:23 PM, Timon Gehr wrote:
> Reasoning from first principles, the right fix is actually to allow non-const length.

D'accordo. Can you please put forth a PR to that effect?

On Mon, Apr 01, 2019 at 07:22:40PM -0400, Andrei Alexandrescu via Digitalmars-d wrote: [...]
> That comment came after a few phone conversations whereby Walter mentioned he has a deluge of pull requests to review. He said if he's to spend due time on all of those, he'd be unable to do any work of his own. Those pull requests that have these things in common (note that some may not apply to the pragma pull request, I'd just wrongly put it in the same bin):
> 
> * they are large
> * the improvement they bring needs arguing
> * their quality could be improved so they need careful review and a
> couple of passes of changes
> 
> This is what I call Good Work.
[...]
> Which brings us to Great Work.
[...]
> This brings us to Right Work.
[...]
> A successful software system is a construction of Great Work on a foundation of Right Work, with the inevitable Good Work here and there.
> 
> That's where we want to be.

Had this been posted openly at the time, there might have been a lot less frustration.  This is an area I feel desperately needs improvement. This repeated lack of communication of this sort of thought process in one form or another is what leads to repeated frustrations and conflicts, because would-be contributors feel like information is being withheld that would have enabled them to better understand what is expected of them.  Even if these were just vague thoughts or a crude outline of what you have in mind, and nowhere near something formal and "presentable", providing partial information is better than no information at all.


T

-- 
In theory, there is no difference between theory and practice.

On Monday, 1 April 2019 at 23:22:40 UTC, Andrei Alexandrescu wrote:
> On 3/31/19 8:01 PM, Mike Franklin wrote:
>> On Sunday, 31 March 2019 at 16:18:35 UTC, Rubn wrote:
>> 
>>> Look at this comment as someone pointed out before:
>>>
>>> https://github.com/dlang/dmd/pull/8557#pullrequestreview-149952733
>> 
>> Yes, Andrei's review was a bit too strong but he did change course later in that thread.  Also recognize that the original author did not provide much motivation or justification (though, I'm guilty of that too).
>
> Those were unnecessarily strong words.
>
> Allow me to give a bit more context whilst clarifying I am not defending or condoning that attitude.
>
> That comment came after a few phone conversations whereby Walter mentioned he has a deluge of pull requests to review. He said if he's to spend due time on all of those, he'd be unable to do any work of his own.

_I_ do most of the reviewing now, and this doesn't seem to have had any effect, see https://github.com/dlang/dmd/pull/9494 and related PRs.

> Those pull requests that have these things in common (note that some may not apply to the pragma pull request, I'd just wrongly put it in the same bin):
>
> * they are large
> * the improvement they bring needs arguing

When they are requisites for fixing bugs they don't, as was the case with most of the ones I'm pissed off about, and Jacob's recent ones are to make DMD as a library more useful...

> * their quality could be improved so they need careful review and a couple of passes of changes

(Exactly which is not at all what has, and _still is_ being done.)
... In particular you are typically seeing a snapshot of a PR when you comment, and see only that change in isolation and miss the conversation in past PR discussion about where this is going. It is perfectly fine, in fact I encourage you, to inquire why this specific change is being made, we'll point you to the previous discussion.

What is _not_ fine is the drive-by style of review. This includes "Please don't let bureaucracy stand in the way of progress".

> A successful software system is a construction of Great Work on a foundation of Right Work, with the inevitable Good Work here and there.
>
> That's where we want to be.

The dlang ecosystem operates as an army of volunteers, you don't _get to choose_ the standard of work that comes in. It is was it is, and it will stay that way until such a time as it is not run by an army of volunteers. Yes, you can try to improve it (and so you should) but it needs to come off that that is your intention. Far too often, it comes off that you don't understand what or why the PR is doing what it is doing.

On 3/29/2019 7:28 AM, ag0aep6g wrote:
> https://github.com/dlang/phobos/pull/6939

Thank you

On 4/1/2019 6:11 PM, H. S. Teoh wrote:
> Had this been posted openly at the time, there might have been a lot
> less frustration.  This is an area I feel desperately needs improvement.
> This repeated lack of communication of this sort of thought process in
> one form or another is what leads to repeated frustrations and
> conflicts, because would-be contributors feel like information is being
> withheld that would have enabled them to better understand what is
> expected of them.  Even if these were just vague thoughts or a crude
> outline of what you have in mind, and nowhere near something formal and
> "presentable", providing partial information is better than no
> information at all.

Actually, Andrei and I simply assumed this was obvious. Obviously, it wasn't.

On 2019-04-02 01:22, Andrei Alexandrescu wrote:

> This brings us to Right Work.

I'm the first to say that I'm all for improving the code base. I really hate how difficult it can be to convince management that a code base need to be improved instead of working on a feature. But, to be blunt, if you get what you want and everyone is doing Right Work as you describe it, there won't be any progress. No bugs fixed or no new features. I don't know how often you expect this Great Work to occur, which might mean progress. Unfortunately the source code is not the product, it's the application, the tool, the library or whatever it might be.

-- 
/Jacob Carlborg

On Tuesday, 2 April 2019 at 08:26:34 UTC, Walter Bright wrote:
> [snip]
>
> Actually, Andrei and I simply assumed this was obvious. Obviously, it wasn't.

Maybe he should adapt it into a D blog post?

On Tuesday, 2 April 2019 at 11:15:42 UTC, jmh530 wrote:
> On Tuesday, 2 April 2019 at 08:26:34 UTC, Walter Bright wrote:
>> [snip]
>>
>> Actually, Andrei and I simply assumed this was obvious. Obviously, it wasn't.
>
> Maybe he should adapt it into a D blog post?

For now on reddit. https://www.reddit.com/r/programming/comments/b8igay/great_work_is_the_cure_for_good_work/

On Tuesday, 2 April 2019 at 12:39:12 UTC, Rose wrote:
> On Tuesday, 2 April 2019 at 11:15:42 UTC, jmh530 wrote:
>> On Tuesday, 2 April 2019 at 08:26:34 UTC, Walter Bright wrote:
>>> [snip]
>>>
>>> Actually, Andrei and I simply assumed this was obvious. Obviously, it wasn't.
>>
>> Maybe he should adapt it into a D blog post?
>
> For now on reddit. https://www.reddit.com/r/programming/comments/b8igay/great_work_is_the_cure_for_good_work/

It's not unusual for a programmer to have strong opinions about programming. While Andrei's actions will have an impact on our community (and I was critical of some of the things he's done earlier in the thread) I don't think there's anything particularly newsworthy about this thread. I've seen nothing to suggest he's unhinged or anything other than frustrated.