[kelseyfrog]

Explicit recursion is as harmful as goto. We already have a solution - they're called recursion schemes[1].

Using recursion schemes is analogous to using structured programming rather than just constructing loops and branches out of gotos. The problem is the functional programming community got there first and the names are the equivalent of FactoryFactoryFactory and going to be a turn off to normal programmers even though the concepts are dead simple.

1. No citation because linking to a blog post containing Haskell is proving my point.

[nextaccountic]

Note, mainstream programming already has widespread use of a bunch of recursion schemes, like map, filter, and fold (also called reduce). It's generally accepted that using map and filter leads to code much easier to understand and modify. Fold is a tiny bit more complicated but generally speaking it is worth it, but there is still some room for specialized folds like a "sum" operation to make code simpler. (map and filter are also special cases of folds, but that's not an interesting observation)

What's missing from this picture is that recursion schemes are not only useful for lists and other sequential things like arrays, vecs, iterators etc, but also for trees and other data types with richer structure. There's some types implementing map here and there (like Rust's Option, which implements map and filter as if it were a list containing 0 or 1 element), but the generic abstraction of "types that have a map operation" for example (the thing Haskell calls Functor) would be really useful to enter mainstream programming some day.

Now, about the more complex recursion schemes: many have too much cognitive weight to be useful. So often a direct recursion will be simpler and easier to understand. But sure, it would be cool if people were more familiar with things like hylomorphisms and such (even if by other name - folds may also be called catamorphisms but nobody calls them that)

I think that the "overton window" of programming constructs is slowly but surely moving towards the more theoretical aspects of functional programming though. So maybe in some decades this stuff will be so familiar that using them won't make code hard to follow.

[TZubiri]

I think focusing on the technicals is missing the forest for the trees.

Security vulnerabilities and limitations of languages are an inevitability. You won't fix them all, you will always find faults in code.

Now are we not seeing the structural problem with these organizations?

[kelseyfrog]

And yet we don't use goto today because of the bugs and we're phasing out manual memory management for the same reason.

You cannot org change yourself out of all technical problems.

[TZubiri]

You throw goto around like it's some revolutionary change that we don't use gotos. Djikstra's paper was like 70 years ago and it was released like immediately after languages were being born.

[ndriscoll]

Recursion schemes are at least as old as "Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire" (1991), which is closer to "Go To Statement Considered Harmful" (1968, so 23 years) than it is to today (34 years). Recursion schemes aren't at all new either.

[dang]

A few past threads:

Functional programming with bananas, lenses, envelopes and barbed wire [pdf] (1991) - https://news.ycombinator.com/item?id=31152801 - April 2022 (28 comments)

Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire - https://news.ycombinator.com/item?id=24056901 - Aug 2020 (18 comments)

Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire (1991) [pdf] - https://news.ycombinator.com/item?id=9080933 - Feb 2015 (2 comments)

Functional programming with bananas, lenses, envelopes and barbed wire - https://news.ycombinator.com/item?id=6195603 - Aug 2013 (1 comment)

[hakfoo]

We don't use GOTO because we got richer alternatives.

A lot of people were using GOTO because they wanted (for example) do-while or switch-case, or because they wanted to box up their code into self-contained functional units, but the 8k ROM BASIC they were working with didn't have proper tooling to implement it.

Most modern languages support enough of those features that people aren't simulating them through GOTOs. Recursion schemes have not hit that level of availability and general awareness.

Going back several levels of parents, I note the mention of Haskell-- it feels like the functional programming world does a lot of heavy lifting on new language theory, but it tends to remain cloistered there for decades until people figure out how to bolt it into something that looks more like Algol or C than Lisp.