Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why I never finish my Haskell programs

blog.plover.com

Post reply on HN
Print view View original

21–30 of 228 posts

Re: Why I never finish my Haskell programs

#21

Post by ajross »

jerf wrote: post #10

You can eventually "come out the other side" and get to the point where you write the general version correctly the first time. But it is some degree of work. I think it's a good exercise for a pro, but you can certainly live without it. The general principle does come in handy elsewhere, though. Doing the most useful work with the minimum power is a generally useful skill. I get a lot of mileage out of it in other l…

> You can [...] write the general version correctly the first time. But it is some degree of work. [...] Doing the most useful work with the minimum power is a generally useful skill.

There's something wrong with that logic, but I'm too lazy to work out the proof in the general case.

Re: Why I never finish my Haskell programs

#22

Post by cortesoft »

galfarragem wrote: post #12
kelvin0 wrote: post #9

Earlier quoted context omitted.

My tentative answer is this: someone who uses Haskell appreciates elegant solutions (a.k.a mathematical/functional) and is inclined to write things 'properly' once and they might also idealize that the functions they write will not only solve this current issue, but be useful to others and themselves in other programs ... thus going down the generalization and elegance rabbit hole. Of course, all of this is purely sp…

Resuming: the typical Haskeller is a perfectionist. If I allowed, without blinking, my perfectionist self would ditch every language but Haskell. No other mainstream language can give you more control and purity. For a perfectionist this is opium.

It is a particular form of perfectionism. Other types of perfectionists might want to be perfect at writing programs as fast as possible.

Re: Why I never finish my Haskell programs

#23

Post by sdegutis »

gabipurcaru wrote: post #5

I think the main reason is that there is no _actual_ problem that OP needs to solve. If there was one, then he would get pragmatic and figure out one of the reasonable solutions to this and move on with his life. Though it's true that Haskell is easy to put you into a mindset where you want to simplify and generalize the code as much as possible, leading to wasted time on overly general solutions. Which shouldn't be…

I lost confidence in Haskell's ability to let me write something one way and safely refactor it later, when I found out that you can't use a ton of the algorithmic functions in the standard library because they do things all wrong.

Re: Why I never finish my Haskell programs

#26

Post by yogthos »

I definitely find there's a strong relationship between language complexity and bikeshedding. When you have a big language like Haskell or Scala, it's easy to get distracted from solving the actual problem by trying to do it the most "proper" way possible. This is also how you end up with design astronautics in enterprise Java as well where people obsess over using every design pattern in the book instead of writing direct and concise code that's going to be maintainable.

Nowadays I have a strong preference for simple and focused languages that use a small number of patterns that can be applied to a wide range of problems. That goes a long way in avoiding the analysis paralysis problem.

Re: Why I never finish my Haskell programs

#27

Post by hhmc »

I'm reminded of one of my favourite HN comments on Haskell:

'There's something very seductive about languages like Rust or Scala or Haskell or even C++. These languages whisper in our ears "you are brilliant and here's a blank canvas where you can design the most perfect abstraction the world has ever seen.'

https://news.ycombinator.com/item?id=7962612

Although it's not 100% applicable in this case (unless you argue that the cost is to your own time) - I think the sentiment is perfect.

Re: Why I never finish my Haskell programs

#28

Post by mac01021 »

yogthos wrote: post #26

I definitely find there's a strong relationship between language complexity and bikeshedding. When you have a big language like Haskell or Scala, it's easy to get distracted from solving the actual problem by trying to do it the most "proper" way possible. This is also how you end up with design astronautics in enterprise Java as well where people obsess over using every design pattern in the book instead of writing…

I don't disagree in general but is Haskell a big language?

Re: Why I never finish my Haskell programs

#29

Post by mockingbirdy »

ajross wrote: post #21
jerf wrote: post #10

You can eventually "come out the other side" and get to the point where you write the general version correctly the first time. But it is some degree of work. I think it's a good exercise for a pro, but you can certainly live without it. The general principle does come in handy elsewhere, though. Doing the most useful work with the minimum power is a generally useful skill. I get a lot of mileage out of it in other l…

> You can [...] write the general version correctly the first time. But it is some degree of work. [...] Doing the most useful work with the minimum power is a generally useful skill. There's something wrong with that logic, but I'm too lazy to work out the proof in the general case.

I've enjoyed this amusing comment a lot, but I'm too lazy to explain why. Have an upvote.

Re: Why I never finish my Haskell programs

#30

Post by jakear »

rzzzt wrote: post #13
laurentl wrote: post #7

Earlier quoted context omitted.

I thought so too at first but given the way addition is defined later on, it makes sense to keep the coefficients sorted by increasing power (the leftmost element in the list is its head, and the easiest to access when doing anything recursive)

Evaluation also becomes easy this way, using Horner's method: https://en.wikipedia.org/wiki/Horner%27s_method#Python_imple...

Something along the lines of this right?

  eval =
  v [] => 0
  v x:xs => x + v * eval v xs
You do have to love how clean definition by cases makes these sorts of things.
Post reply on HN