Recursion is much more of a mathematical concept that we learn about long after preschool, while my 3 year old already gets loops.

> On the other hand, recursion is quite fundamental. It is not inherently a high-level concept, suitable only for grownups but not for children. Most people actually grew up with an implicit understanding of rudimentary recursion long before they understood iteration—that is, before they understood how to carry out a loop of instructions. Given a list of tasks to do, the simplest mode of operation is a recursive approach that charges blindly ahead: […]

> It's only after we've gained experience with such an almost mindless method that we acquire a more global view of the process:

> Do Jobs = Do each job on the list. (2)

> […]

> Do a_k for 1 ≤ k ≤ n. (5)

> All computer programmers have in fact progressed from stage (1) to these later stages rather early in our lives, because of an inner desire to “see through” the entire chain of consequences that result from primitive actions.

> Furthermore, once we reached these later stages, we entirely forgot that they were actually elaborations of the recursive procedure in (1). There was no point in narrowing our perspective to the simple-minded form. The vast majority of recursive situations that faced us as children fell into very simple patterns that could readily be “seen through” and understood as a unit. Thus we came to understand iteration as an elementary idea.

> It was only later, when faced with difficult problems whose recursive structure cannot be visualized in straightforward terms such as operations on arrays of elements, that we re-learned the importance of recursion. Therefore we now tend to regard recursion as a high-level concept, although it is really fundamental.

Possibly these views of his are influenced by his early background in programming in assembly/machine language, where it takes some sophistication to translate recursive ideas into code (maintaining a stack etc), but it's an interesting point of view worth some consideration. This is from his draft of TAOCP Chapter 8 ("Recursion"), and is preceded by the following paragraph:

> High-level languages for computing—which themselves are de ned recursively, because algebraic formulas are built up from algebraic formulas—allow programmers to pretend that recursion is real, that a computer is somehow manufactured from recursive components. But programs that invoke themselves are actually implemented by means of a stack structure behind the scenes. A good programmer is able to understand such algorithms by viewing them simultaneously at a high level and at the machine level, and at many levels in between, thereby perceiving what a real computer can actually do well.

On the flipside, I have a lot of mathematical training, so maybe this is an uncommon perspective.

Recursive has the advantage that when you use the tools for it, recursive is easier to read. If I see e.g. a map, I know we're converting a collection of things to some other things without restriction. With a look, I just have to read through it to see what it's doing.

Anthropomorphism is the bane of our craft. Our untrained intuitions don't really matter.

> Recursion is much more of a mathematical concept that we learn about long after preschool

Programming is applied mathematics. Different from the kind of maths you learn at school of course, and often even more rigorous.

I personally have no qualms about requiring some mathematical proficiency in programming. Makes you much more capable at a number of applications later on.

I didn't downvote your comment but your statement is a very misleading idea. Yes, the study of Computer Science is a discipline of mathematics but common programming done by most devs is not applied mathematics.

Sure, if we really wanted to, we could say baseball is "applied calculus" because when an outfielder chases after a fly ball to intercept it, he's tracking an inverted parabola... and cooking is "applied physics" because of thermodynamics ... but insisting on that is just being pedantic and academic. People do not need calculus and physics classroom training to play baseball and cook food.

No, we can't, because baseball and cooking aren't formal symbol manipulation, but both math and programming are. That is why all programming is applied mathematics, because it's all manipulating symbols in compliance with a set of formal rules.

Observably, many programmers manage to achieve considerable success without much or any mathematical sophistication. This is because the market places relatively little value on correctness, which is what math helps with, and far greater value on pleasantness, which doesn't require mathematical sophistication at all.

Do you think this is the Bronze Age of artisinal craft, poised to be replaced by the dawn of brutally precise mechanized Haskell?

You need a certain kind of curiosity and general problem solving ability to get any further than mid level individual contributor that allows you to see around corners in terms of how large scale human socioeconomic systems function and think strategically. That's not to say that mathematical proficiency isn't indirectly useful -- I do think it's worthwhile in that it teaches a mind how to think in a structured manner and solve problems in a structured manner, and that process is useful and transferrable. But it only transfers so far. There are many challenges you face developing proficiency writing software that you cannot be prepared for in any other way than by using, building and studying software.

Thousands of every day apps and services work just fine without anything more than simple arithmetic. 3 or 4 of the top 5 websites required no math to get started.

Spreading the idea that you need to know math before learning to program is elitist and counter productive IMO.

Maybe that's not such a bad thing? When a big chunk of our world runs on computers, maybe it's not such a bad thing to have standards and take things seriously, like it is done in every single other engineering profession.

The term professional programmer means the programmer is getting paid that's all. You want to put a barrier up? Are you worried about lives being lost? Professional programmers don't decide what to program that comes from the project owner. They translate human requirements to computers.

