As a programmer, you write for two very different kinds of readers. One is the rigid computer platform, the other is the human maintainers of your code. For the former we have quite conclusive guidelines on what works, but the latter is only consistent as a source of disagreement and uncertainty. Typically the guideline is “Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.“, while most people end up writing as if the person maintaining the code is themselves. Neither approach is particularly good -I can’t imagine code written for violent psychopaths  would really be that great to maintain. And on the other end, a lot of coders[…]

Another piece of old research. It’s so interesting, though, I can’t help putting a note up about it. In a piece of research released in 2000, Lutz Prechelt compared C, C++, Java, Perl, Python, Rexx, and Tcl.  (It’s gotten a fair bit of attention before, so it’s not new material) What’s so good is the fairly rigorous and natural approach – instead of leaning exclusively on local students or one company’s employees performing some unnatural task, the researchers solicited for solutions online for the scripting languages (Perl, Python, Rexx and Tcl) and got 80 different implementations of a simple dictionary task. With these tasks they ran a lot of metrics and generated solid, comparable empirical data. Read it for the[…]

15 years ago, the research journal Human-Computer Interaction published their special issue on Object-Oriented Programming.  Having realized that a lot of the claims made about OOP at the time were not technical in nature, but rather were psychological and cognitive, the special issue attempted to present empirical and experimental research examining the claims about OOPs advantages on procedural programming. Or as the editor Bill Curtis notes: Object-oriented (OO) design and programming trace their lineage to research on abstract data types in the late 1960s and early 1970s, but they did not become popular software development techniques until the late 1980s. In all this time there has been little serious empirical or experimental study of OO techniques. What usually passes for[…]

Apparently, the distribution of marks in introductory courses to programming looks like this: How come? Some people just get it and some don’t? A failure of teaching? See the discussion at Mik’s blog. I don’t necessarily agree that this is caused by people falling behind and not being able to catch up (although that is probably also a problem).  If that was the case, you would probably see a skewed single peak distribution, as one of the commenters suggest. Rather, I think the either/or explanation is the right. Now does that mean people in the left hump will never be able to learn, or are doomed to a life of poor understanding of programming? I think not, but how to move[…]

I promised to explain better the idea of variable roles I mentioned in the previous post about natural programming. This is based on a finding by Finnish researcher Jorma Sajaniemi (published work), who discovered that 99% of variables in novice’s code can be categorized in to 11 different roles. These roles are variable uses every programmer will recognize: iterators, constants, flags and so on – although in role-terminology the names somewhat differ (steppers, fixed-values and one-way flags, for example).  Mr. Sajaniemi has also found that these roles matches tacit knowledge in expert programmers – i.e. the 11 roles are also typically intuitively recognized by expert programmers even if it is not explicit or active knowledge. Whether or not the same[…]

I just touched upon how natural programming can be a way forward for Perl in my previous post, and quickly saw a twitter from chromatic not understanding the “criticism (?)” of Perl 6. As he is a member of the Perl 6 development team, I am happy that he noticed my post, but not so happy about the lack of understanding. So a clarification is probably called for. My post was not a criticism of Perl 6. I am quite skeptical and apprehensive about P6, which shone through in my article, but criticising a project that started in 2000 for not implementing ideas published in 2008 would be rather unfair. However, Perl seems to be in search of a purpose[…]

When I hear people start talking about “natural” programming, easier ways of programming or making programming available to non-programmers, I get very skeptical. It makes me think of Logo and Turtle Graphics, or programming languages made to be more similar to natural language. It’s like you could make a simpler English to make it easier for non-authors to write literature. So when I first read about The Natural Programming Project, I balked – although for no reason. The researchers working on NPP certainly does approach programming with the aim of making it easier for laypeople, which seems like a turn-off. However, the output of the project is surprisingly interesting to the professional:  Lab studies scientifically testing the utility of design[…]

Wil Shipley has an excellent blog post on how using simple heuristics – ie. less-than-perfect shortcuts to a goal – can improve life significantly, and how we tend to ignore that. He makes a point about user interfaces, but it is good as a general observation:  A good-enough solution that improves life for many people is better than a perfect solution that can’t possibly be made. Also, he points out that classic programming theory will teach you a lot of computer-sciency methods for problem solving, while in real-life are heuristic methods trying to understand user input as good as possible. That, however, I think is because he is a good programmer, not something all programmers come across: I bet the[…]

Jeff Atwood’s blog Coding Horror has a great post about failing projects! This qoute by Charles Bosk is great: In my interviewing, I began to develop what I thought was an indicator of whether someone was going to be a good surgeon or not. It was a couple of simple questions: Have you ever made a mistake? And, if so, what was your worst mistake? The people who said, ‘Gee, I haven’t really had one,’ or, ‘I’ve had a couple of bad outcomes but they were due to things outside my control’ — invariably those were the worst candidates. And the residents who said, ‘I make mistakes all the time. There was this horrible thing that happened just yesterday and[…]

A quick find: I’ve been wanting to read the programming management classic “The Mythical Man Month” for years, but have never gotten around to it.  Turns out there is a  chapter-by-chapter summary that has been online for only 19 years (!). Enjoy getting through a classic in two hours. However, the whole book can be summarized with the following koan from the Tao of Programming: A manager went to the master programmer and showed him the requirements document for a new application. The manager asked the master: “How long will it take to design this system if I assign five programmers to it?” “It will take one year,” said the master promptly. “But we need this system immediately or even[…]