Assorted links

1. Does market monetarism require stronger financial microfoundations?

2. Should your children be learning how to code?  My views on that topic.

3. The future of doctors?

4. Izabella Kaminska on the role of fiscal distribution effects (FT Alphaville).

5. The Thought Leader.  Is this the cynical David Brooks?  The Straussian David Brooks?  Both?  Something else altogether?  And here is a good recent David Brooks interview, more depth than most interviews get to.

6. Piketty slides on wealth and inequality in the long run (pdf).  Here is my earlier column on Piketty and Zucman.


With regard to #2, good luck with that. It's hard enough teaching kids algebra 1 & 2 and coding is many magnitudes harder (and by coding I don't mean WYSIWYG).

Intro computer science courses regularly have dropout/failure rates above 50%. And this is on a group of students that are already pre-selected for both intelligence and interest in the subject. Research on the topic indicates that even among the most intelligent cohorts a large segment of people are simply incapable of learning to program.

For example the concept of recursion, a basic foundational block of programming, appears to be something that many brains are simply not "wired" to understand.

"For example the concept of recursion, a basic foundational block of programming, appears to be something that many brains are simply not “wired” to understand."

Yes, that meets my personal experience. However, recursion is in my mind a useful and essential technique, but I'll trade a programmer that's good at dealing with edge cases, exceptions and error handling over someone that a natural for writing minimal code.

Recursion tends to be taught with academic examples tailored for recursion. In the work I've done, from machine control to corporate middleware, recursion unrolled to loops is faster and more efficient. Simple recursion tends to throw around a new stack frame and context for very little benefit.

"Recursion unrolled to loops is faster and more efficient"

Of course a good developer can have a long and productive career and never touch recursion. But in my opinion I think you're underselling the advantages of the technique. Almost all modern compilers implement tail recursion, so the stack frame performance impact is a non-issue. In terms of program representation recursion tends to more be a more natural way to model control flow. This is one of the primary reasons that functional languages, which bias the programmer to recursion over iteration, tend to have a lot fewer runtime bugs.

Recursion can arise naturally in various important problems where if the unrolling is so deep that you'd need iteration for efficiency, you're probably already in trouble somehow. For example, it arises in handling interrupts, where if you find yourself even dozens of layers deep there is probably something seriously wrong; it arises in parsing languages (including programming languages), where if you find yourself 100 levels deep in grammatical clauses or in programmatic nested "while" loops inside "if" statements there is probably something wrong; and it arises in searching for solutions (e.g. alpha-beta search in games like chess, and techniques like breadth-first search in a large class of problems which includes games) where if you find yourself evaluating plans that take 1000 steps there is probably something wrong.

That said, there are entire specialties where people get by without recursion and don't miss it. E.g., in my misspent youth I was paid to write quite a lot of assembly language (stuff at the level of serial drivers and arithmetic routines) and I never had to think about recursion except for interrupts; and zillions of people did various kinds of numerical analysis in Fortran-77 for a long time.

Recursion helps provide elegant descriptions of specific algorithms, and it helps instill divide-and-conquer as a problem-solving approach. One of the few homework assignments I still remember from college was coming up with a recursive algorithm to solve a tricky problem, and then unrolling the recursion. Nice sense of accomplishment and understanding when I was done. But later its easier to just write the loops while imagining the recursion in your head. I think recursion is understandable to most, but it requires a good, interactive instructor.

As for learning to code, the reason I would recommend it is that I believe it's a very good way to learn how to build and interact with a complex system in an empirically verifiable manner. You can bullshit in marketing and persuasion (and sometimes economics?), but not easily in programming. Learning to generate, parse, or deflect bullshit is its own valuable skill, but coding practice is less helpful there.

Sure, tail recursion is efficient, but when you focus on that you get programmers trying to conceive of every problem as tail recursion. I took a Scala MOOC, which I did not like, because it was "let's tail-recurse everything!" Ah well, to each his own. I have Go to fit my sensibilities.

"I took a Scala MOOC, which I did not like, because it was “let’s tail-recurse everything!” "

As an aside a lot of these type of university courses exist to filter out CS students for grad school. The general idea being is that if you can figure out how to use Monads than you're probably clever enough to get a PhD.

