Hacker News Reader

Comment by forkerenok | Hacker News Reader

This is indeed bikeshedding (as the author himself rightfully hints at with irony).

And I wouldn't say it's anything specific to Haskell: I've seen a lot of times in other languages people trying to flesh entire libraries around a domain-specific primitive that go far beyond their current needs.

I'd say the Haskell community (its focus) is more "at fault" here, encouraging these kinds of exploratory rabbit-hole-diving. Though, to be fair, there are people there with get-shit-done mentality (github/bos and github/ocharles come to mind) and I see more of that kind coming in lately.

Pick the weakest structure that will satisfy your current needs and move on. (by ocharles, paraphrased)

View on HN

The previous article was about bikeshedding. This one is just about getting distracted.

Isn't bikeshedding defined to be "arguing about trivial details." The first article wasn't about arguing. Also since semantics are trivial, this is meta.

The articles are about two subtly different problems. The first is finding something difficult in your code and then getting distracted learning about it in depth. The second is about getting lost in the process applying deep theory to a simple concept. The first is "I know too little, I must know more", while the second is "I know all this cool theory, I must use it."

I think both could probably be called bikeshedding, but it's interesting to make a distinction between the two.

I've never used bike shed to describe digressions on my own work. I might call these a Yak shave.

I think the jargon you're looking for is "yak shaving" not bikeshedding (which is about arguing about minor changes).

You're, uh, both wrong. Properly, a "bike shed" discussion is one where many people inject their opinion on a subject that is peripheral and needless. The opinions may very well be correct, but the weight of the discussion is a loss vs. just picking someone's choice and moving on.

By implication, this happens because the more complicated details of a project (e.g. designing a nuclear reactor in the original) or community are complicated and the domain of specific experts, and arguing about peripheral details (the color to paint the bike shed) is a way for the non-experts to show contributions.

It's more that Haskell is so powerful and expressive that it let's you see and quickly wxploret ever more powerful and related abstractions, where most other languages would bog you down in syntax or semantic cul-de-sacs that force you to stop (or drain your energy for) expanding the program's power.

I think you could easily frame it either way.

Which framing works best depends on the context. When I'm having fun, or trying to learn, exploring abstractions is deeply edifying.

When I'm on the clock, though, any time I spend on "expanding the program's power" beyond the minimum necessary to get the job done is wasteful.

So this would just be another form of the "Lisp curse"?

http://winestockwebdesign.com/Essays/Lisp_Curse.html

Reply on news.ycombinator.com