I like thinking about variables as boxes with labels. Hadn’t heard that before, but seems like a simple way to teach people. I skimmed the description of recursion. Seemed a bit long for my taste. I was taught how to write a recursive function like this: “Write the function signature, the docstring, and the base case. Then assume the function already works, and use it to implement the rest of the code”
Heck, I still think of variables as boxes with labels.
In some ways they are - they're just a little box of memory with an address.
One of my favorite ways of thinking about recursion (and proofs by induction) is the recursion goblins. When you're writing a recursive function, you don't worry about how you got your input. The recursion goblins took care of that. You also don't need to worry about what will happen to the thing that you return . The recursion goblins will take care of that, too. All you need to worry about is what's happening in be…
One of my favorite ways to think about recursion is that it's a shitty technique that can and will blow up your stack. When I try to solve a problem with recursion, then I have two problems. It's also a great way to filter out morons in interviews. If they ask for a recursive solution, and I tell them that it's a shitty solution, and if they don't immediately agree, then I know I'll be working with morons.
One of my favorite ways of thinking about recursion (and proofs by induction) is the recursion goblins. When you're writing a recursive function, you don't worry about how you got your input. The recursion goblins took care of that. You also don't need to worry about what will happen to the thing that you return . The recursion goblins will take care of that, too. All you need to worry about is what's happening in be…
One of my favorite ways to think about recursion is that it's a shitty technique that can and will blow up your stack. When I try to solve a problem with recursion, then I have two problems. It's also a great way to filter out morons in interviews. If they ask for a recursive solution, and I tell them that it's a shitty solution, and if they don't immediately agree, then I know I'll be working with morons.
One of my favorite ways of thinking about recursion (and proofs by induction) is the recursion goblins. When you're writing a recursive function, you don't worry about how you got your input. The recursion goblins took care of that. You also don't need to worry about what will happen to the thing that you return . The recursion goblins will take care of that, too. All you need to worry about is what's happening in be…
One of my favorite ways to think about recursion is that it's a shitty technique that can and will blow up your stack. When I try to solve a problem with recursion, then I have two problems. It's also a great way to filter out morons in interviews. If they ask for a recursive solution, and I tell them that it's a shitty solution, and if they don't immediately agree, then I know I'll be working with morons.
Why are recursive solutions shitty? I find them easier to read...
I always thought recursion was very elegant, but until now I was using it to scan through folders on the file-system and that was about it. Then I had an interesting problem at work where recursion seemed the most elegant solution ... but I quickly encountered errors that were not caught in a try catch block and made the program fail silently. I'll admit my ignorance, but I thought a stackoverflow was a "feature" of…
C# from .Net 64bit supports tail-call optimization as far as I know. If you write your function in a tail recursive way it will be optimized and you won’t have any stack overflow if you use a C# version more recent than that.
One of my favorite ways of thinking about recursion (and proofs by induction) is the recursion goblins. When you're writing a recursive function, you don't worry about how you got your input. The recursion goblins took care of that. You also don't need to worry about what will happen to the thing that you return . The recursion goblins will take care of that, too. All you need to worry about is what's happening in be…
One of my favorite ways to think about recursion is that it's a shitty technique that can and will blow up your stack. When I try to solve a problem with recursion, then I have two problems. It's also a great way to filter out morons in interviews. If they ask for a recursive solution, and I tell them that it's a shitty solution, and if they don't immediately agree, then I know I'll be working with morons.
Recursion is a powerful, relatively low-level approach, and the price for expressive power is readability, but it has legit use cases. What you said has a grain of truth in that usually you should prefer combinators like map or filter (if you're doing FP), but just throwing away recursion is silly. Having a strong opinion on it and not seeming to know about TCO is also not a good look.
I always thought recursion was very elegant, but until now I was using it to scan through folders on the file-system and that was about it. Then I had an interesting problem at work where recursion seemed the most elegant solution ... but I quickly encountered errors that were not caught in a try catch block and made the program fail silently. I'll admit my ignorance, but I thought a stackoverflow was a "feature" of…
C# from .Net 64bit supports tail-call optimization as far as I know. If you write your function in a tail recursive way it will be optimized and you won’t have any stack overflow if you use a C# version more recent than that.
I use .NET 4.8 but I need to check if it's x86 or x64.
This was how I was "taught" recursion, with (Lucas) Towers of Hanoi. Ugh! I still remember the mostly-filled in function with 2(?) recursive calls placed, for us to fill in the arguments. How the heck would that ever work? was all I could think. I don't think a single person in the class had any idea of progress until the teacher, kinda exasperated, just told us. And we still didn't get it, of course. I get it now, b…
I think the intuition behind your Stooge sort example is that for an array separated into three segments: A | B | C The first sort moves the largest elements of A and B into B. The second sort moves the largest elements of B and C (and therefore of A, B, and C) into C. And the final sort properly orders the elements within A and B.
Ok but what does your intuition say about the first step?
> If the value at the start is larger than the value at the end, swap them.
What if we skip that? Broken sort? Is that step necessary, and if so, what's the edge case? Why even mention it? I hope I don't seem combative, I just find my intuition doesn't quite cover this problem.
One of my favorite ways to think about recursion is that it's a shitty technique that can and will blow up your stack. When I try to solve a problem with recursion, then I have two problems. It's also a great way to filter out morons in interviews. If they ask for a recursive solution, and I tell them that it's a shitty solution, and if they don't immediately agree, then I know I'll be working with morons.
Recursion is a powerful, relatively low-level approach, and the price for expressive power is readability, but it has legit use cases. What you said has a grain of truth in that usually you should prefer combinators like map or filter (if you're doing FP), but just throwing away recursion is silly. Having a strong opinion on it and not seeming to know about TCO is also not a good look.
I don't think it's necessarily more difficult to read, especially with the mindset of the "recursion goblins" mentioned in another comment here, where one only looks at the current iteration and does not care about, where input argument comes from.
But of course, if what one wants to do can be expressed using map and filter and such, why write some recursive procedure.
I always thought recursion was very elegant, but until now I was using it to scan through folders on the file-system and that was about it. Then I had an interesting problem at work where recursion seemed the most elegant solution ... but I quickly encountered errors that were not caught in a try catch block and made the program fail silently. I'll admit my ignorance, but I thought a stackoverflow was a "feature" of…