Sutherland and Myer’s On the design of Display Processors, a fun paper from 1963, is about the nature of progress—it often comes in loops.

As it was found that successive improvements to the display processor design lie on a circular path, by making improvements one can return to the original simple design plus one new general purpose computer for each trip around.

Early terminals had one chip to handle everything, and a lot of time was spent handling the graphics. So to speed things up, they offloaded the work to a new special purpose chip—something in the background that reads a bitmap from memory and displayed it. They could make drawing faster by pushing more work onto this chip—if it did points, then they could extend it to draw lines and shapes, and then why not store shapes for drawing, too.

Eventually, the display chip turned into a complete CPU, supporting subroutines, operations and data structures. Things could still be faster—While it was managing shapes and high level drawing, something else could draw the bitmaps. So they built a new special purpose chip–

Gradually the processor became more complex. We were not disturbed by this because computer graphics, after all, are complex. Finally the display processor came to resemble a full-fledged computer with some special graphics features. And then a strange thing happened. We felt compelled to add to the processor a second, subsidiary processor, which, itself, begau to grow in complexity. It was then that we discovered a disturbing truth. Designing a display processor can become a never-ending cyclical process. In fact, we found the process so frustrating that we have come to call it the “wheel of reincarnation.”

I’ve witnessed a similar occurrence—Memcache is introduced to take some of the load off the database. A simple cache to begin with, but eventually someone asks — why can’t we do queries on the cached data — and so a few more operations are added. Slowly but surely the special purpose store bloats until it becomes a database in its own right. Then memcache is introduced to take some of the load off the new database.

It was not until we had traveled around the wheel several times that we realized what was happening. Once we did, we tried to view the whole problem from a broader perspective.

The cache protocol starts simple, but eventually more commands are added as features are desired. In contrast, HTTP caches don’t tend to expand in this way, as the protocol keeps them simple. Maybe If you’re wanting to do more with your cache than store results, you may need a better database rather than a smarter cache–

General computing power, whatever its purpose, should come from the central resources of the system. If these resources should prove inadequate, then it is the system, not the display, that needs more computing power.

One of the reasons they could constrain the power of the display processor was that the physical distance between display and mainframe—client and server—was fixed. Making the display chip powerful didn’t make sense when there was a powerful chip nearby.

If the display must be located far from the main computer, then the problems of data transmission dictate that it have at least a local memory. Likewise, there are arguments for detaching the display from a parent computer that is running a time-shared system.

When you have widely distributed systems, latency means general computing power can’t always come from the central resources. HTTP caches become rather powerful when they’re Edge caches. Sometimes it’s ok to make something more powerful, without being trapped in a loop.

This decision let us finally escape from the wheel of reincarnation.

Maybe all unconstrained subsystems will always become general—in the same way languages will grow until they are turing complete, and programs grow until they can read mail—or they’ll be replaced by more general ones. Or as Rob Pike put it—Writing programs that do one thing and do it well “is dead and gone and the eulogy was delivered by Perl.”

If you find yourself going back and forward, either you don’t have enough constraints, or the constraints keep changing underneath you.

I spent a couple of days in december visiting my Dad. It was quiet and peaceful, just Dad, Myself, and his cats. We spent the evenings sharing the things we had in common—listening to Dad’s obscure music and complaining about our careers.

He talked about ship-building, I talked about building software—The jargon was different, but the people were exactly the same.

Same denial of risks, same castigation of whistleblowers, and the same putting everything off until it explodes. Schedules that reflect the dreams and ambitions of the company, rather than the treachery of a complex system. With no room for failure, each and every fuck up compounds, as the company moves from one artificial crisis to another.

He called it “A conspiracy of optimism.”

Back in 2011, Effective Denial of Service attacks against web application platforms was presented at 28c3—The annual Chaos Computer Club gathering in Germany. The essence of the attack was exploiting how hash tables are used in modern web frameworks.

A hash table is used to store a series of keys that relate to values— usually built using a hash function f, and some buckets, where the function maps a given key to a specific bucket. To lookup a value for a key, you compute the hash of the key, and search the matching bucket. When the function maps two different keys to the same bucket, you have a collision. To handle this, some use a different bucket, or allow buckets to contain multiple key, value pairs. Collisions make operations like lookups and removals much slower.

In the talk, they show that an attacker can craft colliding keys, submit them in a http request, and cause the webserver to dramatically slow down. To prevent this we might think to use a collision resistant hash (i.e a cryptographic hash,where collisions are hard to guess) but in practice they are far slower than the normal hash functions used, and still deterministic—If the attacker knows the hash, they can always brute force it, and brute force can be quite effective. Instead, implementations moved to randomized hash functions. You can thinking of it as a hash function that takes a secret key, and you should not be able to calculate a hash value or a collision without the secret.

