One more issue

Mon Feb 16 11:46:38 PST 2015

On Mon, Feb 16, 2015 at 09:36:57AM -0800, Andrei Alexandrescu via Digitalmars-d wrote:
> On 2/16/15 6:33 AM, H. S. Teoh via Digitalmars-d wrote:
[...]
> One thought about "forward" and "SortOutput" - first may e.g. go in
> std.functional and the latter belongs to "sorting".

https://github.com/D-Programming-Language/phobos/pull/2996

> >>Also the table at the beginning uses some odd small fonts for the
> >>function names.
> >
> >Then fix the stylesheet. The macros were changed because now they
> >need to link to submodules instead of symbols in the current module.
> 
> This is the wrong attitude. Each pull request must leave the place
> better than it found it. You shouldn't leave stuff for others to clean
> up after you.

The point is that I *did* take the pains to make sure those links still
worked -- otherwise they would look all nice and pretty, exactly the
same as before, except that they wouldn't work anymore. The only fault
was that I didn't notice any font changes -- I usually don't pay
attention to those things, and my browser uses custom fonts anyway so my
default assumption is that it's a quirk of my browser, rather than
anything wrong with the actual font.

[...]
> >I have already said that I just copied the example of std.range and
> >std.container. There were no guidelines about what the .html filename
> >of package.d ought to become, so I did what any reasonable person
> >would do -- follow the example of previous modules in the project.
> 
> That underlines the importance of precedents. Someone way back when
> had a bad solution for adding packages to std/. It's repetitive and
> doesn't scale.  Then in a boiling frog manner, every subsequent
> package copied the bad example. The lesson here is we should not
> accept bad code, even if it seems small and innocuous.

Without a contribution guide, nobody can remember all these scattered
things that must be reviewed prior to merging, like making sure
dlang.org links aren't broken, making sure the navbar definitions in a
separate repo still match up with the current state of Phobos, etc..

[...]
> Then one possibility would have been to focus your efforts elsewhere. As
> things are right now:
> 
> * There is no added value to D users in splitting algorithm.d into a
> package.

I disagree.  Many users were complaining that importing std.algorithm
will pull in tons of Phobos baggage due to the mass of import
dependencies. Ilya, IIRC, wasted days trying to narrow down a compiler
bug because std.algorithm dependency soup made it very difficult to
reduce the problem past a certain point inside Phobos. A lot of
preliminary work was actually done by him -- localizing imports,
reducing inter-module dependencies, etc..

The new std.algorithm submodules, while far from perfect I'll admit, at
least limit the scope of transitive dependencies in user code. This
improves compile times, and makes Phobos more modular for people who
care about not pulling everything including the kitchen sink into their
executables.

> * Even the value to contributors is debatable and definitely low impact.

I completely disagree.

You are obviously unaware of the fact that the reason I embarked on this
fool's errand in the first place was because std.algorithm had grown so
large and unwieldy that I could not even run unittests on my machine
anymore -- the compiler just dies with an out-of-memory fork error. That
means (1) I cannot test my changes locally; (2) I have to rely on the
autotester, thereby adding unnecessary load for experimental changes
that are almost guaranteed to fail.  This increases the barrier of entry
to would-be contributors, since not everybody has the latest and
greatest souped-up PC with gobs of spare RAM, and they would also
experience (1) and (2).

I certainly did not sit down one day with too much free time on my hands
and tell myself "hmm, I'm bored today, I wonder which Phobos module I
can waste time on by needlessly refactoring it." The reason I even
contemplated such a foolhardy idea at all was because it was becoming
increasingly difficult for me to do any meaningful work on std.algorithm
due to its unwieldy size.

I think it's totally unfair to call this "low impact".

> * The documentation is in shambles.

It *wasn't* in shambles before this?

> All told we're looking at a net negative. I understand it can be
> transformed into a positive, but even if executed to perfection it's a
> low-impact artifact. And it's not executed anywhere near perfection.

I must admit I can't wrap my head around equating "make it possible for
contributors to run Phobos unittests locally without needing to upgrade
their PC" with "net negative" and "low-impact artifact".  Am I really
that out of touch with reality?

[...]
> I agree. It's a low impact change. Stop shuffling the deck. Add value.
> For my money I would have been a ton happier if you just finished work
> on groupBy, which _is_ high impact.

Again, I'm baffled by your continual insistence on calling something
"low impact" when it is affecting how contributors can successfully run
Phobos unittests without running out of memory, or reducing the amount
of interdependencies between Phobos modules so that it's easier to
isolate problems and pull in only stuff that's necessary for a
particular piece of code instead of pulling in the entire hairball of
dependencies that will end up linking half of Phobos to your program
just to call a single function.

Obviously, what I care about does not match what you care about, so it
would seem that the path of least pain would be for me to take a break
from contributing.

[...]
> >It would also help if things like the .html filename policy and other
> >such nitpicks were made clear from the beginning instead of being
> >tacked on afterwards and retroactively expected of past
> >contributions. It is making me rapidly lose interest in contributing
> >any further.
> 
> Again, this is the wrong attitude, please wean yourself off of it.
> That's not nitpicking. You changed the name of one high-traffic page
> on dlang.org.  There's no need to explain in a guide that that should
> be approached with maximum care.
> 
> Your work is appreciated. As I said, statistically most of my work is
> shit.  If I let that discourage me, I'd be homeless. Let's convert
> this into something good.
[...]

It's not about my work being shit or not. If my work is shit I would
rather appreciate it if somebody alerted me to that fact, or better yet,
improve on it so that it's not shit.

It's about spending a ton of my spare time to make something I care
about work (i.e., being able to run std.algorithm unittests locally
without running out of memory so that I can improve the quality of my
PRs), and then being told afterwards that it was essentially pointless
churn that adds no value, or worse, a net negative. I don't disagree
that it could have been carried out in a better way than it turned out,
but being told that making things easier for others was essentially
unwanted work really makes me reconsider contributing.

I understand that you are pushing to improve the quality of the website,
the general quality of PRs, etc., but there's no need to trample on
peripheral improvements in the meantime, however marginal they may seem
to you.

T

-- 
Food and laptops don't mix.