Quote of the week – type systems and unit tests

A type system is the most cost effective unit test you’ll ever have.

Peter Hallam

Peter Hallam was a language designer on the first three versions of C#, then became technical lead for the C# compiler before moving to Google and building the Traceur compiler which compiles JavaScript.next to standard JavaScript. If you want to hear him talk about Traceur checkout this video.

Peter’s a man who knows his type systems – good, bad and ugly.

I saw a nice example of using the type system to prevent bugs when I worked on Pixel Bender at Adobe. Pixel Bender is an image processing toolkit. Images are made up of pixels, however, pixels are not always 1×1 in size, and they are not always square – in particular, video processing often uses rectangular pixels. At the time we started the project we hadn’t come to grips with non-square, non-unit-sized pixels so we started with a single coordinate system where moving right one unit moved you one pixel across, and moving up one unit moved you one pixel up. This pixel coordinate system is not isotropic – one unit on the X axis is not necessarily the same distance as one unit on the Y axis. We wanted to be able to represent rectangular areas of pixels so we created two classes – Position (containing x and y values) and Extent (containing width and height values).

We got away with our pixel coordinate system for quite a long time, however eventually we realized that we needed to have an underlying, isotropic, coordinate system. We called this world coordinates. We converted between pixel coordinates and world coordinates by using the width and height of a single pixel. Since we already had Position and Extent classes we used them for our world coordinate system as well.

Imagine you see a function that takes a Position as an input parameter. Is that Position in world coordinates or pixel coordinates? We instituted some naming conventions. They sort of worked. Mostly. Except when they didn’t. We had plenty of tests, which caught some of the bugs, but working with a Position or an Extent was more fragile than we wanted.

Our solution was to create separate classes for pixel and world coordinates. We ended up with:


The two Position classes were identical apart from their name, as were the two Extent classes. In both cases we just had the simplest possible wrapper around two double values with appropriately named accessor methods. We could have used some template magic to avoid code duplication. We could have used some “clever” macros (and I put “clever” in quotes to indicate my disdain). We actually just wrote separate classes – very simple classes, with some repetition of boilerplate between them. Breaking the normal “don’t repeat yourself” rule seemed justified here. For a little (and it really was a little) more work up front we had a very simple system that served us well. If we had been working with tens or hundreds of different coordinate systems we might have used another method to generate the code, but we only had two, and we were relatively convinced that we were never going to add more than one or two additional coordinate systems (as it turned out we only needed pixel and world coordinates).

By looking at code you knew what coordinate system was in use. When writing new code you could specify what coordinate system it needed its inputs to be in. If you tried to pass a value in the wrong coordinate system to a function the compiler would stop you. The system worked. We made it easier to do it right than to do it wrong – using the type system eliminated a whole class of bugs from our code.

Quote of the week – object oriented vs. functional programming

Object oriented programming makes code understandable by encapsulating moving parts. Functional programming makes code understandable by minimizing moving parts.

Michael Feathers

This week’s quote comes with an article, to be specific, this piece by John Carmack on functional programming. There is plenty to like in the article but two points in particular struck me:

  1. A function doesn’t have to be 100% pure to get many of the benefits of purity. Of course you don’t want to use the fact that it’s not 100% pure as an excuse for making it even less pure either.
  2. A more functional programming style often results in more parameters to a function.

A functional style does lead to more parameters, but as Carmack notes, it is much easier to test the functions in isolation. Also, if a function needs a certain set of data to do its job, it has to obtain that data from somewhere. If the data doesn’t come from the arguments passed in, it either comes from globals, or member variables of a class, and that leads us right into the issues Carmack describes with state – storing it and updating it. There are definitely costs associated with all the options, but I am beginning to think that a couple more parameters on a function might not be the worst thing in the world.

Quote of the week – overloading

overloading n. 1 Semantics Ganging up on a poor signifier until it collapses from excessive signification. 2 OOP Assigning unlikely meaning to well-known operators. Ideally, for maximum confusion, the overloading definitions should be hidden.

Stan Kelly-Bootle The Computer Contradictionary

Sadly, Stan Kelly-Bootle died in April 2014. He was a major figure in the computer world and the folk song world. Obituaries can be found here, here and here.

I could quote Stan Kelly-Bootle infinitely, and when I say “infinitely” I do mean infinitely. The Devil’s DP Dictionary gives the following definition:

recursive adj. See RECURSIVE.

although this was later modified in The Computer Contradictionary to:

recursive adj. while (unclear) { unclear--; See RECURSIVE }

Of course the definition of operator -- is overloaded and hidden.

Unfortunately The Devil’s DP Dictionary and The Computer Contradictionary are both out of print but there are plenty of second hand copies available from Amazon or Alibris.

Quote of the week – design

Without requirements or design, programming is the art of adding bugs to an empty text file.

Louis Srygley

If I were a cynical person I would point out that this quote implies that programming is better with requirements and design, an implication that is too often false. Fortunately I am not a cynical person, so I won’t mention it.

Design of software has always interested me – not just coming up with the design, but also communicating the design and modifying it as the project inevitably evolves. How do you get a design from person A’s head into the heads of persons B-Z?

Quote of the week – quality

Quality is a team issue.

Andrew Hunt and David Thomas The Pragmatic Programmer

I have worked on projects where quality was the sole responsibility of the QA department. I have worked on projects where quality was (in theory) injected during the two weeks before shipping. None of these projects have produced quality code or quality products.

Quote of the week – teaching

People have said you don’t understand something until you’ve taught it in a class. The truth is you don’t understand something until you’ve taught it to a computer, until you’ve been able to program it.

George Forsythe

Most of the quotes I pick are on this blog because I agree with them. George Forsythe was the founder and head of Stanford University’s Computer Science Department so he certainly has standing to comment on teaching methods, but I think that this quote underestimates the usefulness of teaching a class to other people. Teaching a computer is useful, it forces me into many corners that I wouldn’t have to explore and exposes my misconceptions; however teaching a class exposes me to other people’s misconceptions, many of which end up not being misconceptions at all. At the very least, they point me towards a different way of thinking about the problem.

Teach it in a class and teach it to a computer.