...the marriage of the poem and music here certainly bears the stamp of emotional significance, but seeks to go deeper than the invention, to its very structure.

Pierre Boulez, on his Improvisations on Mallarmé, originally quoted in the program to his 1974 "rug concert"

A few weeks ago we saw a performance of the piece described in that quotation. You can sample a different performance here. It's striking on many fronts. It's aggressively modern; it's the kind of modernism that people who don't have much time for avant-garde art music would find indistinguishable from a parody of avant-garde art music. It's plinky-plonky, has no real pulse, and the vocal line swoops around without no concessions at all to traditional expectations of melody.

I didn't like it; I think that when I was in high school I would have liked the idea of it very much, because I was intensely concerned with whatever was most modern, and I could have probably allowed my attraction to its position vis-a-vis the canon to sufficiently influence my experience of the performance itself.

Since August I've been designing a written shorthand for English (more on which here). This is a design problem, and the artifact is the system itself: the set of rules that make certain written signs meaningful. The practitioner has to balance the attributes of the system by making a series of planning choices: increasing the number of distinct signs, for example, increases the expressive power of the system at the expense of thematic unity and simplicity. Specific syntactic constructions--for instance: let's decree that doubling the length of a stroke denotes the presence of an r-sound--might make it possible for a user to record a bit of dictation more quickly (the most basic function of any shorthand, arguably), but might require too much practice, or be too hard to read back.

The output of the work, then, is the system. I've just started to read Beyond Pure Reason, by Boris Gasparov, and Saussure's basic bicameral division of language feels relevant here: the work is la langue, the system of rules that make up the system prior to the act of writing.

There is also la parole: the individual instances of the system in the world. Or, let's say: instances of writing which are intelligible according to the rules of the system. If la langue is Smith Shorthand, then la parole is the page of notes that I took in my most recent 1:1. That's under consideration, too. The marks made have to be pleasing to the eye or else the work is a failure. Not for the most heartless utilitarian, maybe, but we have emerged from that period of history during which shorthand existed solely in the realm of the useful.

