The arrogance of computer scientists

Deflate your fucking egos now, please

I’m back! And more cantankerous than ever.

One book that I found useful in the early days of my career as a programmer (if you can call it that) was the famous Structure and Interpretation of Computer Programs by Abelson and Sussman, also known as SICP or “the blue book”. Published in 1984, it was intended for use in MIT’s Introductory Programming course, 6.001.

It is widely viewed as the best book of its kind, and it is quite detailed and comprehensive, but not without its flaws. Its biggest flaw is that it is written in an elitist manner, clearly intended for the brightest of the bright at schools such as MIT and CalTech. Average Joes need not bother.

As such, it is heavily focused on mathematics. If you’re a lover of category theory, mathematical proofs, the lambda calculus, and very abstract language and concepts, well, this is the book for you.

Unfortunately, this leaves out an enormous number of people—the majority, in truth—who would benefit greatly from the lessons in this book.

LISPing

Another choice made in the book, and a good one, I think, was to use a dialect of LISP called Scheme. While most people who program for a living do not use a variant of LISP, the simplicity of the language and its lack of “noise” makes it an excellent choice for focusing on how things work rather than what syntax to use.

And LISP has other benefits, too, such as that the code is itself data and can be manipulated as data. That’s fun.

The focus on such concepts as Fibonacci sequences, Euclid’s Algorithm, etc., mmm, not so much. The naming could be a bit better, too.

But hey, it was 1984, right? Surely, we’ve come a long way since then, especially in our understanding of cognitive function, cognitive load, and pedagogy.

It’s 1984 all over again

So imagine my surprise yesterday when I discovered that SICP has been “translated” into different languages. Different programming languages, that is. And there is a version for JavaScript! And what’s more, it is available for free in online form with a playground and interactive code blocks.

Nice!

Or maybe not so nice after all

The first crushing disappointment came when I discovered that the authors (translators?) had learned absolutely nothing in the intervening decades. The text is as abstruse and impenetrable as the original. All the heavy focus on mathematical algorithms has been retained. Elitism never gets old, I guess.

Apparently, if one wants to learn the secrets of computer programming without significant brain pain, one must look elsewhere.

Steeling myself, I decided to press on. I’m getting a bit old for this shit, but I’m not demented yet (wait… how would I know? hmm). Surely, I can get through this. And it will be interesting to see how they translated the Scheme code into JavaScript.

In the Foreword, the authors claim that Brendan Eich based JavaScript in part on Scheme. I guess he wasn’t paying close attention because there seems to be a lot of other junk crammed in, such as prototypal inheritance, a horrible Date object, and Objects masquerading as modules, but at least he got first-class functions and higher-order functions right, although, hmm, does the runtime optimize tail recursion?

But then it had only been eleven years since the publication of SICP. Maybe Brendan hadn’t had time to study the book carefully. Or maybe he got bogged down in all the math. Cut the guy some slack. He wrote the language in two weeks, or so they claim.

Anyway, I soldiered on. But then came the second crushing disappointment. In truth: a fatal blow.

How to fuck shit up completely

I’m part way through the first chapter and I come across this:

function sum_of_squares(x, y) {
  return square(x) + square(y);
}

WTF? Is this some kind of sick joke? Everyone knows that the convention in JavaScript is camelCase not snake_case. This function should be called sumOfSquares not sum_of_squares.

Say it ain’t so!

Now you may think that this is a trivial thing, but it is not trivial at all. And if you’re going to argue that it is trivial, then it must be trivial to get it right. So why would you perversely fuck this up?

But as I say, it is not trivial at all. Consistent formatting of code following a convention is very important to making code transportable, reusable, and, most of all, comprehensible by the next programmer to touch it.

That’s why we have conventions.

So why oh why would they do something this stupid? They explain their reasons in a footnote:

The way multi-part names such as sum_of_squares are written affects the readability of programs, and programming communities differ on this. According to the common JavaScript convention, called camel case, the name would be sumOfSquares. The convention used in this book is called snake case, and was chosen for its closer resemblance to the convention used in the Scheme version of this book, where hyphens play the role of our underscores.

Holy shit! They begin by stating that the way multi-part names are written affects the readability of programs and that programming communities differ on this. Correct!

Then they admit that the JavaScript convention — the one decided on by the JavaScript programming community — is to use camelCase rather than snake_case.

And then they say that they are going to ignore the convention completely going against the JavaScript community (frankly, an insult to the community—but apparently they know better) because… wait for it… snake_case more closely resembles the train-case of the original book.

This is a blatant falsehood. It is complete horseshit. They are lying.

The original SICP, for all its flaws, respects the conventions of Scheme, its chosen language. If you wanted to mirror the original book, the obvious course of action would be to respect the conventions of JavaScript. Isn’t the point of the “translation” to show us that the language, Turing complete, is irrelevant?

But instead, much of the JavaScript in the book is wrong. It uses the wrong convention, so anyone new to JavaScript and hoping to learn it from this book will learn it the wrong way. And that will make it so much harder when they try to get a job in the community and they have to unlearn the incorrect convention and learn the correct one.

Clearly, this book is not intended to teach people to program, and definitely not in JavaScript. It is intended for computer science students and JavaScript is just a throwaway language, so it’s no big deal to mutilate it to fit the prejudices of the authors. It’s a slap in the face to JavaScript and the JavaScript community.

Why the hell would you do that to your readers? To make the function and variable names look superficially a little more like those in the original book, which most readers of the JS version will never read? Here’s a news flash: train-case and snake_case are not the same, and the similarity is actually a drawback as it is easier to miss the difference.

The truth is that they hate camelCase. They mention that there are arguments about readability. Well, guess which side of those arguments they take. Yep. They believe that camelCase is just wrong, and so with utter disregard for the JavaScript community, they shove their bias down their reader’s throats.

That, my friends, is arrogance. Towering arrogance. The kind you find in ivory towers.

But they’re not done yet!

In the very next footnote, they add:

Our JavaScript environment includes all functions and constants of ECMAScript's Math object, under the names math_……. For example, ECMAScript's Math.log is available as math_log. The MIT Press web page for this book includes the JavaScript package sicp that provides these and all other JavaScript functions that are considered primitive in the book.

Seriously? They have literally mapped all the Math module’s functions to new names to confuse the JavaScript programmer still further, and to, I guess, hide the ugly Math module. Back to the cellar, hideous Math monstrosity!

I swear you can’t make this shit up.

Why the fuck bother to rewrite SICP in JavaScript if you think that JS is a shit, second-class language and needs “cleaning up” to be considered worthy?

The SICP JS version, especially given its free, online format, could have been a major step forward—updated to be more readable, to take advantage of advances in teaching and learning, to focus more on real-world uses, and to feature a workhorse language such as JavaScript rather than an abstract, academic one such as LISP. It could have opened up SICP to a whole new audience.

Instead it is a regression, incorporating the worst aspects of computer science elitism and arrogance and retaining its opaque, pompous prose while disrespecting the language and community it pretends to embrace.

What a shame. Maybe in another forty years we can try again.