This didn’t work out so well—At 29c3 the following year another talk was given Hash-Flooding DOS Reloaded: Attacks and defenses, demonstrating randomized hash functions can still be vulnerable to denial of service attacks. Although the idea was sound—a random value was picked, and used in the hash function, The implementation was poor. Hash functions like CityHash and MurmurHash were vulnerable to a form of differential cryptanalysis—watching the differences introduced by the random value, and derive a way to make these differences cancel each other out. Security, randomness, and cryptography are still very hard to get right.

The talk covers how they translated this analysis into working attacks on a variety of platforms. They also presented a solution too—SipHash. It’s a keyed hash function built around solid, researched cryptographic techniques, designed by experts, that works about as fast as a traditional weak hash function. The home page for SipHash has a wealth of talks, and supporting material.

If you still haven’t had enough crypto, the talk on real world RSA Factorization — FactHacks — makes an excellent followup

Despite my best efforts to warn people about programming, i’m often asked to suggest a good language to start with. I normally suggest a relatively useful language from the outset, and by that I mean something–

• That they can do something useful or fun within their first afternoon
• Their friends know and can help them with
• Relatively easy to install and run or pre-installed
• That doesn’t require spelunking an IDE or learning too many tools
• That is general purpose enough for the projects at hand

So which language is that then?

This usually whittles the contenders down to popular scripting languages—Python, Ruby, JavaScript, Lua or similar. A little more structured than Bash and a lot less effort than a compiled language. To me, the project attempted rather than the language used, is the more important choice. Learning a language should be a side effect of some larger and more interesting goal—It is hard to learn languages for their own merits, without having something to build.

To begin with, think about what you want to create rather than the toolset. Don’t worry about objects and classes too much. Start with logic and flow—if, while, for, and functions—and then worry about data structures and algorithms. Get simple functions working to make fun or useful things happen.

Scripting? Real programmers use C! I want to be a Real programmer!

C is a useful language. Many languages are implemented it it, and many libraries and operating systems are too. Nonetheless, unless C is the only option, I wouldn’t advocate it as a first language—because it is hard to do anything immediately useful with it, in a small amount of time. Advocates argue that “C is character building”. Great job! Suffering is such a fun learning experience!

Even in the grizzly macho world of unix, people learn shell before they learn C. Using C effectively requires much more knowledge of the operating system, as well as data structures. .

I hear Java and C# are also popular in industry, should I learn those first instead? I want to get a Job!

Using C# and Java are difficult for vastly different reasons to C—I’ve been in a class where people were made to chant "public static void main". Using Java and C# well requires a good understanding of objects and classes first, and without it many sprinkle static over their code to make it compile. C# and Java are designed for larger programs, not beginner programs—the learning curve is steep for the basics of procedural programming.

For those languages, a simpler scripting language is available on the runtime, with access to the same libraries. You don’t need to worry about writing larger programs until you’ve written a few small ones first. Java, C# and other heavyweight platforms make better second languages—Where you can invest the time learning the API, rather than fighting an unsympathetic environment

What about mathematics - how much needs to be learned?

Well, I’d say maths and programming are actually quite related, but you need to understand as much mathematics as your program demands—which varies wildly. Not many programs have a high demand of math skills beyond counting. If you can use a spreadsheet, you probably know more than enough to start churning out scripts.

Part of programming is mathematical, not to say that differential geometry is somehow going to be useful, but reasoning about your program requires the same discipline of thought found in mathematics. I’m not saying that programers need to be mathematicians, but programmers /are/ mathematicians. Proofs are programs, innit.

So programs are mathematical but I shouldn’t learn a functional language?

Simply: functional languages aren’t as popular as scripting language. Unless you have a friend who is enthusiastic about them, it can be harder to dive in—often less documentation, a smaller community and less third party libraries. They do make excellent second, third and fourth languages though—You’ll find out the features the mainstream languages will absorb next.

One obvious exception—If you’re going into a computer science course, they make an excellent start. It can be a bit longer before you have something and useful, but Racket and Haskell can be fun too.

What’s the easy way out?

The first programming language you learn will likely be the hardest to learn. Picking something small and fun makes this less of a challenge and more of an adventure. It doesn’t really matter where you start as long as you keep going—keep writing code, keep reading code. Don’t forget to test it either. Once you have one language you’re happy with, picking up a new language is less of a feat, and you’ll pick up new skills on the way.