This is important. If it were 1910 I might still be engaged in such an undertaking, but the spirit of it would be entirely otherwise. In 1910 shorthand was an economic necessity: it was a tool relied upon by secretaries and journalists to do their work. As such there was a bustling trade in the design and marketing of new shorthand systems, dozens of often-thoroughly-eccentric men competing to build a better mousetrap (I can't help but notice how outdated that locution is now, too. Have we reached a global optimum in mousetraps?).

I turned 40 last month.

This was just before the election, so the waves of dread and discomfort that accompanied that milestone were immediately replaced with different waves of dread and discomfort. Nevertheless, I had sat with it for at least a little while and one of the things I decided was that I wanted to ensure that I live a sufficiently creative life.

I felt very sure about that, but I'm not entirely sure what it means. I know, for instance, that it doesn't necessarily mean that I need to be a professional writer. I have seen enough professional artists to know that the median creative profession consists largely of graft, angling, compromise, and unanswered, unsolicited submissions. My current job consists of mostly the same, but most of my Slack messages eventually get answered.

I've always had normal day jobs, even as I've always thought of myself as one kind of a creative or another. Until ten years ago, I was very satisfied that all of my creative efforts would be strictly extracurricular: when I was in my twenties I wrote doggerel, and then graduated to making rather good music with my band. My job was completely undemanding.

In late 2019, I wrote about a new shorthand system I was designing. Less than six months later it was in the bin, neither fully developed, nor learned, nor used. Instead I embarked on four-or-so happy years of consistent use of Henry Sweet’s Current Phonetic Shorthand, which was my regular choice for any and all note-taking.

A few times over that period I tried to learn Oliver’s Stenoscript, purely for fun: there were a few qualities it had that weren’t present in Current and which I wanted to try my hand at.

Stenoscript never stuck. There are some things I like about it but I find it basically too fiddly: there are too many distinctions that are meaningful in its signal space but far too fine for me to comfortably make when writing by hand.

In Combinatory Programming, we attempt to provide motivating examples for the various combinators identified as useful to everyday programmers.

The aim of that piece was to extract the basic concept of combinators from as much its context as possible, and present certain particularly useful combinators as higher-order functions callable inside of nearly any programming language, applicable to most styles of programming. In practice, of course, tacit forms—the style of programming that we can use combinator functions to achieve—are more at home in certain languages and certain contexts than others, and compose most nicely with other features of a programming environment: plentiful pure, first-class functions; partial application; and terse combinator syntax, among others.

In this supplement, we can dig deeper into some of those examples; where useful, expressing the same logic in multiple styles, and at times commenting on features of different styles or languages and the effects they produce.

identity

To The Programmer

A combinator is a kind of function. Specifically, it’s a function that applies its arguments—and only its arguments—to each other in a particular shape and order. The number of possible shapes is of course infinite; but in practice a few fairly simple shapes crop up more often than others, and those specific shapes have names. A very few of them are so common and so famous that their names and shapes are already well-known to programmers; because they’re well-known there are often functions available in standard libraries that apply their arguments in shapes corresponding to them. Function composition is one: many languages available today recognize that f(g(x)) is a sufficiently common pattern, and that, for instance, writing xs.map(x => f(g(x))) is sufficiently common, inconvenient, and at times error-prone, that they allow the programmer to write xs.map(compose(f, g)) instead.

It therefore seems worthwhile to push at the boundaries of this set of well-known shapes; are there others that crop up often enough that we can give them names, and in so doing abstract away some of the repetitive guts of our code?

The Field

Let’s take a standard, classical haiku:

furu ike ya
kawazu tobikomu
mizu no oto¹

—Matsuo Bashō

There are a few formal characteristics that make a haiku. We’ll focus on the most famous one: its moraic structure², the counting of 5, 7, 5 morae, respectively, in the three lines of the poem.

We are now fifteen days into the year of Ulti.

For the calendar year, we will play and discuss Ulti to the near-exclusion of other card games. The point, at the highest level, is twofold:

1. To inject into English-speaking a culture a new, credible alternative to bridge;
2. In my personal games-playing, to go deep rather than broad: to develop expertise and intimate knowledge of a single game rather than trying out many as they strike my fancy.

I’ll tell you about my plan for 2023: I want to embark on a year-long media campaign to plant the seeds of a new card game in Anglophone culture.

Previously I spoke about my ambivalence towards bridge. But that ambivalence comes along with a realization: just because I think bridge isn’t a very fun game, it’s not enough to claim that there are superior options out there and leave it at that. A game makes its way into people’s lives and habits on the strength of their encounters with it in their culture and society, just as much its formal characteristics. If we want a compelling alternative to suggest to people wanting a fun way to spend time with each other, it can’t just be a good game; it has to have a real, full, multifaceted cultural presence. There needs to be writing about it, discourse, Youtube videos. Podcasts.

Well, let’s get started, then.

Every so often, someone who knows I’m avid card-player says, “Oh, I’ve always wanted to learn bridge!” I generally feel that I’ve got to dissuade them, or at least prepare them for what’s ahead: bridge, despite its prominence in English-speaking culture, is a weird game, with an awful lot of its meat located in an odd information-theoretic metagame played out in the auction, with players making increasingly fine estimations of the cards everyone else is holding according to the often elaborate and often entirely artificial sequence of bids for the contract that will hold back on the actual field of play. And bridge culture is sometimes monomaniacally focused on this single facet of the game, going to great lengths to ensure that no information about one’s holdings can possibly leak into the auction except by the bids, and bridge players can be a bit persnickety about just this point. Not that any of this is necessarily to its detriment, but it’s not really what many of us have in mind after we’ve seen a few civilized games played over cocktails in the room next to the one with the murder in it on Poirot.¹

I take it as given that these people aren’t necessarily interested in bridge as a card game, set against all other card games. That is, I don’t think they’re telling me, “I’ve always meant to pick up a 4-hander Whist derivative with fixed partnerships and a granular auction!” So what I’d like to do is say: you don’t want to learn bridge. You want to learn Slovenian Tarok (or Vira, or Scopone, or Skat). I’d like to tell them about a game that will hold their interest and reward skill and deep, strategic thinking just as much as bridge will, but that is more fun, and whose players are friendlier.

We know: that’s not how things work. I’m guessing that my friends have conceived an interest in bridge in this manner:

As native English speakers, born and raised in the United States, Canada, or United Kingdom, they played no card games growing up, or relatively simple ones. They might have played chess, but chess is extremely hard to play casually, and few of us got in at the right angle to get devoted to it. In the US we have a handful of relatively weak or localized cards traditions: Euchre, Spades, and gin might be the biggest ones. If they grew up in a few specific subcultures they might have played one of these games with their friends and family, but it wasn’t the sort of thing that made it outside the bubble. Otherwise they might have played something with a grandparent—a tradition that might even persist within the family—but again, it wasn’t a practice that translated to their larger community. By young adulthood, it’s quite likely that my friends encountered poker and had at least a few late, fun nights with it. To this day poker is by far the most prominent card game in America (though its ubiquity in the mid-aughts now seems like a fever dream), but it doesn’t really work in the same way. When you play poker you’re making a series of wagers against your opponents, with the cards as a series of randomized outcomes to bet on. It’s hard (not impossible, but hard) to have a good time unless there’s actual money at stake, and that means that it can never be a pastime in the same way that other games can be.

I recently watched Conrad Barski’s video introducing zek, a program he wrote to take Zettelkasten-style notes on the command line.

This is the perfect spur to a programming project: another, already perfectly fine, program that does almost what you want but not exactly. In my case, I was intrigued by the idea of a Zettelkasten-style note-taking app on the command line, but the whole line-editor approach seemed to me to be a bridge too far. So of course I started thinking about how I’d write my own.

I came up with an idea that I like, and that is extremely simple, deferring as much as possible to my text editor, and could conceivably be written as a single shell script calling widely-available tools.

I thought about it during a couple showers, and then I wrote a Pantagruel spec for what I came up with. I reproduce that here.

Array logic operates by a fill algorithm. Fill the ds with the smaller rank to the be the same shape as the ds with the larger.

I recently released—so to speak—a new project that has occupied the last several weeks of my free time: a calculator program, called EC.

I decided to build it for a few reasons. Probably the first reason is that it seemed to be a good use-case for the project I had been working on for the prior few weeks: Fugue, an object system for the Janet programming language. I had settled on the basic approach and feature set, and built a little proof of concept, but obviously if I was going to herald this as the spiritual successor to CLOS it would behoove me to put it through its paces more substantially.

A little desk calculator struck me as a nice, mid-sized project, with enough potential for object-orientation that it could potentially benefit from what Fugue offers. It’s quite difficult to think of useful software to write; it’s much easier to think of useful software libraries, that will help other people make useful software.

Above is a sample of Offenbacher Schrift, a style of handwriting designed by the type designer (and, regrettably, enthusiastic German nationalist), Rudolf Koch. Offenbacher Schrift was arguably the final incarnation of the venerable German handwriting style known as Kurrent, a tradition particular to German-speaking areas for hundreds of years, up until the Nazis fucked it up in some historically interesting ways. It’s closely related also to Sütterlin, which was the dominant form of Kurrent in its final flowering.

One of the attractive and interesting qualities of the Kurrent scripts, especially in comparison to English cursive, is their abhorrence of re-crossing and overlapping lines. For instance, the lower-case c: in English cursive, the pen, starting from the lower-left, slopes up to the top part of the c, and then doubles back along the same line to make the bottom part. This is studiously avoided in the Sütterlinschrift, which opts for the single minim.

It’s also this quality that is responsible for Offenbacher’s most extravagant peculiarities. There’s a lot that’s attractive about it (I’m someone who also has a lot of difficulty with those parts of the letter that have to cross over each other; when writing in cursive, I usually pick up the pen and start again when I have to write an a, c, d, g—in other words, when I have to cross from the bottom left to the upper right in order to start a letter), but unmodified, Kurrent is a little too eccentric to the Anglophone eye.

For the past month and a half or so, I’ve been working on a new software system for playing card games online. If you’d like to follow along it’s being hosted on sourcehut.

The idea came to me when I was talking with a friend who shares two notable characteristics with me: 1) he is a computer programmer; 2) he’s an enthusiast of obscure traditional card games. He was implementing a new card game on Board Game Arena, which is more or less the best that you can currently do if you want to build a new card game that can be played online and don’t want to implement the entire site from scratch. It’s a generic board games/card games site which has a “studio” feature, where developers can upload their own logic which describes a new game. It’s also, from where I sit, a pretty poor experience: you need to write your game in PHP, and you need to upload it by FTP. It’s a little antiquated, in other words.

