The Universe of Discourse

Sat, 05 Oct 2013

PIGS in SPACE!!!
Today I was at the Pittsburgh Perl Workshop and I gave a talk because that's my favorite part of a workshop, getting to give a talk.

The talk is about Moonpig, the billing system that Rik Signes and I wrote in Perl. Actually it's about Moonpig as little as possible because I didn't think the audience would be interested in the details of the billing system. (They are very interesting, and someone who is actually interested in a billing system, or in a case study of a medium-sized software system, would enjoy a three-hour talk about the financial architecture of Moonpig. But I wasn't sure that person would be at the workshop.) Instead the talk is mostly about the interesting technical underpinnings of Moonpig. Here's the description:

Moonpig is an innovative billing and accounting system that Rik Signes and I worked on between 2010 and 2012, totaling about twenty thousand lines of Perl. It was a success, and that is because Rik and I made a number of very smart decisions along the way, many of which weren't obviously smart at the time.

You don't want to hear about the billing and accounting end of Moonpig, so I will discuss that as little as possible, to establish a context for the clever technical designs we made. The rest of the talk is organized as a series of horrible problems and how we avoided, parried, or mitigated them:

• Times and time zones suck
• Floating-point arithmetic sucks
• It sucks to fix your mangled data after an automated process fails
• Testing a yearlong sequence of events sucks
• It sucks to have your automated test accidentally send a bunch of bogus invoices to the customers
• Rounding errors suck
• Relational databases usually suck
• Modeling objects in the RDB really really sucks
• Perl's garbage collection sucks
• OO inheritance sucks
Moonpig, however, does not suck.

Some of the things I'll talk about will include the design of our web API server and how it played an integral role in the system, our testing strategies, and our idiotically simple (but not simply idiotic) persistent storage solution. An extended digression on our pervasive use of Moose roles will be deferred to the lightning talks session on Sunday.

Much of the design is reusable, and is encapsulated in modules that have been released to CPAN or that are available on GitHub, or both.

I went to sleep too late the night before, slept badly, and woke up at 6:30 and couldn't go back to sleep. I spent an hour wandering around Oakdale looking for a place that served breakfast before 8 AM, and didn't find one. Then I was in a terrible mood. But for this talk, that was just right. I snarled and cursed at all the horrible problems and by the end of the talk I felt pretty good.

Slides are available here. Video may be forthcoming.

Share and enjoy.

[ Addendum 20131217: I wrote up the talk contents in detail and posted them here. ]

[ Addendum 20131217: The video of the talk is available on YouTube, and has been since October, but I forgot to mention it. Unfortunately, the sound quality is poor; I tend to wander around a lot when I talk, and that confuses the microphone. Many thanks to Dan Wright for the video and especially for putting on PPW. ]

Offensive stuff in classes
Many years ago I gave a short talk about the internals of the Perl regex engine. One continuing theme through the class was vomit. I handed out custom-made barf bags before the talk. There's one point in the engine where if the internal compiled format is invalid, the engine dies with the helpful error message Internal urp. I had a slide about that bit of code, illustrated with a picture of two people vomiting. (At least in 2001, that was harder to find on the Internet than you would have thought.)

Shortly before I gave the talk, I got cold feet. I asked a bunch of conference attendees if they thought I should take the picture out. All but one set yes, I should. The one dissenter was Gurusamy Sarathy, at that time the Pumpking, the Perl release manager. "Take it out?" he said incredulously. "Are you crazy?"

I left it in. I don't think it was an error.

I wonder, though, if I would have gotten away with it now. People are a lot more on edge about unprofessional-seeming and potentially offensive conference presenations. They also seem to be more common. When I hear about conference presentations with pictures of porn stars, or "humorous" presentations about projects to "titstare", I wonder where these morlocks came from; I've never seen anything like that at a conference and I would have been surprised and offended to see it ten years ago.

On the other hand, maybe I'm a hypocrite. One year at OSCON I did present a slide that used a still from a porno:

# The Biggest Mistake You Can Make

• I'm going to start big

• What is the biggest mistake you can make when making a conference presentation?

• Forgetting to go to the bathroom beforehand

The porno in question was a full bladder fetish video.

Were there people offended by this then? I don't know; I hope not. Nobody complained, but that doesn't prove anything. I can certainly imagine people finding this extremely offensive today. But I still think it's hilarious. Would I do it again? I don't know, but probably not.

From the same talk, was the illustration I used on a slide about "bullshit". I don't know if that's more or less offensive. On the one hand, the picture is a lot more visually disgusting. There is no mistaking what is happening; in the omoroshi picture you might not realize what is happening. (At least one participant commented on my "clever visual pun", explaining "well, of course she's just bowing". "Huh," I said, "that would have been clever.") On the other hand, if you do take the omoroshi picture at face value, it could be understood as a powerfully misogynist image of the humiliation of a woman by men. On the other other hand, I could have used an identical image that wasn't from an actual porno and it could have been understood the same way. But then I would have had an ironclad defense: No, it's just a picture of a woman standing in a room. But it could be the same picture. So I'm not sure. Regardless, I will apologize to anyone who wants an apology; although I considered the image carefully at the time, I hoped that it would not offend anyone, but nevertheless recognized the possibility and chose to risk offense anyway.

Another conceivably offensive slide image I used once is below:

These are two-headed sperm; it's possible that this is an image of human semen. I can imagine someone complaining bitterly about this. Meng Wong told me once that if anyone ever did, I should soothe them by claiming that it was gorilla semen; then it would be all right. That does seem like it might work, although I'm not sure why it should.

But none of that is really what I wanted to discuss; I was only thinking about it today because because I was writing a new talk in which I discussed the following piece of code:

        #!/usr/bin/perl

use DateTime;
use DateTime::Duration;

my $then = DateTime->new( month => 4, day => 2, year => 1969, hour => 0, minute => 0, second => 0); my$now = DateTime->now();
my $elapsed =$now - $then; print$elapsed->in_units('seconds'), "\n";

This looks like it ought to calculate and print out the number of seconds between midnight 1969-04-02 and the current time. Instead, because of a series of bad decisions by the designers of DateTime::Duration, it calculates that value as a number of months, days, minutes, and nanoseconds, and then prints out the leftover nanoseconds divided by one billion; typically the answer is a number on the order of 30. In this case it's obvious that something peculiar is going on, but in general you might not realize that this code is not doing what you (or anyone else) wants; you might test it on two times with only a few seconds difference, see that it produces the correct answer, and fail to realize that it breaks completely for any interval that crosses a minute boundary.

My first idea was to claim that this code prints out FUCK YOUR MOTHER, suggesting that although the object knows how much time has elapsed, it refuses to tell you, because it is a spiteful and foulmouthed object. But people have pointed out that sometimes kids attend these conference talks and don't want to hear FUCK YOUR MOTHER (or their parents don't want them to hear it) and anyway, FUCK YOUR MOTHER is sexist and I would prefer to offend everyone without resorting to racism or sexism. I don't mind offending people in general, but it is unfair to do it from a position of power, and to direct it against people with less power than I have.

