{ datagubbe }

datagubbe.se » the cults of ken and kay

The Cults of Ken and Kay

Can - and should - everyone learn to program?

Spring 2021

A couple of nights ago when I was browsing the UNIX v6 sources (as one is prone to do), I came across some peculiar lines of code in the "if" shell command. They look like this:

register int np, i, c;
char *nargv[50], *ncom, *na;
/* -- Snip! -- */
ncom = "/usr/bin/xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx";   
while(c=nargv[0][i])  {
     ncom[9+i++] = c;
ncom[9+i] = '\0';
execv(ncom+4, nargv, np);
execv(ncom, nargv, np);

To call me in any way knowledgeable in the field of C programming would be a gross overstatement, yet I noticed a problem with this code: When constructing ncom, there can be an overflow if any command supplied is longer than 35 characters. (Looking at the code in greater detail suggests it should also be possible to overflow nargv, though it would require quite a lot of arguments.)

This overflow bug might not have manifested itself at all in a system used by a handful of people on a PDP-11, with shallow directory structures and mostly three letter file names. Nevertheless, its existence is interesting.

Tracing the code back as far as possible in the available UNIX source trees, it seems this bug was there from at least v2 and then disappeared when Bourne's sh internalized if in v7. According to Brian W. Kernighan's book "UNIX - A History and Memoir", the first versions of research UNIX were written by a small group of people who regularly reviewed each other's code. According to the same book, Bell Labs seems to have never hired anyone without a university degree and only very rarely someone without a PhD.

From this, we can learn a lot of lessons. A few that come to mind:

Who knows how to program?

I'd like to think that I can program fairly well. Twenty years ago, I also thought I could program, but today I know I didn't - not really. Twenty years from now I'll probably think the same about today. Experience and insight into how little you really know is very humbling.

Both overconfidence and humility is part of the problem with defining programming knowledge: ask fifty different programmers what it means to be able to program and you'll get fifty different answers. Programming can mean anything from doing something simple but fun in Scratch, constructing an advanced spreadsheet, making an interactive web page, producing a first person shooter, hardware interfacing with assembler, or dedicating your life to studying graph theory. It can be deceptively easy and insanely complex at the same time.

Let's for the sake of argument define some base level of programming knowledge: basic Boolean algebra, conditional branching and looping, understanding variables and types such as strings and numbers, using simple data structures such as lists, and perhaps even a bit of recursion. This should get you going in most modern high level languages. Depending on the language and with some understanding of domain-specific API:s, you should for example be able to make an image of a ball move around in a browser window according to arbitrary sets of rules.

One Smalltalk Per Pupil

Alan Curtis Kay is a computer scientist and visionary famous for leading the Xerox PARC team that, in inventing Smalltalk, pioneered both object oriented programming and the modern GUI. Although exceptionally successful as concepts on their own, both were mostly means to an end. Kay's main calling in life is about programming as an everyday tool, an empowering skill that will help people understand the world by letting them process information through controlling the machines we now all use for convenience and communication. As such, everyone should learn it.

Programming in this context could be seen as a lot of things. Spreadsheet software, advanced text editors and UNIX pipelines don't have to be Turing complete to grant users great freedom and power when it comes to processing large sets of data. The former two are even intuitive enough for most people to grasp with very little prerequisite knowledge. Yet, Kay goes further, as evidenced by his writings and work: The GUI and Smalltalk were born alongside a research project in which children living close to the Palo Alto Research Center were taught to program and work with computers.

Not program in the sense of spreadsheets, but program-program: writing and altering application code, constructing things like music and graphics editors. Kay's later efforts in projects such as One Laptop Per Child and Squeak confirms his view of programming as constructing and assembling building blocks to create your own working environment, rather than just working within the confines of a program designed by someone else.

Although computers are now commonplace, Kay's vision has yet to become reality. In 1997, he proclaimed in the title of a lecture that "The Computer Revolution Hasn't Happened Yet". He also, like most programmers who made their bones in the good old days, complains about modern software bloat.

The cult of Kay

I hasten to add that I don't know Kay by any stretch of the word: I know his work and some of his recorded public appearances. Regardless, I can confidently say that he's not a cult leader, nor does he come across as the kind of fellow who aspires to be one - yet his ideas have garnered a cult-like following.

These cultists mostly manifest as various movers and shakers in society furthering the idea that programming should be taught to all children very early on in school. Computers are now irrefutably here to stay and thus programming is an important life skill - and at least currently highly viable on the job market.

Overconfident cultists

The crucial thing the cult of Kay keeps forgetting is that programming, once you've passed a certain level, is hard. That doesn't mean anyone can't learn to program on the level Kay suggests, just that it'll take a lot of effort. This time and energy is something many might want to or even must invest in learning something else.

Making a ball move around the screen using a predefined API isn't the same as parsing large, complex data structures efficiently. Programming language grammar for truly empowering tasks seems to always tend towards the dreaded territory of "do what I mean, not what I say": the user suddenly has to know about how things are stored and accessed in structures that oftentimes can't be "seen" in the same meaningful way a ball moves across the screen or even in how a spreadsheet can present hierarchical, multi-dimensional information. And even if it can be visualized in a satisfactory manner, the manipulation must happen outside of that visualization for it to be automated by programming, rather than manual busywork.

From an educational standpoint, programming can be compared to mathematics. With maths, most people learn, understand and remember the stuff that's really useful in everyday life. Schools teach a bit more than that, so that those with an aptitude for it can prepare for learning even more later on in life.

The things we don't keep practising are forgotten. Even though having studied maths for several hours a week, almost every week of the year for twelve consecutive years, many adults still confuse percentages with percentage points and per mille. Personally, I don't remember when I last had to solve even a single variable equation. Let's just say I wouldn't want to have to do one on the spot during a job interview. (Good news; I just tried doing one and I remembered how.)

Teaching programming to a meaningful level would be an undertaking similar to teaching maths - and for what end result? What would most people remember from their programming classes? Would most keep writing programs if they didn't have to?

The path to modern programming

In maths, it's rarely enough to just know fundamental concepts such as arithmetic. You have to understand when and how to apply them: for example, how to use division to get a percentage. The same goes for programming, but here you also need other prerequisite knowledge depending on what you want to make: musical notation, various concepts of animation, color blending or perhaps statistical analysis. This knowledge must then be translated into something approachable by code - "programmatical thinking", for lack of a better term. This is one of the many hard parts of programming.

Kay and his team at PARC seemed surprised, almost puzzled, by how people struggled with this, leading to Adele Goldberg's invention of what she called design templates. This helped their students reason about the problem at hand rather than immediately diving into typing Smalltalk code. A set of API:s was also constructed utilizing Smalltalk's inheritance. This shielded the would-be hackers from complexity and let them focus more on creative and productive aspects of programming. Such API:s eliminated not only the complexity of certain code but also acted as a stand-in for various domain specific knowledge. Even so, the results weren't nearly as promising as the researchers hoped for.

True to his calling, this didn't cause Kay to give up. He still hasn't; he remains unsatisfied. The Revolution is yet to come and things are getting bloated and complex. Ironically, a lot of the complexity and bloat Kay laments has the same origins as his own desire to to shield people from the hard parts of programming. Inherited API:s and design templates have evolved into massive libraries and rigid OOP design patterns, in use in almost all software written today - for better or worse.

On a more positive note, more kids than ever have better access than ever to tools and information that will let them learn to program if they so desire. There are more programmers around today than ever before. Many of them, whether programming for fun or profit, wouldn't poke C, Assembler or Lisp with a stick. A lot of them - myself included - probably wouldn't be programmers at all if it wasn't for Kay's pioneering work. I'd say that constitutes some level of success, after all.

The cult of Ken

Kenneth Lane Thompson, like Alan Kay, is another pioneer in the field of computer science. He was initially part of the MULTICS effort through Bell Labs, and then went on to create UNIX. Today, he works at Google on the Go programming language. He also, like most programmers who made their bones in the good old days, complains about modern software bloat.

As with Kay, I only know Thompson through his work and writing and, as with Kay, he doesn't strike me as a cult leader. Despite this, his crowning achievement enjoys a following so big and loud they make even the most incessant hollering from other computer cults fade into background noise. The Cult of Kay can be likened to a small gathering of primitive wood spirit worshippers compared to the hordes of UNIX fanatics and the Lovecraftian horrors summoned by their zealotry. I must confess that I am in their midst, though not as deeply entrenched as the most hardcore fundamentalists.

In the beginning, UNIX was a rather small operating system built around ideas of simplicity (not to be confused with ease of use), modularity and frugality. A lot of good ideas came out of Bell Labs and the UNIX team's efforts. A sane approach to file systems, command pipelines, I/O redirection and of course the awk and C programming languages.

While UNIX was designed and built for programmers, the underlying philosophy and approach wasn't that of Alan Kay. It wasn't necessarily elitist in the sense that programming should be kept secret or only taught to a select few, but it was built around the crucial insight that programming is hard. This can be seen in efforts to compartmentalize functionality in order to reduce complexity, creating tools such as lint and designing various domain-specific languages such as regular expressions, awk, shell scripting, troff and dc.

Ironically but quite correctly, UNIX is also known for being almost mysteriously hard to learn. Whenever a syntax can be terse, it is. Why have a three character command name if you can shorten it to two? A lot of the languages and utilities require intimate knowledge of how a computer works on a low level, at least compared to Kay's abstractions and GUI. This can make it seem daunting at first, but to the people who were into computers at the time, such knowledge was assumed commonplace and if you had it, UNIX let you be phenomenally productive.

While Thompson and the UNIX team were visionary in their own right, they were hardcore techies making tech for other hardcore techies. Kay's approach is much more holistic and, well, human, but their goal was ultimately one and the same: to make programming accessible, simple and productive, empowering people to take control of their machines and process information to help understand the world.

UNIX was - and is - a huge success. Kay's contributions are significant to say the least and though I admire his work and ingenuity, I have to say that he has so far been unsuccessful in his quest, such as he himself has formulated it.

I think the success of UNIX in part stems from the cult of Ken having a healthy dose of respect for the complexity of writing programs: Anyone is welcome, but they should know what they're getting into.

Computing as a skill

Kay's vision isn't a bad one. I'm a big champion of user empowerment, the concept of general purpose computers and open systems. But if programming isn't for everyone, how do we make the best of the situation?

Without Kay's GUI I probably wouldn't have gotten into computers as early in life as I did. Abstractions helped keep me motivated when writing my very first programs, because they yield quick results. OOP and design patterns can, when used discerningly, help compartmentalize problems and solutions in an effort to manage complexity.

Without the UNIX approach of terseness and small, domain-specific languages and command pipelines, I wouldn't have learned a lot of the more complex concepts and skills needed to tackle and understand certain problems. Everyday interaction with the UNIX philosophy is, in a sense, its own school of complexity management.

But even before I had ever written any meaningful code, I understood a lot about how a computer works and what can go wrong with one. The way UNIX (and before that, my Amiga) exposed this, rather than shielding me from it, played a huge foundational part in my general approach to technology.

Perhaps we shouldn't start by trying to teach kids how to program. I posit that we should instead teach them how to properly use and understand a computer. Not in the sense of clicking icons to start programs and copy files, but make them really, really understand that...

...and the very real effects that can have on one's life, now that so much of it is spent online. After that they can enroll in a voluntary programming class, if they want to.