Hearing about the developer experience I had the sudden inspiration of a site that worked on the Slack installable apps model instead: one that exposed the generic bones of interaction with a deck of cards, but where you as the developer wrote a simple JSON API to describe the actual game, and installed the game simply by pointing the site at your callback URL. In other words, you could write the game itself in whatever language you liked, and only had to spin up a new web server rather than using anyone’s crufty old library.

I called it Tamerlane, being the first word that popped into my head. The viability and suitability of this model as a product aside¹, I thought I’d go into some detail about how I’ve been building it.

Card-playing, as a pastime, depends on the ability of people to gather freely, in close quarters, and handle the same objects in turn. It is not, however, utterly reliant. Playing cards together can migrate to Zoom; it just takes a bit of legwork.

Generally speaking, when it comes to choice of medium, there are two main options: on the one hand there are online a few different generic card or board game engines, where players can all join a room and manipulate some set of objects (say, a deck of cards and a few score counters). You only need a few primitives to simulate pretty much any card game in this way: the ability to draw cards, turn them over, split them into piles, and bring them into a player’s hand. On the other hand, there are websites or native apps that directly simulate some specific game: a Poker app, a Euchre app, et cetera. These expose to the player the actions of the game itself, as well as encode its rules; for instance, they will prevent a player from playing an illegal card.

