Hacker News Reader

Comment by edifice | Hacker News Reader

Good question. My opinion is that thinking in terms of recursive transformations of immutable datastructures is just fundamentally more difficult than the imperative equivalents. My earliest exposure to recursive algorithms was in AP computer science in high school and I remember a lot of the students really struggled with them, both those with previous imperative experience and without. This extra effort can pay off over time though because it makes the overall program easier to understand and incurs fewer bugs than the imperative style. You can also avoid a lot of this if you express your functions in terms of other elemental sequence functions (map, reduce etc) instead of explicit recursion.

Doubtless others will disagree though. Maybe we don't all have the same mental strengths and weaknesses.

View on HN

I think many programmers find it hard because experience with Algol-derived languages give them bad assumptions - they expect all of the conceptual baggage of mandatory stack allocation, so recursion seems ludicrous and complicated.

Recursive cases in languages with tail-call optimization are like inductive reasoning in mathematics - "How long is a list? If it's empty, zero, otherwise one (for the head) plus however long the rest is."

Chalk me up as someone who disagrees. Personally, I find recursive transformations of immutable structures far easier to reason about than iterative modifications to mutable structures.

At least in some cases, I think that's the expected result: consider the difficulty of reversing a singly linked list in-place and reversing it applicatively.

Perhaps the difficulty is in designing the appropriate data structures and identifying the correct transformation functions. In other words, designing a good FP program is difficult just like designing a good OO program is difficult.

It definitely depends on the algorithm. It also depends on the language. A lot of the difficulty of learning Haskell, for example, is in the type system. A dynamically typed FP lang like Clojure has a shallower learning curve.

It is true, but it's also unfortunate—I think a lot of Haskell's strengths come from its type system. So what makes Haskell worth learning also makes it hard to learn Haskell :)

Haskell's type system is unfortunate, because for most programmers, 80+% of the benefit comes from how it utterly nails the basics (checking variant type coverage in pattern matching, typeclasses), but the language community is focused on the cutting edge top .003%, because that's where the research papers are.

After working through a few of my own Haskell projects, I eventually found the type system disappointing. A better design would have made it even more sophisticated and harder to learn, IMO. That's the price to pay for being purely functional. Instead, I felt that certain design trade-offs were made, which in effect, make the type system awkward and tend to lead to inflexibility in writing ambitious, comprehensive programs.

Any examples you care to share?

Iit's also unfortunate - I think a lot of Clojure's strengths come from its macro system. So what makes Clojure worth learning also makes it hard to learn Clojure :)

There is stuff to learn in every language :)

He i think you are write but that is where the Language can help you. You don't have do the recursion every time by hand. You can have language constructs that are just as easy as normal loops but work like recursion in the compiler. If you really need to do the recursion you would have to do so in imperativ languages to.

(Node: I don't no haskell)

Reply on news.ycombinator.com