Many-to-Many Protocols

My colleague Michael Ilseman shared a design problem with me today, which came down to something like this:

Today, we have a protocol RawRepresentable, which says that “if I have a type X, I can convert it to and from X.RawValue”. You can then make a whole host of types that use Int as the raw value, and indeed that’s how Swift represents enums imported from Objective-C. (Well, those with an NSInteger underlying type, at least.) That makes this, in some sense, a “many-to-one” relation, because many types can have the same one raw value type. But what you can’t do is make a single type have multiple RawValue types—one of them has to claim the name X.RawValue.

The New Kingdom of Nouns

Last time I talked about how algebraic abstractions like “monoid” and “semigroup” didn’t seem to be pulling their weight, despite love from functional programmers. That focused on a practical issue: do these abstractions aid or harm comprehension? Do they make programming easier or harder? (Of course, there’s not a simple answer to this question.)

This time, though, I want to talk about something more exploratory: do we have the right tools to talk about these abstractions? This post is therefore going to be much longer and contain a lot more rambling.

Re: Contempt Culture

Two weeks ago Aurynn Shaw wrote a piece called “Contempt Culture”:

And even before I finished reading it I had a thought:

Oh, this is not the article I expected to be reading.

So here’s the article I thought I was going to read, based on the tweet. A short version, anyway.