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.

Compile-Time Sort in D

Michael Parker recently wrote a blog post showing how to implement a compile-time quicksort in D after Björn Fahller recently wrote a blog post showing how to implement a compile-time quicksort in C++17. It’s a skillful demonstration that employs D’s powerful compile-time programming capabilities to write code that, while not always useful, is quite concise.

Reading it, of course, the thought that came to my mind was “Surely Nim can do better.”¹

First let’s take a quick look at Michael’s D code:

Unit Testing in Nim and Python

Here’s a snippet of a unittest test case that I wrote in Python some years ago:

class TestClasses(TestCase):

    def setUp(self):
        self.ace_diamonds = Card(Rank.Ace, Suit.DIAMONDS)
        self.king_clubs = Card(Rank.King, Suit.CLUBS)
        self.ace_clubs = Card(Rank.Ace, Suit.CLUBS)

    def test_card(self):
        self.assertGreater(self.ace_diamonds, self.king_clubs)
        self.assertEquals(self.ace_diamonds, self.ace_clubs)

As you might guess, it was testing a class involved in a card game. It should be familiar to most Python programmers; TestClasses is a class inheriting from unittest.TestCase, which defines a method test_card. The test runner of my choice will read the module, instantiate the test case class, and then run any methods beginning with test_. In that method, I set up a few objects and then run some asserts on them.

I’ve been spending a lot of time with the Nim programming language recently. It’s a great language: its principles, roughly, are to achieve the efficiency and speed of C with a much greater level of safety and expressiveness. It also so happens to take a lot of its surface-level syntactic cues from Python, including code structuring through significant whitespace and colons—that plus its emphasis on expressiveness make it very appealing and inviting to a Python programmer (like myself) who wants greater type safety and greater speed in their code.

The Nim for Python Programmers page on the Nim Wiki has a useful overview of some of the most salient differences between Nim and Python for those just diving in. After all, it’s not actually just Python With Types; it’s more like C With All The Features That Make Python So Pleasant (and some more besides). Things like homogeneous arrays/lists, significantly reduced emphasis on object-oriented design, static typing, strings vs. chars—all of those will crop up if you sit down and start typing Python into foo.nim.

I want to spend a little time, however, thinking about some of the more subtle differences between Nim and Python: the things that will crop up after you’ve learned the Nim syntax but are still writing the language with a Pythonic frame of mind.

Types, Classes, and Types

Uncle Bob, noted programming pundit, has written a strange blog post. It’s a litany against, as near as I can tell, a certain attitude around static typing: that the purpose of strong static typing, and by extension programming language features, is to provide a high degree of security against certain classes of programmer errors: uncaught exceptions, unchecked nulls, using Javascript, et cetera.

Bob says:

The question is: Whose job is it to manage that risk? Is it the language’s job? Or is it the programmer’s job.

(It is, per Bob, the programmer’s job.)

Let’s establish a few terms.

Computation is what computers do. And a programming language is a system for expressing computation.

I take it as an article of faith that the value of a programming language is the degree to which the language makes it easier to reason about computation. This is a departure from the implicitly stated value of a programming language in Hague’s article, which is to “reduce the pain of programming.” I think the latter is reducible to the former. But if you don’t say that outright, I think you can miss it. A lot of Hague’s article expresses a sense that he and others are using the wrong programming language; that there are certain languages that are appropriate to use, and others that are inappropriate to use, and that too many people are using the inappropriate ones. That is, it seems that a lot of his dilettantism is driven by a sense of anxiety about his chosen milieu and tools at a point in time.

This is an understandable anxiety, and one I share every time I have to write JavaScript: 1) there is considerable pain and uncertainty, and 2) I have the sense that the language I’m writing in is somewhat to blame.

The issue at hand

When working in Django, one often finds oneself with the following sort of question:

How many records were created (or updated, or posted) today (or yesterday, or last Monday)?

