> Just because someone can't do exactly the type of program you're looking for, or in a particular way, doesn't mean they can't program. It only means they couldn't program what you asked in the way you asked. A fail for sure, but that doesn't always mean what you think.
Two relevant examples of this come to mind.
The first is that the author mentions recursion as a fundamental skill. While I agree, as a Python developer the vast majority of my experience with recursion is thinking "Oh, wait - I can't do that, I'll reach the stack limit". In fact I would go so far as to argue that for any language without proper tail recursion, recursion is almost certainly the wrong way to solve a problem.
The second is the oDesk Python proficiency exam. I took it on a whim a while back and failed. Many of the questions were about obscure parts of the Python standard library. I can't imagine many jobs requiring me to know how to parse email message archives without opening the docs, but apparently that's what they were looking for.
I think what'd be even more interesting is whether a candidate can transform a simple recursive algorithm to an iterative one and vice versa.
It's taught in CS courses for instance but I know a lot of software "engineers" who aren't able to come up with a solution for such problems.
(Hint: It's rampant in the webdev crowd)
As a side note: Yeah I also think that recursion is really seldom needed, but sometimes it's actually your only option.
For instance I wrote a Future/Promise library with support for continuation for Rust (it'd be the same for C++).
Simply said: Since the Promise is a generic the actual type (and thus it's machine code) changes from type to type so you have to use virtual function calls to invoke the next promise in the continuation chain.
This obviously has the disadvantage compared to dynamic languages that the chain length is limited by the stack size.
> While I agree, as a Python developer the vast majority of my experience with recursion is thinking "Oh, wait - I can't do that, I'll reach the stack limit". In fact I would go so far as to argue that for any language without proper tail recursion, recursion is almost certainly the wrong way to solve a problem.
Thank you for pointing out the thing that I couldn't remember that always bothered me the times that I had to work in Python. I'm blown away by the vast amount of work being done in that language without it, thought I understand Guido's reasons...and I agree with yours about using recursion in it.
I think in 2016 it should be clearly established that tail recursion is a fundamental programmer right! It is time to write it into programmer constitution.
Two relevant examples of this come to mind.
The first is that the author mentions recursion as a fundamental skill. While I agree, as a Python developer the vast majority of my experience with recursion is thinking "Oh, wait - I can't do that, I'll reach the stack limit". In fact I would go so far as to argue that for any language without proper tail recursion, recursion is almost certainly the wrong way to solve a problem.
The second is the oDesk Python proficiency exam. I took it on a whim a while back and failed. Many of the questions were about obscure parts of the Python standard library. I can't imagine many jobs requiring me to know how to parse email message archives without opening the docs, but apparently that's what they were looking for.