Down to the metal

Computer scien­tist Donald Knuth opined in 1974 that art is what­ever we haven’t yet taught a computer to do, and that one way of advancing an art is teaching computers to do more of it.

True, at the end, this removes certain topics from the domain of art and places them within the realm of empir­ical algo­rithmic knowl­edge. (Knuth, for instance, co-created an algo­rithm that finds the optimal line breaks for a para­graph of text, some­thing that type­set­ters had done by eye for hundreds of years.) But along the way, what advances the art is grap­pling with the chal­lenge of teaching what we know to a computer, a machine that Richard Feynman described as “dumb as hell but … goes like mad”.

When we speak of describing what we know to a computer, we are speaking of computer program­ming. There’s more than one kind of computer program­ming, just like there’s more than one kind of writing. For me, what makes program­ming inter­esting is exactly the chal­lenge Knuth describes: taking things that today seem like matters of judg­ment, taste, or opinion, and converting them into tasks a computer can do.

Why? Because the process of teaching is also a process of learning. This is a widely reported side effect of writing a book about a topic: you end up knowing a lot more about the topic than when you started. Like­wise, to be able to teach some­thing to a computer (via program­ming), one first has to under­stand the topic in a much deeper way.

What makes this learning process unusual & inter­esting is that it’s often more exper­i­mental than other forms. Some­times there are books you can read or existing algo­rithms you can study. More often, it’s a process of trial and error, often chasing false leads on the way to a discovery. The 1985 book Struc­ture and Inter­pre­ta­tion of Computer Programs (aka SICP) is maybe my favorite book on program­ming because from the first page it commits to this idea, which it calls “proce­dural epis­te­mology”, a qual­i­ta­tive change in “the way we think and the way we express what we think.”

I spend a certain amount of time each year trying to persuade people to try program­ming—some­times adults, but when­ever I can, teenagers. “Put on some Taylor Swift,” I say, “and let’s talk about the Scheme program­ming language.” Truth­fully, my campaign has not yet won many hearts & minds. (I have managed to foist a few copies of SICP on the unsus­pecting.) But if you think of your­self as a smart person, learning to program will tell you for sure; if you pass that test, program­ming will become one of your favorite activ­i­ties, because it allows you to handle the mate­rial of ideas in a way that is unlike any other medium; and if you are a teenager, it’s going to become a table-stakes skill in many (most?) desir­able job markets of the future.

* * *

Like a lot of program­mers, a big moti­vator for me has always been tool­making: upgrading a certain boring task into the more inter­esting meta-task of writing a program to do the boring task. This, in turn, gives me more time to devote to the parts of the project I care about. Prac­tical Typog­raphy, for example, was made possible by my web-publishing system Pollen. Yes, writing Pollen was a lot of work. But I had already tried to tweeze together Prac­tical Typog­raphy by other means. I’d gotten nowhere. I had to choose: either create a better tool, or give up.

Fonts are, in their way, a tool. But like the federal courts, their juris­dic­tion is limited. You install them on your system. They play their role. But they don’t have any larger partic­i­pa­tion in the overall design, appear­ance, layout, or engi­neering of a docu­ment. For that, we need multi-billion-dollar tech compa­nies.

Ha ha, just kidding, no we don’t. One of my smol­dering projects over a number of years has been Quad, a type­set­ting system that takes an anno­tated text file, lays it out, and outputs a nice PDF. I’d like to publish a book—maybe a lot of books—using Quad. For now it’s missing a few key pieces. In the mean­time, I’ve been using it to generate my font license and FAQ.

But as someone who already knows how to make fonts, having total control of a type­set­ting system raises new & inter­esting possi­bil­i­ties about orches­trating all the pieces to produce better results for less effort. Why shouldn’t the soft­ware do more of the work?

It’s an idea I’ve thought about for a while. But it’s time to see if it will work.

* * *

It’s also a chance for me to circle back to where I started with program­ming: desktop apps.

As a warmup, my first project has been a font editor called Arche­type. It’s a collab­o­ra­tion with the wonderful type designer Antonio Cave­doni. (Antonio is in the process of starting his own type foundry. Before that he worked at Apple, where he had a huge role in designing the San Fran­cisco font that is now their primary corpo­rate & UI font.) If you’ve down­loaded MB Type fonts in 2021, they were made with Arche­type.

Like me, Antonio loves to program his way out of drudgery. He & I also share a love for soft­ware that goes intensely fast and can fill multiple screens. So Arche­type has been designed from the ground up to do just that. It’s a very fast, highly program­mable envi­ron­ment for making fonts.

It’s not clear yet whether Arche­type will become a tool that we share with the public, or a handful of like-minded type designers, or just keep for ourselves. For now, it’s a way of getting some prac­tice using the current gener­a­tion of Mac devel­op­ment tools (including the Swift program­ming language, which has grown on me). It’s also a way of teaching more of what we know about type design to the computer. And in turn, learning more about type design ourselves.