I believe you'd be hard-pressed to find a modern compiler that doesn't unroll recursion when possible (and not just , probably including just-in-time compilers. (More generally, very few programmers can write more efficient code than a well-optimized compiler. This is partly because compiler makers tend to recruit very good programmers, and partly because compilers can be mechanically relentless.)

(Here is an example of a compiler optimizing tail recursion into loops:

Nonetheless, the general case remains: not only is programming mostly hard to learn, the difference in skill level between people who have supposedly learned the skill is massive. I do think part of the problem is most programming tools are crude (or more generously, optimized for very serious coders doing very serious coding).

Finally, I think Mr. Personna is right to advocate for problem analysis and solving as skills worth learning, but consider how notoriously groan-inducing math word problems are: they're all about that, and they're hard for most people. Perhaps coding could teach people to be better at problem analysis, perhaps not.

But as a skill for the modern world, I think learning how to manipulate software systems programmatically--whether that means learning assembly or being (shudder) That Guy with All The Excel Macros--is valuable.

+1 - I don't use recursion either--a loop is faster. But if you want to learn a cool language try F#--a functional language that is very terse, perhaps the wave of the future? (I am a C# person myself)

This caught my eye: TC saying “Take Mark Zuckerberg who, of course, has been a great programmer,” says Cowen." Googling it, we find indeed Zuckerberg is a coding guru.

To be honest, I wanted to come out strong against recursion in part because I think it is oversold, but also to see what came back. I think many of the responses, pro-recursion, were strong. Still ... I'd limit my enthusiasm to solutions that are natural recursions, and not forced to fit ... fashion.

"Almost all modern compilers implement tail recursion, so the stack frame performance impact is a non-issue."
In fact, almost all of the most commonly used languages (from do NOT support tail recursion, including Java, PHP, JavaScript, Python, bash, and Ruby.

My early idea on "teach kids to code" was that the high dropout rate was fine, and you are really just exposing a population to one possible path. Certainly not everyone needs to become a real programmer.

On the other hand, simple, primitive, programming (without the math or recursion) is just about breaking down a problem and solving it piece-wise. That is a valuable life skill.

It is also more emotionally rewarding. The feeling that they cobbled together something that obviously works and can be tuned to work slightly differently is very positive. Sort-of "look, daddy, what I did here!"

Algebraic tasks are way less lively.

"On the other hand, simple, primitive, programming (without the math or recursion) is just about breaking down a problem and solving it piece-wise. That is a valuable life skill."

Most education research indicates that learning to do any task, pretty much only confers narrow and specific benefits. A similar argument could be made for teaching calculus, but no one has ever shown that calculus increases general reasoning ability. Teaching kids to move turtles around in Logo will pretty much just make them good at moving turtles around in Logo, and not much else.

Isn't that contra what we know about neurobiology (link)?

Some parts of what might be described as a “social brain” network are also activated differently in teenagers compared with adults when thinking about intentions (Catherine et al, 2008) and brain regions responsible for the control of impulses appear less well functionally connected in adolescents’ than in adults’ brains (Steven et al, 2007). Teenagers also appear to activate different areas of the brain from adults when learning algebraic equations, with this difference associated with a more robust process of long-term storage than that used by adults (Luna, 2004; Qin et al, 2004).

I don't necessarily think its contradictory. Teenagers may store the knowledge of how to perform a task in a longer-term way. But that doesn't mean that makes them any better at transferring knowledge of that task to other tasks.

For what it's worth, my intuition is that a generation of 7th graders trying algebra improves them, even when they do not achieve algebra.

Disclaimer: I dropped out of a Computer Science major after a term.

I blame the instruction as much (or more) than the content. Also computer science is HORRIBLE about expectation management - it has fairly little to do with coding, after all. Personally, I just found the whole algorithm stuff to be fairly boring (and I had like math until that). In real life, I am going to use the library and I should know which algorithm performs how, but I could care less about the implementation in some inane language that is not even really suited to implement it in (learning algorithms without having access to pointers seemed rather besides the point for me).

As for recursion, that one is not too bad. Now functional programming on the other hand...

The algorithm stuff you're not using everyday, but it's still very important for anyone doing high-level work. Critically at the point of architecting large-scale systems. For example most times you're tweaking a system for performance you're making constant or proportional adjustments. In this case asymptotic run time is mostly irrelevant. Many times a O(N) implementation runs faster than a O(ln N) implementation if you're not chaining the size and scope of the data significantly. However when you're making major revisions to the system or trying to drastically increase scale, activities which by their nature are not day-to-day, you better have a firm understanding of these concepts.

The best analogy I could make would be with doctors and microbiology. How many times a day is an oncologist going to need to know the base pairs of DNA or the chemical reactions involving ATP? But do you really think it would be a good idea to drop these courses from medical school?

All undisputedly true. Still does little to change my opinion that teaching algorithms before any actual, straight-forward coding is a bad approach to teaching a subject. Especially when half of your class already code and wonder WTF you are bothering them with arcane algorithms people largely do not use and the few that do will use the library.

Hook people on application for a while, then throw the dry theory at them. Otherwise the best and brightest might venture off doing other things (which may well be a socially superior outcome but is unlikely to be in the interested of the comp sci department). Personally and went and got an MA in Econ. Got me far more options and better pay to boot. Ironically, almost ten years down the road I am looking at getting back closer to tech but I by now have learned that I lack the patience to actually go and write any significant amount of code.

I like the DNA metaphor. (Also I think recursion is really cool and would be loathe to hire a programmer who did not.)

The interesting thing about your metaphor is that *nurses* are not required to learn about ATP, and over time we are seeing nurses claim territory once owned by doctors. (Nurse practitioners can write prescriptions, for example.) So medical school won't change, and (at least in this regard) it shouldn't, but more and more of your health care practitioners won't have gone to medical school.

"Especially when half of your class already code and wonder WTF you are bothering them with arcane algorithms people largely do not use and the few that do will use the library."

That reminds me of this web comic.

"The interesting thing about your metaphor is that *nurses* are not required to learn about ATP, and over time we are seeing nurses claim territory once owned by doctors. (Nurse practitioners can write prescriptions, for example.)"

The biggest barrier I see to programmer nurses is that medical problems are more easily dividable into "high" and "low" tasks. We pretty much know what jobs can be done by those with more superficial skills, e.g. drawing blood, and what jobs require deeper knowledge, e.g. whatever Dr. House does. In programming the distinction is harder to make. Components that are anticipated as "simple" often times end up being extremely complex. And vice versa. Then throw in the fact that requirements change and the overall system needs to lean more on previously parts that were previously under-engineered.

You can see this manifested in the fact that software project time estimates are often off by an order of magnitude or more. As of now with the tools we have humans are far worse at planning ahead the requirements and design of large software systems. Which makes it very difficult to segment out the work to different levels of skill. It's usually more cost-effective to hire a few highly skilled developers and have them do everything. This is largely why the movement to outsource low-cost, low-complexity development to India has mostly been a failure.

It seems strange to me that you would learn analysis of algorithms before writing any code. Most first-term computer science courses are "introduction to programming" of some variety.

"It’s hard enough teaching kids algebra 1 & 2 and coding is many magnitudes harder"

I think that varies according to the child. Algebra was a really hard intuitive leap for me. It was the only math class I ever struggled with. For several months, I didn't "get" it, but once my mental paradigm shifted it was trivial.

Coding was always pretty straightforward.

I always found coding more straight forward than a lot of algebra and calculus. For starters, it helps to have mnemonic variable names (and I doubt I would have understood variables in algebra if I had not already come across the concept in programming beforehand).

#5. The arc described by Brooks is applicable well beyond his denigration of "Thought Leaders".

By the end of that column I found myself convinced he was writing about himself ... maybe this is the depressed David Brooks.

I thought maybe he read that essay of Tom Scocca's (some Gawker Media yapper, I gather) on snark and civility that people have been tut-tutting about lately and this column was a general issue response.

I think it's just regular David Brooks.

"3. The future of doctors?"

The usage of computers in the described article is usually referred to as Expert Systems. It's basically a version of dumb AI, where the computer is essentially a really nice Medical Encyclopedia.

Doctors can be empathetic, but a machine won't.

Yeah, that's dumb AI he's talking about. If you can give an objective definition of what "empathy" is, we can code it. If you can't, you're some form of racist -- probably one of those meat-body doctors, always forgetting things and not familiar with the latest research.

Unlike you, I would not guess that the readership of this blog is uniformly able to supply the missing sarcasm tag to your insightful comment

True. I for one am just not programmed that way.

And that comment fails the Turing test.

Re Piketty: Did you see the skyrocketing share of housing capital as a % of national income!?

Paging Henry George! And Ed Glaeser, Matt Yglesias, Donald Shoup...

We don't have a capital problem, we have a land/housing problem. Where'd I leave my old Ricardo textbook?

I noticed the same thing! Given that the two countries involved are France and the UK, the causal relation is perhaps even clearer. Paris and London are both far more productive than the rest of their countries (by a factor of at least 2), they have housing prices that outstrip those in the (much wealthier) United States. I imagine median rent versus median income is through the roof there. One might even suggest, per Ryan Avent, that the high cost of housing is greatly holding back prosperity, as people from the provinces cannot move to the capital where wages are much higher - they're simply priced out. This too, would drive wealth to output ratios higher. Not to mention that the residents whose entire income is eaten up by rent don't have leftover money to build up any wealth...

#2 I don't agree, coding is a life skill, like cooking and counting. If achievable, it should be learnt in parallel to other subjects, not to the exclusion off. Yes, programming languages change and that language you learnt will be outdated a few years hence but it is a method of thinking that you do not learn anywhere else, not in learning a foreign language, math, biology or even philosophy.

This advice that you do not need to learn how to code is really a false advice. Mark Zuckerberg is a nice example, he studied psychology but he also knows how to code, and therefore understands that way of thinking. He would not have been as succesful had he just followed a few engineering or statistics courses as promoted.

I am a physician that knows how to code, and believe me, I observe my colleague physicians that are engineers, that know about technology, but do not know how to code, and it is really hard for them to truly understand the possibilities and limitations of IT in healthcare, for example.

If you can, learn to code. It is a way of thinking that you cannot acquire in any other way (that I know off)

What does this mean? I "learned to code" in that I took classes in Pascal, C, assembly language, LISP, then did a bunch of stuff in Matlab during college. Does that count? I could still go and write some C or Matlab code I am sure if I needed to. I don't think that contributes in any way to my understanding of anything, let alone the implementation of IT in health care. What connection does it have to anything in life?

You are 45 years old. How close am I?

Not very :) Off by about 15 years. Matlab is still the code of choice for engineering as I understand it. The other stuff was in high school. It was actually C++

I wish I could have learned C in high school. (I am 45 and took Pascal, C, and assembly language in college... but Scheme instead of Lisp.)

I'm 34 and took Turbo Pascal for the AP computer science in 1996. Scheme freshman year of college too.

I think they switched the classes to C++ just a couple of years afterwards.

Furthermore, you will write terrible and dangerous C code. C will let coders do anything they want, better or worse. No under grad class will approach the required rigor, so what's the point if the student does not move on to more intense study?

@Cliff No, learning to code is not the same as doing an MS in computer science. Please engage with the argument Tyler is making and I am trying to rebut here. My point was that even a one year course of any programming language in high school has benefits to understanding that a general course in technology or science simply does not have. Tyler disagrees AFAIK.

@Ricardo I am using my full name, unlike you, so do feel free to look me up. While you are at it, please explain what my age or that of my kids has to do with any of this.

I think Ricardo was guessing at Cliff's age, based upon what kind of programming classes Cliff listed, and wasn't really responding to your post at all.

JWatts, you are correct. Michael D. Abramoff, sorry for the confusion, and I have no idea how your kids entered the discussion. Using your full name in blog comments will lead to regrets with P=0.64.

Aha, embarassing! I also comment here under pseudonym, for the less politically correct stuff. But so far comment discussions while using my real name have led to more interesting debates.

That is interesting - is it because you invest more in your posts when you put your real name on them?

My children should learn to code. Your children? Who can tell?

Based on genetics I would go with competitive bridge or "networking" for anyone closely related to me who has more than 5 decades of earning potential in front of her

#2 I found the part "'There won’t be much room for a ‘rebel without a cause’ or, for that matter, a rebel with a cause,' writes Cowen." a little jarring to end a section about collaboration. I may grant you the former, but not the latter. Efficiency requires specialization and that means you have a lot of people skilled in particular areas, even within one organization. With scarce resources and human nature as it is this often leads to silo building and accentuating your own efficiencies. A true collaborator is a generalist who bucks that specialist trend and pulls people together. Given the tendencies of the efficient organization, it is pretty rebellious to care about the greater good and venture off your silo. I suspect there will always be room for rebels with a cause, not because people like them but they help get stuff done.

I did like the article in general though. I think everyone should learn at least one programming language and one foreign spoken language too ... if nothing else to learn about the culture and appreciate how others approach their life and work.

LOL @ #6: " decline in top [income] tax rates [in US]..."

Evidently they missed the memo that US income tax rates for top earners are often higher than EU counterparts.

Look at their figure 14.1 - they mistakenly report top US income tax rate as 40%, haha!

Bush league, guys.

Even Wikipedia knows that top rate is more like 55%, heading up to 58+% for 2014.

I would think effective rates are the pertinent measure.

Effective rates aren't covered in that paper.

Obviously. However your comment

"Evidently they missed the memo that US income tax rates for top earners are often higher than EU counterparts."

Is only true if a person looks at published rates, not effective rates.


Again, the effective rates for the US appear low only if you ignore state and local taxes. Virtually all articles, even including the OECD's GINI calculations, do precisely this.

For example, a typical article from the Atlantic claims US tax/GDP ratio of 27.3%

Actual number oscillates around 33%:

#2: Basics of programming and electrical engineering should be taught (as basics of reading and math are taught), but learning to use a linux shell is probably more valuable.

#3 Number of doctors can be reduced dramatically with very good AI fake. Nurses - not so much. They are the ones actually observing the patient, talking to him and rolling him in the bed when needed.

#2 Yes, of course
Ability to code greatly enhances one's intellectual abilities. Just like calculus or algebra, maybe more. Good coders are good thinkers.

David Brooks needs a hug.


Coding is a tool, much like any other. It's incredibly useful, and those who can do it have an advantage over those who can't.

Coding is not hard. It doesn't require any special level of intelligence. There's really nothing special about people who can code, other than they took the time to learn to do it. And, anyone can learn to do it.

In fact, I'd say coding is one of the easiest technical skills you can learn. The information available, and the resources, and online tutorials, and ease of access to tools is unparalleled. Anyone could pick up Python in a few days, and be doing something useful with it. And the feedback is near instantaneous. It's not like learning math, where you need someone to check over your work to make sure your answers are correct. If I write a piece of code to perform some task, I can run it, and immediately tell whether or not it behaved as I intended.

And it's advancing incredibly fast. So things keep getting easier. It would have only been a few years ago where, if you wanted to create a nice, interactive website it would have required a lot of special skills. Now it's next to trivial.

Algorithms are hardly relevant to most people. Unless you're dealing with huge amounts of data, or something that requires a lot of optimization it just doesn't matter. And, even when it does, you can get 95% of the way there using libraries. What modern language doesn't have built in dictionaries, and sort functions?

Recursion rarely comes up, and isn't nearly as bad as CS majors like to think. Sure, it's confusing when you first try to use it, but, again, it's something anyone can learn, if they're motivated.

Ultimately, coding is an incredible tool, generally more useful in my life than most of the math I've learned. I can automate tasks that would otherwise require a lot of manual work, that certainly comes up far more often than needing to solve integrals.

As an example, when my wife was in residency she had to edit a book chapter, which meant adding content, reorganizing content, removing some content, and updating some content. It was a long chapter, with 100s of enumerated references. She would have needed to manually fix all of the references on every submission, since adding a new reference at the top would change the number of everyone below, and the reorganizing was basically shuffling them.

Because I can write code, I took a couple of hours to automate that process for her. I could parse her chapter, find the references, and reassign all of the numbers, then reorganize the references at the end of the chapter to be in correct order. It would have been hours of manual work for her on each submission, reduced to a couple of hours of development time for me, that could then be reused each time she had to make revisions and resubmit.

I can only imagine if most average office workers knew just enough coding to get by, how much of their work they could automate if even some small percent of them were motivated to do so.

A bit late, but I'd like to chime in if I may. We hear a lot about maths being required for many jobs. I think that for a vast majority of those jobs it is critical thinking and logical problem solving that is required and ability in maths is used as a proxy for these desirable side-effects. Ideally, we should teach critical thinking and logical problem solving as a subject in itself as it is possible for someone to find maths daunting and incomprehensible but still be good logical thinkers. But in the mean time, I think programming is a good skill that can better act as a proxy for problem solving than maths. As others have mentioned - nobody is suggesting advanced computer science for 6 year olds. But the basics of programming (variables, conditionals, loops) can be applied to many areas and help with other topics especially maths and physics.

Children don’t need to learn to become coders, but I argue that they should learn how to code. My second-grader just finished One Hour of Code ( where she learned, in a fun way, about the world of IF, THEN, AND and OR statements. Knowing the basics of coding, and its underlying logic, with help her work with technology, whatever field she chooses.
- See more at:

Comments for this post are closed