[igorbark]

This article touches on some good points. In particular, the part about trusting that the function will do the right thing is something that people who already understand recursion take for granted but is extremely crucial. However:

"Let's tweak our sum function a a bit: ... That's it."

I really dislike articles that earnestly try to convince the audience that some subject which many find extremely difficult to understand is actually very simple. My impression is that the intent is to help people who lack the confidence to engage with the topic, but in my opinion the exact opposite effect is achieved. At that point in the article, nothing about recursion had been explained and it's not reasonable to expect someone who previously did not understand recursion to read that section and come to the conclusion "that's it!" Instead they'll be sitting there, extremely confused by something which they're being reassured is actually quite simple. This is not going to help their confidence.

So while I appreciate the author's intent, I think that someone who is struggling to understand recursion might leave this article worse off than when they started. And I wish this trope would disappear from tutorials.

[dajohnson89]

I auto-ignore tutorials that say stuff like, "X made simple". It's almost always trying too hard to make a genuinely difficult subject easy, thereby obfuscating the topic more.

[bluGill]

I learned long ago that books titled like "advanced X" will be a very simple book on X suitable for any layperson with basic knowledge. Books titled "introduction to X" or "elementary X" will be extremely difficult.

[tomsmeding]

I have not yet seen books titled "advanced X" that are actually grokkable, but my university courses called "introductory X" were exactly the hardest ones.

[chii]

In general, laying foundations to any broad topic is hard! I imagine knowledge to be like pyramids, where the bottom support the top. But to support a tall pyramid, a large bottom is required. Thus, we get these obscenely difficult 'intro' books...

[bluGill]

Try going to a "technical college" instead of a university. All your text books will be "advanced X". These schools have earned their reputation for being easy to pass.

[kej]

I've noticed the same thing, and even worse is a friendly or gentle introduction.

[khedoros1]

I remember in college that I took some examples of recursive functions, hand-wrote the call stacks, and spent hours and hours pacing in a study room, thinking about it, until the patterns started to feel natural.

I did that kind of thing more than once, just working through algorithms in my head, I guess learning to trust that it'll work, as long as there's a path from the allowed arguments down to the base case. For me, it was never something that reading a few words could clarify.

[evincarofautumn]

I agree with your sentiments about this style of article, but I’d say recursion is simple—the problem is that “simple” doesn’t mean “easy”. A lot of programming & math concepts were like this for me when I was first exposed to them—amazingly simple and clearly useful after they “clicked”, frustrating and inscrutable before.

[chii]

They should've called it fundamental, rather than simple. Or, axiomatic.

It feels bad when a topic you find hard to understand is called simple, and actively discourages those with less self confidence from approaching it.

[evincarofautumn]

I suppose so, yeah.

I was thinking of things like monads. They’re a class of type constructors with a couple of associated functions (unit & bind or unit & join). The definition is undoubtedly simple, as well as fundamental in Haskell. But understanding how to use them, what to use them for, how to tell whether & why a type admits monad/applicative/functor instances, &c., are still difficult things for a lot of people, because these are unfamiliar abstractions. Moreover, they take advantage of unfamiliar features like higher-kinded types, so you can’t even explain them by offering a translation to other languages, because most other languages lack the ability to adequately express them.

For myself, I think of learning as “discovering simplicity”. I know I understand something when it finally feels as simple as it really is.

[ImaCake]

I find claims that something is simple are often just misleading. It's really common to see these kind of claims with articles talking about learning a foreign language. Often the grammatical rules and concepts ARE quite simple. But you often find sentences where several simple rules are piled on top of each other and you end up with something that takes some time to understand.

For example, in German there are straightforward ways you modify the definite article associated with a noun based on whether it is the subject or object in a sentence. A fairly simple, and useful concept! But first you have to remember what gender that noun is, which is fairly challenging in german because there are several word endings for each gender. Next you might need to pay attention to how the sentence has been constructed: in a relative clause, the definite article after the comma is associated with the noun BEFORE the comma - and that definite article is different because it is in a relative clause!

[zzzcpan]

Yeah, looks like the author is not doing a good job at explaining recursion. If I had to do it I would probably visualize stack and show how function calls work.

[KirinDave]

I agree, this kind of "it's all so simple" approach is often less helpful than folks think it is.

I always try to explain it thusly: Recursion makes big, complicated problems easier to solve. But it's a bit like using a cannon to swat a fly if you have no big, complicated problems to wrestle.

Explanations like this do not deny the complexity present in the scene, but reframe it so that were using a technique to tackle said complexity.

[accatyyc]

Agreed. This is just like when I tried to grok monads. So many articles trying to tell me how simple they are... yet still so many articles needed to explain it (and I'm none the wiser)

[continuational]

Monad is just an interface with these methods:

    pure :: a -> List a
    flatten :: List (List a) -> List a
    map :: (a -> b) -> List a -> List b

The above types are for lists, but you can substitute your own type constructor for List.

For lists, the implementation is as follows:

    pure x = [x]

    flatten [] = []
    flatten (x:xs) = x ++ flatten xs

    map f [] = []
    map f (x:xs) = f x : map f xs

A flatMap method can be defined once for all monads:

    flatMap f m = flatten (map f m)

This method is sometimes called "bind" and is written ">>=" in Haskell (where pure is also called "return" and flatten is also called "join"):

    m >>= f = flatMap f m

The methods are related by the monad laws - you can look them up if you're interested, but they're not required to gain an intuition.