Agreed that RPN (and stack machines) are beautiful and underappreciated. Unfortunately, it's for a relevant reason that I have to push back against the author's newfound love of recursion. Like everyone else I had the same brain-exploding moment when I realized that recursion was possible and how if forced me to re-think what functions were capable of, but now that I'm old and ornery I'm of the Hot Take that recursion is a clumsy alternative to a loop, not the other way around. Which is to say, if a portion of a program is going to threaten to execute for an unbounded amount of time, I want that fact to be explicitly called out in the code via a looping construct, rather than having to worry whether any random function call is going to recur (or even mutually recur), to say nothing of the efficiency of holding onto a single piece of loop-relevant mutable state rather than forcing my runtime to handle an unbounded number of stack frames. If your language both guarantees tail recursion and calls it out syntactically, then you get a pass, otherwise I'd be perfectly happy working in languages that didn't support recursion at all.
I don't know man, very often sophisticated problems require recursive thinking (even if you don't write it so later on) to be able to see similarities in sub problems. Just last week I had to resort to this to flatten-index json files. I started confused and then made an inductive leap and the solution unfolded itself (no pun intented) as a two-liner.
It's way beyond brain-teaser for me, it's the sharpest tool I know of.
If I have to traverse a tree, then recursion is more natural to me. With a loop you’ll have to manually use a stack (it’s fine, but more error prone). For lists, I rarely write loops or recursion. It’s mostly folds and maps.
Agreed that RPN (and stack machines) are beautiful and underappreciated. Unfortunately, it's for a relevant reason that I have to push back against the author's newfound love of recursion. Like everyone else I had the same brain-exploding moment when I realized that recursion was possible and how if forced me to re-think what functions were capable of, but now that I'm old and ornery I'm of the Hot Take that recursion is a clumsy alternative to a loop, not the other way around. Which is to say, if a portion of a program is going to threaten to execute for an unbounded amount of time, I want that fact to be explicitly called out in the code via a looping construct, rather than having to worry whether any random function call is going to recur (or even mutually recur), to say nothing of the efficiency of holding onto a single piece of loop-relevant mutable state rather than forcing my runtime to handle an unbounded number of stack frames. If your language both guarantees tail recursion and calls it out syntactically, then you get a pass, otherwise I'd be perfectly happy working in languages that didn't support recursion at all.
I don't know man, very often sophisticated problems require recursive thinking (even if you don't write it so later on) to be able to see similarities in sub problems. Just last week I had to resort to this to flatten-index json files. I started confused and then made an inductive leap and the solution unfolded itself (no pun intented) as a two-liner.
It's way beyond brain-teaser for me, it's the sharpest tool I know of.
If I have to traverse a tree, then recursion is more natural to me. With a loop you’ll have to manually use a stack (it’s fine, but more error prone). For lists, I rarely write loops or recursion. It’s mostly folds and maps.
Linear recursion vs tree recursion.
Made me feel like I understand monads finally...will read again in a couple days when I inevitably forget.