Live data from Hacker News

Why I never finish my Haskell programs

blog.plover.com

31–40 of 228 posts

Re: Why I never finish my Haskell programs

#31
post #9
post #8

>I ought to be able to generalize this I've never understood this. Unless you write a library that you plan to publish, or already have actual cases where you need a more general solution, why spending time trying to generalise code instead of switching to the next task?

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…

>elegant solutions (a.k.a mathematical/functional)

Meanwhile, if you look at pseudo-code written by actual mathematicians or logicians, it's almost always imperative, full of side-effects and global variables. Sometimes they even use GOTO!

Re: Why I never finish my Haskell programs

#32
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…

Reminds me of one of Rich Hickey's talks where he states that people just love to solve puzzles, and that complex languages with, for example, demanding type systems trick people into thinking they are adding safety or value when in fact they're just outsmarting themselves.

Often when I write something in Haskell I have this feeling. It feels satisfying to build up nice types and constructs but I don't know if it at all pays off in any objective or empiric sense. I can't really tell if I've invented the problem that I just solved.

Re: Why I never finish my Haskell programs

#33
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?

Large in the sense that it admits many approaches to solving problems.

https://www.willamette.edu/~fruehr/haskell/evolution.html

Re: Why I never finish my Haskell programs

#34

1) to me, this is the difference between haskell and Clojure 2) in the future, normal people will be able to code, so work backwards from that

>in the future, normal people will be able to code, so work backwards from that

This.

I'll never be able to understand certain programmers' insistence that imperative code is somehow unnatural or that "we're only used to it because of momentum" or whatever. For thousands of years people have been issuing imperative instructions to each other.

"Wash. Rinse. Repeat."

Re: Why I never finish my Haskell programs

#35
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?

Haskell has a ridiculous number of obscure operators. Here's a list of "common surprising" operators in Haskell:

https://haskell-lang.org/tutorial/operators

Re: Why I never finish my Haskell programs

#36
post #13
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...

But this doesn't argue for the low-to-high order, because of reversed(). This code would be simpler and faster with the coefficients in the opposite order.

Re: Why I never finish my Haskell programs

#37

In Haskell (and similar), the language offers the ability to really stab genericization in the heart in a good way, to do it the right way. But 90% of the time, you shouldn’t and it’s very hard not to. Not a matter of restraint, but the language makes it actually very hard to get simple things done unless you plug into the abstraction vortex. Conversely, languages like Java, C++ and Python (if you use classes), make…

True but I still manage to go down some rabbit holes in C++.

I could use the older STL iterators, but nooo I use a range, with a lambda. Returning a tuple with tie and pair and some more stuff from the latest C++1x standard.

And in Linux userland, I just want to check a pid but I invent some smart locking system to ensure I never get a false positive or negative.

Re: Why I never finish my Haskell programs

#38

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.

What?

Other than strings desperately needing to be purged from the library, what are you talking about?

Haskell has some really solid standard libraries, and it's extended library set has some of the most sophisticated algorithms packages in the world.

Re: Why I never finish my Haskell programs

#39

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.

Could you give examples of algorithms done wrong?

Re: Why I never finish my Haskell programs

#40

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.

[deleted]
Post reply on HN