I think the main problem with the specific example is that a list is the wrong data structure to represent a polynomial. Even a simple `IntMap` would be better, where the key is the power.
Why I never finish my Haskell programs
11–20 of 228 posts
Re: Why I never finish my Haskell programs
#12>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…
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.
Re: Why I never finish my Haskell programs
#13I 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)
Evaluation also becomes easy this way, using Horner's method: https://en.wikipedia.org/wiki/Horner%27s_method#Python_imple...
Re: Why I never finish my Haskell programs
#14I've always felt of Haskell that it's a way for very smart people to never get anything done.
I want to like Haskell, I really do, but it's like learning Latin - you'll feel very smart except no one can talk with you except other people that correct your grammar.
Bleh.
Re: Why I never finish my Haskell programs
#15You could also just: write the less general version and stop listening to folks who flip and scoff at every piece of code isn't maximally general.
Crazy, I know, but especially when were doing labor in industry, even without maximal generality your code is probably going to outlive its patron corporation and then die in obscurity.
Re: Why I never finish my Haskell programs
#16Premature generalization. There.
Re: Why I never finish my Haskell programs
#17Similar things happen in other languages. Most recently, I started writing a program in Elm to try it out, realized I wanted to use some CSS, and then got distracted looking at the various ways to do that, with their different tradeoffs. (What is this stylish-elephants package?)
Sometimes it's more productive when you join a team that has already decided on its standards. You don't learn as much, though.
Re: Why I never finish my Haskell programs
#18>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 take is it's because there are some really great benefits to implementing things more precisely (which usually means "more general" in this sense), and Haskell is more amenable to it than most.
There are many cases where it's worth it, so much so that it's worth at least considering whether a more generic solution is better.
I think the problem is that it's hard to predict how deep a rabbit hole like this gets - so you think it's just a few minutes extra work, but it ends up completely derailing the project.
Re: Why I never finish my Haskell programs
#191) 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
Re: Why I never finish my Haskell programs
#20In 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…
i think i agree with you, but want to make one additional point.
I think haskell is actually fine at writing code without abstraction, it's just that people don't choose haskell to go down that path, and so aren't satisfied with those "simplistic" solutions.