4 ms·

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 ti

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)

mjd 8y ago
The previous article was about bikeshedding. This one is just about getting distracted.
- comesee 8y ago
  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.
  - gh02t 8y ago
    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.
    - glennpratt 8y ago
      I've never used bike shed to describe digressions on my own work. I might call these a Yak shave.
    - comesee 8y ago
      I think the jargon you're looking for is "yak shaving" not bikeshedding (which is about arguing about minor changes).
- ajross 8y ago
  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.
fjsolwmv 8y ago
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.
- bunderbunder 8y ago
  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.
- steinuil 8y ago
  So this would just be another form of the "Lisp curse"? http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html

mjd 8y ago

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

comesee 8y ago
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.
- gh02t 8y ago
  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.
  - glennpratt 8y ago
    I've never used bike shed to describe digressions on my own work. I might call these a Yak shave.
  - comesee 8y ago
    I think the jargon you're looking for is "yak shaving" not bikeshedding (which is about arguing about minor changes).
ajross 8y ago
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.

fjsolwmv 8y ago

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.

bunderbunder 8y ago
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.
steinuil 8y ago
So this would just be another form of the "Lisp curse"? http://winestockwebdesign.com/Essays/Lisp_Curse.html http://winestockwebdesign.com/Essays/Lisp_Curse.html