I spent quite a while thinking about this. Before I committed the slides I struck out FUCK YOUR MOTHER and replaced it with UP YOUR NOSE, EPSTEIN (a catchphrase from the 1970s sitcom Welcome Back, Kotter) and then SIT ON IT, CUNNINGHAM (a catchphrase from the 1970s sitcom Happy Days). Both of these, having aired on prime-time network television in the 1970s, can be presumed to be sufficiently innofensive for a conference talk in 2013.

But they didn't seem to be quite what I wanted, and for a while I considered CHINGA A TU MADRE (Mexican slang for FUCK YOUR MOTHER) which has advantages and disadvantages. I think it's funnier if the DateTime::Duration module turns out to be a Spanish-speaking punk. And some of the people who might have been offended won't understand the Spanish. On the other hand, some of the people who might have thought the joke was funny won't understand the Spanish. And the sexism is the same as in English.

A friend suggested that I just go with GO FUCK YOURSELF, but I decided that I could probably find something funnier if I went in a scatalogical direction. Scatology is safer than sex, because sex is a forbidden adult subject, but everybody poops. Four-year-olds can, and do, make poop jokes and find them hilarious.

The first thing I thought of was I'M SHITTING IN YOUR MOUTH which I do think is funny, but perhaps too physically offensive; it's a really unpleasant image.

