Why I never finish my Haskell programs

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 it very easy to write simple things without abstraction, but virtually all use of abstraction goes off the rails immediately and everything shoots you in the foot, so that good abstraction is not even really a thing at all.

Pick your poison!

Re: Why I never finish my Haskell programs

#4

Post by sqrt17 » Mon, Sep 03, 2018, 9:12 PM UTC

jonalmeida wrote: post #2

I think there's an error in the first example. Poly [1, -3, 0, 1] Should be: Poly [1, 0, -3, 1] EDIT: My mistake.

It's not - it starts with the unit coefficient (1), then x (-3), then x^2 (0), then x^3 (1). Some things become easier this way - including addition of polynomials of differing degree - and as an added bonus you can phantasize about representing power series as (lazy) infinite lists.

Re: Why I never finish my Haskell programs

#5

Post by gabipurcaru » Mon, Sep 03, 2018, 9:12 PM UTC

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 the case, because e.g. if you want to extend the solution from lists to traversables, Haskell gives you the confidence to safely refactor the method at a later time.

Re: Why I never finish my Haskell programs

#6

Post by ssadler » Mon, Sep 03, 2018, 9:13 PM UTC

Polynomial long division in Haskell: https://github.com/libscott/math/blob/master/src/Math/Polyno...

Re: Why I never finish my Haskell programs

#7

Post by laurentl » Mon, Sep 03, 2018, 9:14 PM UTC

jonalmeida wrote: post #2

I think there's an error in the first example. Poly [1, -3, 0, 1] Should be: Poly [1, 0, -3, 1] EDIT: My mistake.

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)

Re: Why I never finish my Haskell programs

#8

Post by ainar-g » Mon, Sep 03, 2018, 9:15 PM UTC

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

Re: Why I never finish my Haskell programs

#9

Post by kelvin0 » Mon, Sep 03, 2018, 9:22 PM UTC

ainar-g wrote: 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 speculation on my part.

Re: Why I never finish my Haskell programs

#10

Post by jerf » Mon, Sep 03, 2018, 9:28 PM UTC

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 languages, because across a couple hundred modules, the difference between modules that have minimum dependencies and modules that carelessly overuse power becomes quite substantially different in character.