Coding requires interdisciplinary set of skills—to be able to write fluently, have critical reasoning skills, and exercise engineering dicipline as well as mathematical reasoning. Often overlooked is one of the most vital skills—Domain experience of the problem you are trying to solve.

Programming isn’t just explaining things to the computer but a medium for design, engineering, science, art and play.

Dijkstra is an emminently quotable computer scientst, mostly for his famous lists of uncomfortable truths. Oft repeated is his rallying call against BASIC, most of the time without context–

It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration.

The essay itself was arguing “How do we tell truths that might hurt?”, when commonly accepted problems are shrugged off or avoided. The answer turns out to be rather inflamatory. Dijskstra was so effective at raising his arguments this way that we’re still arguing about them now.

The thing people forget is that programming was substantially different in 1975. Dijkstra railed against Dartmouth Basic—a glorified assembler language. It isn’t the BASIC used today–

• Variables names were one letter long with an optional digit
• Although FOR was present - while loops, break and other niceties were implemented with unrestricted goto.
• Whitespace was optional between expressions.
• Subroutines were available. GOSUB line number and RETURN.
• All parameter passing had to be done with the existing global variables.
• 26 user defined functions could exist FNA-FNZ, which could contain one line of code.
• IF statements were also limited to one line of code.

I could go on about the limitations, but the consequecnes are pretty obvious: It was hard to write readable and understandable code in. The features we take for granted now just weren’t present. It wasn’t until after the article that BASIC began to grow up, into the language people know today.

When you learn your first language, you continue to write programs in that style in other languages (“You can write FORTRAN in any language”). The hardest part of growing as a programmer is not accquiring new knowledge, but unlearning old habits in light of it.

Learning to carefully assemble a large ball of mud doesn’t help you to write structured programs. Even today, it would be easier to teach someone a modern variant of basic if they’d had little or no exposure to its grotesque ancestor. Although some sucessors still have a lot to answer for.

Programming is hard. Making it harder doesn’t help beginners, or experts alike. Dijkstra hated basic, but you would probably hate it too. It is a shame that Dijkstra is most remembered for his vocal criticism rather than his vast contributions to programming, but that is another issue altogether.

If you ask any programmer how you should learn to program, you will get the following answer:

People should learn programming from my mistakes by repeating them exactly, because my mistakes have been refined and polished over the years

Nostalgia, and the way in which the teacher learns best—both have a significant influence on how programming is taught. A cargo cult of learning—do what I do and you will learn what I did.

Much of the discussion of education focuses heavily on “what students must know”, rather than “What do students want to learn, and how do they learn?”. A vital skill for a programmer is a willingness to learn and to explore unaided. Instead of encouraging autodidacticism, we prescribe a series of features, tools and factoids to consume and regurgitate.

Sure, a little guidance and help goes a long way, but many teach in the way that they prefer to learn, rather than working with the student’s preferences. If someone asks you to teach them to program, ask them what they want to create, and then guide them in the right direction, rather than asking them to copy you.

I encourage people to find a sandbox to play in. Be it a 2d environment with a turtle drawing pictures, or a musical environment, or even a browser—somewhere you can add elements and program them, experimenting by changing existing programs. I try to focus on getting them to explain things to me and asking questions, rather than the drudgery of rote exercises. I want the computer to be a tool for learning and exploration, driven by the student.

Why? I must confess that I too am tainted with a nostalgia—for Logo

Logo’s creation is described in Seymour Papert’s book, Mindstorms, in which Logo and Turtle Graphics are used to build a ‘math world’ for students—an environment in which to construct their own rules and problems—leaning by creating, exploring and experimenting in this world. One example from the book is how code helped someone to learn english grammar.

The student in question was struggling with tense, so the teacher suggested she wrote a poetry generator. Working through the code allowed her to internalize the rules they had originally struggled with.

Mindstorms argues that learning is more fun and rewarding when the student is allowed to be creative. Papert isn’t alone, I’ve seen a similar idea espoused in Math education—let the students solve the problem, rather than making them memorise a solution

Creativity doesn’t require originality—when I found the web, I started by taking other peoples JavaScript, HTML and changing things to make things work. Playing with code I didn’t understand to find out how it worked has always been more fun for me than laboriously stepping through a problem in tiny chunks. I learned a lot more from reading other peoples code and changing it, than I’ve learned from writing my own

Despite my nostalgia, I’m not arguing for everyone to learn Logo, or that we start teaching dynamic html, or demanding people program on 8-bit machines in a crazed basic dialect. I’m arguing we should be optimising for fun—back when I learned, I couldn’t share code so easily with my friends, either I had to type it in manually again each time, or find some fragile electronic container to lumber around. Now I can hack up something in JavaScript for the rest of the Internet to play with.