After a bit of experimentation, I strongly prefer the latter. The promise of the former is lovely and it’s nice to have something to fall back to, but it will almost always be an order of magnitude faster and more fluid to play a dedicated app than to manipulate on-screen objects as though they were cards.

In general, what one looks for is speed, fluidity, and unobtrusiveness. Even if, in general, computer games benefit from a degree of interface richness and delight, in this case we do not expect to dedicate any more attention to the actual interface than we must. To replicate a weekly dinner table card game, we’ll be on Zoom or Facetime, and if we have two monitors we’d like to have our opponents’ faces in video on the other screen; so as we select games to play we’ll be looking for a system that exposes the mechanics of the game to us with a minimum of fuss.

Henry Sweet’s Current Shorthand¹ is a historical curiosity twice over: once because very few people today need to learn shorthand at all or even know what it is; twice because as shorthands go, it’s completely obscure. I learned about it because the surprisingly active and enjoyable Shorthand Subreddit is populated by people who seem to really enjoy spelunking in digital archives for self-published books from the late 19th century, the heyday of shorthand, when there was actual money in designing and publicising a shorthand system of one’s own.

Nevertheless, insofar as one is already interested in learning a shorthand², it’s quite worth taking a look at. I think it has a combination of qualities that make it very recommendable:

• it is efficient, compressing quite a bit of writing into a small number of strokes;
• it is (relatively) cursive, visually and mechanically resembling longhand writing more than simple ellipses or geometrical shapes;
• by means of the second fact, it is, visually, fairly resistent to ambiguity (I’ve talked about this before).

It’s also got some marks against it. In addition to being very complex (or at least involved, or at least deep), it is doubly inaccessible: once because the only extant text that I know about is a scanned PDF of Sweet’s own handwritten (!) manual from 1892, and twice due to the fact that the manual is, frankly, not well-laid out.

I The New Abbreviations

Thus far I’ve designed and used three shorthands. The first was an alphabetic, orthographic shorthand, which I’ve written about in more detail elsewhere: The New Abbreviations. It originated as a project to correct my handwriting, which was crabbed, ugly, and above all, inconsistent.

It ended around 2017. Ultimately, I hit the limit of what you could do as long as you insisted on block lettering and preserving spelling exactly; the character set continued to increase in size as I came up with new glyphs to abbreviate certain combinations. At an aesthetic level, my one-time aversion to cursive had dissipated over the years; I was more interested in cursive forms (at the above link, you can compare the first image with the second to see how my own writing grew more cursive) and thus more tolerant of those schools of proper shorthand.

Having not set out to learn shorthand, after all, I had never had much motivation to learn a whole shorthand system. But my interest in other forms started percolating a little and so I decided to look around at what there was.

Friends, I am now at least in this respect a rare breed: an Elixir programmer who has never written Ruby.

I was never a professional Erlang programmer. I cut my teeth on Python and began working in Python, but Erlang was the language I learned after that and the one that I looked for excuses to write in (in addition to Nim, which would come a little later, but which I would also be able to finagle into production at MakeSpace).

So here was my impression of Elixir for the first several years of my passing acquaintance with it: it’s Erlang with Ruby syntax. I had never ended up writing any Ruby, and I was already happy with Erlang and its syntax. So I had a fairly simplistic understanding of the Elixir language and the roots of its popularity and it didn’t seem that there was anything of value to me.

For better or worse, the first thing that many people mention when Erlang comes up is that the syntax is unfamiliar and confusing; at the very least it’s controversial (I love it). Ruby, on the other hand, is vastly more popular than Erlang. So there’s a significant population that finds Erlang syntax eccentric and Ruby conventional and pleasing.

Effectively speaking, I’ve always been a Vim user. When I got my first shell account, I started with Vim (In the Paleozoic, Mesozoic and Cenozoic ages of vi, vim and neovim, I came of age somewhere in the late Jurassic): my first CS teacher had studied at MIT and so was a dyed-in-the-wool LISP hacker; accordingly, he set up a Linux server in the back of the server closet at my high school, gave me a shell account, and introduced me to emacs. By that point I already found myself inclined to the left-hand side of the dichotomy between what felt like the lightness and agility of Vim (shorter startup times, fewer keypresses) and the power and flexibility of Emacs.

Last year, around this time, I got a Linux laptop. At the time my motivations—at least the ones apparent to me—were primarily practical and maybe a little political: a long-time Mac user, I was now doing enough debugging of applications running on Linux servers that it seemed sensible to reduce the number of differences between my local and production development environments; plus Apple had just released their new MacBooks without the escape key, and that whole thing felt like a bridge too far at the time.