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: