Hacker News Reader

Comment by jashkenas | Hacker News Reader

The Rails commit that spurred this post, apparently: https://github.com/rails/rails/pull/5329

To me it is not bike-shedding, but being rightfully indignant with decisions being made not by merit but from a position of "authority", completely ignoring the opinion of the majority of people presenting pretty logical arguments in favour of the change. I do not understand how you can defend returning a method call result completely meaningless from the caller point of view by saying that returning an actually meaningful one would suddenly make everyone think that the xyz? methods have to return true/false everywhere. This is the kind of reaction you get from people when you refuse to admit you were wrong after it is already clear to everyone you were.

Maybe they are just trying to optimize for pedantry.

That's the only objective read of this. There were a couple of good reasons to make the change, a couple of bad reasons to, and no reasons not to. The discussion fixated on the bad reasons early on, it became a matter of principle on both sides, and thus the change was not made despite the good reasons.

It's not bikeshedding, but there ought to be a name for that.

My read of the article is that "bikeshedding" generally covers discussions in which the energy expended vastly outweighs the gravity of the topic under discussion. There can be a correct answer to, "what color should we paint the bike shed?" (or, at least, many incorrect answers). The fact that one side might be correct (or more correct) than the other does not justify the effort.

The point of the article, as I read it, was that you should consider the energy needed to influence a decision v.s. the impact of that decision.

I think the point we're making is that most of the people arguing over that PR didn't have a strong opinion about the feature itself, but were irritated by the weirdly philosophical reason for rejecting it. (I don't care what color you paint your bike shed, but if your local government says you can't paint it green because that's surrendering to the plants, I'm likely to have an opinion about that.)

Obviously at some point (and the earlier the better) you still need to to throw up your hands and walk away, but I'd say pig wrestling is the better metaphor here.

Bah, I can't be bothered to read the whole thing. Before the request was closed, if I understood correctly, the argument was about whether or not `xhr?` needed to return a boolean rather than what it's doing which is aliasing a regex match.

Hmm, call it bike-shedding if you want, but I have to be honest part of the beauty and value of Ruby is how semantic it can be made when you follow some conventions. How hard or awful is it to just actually return a boolean here? I mean is anyone expecting or relying on the clearly undocumented feature that it also returns the offset of where `/XMLHttpRequest/i` is found in the request?

The problem with throwing out the 'bikeshedding' defence is that it goes both ways. It's their choice to fight a small, trivial pull request that appears to make logical sense, and arguably reduces the potential for cognitive friction.

It's debatable who's actually bikeshedding here.

Dude, that's deep. You're bike shedding the bike shed. So meta. Turtles all the way down. Touché!

Fair enough, I wont argue with your elastic defence ;).

Upvoted you despite the slightly obfuscated phrasing, because it's essentially true. This turned into a bikeshedding discussion on bikeshedding the moment lucisferre misrepresented his own definition of bikeshedding as the canonical definition.

Did I? Perhaps you could elaborate for my benefit then.

This happens all the time, and I'd argue, is the source of what many consider bike shed issues, even when they're not.

An essential element of a bike shed disagreement is that the matter being discussed must be trivial. That is, the color of a bike shed doesn't matter. It has no impact on the utility of the bike shed. This is a function before form viewpoint.

Ah, but if real life were only so black & white.

In practice, triviality is a sliding scale. The presence of the offset is only trivial if you're not using it. So, to some people, it's a bike shed issue. To others, it's a matter of breaking lots of code. Clearly not a bike shed.

Agreed. It all depends on perspective. That's why I've always found the term to be needlessly dismissive.

Just wanted to note, I had a chance to read the closed pull request from later and then this post (http://blog.leshill.org/blog/2012/03/25/a-question-of-truth....) and I see the point being made, which is not against the change, but in defence of not making an unneeded one.

So my understanding of the situation was poor. But then I am, admittedly, a bike shedding rookie.

However, and this is just my opinion, I still feel as though calling out everyone (there was a good number of people involved including @tpope) as rookies and accusing them of bike shedding, seemed like, well, poor taste, and unhelpful.

To summarize it: Someone upgraded from Rails 2.3 and had an issue, since xhr? stopped returning a boolean but 0 instead (the regex index of the first match). But he used the return value of that predicate in javascript. In Ruby 0 is truthy, but in Javascript it is false. So he made a pull request to change the behavior back to a boolean instead of 0.

@fxn then said that's not needed, and the predicate did return a truthy value and the contract never specified that it would actually return a boolean, so no contract was broken, so there is nothing to fix. (The Rails documentation uses monospaced "true" and "false" for the singletons and normal "true" and "false" for truthy and falsey values.)

Then Tim Pope suggested an alternative solution that would actually return a boolean. It got merged by @tenderlove but quickly reverted by @fxn again.

And so the bike shedding continued...

Indeed, it took me some 24 hours to revert. I reflected about it for some time.

After thinking about it for a day, I was convinced the commit was sending the wrong message, and felt it had to be reverted. The commit message explains the rationale.

Ah I'm sorry, I should have rechecked before posting this. I meant no offense.

There you see how closely I follow this story... :)

I hate to be harsh, but just to give some perspective: You really come across as stubborn and intractable there. Your rationale basically boils down to "People might think I was wrong if we change this." The reason given is not anything like "The code I am reverting is inferior," it's just "This code doesn't support the point I want to make." You even said that if his commit message had been different — not the code, just the commit message — you would have left it.

Try imagining this from somebody else's eyes — what does it look like?

I can only say you basically have no idea what you are talking about. I know my motivations, you can't read my mind chc.

That is true, and I'm sorry if it sounded that way. I was speaking from the perspective of interacting with other people, not your inner thoughts. You might actually have had very good reasons why your choice was superior, but you did not share them with anyone else, and from an impartial observer's perspective, it looks like this stonewalling is what made a simple PR turn into a huge bikeshedding flamefest. If this doesn't matter to you, I apologize for wasting your time. It just seemed like something I would want to hear if I were in your place.

If that was the intention I appreciate it.

Yes it matters to me, but up to a point. I cannot do things in my life seeking approval or saying yes to some people when I am convinced the answer is no.

Also, saying no, and not applying the PR the way I did, with the rationales and respect I showed, should not be taken as an offense. People just get upset when they see the red label "Closed".

On the other hand, for every 24 haters, I can present 24 lovers. It just doesn't matter, one has to do what he thinks is the correct action. Do it politely, but do it.

It's more than that though. It seemed really clear that a lot of people thought this was useful, and you blew off all objections without really explaining sufficiently why. It's not that big of a deal, and it sucks that everyone wasted so much time on it, but the thing that bothers me about it is that I (and it sounds like a number of other people) have come away from this still not understanding why the change is rejected. We understand what you wrote about predicates not guaranteeing a boolean, but your attitude kind of implied that predicates should not return a boolean and, clearly, a number of people don't understand why that makes sense.

What you failed to address was why your way was better than returning a boolean true/false. Everyone understood your comments that predicates don't necessarily need to return those, but your comments kind of read like "my way is perfectly valid Ruby" while the other people's perspective seemed to be "our way is perfectly valid Ruby also, and it alleviates some potential annoyances or pitfalls". You never really addressed any of that, it always seemed to just go back to "my way is valid Ruby".

Maybe this wasn't really your intention, but it honestly seemed as though you were deliberately trying to frustrate people. I think that's why there was so much push-back (in the form of about three other PRs being opened). Not because people felt so strongly about xhr?, but because it just seemed like you were just rejecting everyone's opinions without really expressing why returning true/false is worse than returning 0/nil.

I'm basically a total outsider since I haven't contributed to Rails yet, so feel free to completely ignore my perspective.

Yes, good point - all the more reason to be mindful of the impressions you make on others, since their perception is their reality.

Thanks for not allowing code convention to be based on mob psychologoy.

It was my pull request. It was spurred by a compatibility break that took all of two seconds to fix in our app, but the principle of the matter is what irked me.

And it wasn't from passing it to JavaScript, it was from parameterization from Ruby to Ruby.

I didn't really care that much about it getting merged in, so long as the docs changed (fxn's argument about using a fixed-width font in html docs to indicate the singleton true vs a truthy value is something that really ought to change). That stance is unfriendly to developers and follows what seems to be the Principle of Most Surprise.

At the end of the day, it's not worth all the trouble for something so trivial. I'd rather rails-core deal with more important issues. And that's the last time I ever send a pull request on principle to a project I don't own.

Thanks for the link. It wasn't clear to me, however, who was doing the bikeshedding.

If you read the original source for the term at http://bikeshed.com/, Kamp shows his respect for the submitter of the change:

  I bow my head in respect to the original proposer because 
  he stuck to his guns through this carpet blanking from
  the peanut gallery, and the change is in our tree today.
  I would have turned my back and walked away after less
  than a handful of messages in that thread.

This is how I feel about the pull request: a seemingly innocuous change that looks, to this outsider anyway, well worth making. It seemed to have been declined over a concern that people would come to expect Rails to formalize undocumented behavior that others had relied on. I've been consuming Rails docs for years (thank you to the contributors), and that doesn't seem that crazy to me.

(Edit: formatting.)

I found this comment https://github.com/rails/rails/pull/5329#issuecomment-466968... interesting for the implications of keeping an instance variable around as opposed to true / false.

It's frustrating to work with people who will go to the mat over pedantic, highly philosophical points like that, right or wrong. Arguments should be grounded on concrete pros/cons.

Reply on news.ycombinator.com