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)
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.
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.
This seems to be a form of self-inflicted "nerd sniping", as defined by XKCD: https://www.xkcd.com/356/
It's fair to question the tool in this case. As programmers we rely on our tools to provide abstractions that free our minds from thinking about details that don't matter. If the tool (or perhaps the culture around using the tool) insists that we deal with details we're not interested in or don't care about, perhaps the tool is not the best one for the task at hand.
It’s meta-fun because you’re getting fun with the mean rather than the end.
To me, it’s fun to achieve a goal — programming to solve a real problem, implementing something that I can use or others can. It’s super
fun when my program works, has no bugs, it’s cute and nice.
To others, the act itself of programming is funnier than actually doing something useful, so that you can deep dive into the best way of programming without actually doing something useful if not a program complex enough to use whatever programming feature you want to have meta-fun with.
The tool/culture doesn't insist on this. One of the arguments for using languages like haskell is: it is easier to refactor your abstractions as necessary along the way, so you should just pick the one that works now, although the tooling around could always be improved.
15 comments
[ 3.7 ms ] story [ 38.2 ms ] threadAnd 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)
I think both could probably be called bikeshedding, but it's interesting to make a distinction between the two.
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.
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.
http://winestockwebdesign.com/Essays/Lisp_Curse.html
It's fair to question the tool in this case. As programmers we rely on our tools to provide abstractions that free our minds from thinking about details that don't matter. If the tool (or perhaps the culture around using the tool) insists that we deal with details we're not interested in or don't care about, perhaps the tool is not the best one for the task at hand.
To me, it’s fun to achieve a goal — programming to solve a real problem, implementing something that I can use or others can. It’s super fun when my program works, has no bugs, it’s cute and nice.
To others, the act itself of programming is funnier than actually doing something useful, so that you can deep dive into the best way of programming without actually doing something useful if not a program complex enough to use whatever programming feature you want to have meta-fun with.