I listened to an interview last night with Perl guru Randal Schwartz. He said that Perl is meant for people who use the language at least two or three hours per week. If you’re not going to use it that often, you’re probably better off using something else. But if you use it full time, you can see huge productivity increases.

That matches my experience, at least the first part. I was attracted to Perl because I could imagine being very productive with it. At first I used the language infrequently. Every time I sat down to write Perl I had to work hard to reload the language into my brain. Then for a while I used it frequently enough to achieve some fluency. Then as I wrote Perl less often I could almost feel the language slipping away.

Of course you have to use any language, human or computer, to achieve and maintain fluency. But my sense is that Perl requires more frequent use than other programming languages in order to remain minimally competent, and it repays frequent use more than other languages. I imagine this is a consequence of the natural language principles baked into the language.

One of the things I prefer about Python is that you do not have to use it three hours a week to remain competent.

I no longer write Perl, but I still enjoy listening to thought-provoking Perl speakers like Randal Schwartz.

My daughter asked me recently what I thought about a Rube Goldberg machine she sketched for a school project. I immediately thought about how difficult it would be to implement parts of her design. I asked her if she really had to build it or just had to sketch it. When she said she didn’t really have to build it, I told her it was great.

I thought of a friend’s comment about designing code versus actually writing code: “I’ve never seen a piece of paper abort.” The hard part about writing software is that people can tell when you’re wrong.

In any programming project there comes a point where the programming ends and manual processes begin. That boundary is where problems occur, particularly for reproducibility.

Before you can build a software project, there are always things you need to know in addition to having all the source code. And usually at least one of those things isn’t documented. Statistical analyses are perhaps worse. Software projects typically yield their secrets after a moderate amount of trial and error; statistical analyses may remain inscrutable forever.

The solution to reproducibility problems is to automate more of the manual steps. It is becoming more common for programmers to realize the need for one-click builds. (See Pragmatic Project Automation for a good discussion of why and how to do this. Here’s a one-page summary of the book.) Progress is slower on the statistical side, but a few people have discovered the need for reproducible analysis.

It’s all a question of how much of a problem should be solved with code. Programming has to stop at some point, but we often stop too soon. We stop when it’s easier to do the remaining steps by hand, but we’re often short-sighted in our idea of “easier”. We mean easier for me to do by hand this time. We don’t think about someone else needing to do the task, or the need for someone (maybe ourselves) to do the task repeatedly. And we don’t think of the possible debugging/reverse-engineering effort in the future.

I’ve tried to come up with a name for the discipline of including more work in the programming portion of problem solving. “Extreme programming” has already been used for something else. Maybe “turnkey programming” would do; it doesn’t have much of a ring to it, but it sorta captures the idea.

During the Victorian era, Scotland produced the best engineers in the world. It became routine for British ships to have a Scottish engineer on board. Star Trek’s Scottish engineer Montgomery Scott reflects this tradition.

Until quite recently, astronomers thought that comets formed in the outer reaches of the solar system and then were drawn into highly elliptical orbits that pass near the sun. But samples collected from comet Wild 2 look more like they came from the inner solar system like asteroids. Maybe the outer solar system is more like the inner solar system, or maybe comets didn’t form where we thought they did.

For more details, listen to yesterday’s 60-Second Science podcast or read the Science Magazine article the podcast is based on.

Phil Haack gives his summary of a recent study on the benefits of test-driven development (TDD). The study had two groups of students write unit tests for their programming assignments. Students assigned to the test-first group were instructed to write their unit tests before writing their production code, as required by TDD. Students assigned to the test-last group were told to write their tests after writing their production code. Students in the test-first group wrote higher quality code.

The study concluded that code quality was correlated with the number of unit tests, independent of whether the test were written first or last. However, the test-first students wrote more tests in the same amount of time.

Note that students were assigned to test-first or test-last. Most programming studies are just surveys. The results are always questionable because professional programmers decide their tools. So, for example, you cannot conclude from a survey that technique X makes programmers more productive than technique Y. The survey may say more about the programmers who chose each technique than about the techniques themselves.

Shell shock was identified during World War I as a condition that causes soldiers to become dazed after being near explosions. Symptoms may appear weeks after exposure and there are no outward signs of injury. Naturally, this was regarded as a psychological rather than physical disorder.

But according to a story in today’s Science Magazine podcast, there is increasing evidence that shell shock is caused by physical trauma to the brain. One theory is that compression waves from the explosion hit the torso and transfer pressure to the brain via the circulatory system. If this theory is true, improved head gear will not help but improved body armor might.

The law of small numbers says that people underestimate the variability in small samples. Said another way, people overestimate what can be accomplished with a small study. Here’s a simple example. Suppose a drug is effective in 80% of patients. If five patients are treated, how many will respond?

Many people reason that 80% means 4 out of 5, so if 5 people are treated, exactly 4 will respond. Always.

Others understand that things are not guaranteed to work out so neatly, but they still believe that it is highly likely that 4 people would respond. Maybe a 90% chance.

In fact, there’s only a 41% chance that exactly 4 would respond out of a sample of 5.

In case my previous note on the law of small numbers confused anyone, I’ll compare it to the law of large numbers.

The law of large numbers is a mathematical theorem; the law of small numbers is an observation about human psychology.

The name “law of large numbers” is a standard term applied to a theorem about the convergence of random variables. (OK, actually two theorems. Like nuclear forces, the laws of large numbers comes in a strong and a weak form.)

The name “law of small numbers” is a pun, and I don’t believe the term is commonly used. Too bad. It’s a convenient label for a common phenomena.

The book Judgment under uncertainty analyzes common fallacies in how people estimate probabilities. The book asserts that no one has good intuition about probability. Statisticians do better than the general public, not because their intuition is much better, but because they know not to trust their intuition; they know they need to rely on calculations.

One of the common fallacies listed in the book is the law of small numbers. In general, people grossly underestimate the variability in small samples. This phenomenon comes up all the time. It’s good to know someone has given it a name.

I think it was in 1970 that I gave my first talk in a foreign country on the design of programs that you could actually control and prove were correct. … The talk fell completely on its face. … The programmers didn’t like the idea at all because it deprived them of the intellectual excitement of not quite understanding what they were doing. They liked the challenge of chasing the bugs.

During WWII, statistician Abraham Wald was asked to help the British decide where to add armor to their bombers. After analyzing the records, he recommended adding more armor to the places where there was no damage!

This seems backward at first, but Wald realized his data came from bombers that survived. That is, the British were only able to analyze the bombers that returned to England; those that were shot down over enemy territory were not part of their sample. These bombers’ wounds showed where they could afford to be hit. Said another way, the undamaged areas on the survivors showed where the lost planes must have been hit because the planes hit in those areas did not return from their missions.

Wald assumed that the bullets were fired randomly, that no one could accurately aim for a particular part of the bomber. Instead they aimed in the general direction of the plane and sometimes got lucky. So, for example, if Wald saw that more bombers in his sample had bullet holes in the middle of the wings, he did not conclude that Nazis liked to aim for the middle of wings. He assumed that there must have been about as many bombers with bullet holes in every other part of the plane but that those with holes elsewhere were not part of his sample because they had been shot down.