But Google search for the Mexican version of FUCK YOUR MOTHER had led me to Wikipedia's page on Spanish profanity, which is a gold mine. Reading through it, I knew, as soon as I saw ME CAGO EN LA LECHE, that I'd found the right phrase.

It means "I shit in your milk!"

That seems to me to lie at the perfect intersection of what I want. It displays the program's obnoxiously unhelpful attitude, it should be no more offensive to anyone than to anyone else, and it conjures u pa mental image whose unpleasantness is strongly tempered by its surreality.

[ Addendum: I should mention that this accusation against DateTime::Duration is false, and it would be completely unfair, except that the desired answer here is so perfectly at the center of DateTime::Duration's purported area of expertise, the answer actually given by DateTime::Duration is so utterly and manifestly useless, and there is no way to get it to produce that answer you actually wanted. If you ask me how many seconds have elapsed since April 2, 1969, and I say "43", can't you reasonably claim that I might as well have said "¡Me cago en la leche!"

Mon, 03 Nov 2008

Atypical Typing
I just got back from Nashville, Tennessee, where I delivered a talk at OOPSLA 2008, my first talk as an "invited speaker". This post is a bunch of highly miscellaneous notes about the talk.

If you want to skip the notes and just read the talk, here it is.

### Talk abstract

Many of the shortcomings of Java's type system were addressed by the addition of generics to Java 5.0. Java's generic types are a direct outgrowth of research into strong type systems in languages like SML and Haskell. But the powerful, expressive type systems of research languages like Haskell are capable of feats that exceed the dreams of programmers familiar only with mainstream languages.

In this talk I'll give a brief retrospective on the history of type systems and an introduction to the type system of the Haskell language, including a remarkable example where the Haskell type checker diagnoses an infinite loop bug at compile time.

I did not say in the abstract that the talk was a retread of a talk I gave for the Perl mongers in 1999 titled "Strong Typing Doesn't Have to Suck. Nobody wants to hear that. Still, the talk underwent a major rewrite, for all the obvious reasons.

In 1999, the claim that strong typing does not have to suck was surprising news, and particularly so to Perl Mongers. In 2008, however, this argument has been settled by Java 5, whose type system demonstrates pretty conclusively that strong typing doesn't have to suck. I am not saying that you must like it, and I am not saying that there is no room for improvement. Indeed, it's obvious that the Java 5 type system has room for improvement: if you take the SML type system of 15 years ago, and whack on it with a hammer until it's chipped and dinged all over, you get the Java 5 type system; the SML type system of the early 1990s is ipso facto an improvement. But that type system didn't suck, and neither does Java's.

So I took out the arguments about how static typing didn't have to suck, figuring that most of the OOPSLA audience was already sold on this point, and took a rather different theme: "Look, this ivory-tower geekery turned out to be important and useful, and its current incarnation may turn out to be important and useful in the same way and for the same reasons."

In 1999, I talked about Hindley-Milner type systems, and although it was far from clear at the time that mainstream languages would follow the path blazed by the HM languages, that was exactly what happened. So the HM languages, and Haskell in particular, contained some features of interest, and, had you known then how things would turn out, would have been worth looking at. But Haskell has continued to evolve, and perhaps it still is worth looking at.

Or maybe another way to put it: If the adoption of functional programming ideas into the mainstream took you by surprise, fair enough, because sometimes these things work out and sometimes they don't, and sometimes they get adopted and sometimes they don't. But if it happens again and takes you by surprise again, you're going to look like a dumbass. So start paying attention!

### Haskell types are hard to explain

I spent most of the talk time running through some simple examples of Haskell's type inference algorithm, and finished with a really spectacular example that I first saw in a talk by Andrew R. Koenig at San Antonio USENIX where the type checker detects an infinite-loop bug in a sorting function at compile time. The goal of the 1999 talk was to explain enough of the ML type system that the audience would appreciate this spectacular example. The goal of the 2008 talk was the same, except I wanted to do the examples in Haskell, because Haskell is up-and-coming but ML is down-and-going.

It is a lot easier to explain ML's type system than it is to explain Haskell's. Partly it's because ML is simpler to begin with, but also it's because Haskell is so general and powerful that there are very few simple examples! For example, in SML one can demonstrate:

        (* SML *)
val 3 : int;
val 3.5 : real;

which everyone can understand.

But in Haskell, 3 has the type (Num t) ⇒ t, and 3.5 has the type (Fractional t) ⇒ t. So you can't explain the types of literal numeric constants without first getting into type classes.

The benefit of this, of course, is that you can write 3 + 3.5 in Haskell, and it does the right thing, whereas in ML you get a type error. But it sure does make it a devil to explain.

Similarly, in SML you can demonstrate some simple monomorphic functions:

	  not : bool → bool
real : int → real
sqrt : real → real
floor : real → int

Of these, only not is simple in Haskell:

            not :: Bool → Bool
fromInteger :: (Num a) ⇒ Integer → a    -- analogous to 'real'
sqrt :: (Floating a) ⇒ a → a
floor :: (RealFrac a, Integral b) ⇒ a → b

There are very few monomorphic functions in the Haskell standard prelude.

### Slides

I'm still using the same slide-generation software I used in 1999, which makes me happy. It's a giant pile of horrible hacks, possibly the worst piece of software I've ever written. I'd like to hold it up as an example of "worse is better", but actually I think it only qualifies for "bad is good enough". I should write a blog article about this pile of hacks, just to document it for future generations.

### Conference plenary sessions

This was the first "keynote session" I had been to at a conference in several years. One of the keynote speakers at a conference I attended was such a tedious, bloviating windbag that I walked out and swore I would never attend another conference plenary session. And I kept that promise until last week, when I had to attend, because now I was not only the bloviating windbag behind the lectern, but an oath-breaker to boot. This is the "shameful confession" alluded to on slide 3.

### On the other hand...

One of the highest compliments I've ever received. It says "John McCarthy will be there. Mark Jason Dominus, too." Wow, I'm almost in the same paragraph with John McCarthy.

McCarthy didn't actually make it, unfortunately. But I did get to meet Richard Gabriel and Gregor Kiczales. And Daniel Weinreb, although I didn't know who he was before I met him. But now I'm glad I met Daniel Weinreb. During my talk I digressed to say that anyone who is appalled by Perl's regular expression syntax should take a look at Common Lisp's format feature, which is even more appalling, in much the same way. And Weinreb, who had been sitting in the front row and taking copious notes, announced "I wrote format!".

### More explaining of jokes

As I get better at giving conference talks, the online slides communicate less and less of the amusing part of the content. You might find it interesting to compare the 1999 version of this talk with the 2008 version.

One joke, however, is too amusing to leave out. At the start of the talk, I pretended to have forgotten my slides. "No problem," I said. "All my talks these days are generated automatically by the computer anyway. I'll just rebuild it from scratch." I then displayed this form, which initialliy looked like this:

I then filled out the form appropriately for OOPSLA:

I pushed the button, and poof! Instant slides.

I had the chance to talk to Philip Wadler, one of the designers of Haskell and of the Java generics system, before the talk. I asked him about the history of the generics feature, and he told me the following story: At this point in the talk I repeated an anecdote that Wadler told me. After he and Odersky had done the work on generics in their gj and "Pizza" projects, Odersky was hired by Sun to write the new Java compiler. Odersky thought the generics were a good idea, so he put them into the compiler. At first the Sun folks always ran the compiler with the generics turned off. But they couldn't rip out the generics support completely, because they needed it in the compiler in order to get it to compile its own source code, which Odersky had written with generics. So Sun had to leave the feature in, and eventually they started using it, and eventually they decided they liked it. I related this story in the talk, but it didn't make it onto the slides, so I'm repeating it here.

I had never been to OOPSLA, so I also asked Wadler what the OOPSLA people would want to hear about. He mentioned STM, but since I don't know anything about STM I didn't say anything about it.

### View it online

The slides are online.

[ Addendum 20081031: Thanks to a Max Rabkin for pointing out that Haskell's analogue of real is fromInteger. I don't know why this didn't occur to me, since I mentioned it in the talk. Oh well. ]

Fri, 27 Jul 2007

Conference talk brochure descriptions
I just got back from doing some tutorials at OSCON, which were generally well-received. Sometimes it goes better than other times; this time it went pretty well, I thought, except that I was seven minutes late to the Tuesday morning one, through a tremendous series of fuckups beginning with the conference hotel not being able to find my reservation on Saturday night, continuing with my barely missing two unrelated streetcars on Tuesday morning, and, let's not leave out the most important part, my forgetting that the class started at 8:30 and not at 9:00 until about 8:00.

I've written before about the general worthlessness of the attendee evaluations, so maybe I won't go into detail about them again. What I want to complain about here is the descriptions of the classes that appear in the conference brochure and on the web site.

One of the things that Nat (the program committee chair) and I have commiserated about in the past is that no matter how hard you try to make a clear, concise, accurate description of the class, you are doomed, because people do not use the descriptions in a rational way. For example, suppose I happen to be giving the same class two years in a row. The class title is the same both years. The 250-word description in the brochure and on the web site is word-for-word identical both years. Nevertheless, you can be sure that someone will hand in an evaluation the second year that complains bitterly that the class was a waste of time, because they took the class the year before and there was no new material. I vented about this to Nat once, and the look of exhausted disgust on his face was something to see. Because I only have to read my own stupid evaluations, but Nat has to read all the stupid evaluations, and he probably sees that same idiotic complaint ten times a year.

Here's one I was afraid I'd get this year, and, who knows. It may yet happen. I sent the program committee seven proposals. They accepted three. One was for the Advanced techniques for Parsing class; one for for Higher-Order Perl. There was significant overlap between these two classes; the last third of the Higher-Order Perl class is about higher-order parser combinators, which are the principal subject of the advanced parsing class. This puts me in a difficult position. The program committee has accepted two classes that overlap. I have to deliver the material that I promised in the brochure, which people paid money to hear. I cannot unilaterally eliminate the overlap, say by substituting a different topic into Higher-Order Perl, because then someone in that class might quite rightly complain that they had been promised a section on parsing techniques, had paid for a section on parsing techniques, but had not been delivered a section on parsing techniques. But some people will sign up for both classes, and then will inevitably complain about the overlap, even though it should have been clear from the brochure that the classes would overlap.

The only way out for me is to try to get the program committee to agree beforehand to let me change around one of the classes to remove the overlap, write one-third of a new class, and document the change in the brochure description before it is published. That is a lot of work to do in a short time. Some people write their class slides the night before they give the class. I don't; I take weeks over it, revising extensively, and then I give a practice session, and then I revise again. So the classes overlapped, and I'm sure there were complaints about it that I haven't seen yet.

My favorite complaint of all time was from the guy who took Tricks of the Wizards and then complained that the material was too advanced.

This year I had the opposite problem. I gave a class on Advanced techniques for Parsing, and the following day I read a blog article from someone who had been disappointed that it was insufficiently advanced. This is a fair and legitimate criticism, and deserves a reasonable response. The response is not, however, to change the class content, because I think I have a pretty good idea of how sophisticated the conference attendees are, and of what is useful, and if I made the class a lot more advanced than it is, hardly anyone would understand it. But I did feel bad that this blogger had mistakenly wasted hours in my class and gotten nothing out of it. That should have been avoidable.

The first thing I did was to check the brochure description, to see if perhaps it was misleading, or if it promised extra-advanced material that I then didn't deliver. This sometimes happens. The deadline for proposals is far in advance of the deadline for the class materials themselves. So what happens is that you write up a proposal for a class you think you can do, that people will like, and that will appeal to the program committee, and you send it in. A few months later, it is accepted, and you start work on the class. Then sometimes you discover that even though you proposed a class about A, B, and C, there is only enough time to do A and B properly, and to cover all three in a three-hour class would just be a mess. So you write a class that covers A and B properly, and has an abbreviated discussion of C. But then there will be some people who came to the class specifically for the discussion of C, and who are disappointed. It is a tough problem.

Anyway, I thought this time I had done a reasonably good job of writing a class that actually matched the brochure description. So I wrote to the blogger to ask how the description could have been better: what would I have needed to say in it that would have tipped him off that the class would not have had whatever it was he was looking for?

The answer: nothing. He had not read the description. He attended the class solely because of the title, Advanced techniques for Parsing, and then after two hours figured out that it was not as advanced as he wanted it to be.

Not my fault! Not my fault!