But most of the time, your created_on/updated_on/posted_on column will be a Datetime, and today is not a Datetime—it’s a Date¹. So if you simply query like this:

Let’s begin 225 years ago. In the year 1789 of the conventional Gregorian calendar, widespread crisis and dissent forced the Estates-General to convene in France for the first time in 175 years. Thus began the French Revolution.

60 years after that, in that same nation, the philosopher August Comte proposed a calendar reform known as the Positivist Calendar.

Here Are Some of the Reasons That the Gregorian Calendar is Awful

The kludginess of the commonly used Gregorian Calendar will be immediately apparent to anybody who has had to use it, which population happens to include the majority of persons living in the world today.

Prelude

A year ago I didn’t know what I wanted to do when I grew up.

I had been in the workforce since I came back to New York in 2005. I had never, blessedly, been out of a job for more than a few months, having worked as a temp, then an administrative assistant, before putting in seven years as a computer repair technician. But even within those seven years in a stable job that required at least a modicum of skill, I knew it wasn’t what I wanted to do, and I didn’t know what what I wanted to do was.

I had studied programming in high school, and enjoyed it. But it had fallen away and I’d formed the very sticky opinion that I simply wasn’t very good at it.

Today I deployed gitp, my first Sublime Text plugin.

Git

Let’s start with git. This very popular version control system, beloved by many, backbone of Github, and de facto standard at Hacker School, can do a lot of marvelous things—and one of my favorites is patch mode. Patch mode lets you stage individual portions of your working text for commit, rather than an entire file. I’ll explain what I mean:

Ordinarily, your git workflow might look like this:

In French Canada, according to Pagat.com, there’s a game called Mitaines, which means “Mittens” in French. I’m not sure when I first heard about this game, but it stuck with me. I couldn’t fathom, judging from the rules, how it was played, but I knew that the game consisted of building combinations that were called mittens, gloves, and socks. This struck me as adorable and odd. I couldn’t find any other information about it; if you google “Mitaines card game”, the only results aside from Pagat are pages that seem to derive entirely from Pagat, and earlier works by me, including the stream on Thoughtstreams.io that this article is based on. But Pagat is pretty authoritative so I persist in believing that this game exists.

I don’t know when I first found out about Mitaines, but I first mentioned it on the internet in February 2009. It next comes up for me in August of 2010, but only to say that I had forgotten about it. It wasn’t until late 2012 that I actually went to the trouble of learning how to play the game.

How You Play

I’ll try to establish a basic account of how we play the game. The ‘we’ is important here: I have never been taught this game by a French Canadian, who might have learned it from other French Canadians. I have never played this game with a French Canadian. I barely know any French Canadians. I have indeed never met anybody who has heard of Mitaines before. In other words, I have no acquaintance with anything you could call ‘authentic’ Mitaines.

I’m a fan of 85 Ways to Tie a Tie, by Thomas Fink and Young Mao. It’s an exploration of a mathematical model for necktie knots. I’ll let them explain:

We have developed a mathematical model of tie knots, and provide a map between tie knots and persistent random walks on a triangular lattice.

What this means for the likes of me is that they a) articulated, essentially, the full array of knots it’s possible to tie with a necktie, and b) provided an unambiguous notation for their tying. Thus as additions to the traditional Windsor, Four-in-Hand, Pratt, etc. (all also notatable in the 85 Ways system), they furnished knots like the Plattsburgh and Cavendish.

The Plattsburgh, for instance, can be notated thus:

My first major project at Hacker School is called Abba, the Abbreviation Engine. In order to understand why Abba exists I need to backtrack a little.

The New Abbreviations

Since around 2006 I have written in an alphabetic shorthand that I call (when I have to write about it in places like this) the New Abbreviations. When asked for a snappy one-line I say it’s basically a ‘human-readable non-lossy compression algorithm for text’. It’s also of the same general family as the abbreviationes of the Middle Ages. It looks like this: