Down to the metal
Computer scientist Donald Knuth opined in 1974 that art is whatever 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 empirical algorithmic knowledge. (Knuth, for instance, co-created an algorithm that finds the optimal line breaks for a paragraph of text, something that typesetters had done by eye for hundreds of years.) But along the way, what advances the art is grappling with the challenge 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 programming. There’s more than one kind of computer programming, just like there’s more than one kind of writing. For me, what makes programming interesting is exactly the challenge Knuth describes: taking things that today seem like matters of judgment, 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. Likewise, to be able to teach something to a computer (via programming), one first has to understand the topic in a much deeper way.
What makes this learning process unusual & interesting is that it’s often more experimental than other forms. Sometimes there are books you can read or existing algorithms 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 Structure and Interpretation of Computer Programs (aka SICP) is maybe my favorite book on programming because from the first page it commits to this idea, which it calls “procedural epistemology”, a qualitative 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 programming—sometimes adults, but whenever I can, teenagers. “Put on some Taylor Swift,” I say, “and let’s talk about the Scheme programming language.” Truthfully, my campaign has not yet won many hearts & minds. (I have managed to foist a few copies of SICP on the unsuspecting.) But if you think of yourself as a smart person, learning to program will tell you for sure; if you pass that test, programming will become one of your favorite activities, because it allows you to handle the material 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?) desirable job markets of the future.
* * *
Like a lot of programmers, a big motivator for me has always been toolmaking: upgrading a certain boring task into the more interesting 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. Practical Typography, 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 Practical Typography 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 jurisdiction is limited. You install them on your system. They play their role. But they don’t have any larger participation in the overall design, appearance, layout, or engineering of a document. For that, we need multi-billion-dollar tech companies.
Ha ha, just kidding, no we don’t. One of my smoldering projects over a number of years has been Quad, a typesetting system that takes an annotated 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 meantime, 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 typesetting system raises new & interesting possibilities about orchestrating all the pieces to produce better results for less effort. Why shouldn’t the software 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 programming: desktop apps.
As a warmup, my first project has been a font editor called Archetype. It’s a collaboration with the wonderful type designer Antonio Cavedoni. (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 Francisco font that is now their primary corporate & UI font.) If you’ve downloaded MB Type fonts in 2021, they were made with Archetype.
Like me, Antonio loves to program his way out of drudgery. He & I also share a love for software that goes intensely fast and can fill multiple screens. So Archetype has been designed from the ground up to do just that. It’s a very fast, highly programmable environment for making fonts.
It’s not clear yet whether Archetype 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 practice using the current generation of Mac development tools (including the Swift programming 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.