Wild Rats and “Evidence-based” Programming Language Design [Very Geeky]

If we want to create a world in which in every community as many people as possible can participate in creating robotics, AI, virtual and augmented reality, etc., we’re going to have to “disrupt” the world of programming languages so coding is easier for adults. As part of a pilot project to try to do that — Mixed Reality for All — I’ve started reading research on “evidence-based” programming language design. I’m just getting started, but so far much of the research reminds me of a story my grandfather Sandy used to tell.

In the 1950s, Sandy spent some time designing rat mazes for some university psychologists. The rats they used were carefully controlled; you literally ordered them out of a catalog based on the characteristics you wanted. One day, the lab techs put a new batch of rats in a rat maze, went away for a bit, then came back to see how the rats were progressing. They couldn’t find them. After a little investigation, they figured out what had happened. They’d accidentally been sent a batch of wild rats. Rather than running the maze like genetically bred docile rats did, the wild rats had found a place in the maze that provided some visual cover, chewed a hole in the floor of the maze, and escaped!

Sandy’s point was that the psychologists’ work on “intelligence” assumed that they were working with animals that weren’t that intelligent. If you worked with truly intelligent animals who had to cope with the complexities of the real world, it was hard to get them to focus on the very small corner of intelligence that you want to study. Like a prisoner of war, the first duty of a wild animal being held in a lab is to escape.

A lot of the research on the best way to design a programming language seems to be like it falls into the same trap: it focuses on one small corner of design while not paying enough attention to the larger context.

For example, there’s a programming language called Quorum that was designed from the ground up to be driven by the best evidence we have about what makes a good programming language. Their website has a great page that summarizes a lot of the best evidence. The first example: whether programming languages should be statically or dynamically typed (WARNING: this is pretty geeky).

Some programming languages, such as Java, use “static typing”: whenever you are going to store info in a variable, you have to tell the computer what type of data you’re going to put in that variable.

[code lang=text]
firstName: String;
firstName = "Beyoncé";
numberOfAlbums: Int;
numberOfAlbums = 6;

print firstName + " has sold " + string(numberOfAlbums) + " albums";
[/code]

Other programming languages, such as Python, use what’s called “dynamic typing,” where one of the advantages is that you don’t have to spell out what type of data you’re using, the computer figures it out:

[code lang=text]
firstName = "Beyoncé"
numberOfAlbums = 6

print firstName + " has sold " + numberOfAlbums + " albums"
[/code]

There are pros and cons for each approach, and more than a few coders like to trash each other for their opinions about it. Guess what, say the evidence-based coding language researchers. We don’t need no stinkin’ opinions, we’ve got data: beginners make a lot fewer mistakes with static typing. Game over!

I read one of the papers making that case. It was a smart paper. Essentially what they showed was that if you give programmers one of 2 options:

[code lang=text]
function taskCollision(player: User, opponent: Enemy, engine: GameEngine) // Static Typing
function taskCollision(player, opponent, engine) // Dynamic Typing
[/code]

More programmers make fewer mistakes with the statically typed code.

Makes sense to me. In their example, static typing gives me more info about what’s going on, so I’m less likely to get stuck.

But in the real world, it’s not so cut and dried.

Take one of my favorite new editors for writing code: Visual Studio Code. One of the things I like about it is that you can customize it, including adding new features. To do so, you use Type Script, a version of JavaScript that has Static Typing. In theory, Static Typing should give me a more info. But in practice? Here’s some sample code from one of their tutorials:

[code lang=text]
export function activate(context: ExtensionContext) {

}

class WordCounterController {
private _wordCounter: WordCounter;
private _disposable: Disposable;
constructor(wordCounter: WordCounter) {
this._wordCounter = wordCounter;

// subscribe to selection change and editor activation events
let subscriptions: Disposable[] = [];
[/code]

When you first see this code, it looks like gibberish. The fact that the static typing tells you one variable is an ExtensionContext and another one is a Disposable doesn’t help much.

In my experience, many systems that use static typing have the same problem: it takes a lot of lines of code to do just about anything, and a lot of the “types” have strange names. It’s almost as if languages that use static typing also tend to encourage coders to be more verbose and use (somewhat) geekier names. In contrast, one of the reasons I like working in the programming language Python, which is dynamically typed, is that it encourages people to write code that’s more concise and more intelligible (although you can create a hot mess in any language).

An experiment in a lab can tell you that in isolation, one feature/strategy is more effective than another. But that’s not all that useful. What you really need is data that tells you what’s most effective when you’re dealing with all the complexities and interdependencies of code out in the world.

And that brings me to the programming language Quorum, whose website has the synopsis of evidence-based programming design. If it’s the most “evidence-oriented” programming language around, it must be pretty hot stuff, right? But from what I can tell from googling and from checking out the rest of their website, nobody seems to be using it for solving real world problems.

Don’t get me wrong. A lot of great work was put into it, and some of the tutorials, including how to create a Frogger-like game, are fun and show a lot of thought (although it requires way too many lines of code). But as far as I can tell, the only people who are seriously into Quorum are high school teachers.

If your only goal is to make it easier to teach kids the basic principles of programming, that’s fine. But if you read most of the articles about evidence-based programming design, they’re hunting bigger game. There’s definitely an undertone to a fair number of evidence-based articles that most people who design coding languages don’t have their act together. What’s wrong with these jokers that they aren’t bothering to look at all this great research?

To which I’d reply: if Quorum is so awesome, why isn’t anyone using it for real work? Most of the best coders I’ve known love learning new programming languages. Many believe if you want to be at the top of your game you should learn a new language every couple of years, if only so you can pick up on some of the latest design concepts that went into them. If anything, these folks can go overboard, forever searching for the Holy Grail of coding languages. If Quorum was all that, at least some of those really skilled folks would be using it and evangelizing for it. But the data is pretty clear: for all its prowess in the lab, Quorum doesn’t seem to have gained traction in the real world.

I’m not saying we shouldn’t pay attention to research on programming design, some of which is quite thought-provoking. But after my first pass through the literature, it feels like they need to seriously up their game. They need, in short, to start learning from the “wild rats” of coding.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: