5 ms·

How often do you use recursion at work? I can count on one hand the number of times I’ve written a recursive algorithm in almost 20 years of coding for work.

ggambetta 4y ago
Very rarely, but the point is that I could use recursion if I had to (and perhaps more importantly, that I could recognize the need to use recursion).
thomastjeffery 4y ago
I expect that has everything to do with what language your are using. If it has tail call optimization and clean pattern matching syntax, then recursion tends to be the more readable (and equally performant) way to traverse data structures, especially anything more complicated than a 1-dimensional list. These two features (tail call optimization and pattern matching) have seen a surge in popularity over the last decade, notably in Rust.
- steveklabnik 4y ago
  Rust does not guarantee TCO, just to be clear.
e63f67dd-065b 4y ago
Any kind of tree or graph traversal in a moderately functional language? If you’re a frontend dev trying to glue together something that works I can see it, but I would wager that you’ve come across some kind of tree or graph problem that would be best formulated in terms of a recursive algorithm in 20 years of professional work. Maybe I just have a skewed perspective as a grad student working on filesystem stuff, but I can’t imagine going for years without having to solve some kind of graph problem.
- hnfong 4y ago
  > If you’re a frontend dev trying to glue together something that works (Not the GP) I mostly do "backend" work, my limited experience with the frontend (mostly javascript) is that you actually need to deal with (explicit) tree structures more in the frontend. The DOM tree is one, for example. Other UI elements can be modeled quite nicely with a tree structure too.
nunez 4y ago
All the time
physicles 4y ago
I honestly don’t think that’s relevant. A whiteboard interview tests your ability to do something you do constantly while writing code: you look at the code you wrote and run it in your head with enough fidelity that you can verify it to a first approximation. If you can’t do that, you’re going to be slower and you’re going to make more mistakes than someone who can. Small contrived problems like recursion are useful for testing this specific skill. A program to calculate e.g. Fibonacci using recursion isn’t that complicated; to me it seems like table stakes for actually writing new software.

ggambetta 4y ago

Very rarely, but the point is that I could use recursion if I had to (and perhaps more importantly, that I could recognize the need to use recursion).

thomastjeffery 4y ago

I expect that has everything to do with what language your are using. If it has tail call optimization and clean pattern matching syntax, then recursion tends to be the more readable (and equally performant) way to traverse data structures, especially anything more complicated than a 1-dimensional list. These two features (tail call optimization and pattern matching) have seen a surge in popularity over the last decade, notably in Rust.

steveklabnik 4y ago
Rust does not guarantee TCO, just to be clear.

e63f67dd-065b 4y ago

Any kind of tree or graph traversal in a moderately functional language? If you’re a frontend dev trying to glue together something that works I can see it, but I would wager that you’ve come across some kind of tree or graph problem that would be best formulated in terms of a recursive algorithm in 20 years of professional work. Maybe I just have a skewed perspective as a grad student working on filesystem stuff, but I can’t imagine going for years without having to solve some kind of graph problem.

hnfong 4y ago
> If you’re a frontend dev trying to glue together something that works (Not the GP) I mostly do "backend" work, my limited experience with the frontend (mostly javascript) is that you actually need to deal with (explicit) tree structures more in the frontend. The DOM tree is one, for example. Other UI elements can be modeled quite nicely with a tree structure too.

nunez 4y ago

All the time

physicles 4y ago

I honestly don’t think that’s relevant. A whiteboard interview tests your ability to do something you do constantly while writing code: you look at the code you wrote and run it in your head with enough fidelity that you can verify it to a first approximation. If you can’t do that, you’re going to be slower and you’re going to make more mistakes than someone who can. Small contrived problems like recursion are useful for testing this specific skill. A program to calculate e.g. Fibonacci using recursion isn’t that complicated; to me it seems like table stakes for actually writing new software.