The people who decide what programmers write are defined by rules governing their project. If it's a health project laws around privacy restrict what the project owner can do.

I believe that programming is a skill, not a profession. You can know how to program without being a professional programmer.

Of course you can. You just… won't be a professional, and won't be held against professional standards (minimum output & quality, that kind of stuff). That's okay. But if you're going to get paid for it, you ought to be better than a random self taught amateur.

Though I suspect we aren't, in fact, much better than the average self taught amateur. That would be an indication that we still have progress to do.

I suspect this is because programming is actually even more rigorous than maths. When you do maths, you can gloss over details, and sometimes delude yourself into thinking false things (that very same thing happened on my last HN submission: I failed to notice a data dependency in EdDSA, and thought an attack were possible, when in fact it wasn't).

Programming uses an external cognitive engine (the computer), that is faithful, exact, and ruthless. Your program has to work. And when it doesn't, you're forced to revisit your assumptions (as I was forced to revisit mine when I actually tried to implement that attack and failed miserably).

So yes, totally with you here.

Whether that follows depends on how much and what kind of proficiency we require. We require programmers to be able to read and write, too, but we don’t require them to be excellent orators or literary writers.

I do think requiring some proficiency is OK. Basic arithmetic, for example, definitely is ‘in’. A bit of ability to think logically, too. That doesn’t mean all programmers have to know what a group or a ODE is.

In any event, I think it's possible to have your cake and eat it too. See http://iconicmath.com/ I think we can make mathematical toys.

Heck Scratch is a mathematical toy, eh?

It is almost cruel to taunt practitioners working around the hard, messy, ugly constraints of reality with the beautiful, elegant, and noble idea of not just conceptual mathematics, but the ability to immanentize it. But, this does little to solve the inherent messiness of the world that the software interacts with, and the messy things that people do which affect what it needs to do.

And sure, the world is messy. But some things aren't worth automating. I've seen a talk about how the guy was writing a program to generate invoices. Turns out invoices are incredibly messy. The previous system was an overly complex brittle pile of code, that didn't quite work. His approach? Solve the common case first, and let human handle the messy bits. He started by something very simple, that could handle 60% of the invoices. Then 90%. Then 95%. Then 99%. The he stopped.

With 99% of the invoices handled, he had a simple, solid system. The messy part was handled by humans, and they had the time to do so because 99% of the grunt work was taken away from them. Plus, they could trust it works because since those invoices were relatively simple, they could be automated reliably. I believe that approach can be generalised. As Mike Acton said: "solve the common case first".

That I believe would work to "solve the inherent messiness of the world". Automate what you can, let humans deal with the rest. Or don't automate at all, just give tools & tricks so humans can work faster.

Alternatively, we could adapt around computers. Before electricity, factories used to have a giant engine that powered everything through mechanical transmission. Wen electricity first came along, we did the same thing. But it turns out electricity is much easier to distribute at a small scale. So factories adapted, and instead of having a big engine at the centre, they started to have lots of small engines everywhere, close to where they were needed. I believe computers are similar: we started using them as glorified paper, but as we understand what they can do, we employ them in more efficient ways. But the interface of a computer (it can do anything!) is much more complex than that of an engine (it can rotate!). I believe we haven't found how to best make use of them just yet.

My point is that this judgment is the messy and valuable part. And to your point around the end, that you believe we haven't found how to best make use of them just yet -- I agree with that too, and that's why I think the work of writing software, or best practices, or sound theory is not fully established. To build good product does fundamentally require a pioneer spirit that can make compromises and negotiations and arrive at that sweet spot that's not quite 100% but high enough to be "good enough".

On the contrary, we have no choice but to use our intutions, at whatever level of training they are at, all the time. So it matters a lot. If A is easier than B iff we learn to think differently, but learning to think differently is harder than just doing B, then A isn't actually easier than B.

I played the Witness. There's a time based challenge at some point, that I could only beat when I changed the way I thought about those puzzle just so I could go through them faster.

I learned to touch type. To do that, I stopped thinking visually, and instead think kinaesthetically. Then I developed some kind of intuition, where I think a word, and the letters just flow through my fingers. I don't really think at the letter level any more. Neither does anyone proficient with a keyboard. (50 WPM and up).

Our untrained intuitions don't really matter. Seriously learning anything trains us out of them. Programming is no different.

It may be instructive to look at how readable a very naive implementation of a basic function like "min" is, but it probably doesn't actually matter that much in practice, because you'll be using what the standard library offers (and its implementation is probably much less straightforward than you might think).

If you are attempting to debug logic, it often helps to have all the context. To do that in recursion, you have to travel up and down the stack, examining local contexts one by one.