We Don't Need No Education

My friend Sean posted an excellent response to a blog post by Chris Tompkins about programming languages that seems to be generating some controversy. The original post argues for a more user-friendly natural language based programming language for people who are turned off by overly terse notation typical of most languages. Sean argues that programming is a skill that takes years to master and the terseness actually ultimately benefits the programmer.

However, Tompkins has a very good point. He just argues it very, very poorly.

Let's start with what he gets wrong. As Sean points out, programming can be very difficult to the novice because communicating to a machine is very different than communicating to a person. People have a vast amount of contextual knowledge that they take for granted, and can become frustrated when a computer does not possess this knowledge, and therefore must be instructed to do things in excruciating detail. This is a typical novice mistake: assuming the computer knows more than it does.

Having been frustrated by the inherent complexity of the task, the novice blames the tools for being insufficient. This is another typical novice mistake, as the novice has no idea what decisions were made when those tools were created, what their intended use was, and by whom they were intended to be used. The fact that the blog post confuses C and Objective-C is a tip-off that the poster doesn't fully understand what he is talking about.

But what rankles me the most about this post as a professor of computer science is that the poster assumes that a very complex skill can be learned quickly without the benefit of a proper education. There are plenty of self-taught programmers out there, but each and every one of them spent hours and hours honing their craft and learning the ins and outs of programming, and are probably still doing so. For those who need a bit of a leg up there are books and classes and degrees aplenty to provide assistance in mastering these skills. Fundamentally, if you are not willing to do the work of learning, you will not learn.

All of this is a great shame, because the blog post has touched on a very real problem that the blogger frankly lacks the expertise to properly explain. The problem is that historically, the first programmers were solving mathematically sophisticated problems dealing with complex tasks like computing weapons trajectories and cracking encrypted messages, and therefore the languages they created were highly mathematical in nature. Despite the fact these types of problems have become the minority of what programmers deal with today, many of the mathematical concepts (functions, variables, structures, etc.) persist.

Of course this complaint is nothing new. In 1959 a committee came up with a language intended for use by business professionals who lacked the advanced technical training required to program in a language like Fortran or ALGOL. The result was COBOL, a hugely successful language that is still widely used today. However COBOL had one little problem: working programmers and computer scientists hate it. The great Edsger Dijkstra one said that "[t]he use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense."

Here we have arrived at the great tension in programming languages that poor Mr. Tompkins has blundered into without the knowledge and experience to address properly: if you create a programming language that is easy enough for anyone to learn, people will assume that programming is easy and proceed to write very, very bad programs. This is the main reason why languages like COBOL, BASIC, Pascal, Visual Basic, PHP, and JavaScript get as much flak as they do. This is not to say that bad programs do not exist in other languages, they most certainly do. However, if one is not willing to learn the admittedly opaque syntax of a language like C, one is probably not willing to learn the much more important principles of programming.

That said, I think there is plenty of room for languages that make it easier to write good code, and resources that help aspiring programmers to understand the complexity of the tasks they are about to take on. I hope that both my research and my teaching can contribute to the equally important tasks of making programming easier to learn and providing the understanding to do it well.