Raw Meat is a quoteblog by Aaron Swartz.

Originalist Indexicals

From the Scalia-Posner fight:

As an example of originalism, Scalia said the death penalty was not covered by the U.S. Constitution’s prohibition against cruel and unusual punishment. At the time that clause was adopted, he said, the death penalty was a standard punishment for a felony. If people want to ban it, they must amend the Constitution or vote to abolish it at the state level, he said.

This doesn’t seem to be a claim about originalism, but a claim about indexicals. The Bill of Rights also says “No Soldier shall, in time of peace be quartered in any house, without the consent of the Owner”. Imagine, after the Constitution was ratified, I purchased an old Revolutionary War barracks and made it into my house. Does Scalia believe that the government can quarter soldiers there because at the time the third amendment was adopted that was a standard place to quarter soldiers? Is the only way to fix this to amend the Constitution?

This seems ridiculous. Clearly by “any house”, the Constitution does not mean “any house existing at the time this Constitution is ratified”. So why does Scalia think “cruel and unusual punishment” means “what’s considered to be cruel and unusual punishment at the time this Constitution is ratified”? What matters is that it’s a house now and that it’s cruel and unusual now, since now is when the law is being enforced.

Updates: Let’s say, for the sake of argument, that “unusual” means “not habitually done” and house means “building inhabited by a family” both then and now. Then the meaning has not changed, there is no issue of original meaning to be recovered here. What has changed is the extension: there are different places in the world that meet the description “building inhabited by a family” and different acts that meet the description “not habitually done”. Both my imaginary house and the death penalty weren’t in the extension when the Constitution was ratified, but they clearly are now.

(Of course, it’s also possible that the ratifiers were mistaken: the death penalty was equally “cruel and unusual” then as it is now and they just didn’t realize it. It’s also possible they were weak: it was cruel and unusual then but they kept doing it because the laws weren’t properly enforced.)

Julian Sanchez (via Twitter) argues I’m making a type/token confusion. So instead of talking about that particular barracks-turned-house, let’s talk about a class of houses. Imagine when the Constitution was ratified nobody lived in caves and now a lot of people do (it’s a hipster thing). Obviously the entire type of “caves” was not considered to be in the extension of “house” when the Constitution was written, but it clearly is now. I think it’s clear the third amendment would apply to people who live in caves, even though it obviously wouldn’t apply to your cave when the Constitution was ratified.

The simple function call

In his post, “The Plain Old Function Call,” Vinicius Gomes compares these two lines of code:

# version 1
choose('color', ['red', 'black', 'green'], 'ie7')

# version 2
choose('color').from('red', 'black', 'green').ignore('ie7').any

In Python, at least, you can always provide names for your parameters, so we can rewrite his first idea:

# version 1b
choose('color', from=['red', 'black', 'green'], ignore='ie7')

Gomes’ argument is that version 2 reads better, but I don’t see it. Version 1b has the square brackets, but version 2 has extra parentheses. Version 2 also has the weird .any at the end (I’m actually not sure what it’s supposed to do or indicate).

So I dispute Gomes’ first premise: I find it hard to believe version 2 is significantly more readable than version 1b.

But this just avoids his larger point: that we shouldn’t sacrifice readability for ease-of-implementation. Anyone who’s familiar with my work knows I heartily agree — this is the slogan of my own web framework, web.py. But I think Gomes (and the larger tradition in which he writes) has a problematically narrow view of readability.

Take this bit of Perl poetry:

my $dear = "friends" .  
while (<i am gone>) {}  
do { $give_me_a_call=  
"on";  
my $cell = "+00 0000000000";  

The poem is perfectly intelligible as English; it’s just some standard English phrases with some very weird punctuation. Reading it as an English document reveals:

my dear friends  
while i am gone  
do give me a call  
on  
my cell +00 0000000000

But it’s not English; it’s Perl. And reading it as Perl reveals utter nonsense. Take just the first line:

set the variable "dear" to the string "friends"

This doesn’t mean anything (the variable isn’t used elsewhere in the program); it’s purely there because it looks good to English speakers. But this isn’t English; it’s Perl.

A good programmer does not simply read the code as English. They build a model of it in their head and try to figure out what it’s doing. That’s impossible to do with this bit of Perl, because what it’s doing is not at all the same as what it’s saying.

And the same is true of Gomes’ version 2: What is the object choose is returning? And from? To understand the code, you need to know the implementation details of choose — and, as Gomes admits, the implentation details of choose in version 2 are unusual and difficult. How does forcing someone reading the code to understand unusual and difficult things make the code easier to maintain?

Compare this to a sample of web.py code:

class hello:
    def GET(self, name="world"):
        return 'Hello, ' + name + '!'

This code here is perfectly easy to read — but as Python, not as English. We’re creating a class with a method (GET) with an optional argument (name). What it says in English is exactly the same as what it says in Python. Gomes claims his version 2 “requires less mental mapping between the computational representation and the real world thing.” I don’t think that’s true there, but it’s certainly true here.

Rob Pike tells a story from when pairing with Ken Thompson. When they hit a bug, Rob would dig into the code, “examining stack traces, sticking in print statements, invoking a debugger, and so on. But Ken would just stand and think” for a bit, before announcing “I know what’s wrong.”

Ken was building a mental model of the code and when something broke it was an error in the model. By thinking about how that problem could happen, he’d intuit where the model was wrong or where our code must not be satisfying the model.

I’m with Ken — I don’t think you can be a great programmer unless you can build a model of the software in your head. But this is precisely what today’s magical frameworks make it so hard to do. It’s next to impossible to build a model in your head of how a Rails program works — Rails calls random pieces of code at random times while doing all sorts of different things behind the scenes. The result is code that reads very well — but as English, not as code. If you try to understand what it’s doing, rather than just what it says, it’s next to impossible without some very deep engagement with the Rails internals. Under those conditions, you’re not a programmer — you’re a prisoner.

How the NYC Subway Should Work

I wrote a little bit about this after visiting San Francisco but spending time in New York has made it even clearer.

Right now the New York City Subway has a series of train lines (named A, B, C, 1, 2, 3, and so on) which each make a different combination of stops.

Sometimes construction or accidents or other things require trains on one line to make an abnormal series of stops. This leads to philosophical paradoxes like “This is an F train running on the N line and making all N stops.” (If it’s on the N line making N stops then how is it an F train?)

Some lines are express versions of other lines (e.g. the 2 makes a strict subset of 1 stops for most of Manhattan) but during peak times some lines also “go express”, skipping stops they would otherwise make. During late nights, sometimes the reverse happens.

All of this is very confusing to the novice traveller. But it could all be made very simple with just one change: name groups of stops, not groups of trains.

Right now you take a 2 train to Chambers St. The train only has one affiliation (to the 2 line) but the stop is affiliated with many lines (it is served by the 1, 2, and 3).

I would reverse this. The stop now just has one affiliation (let’s call it X), while the train can have many (it might be making X, Y, and K stops).

Now if I want to go to Chambers St., I just look at the map and note it is an X stop and then get on any X-stop-making train. If the train is only making X stops, it’s obviously going to be faster than one making X, Y, and K stops. If it is no longer making X stops due to construction, I know I need to adjust. If I’m telling a friend to meet me, I just say “find an X train” instead of “take a 1, 2, or 3 train”.

Further, right now situations like “this train makes 4 stops in the Bronx but 5 stops in Brooklyn” are very confusing (the 4 and 5 make the same stops in Manhattan) but often happen due to vagaries of traffic, etc. Under this system they wouldn’t even be an issue: normally you’d run X-Y-K trains but today you’d be running X-Y-P trains as well.

I can’t see any disadvantages to the system, so I think naming the lines this way was simply a mistake, caused by the fact that the MTA must dig physical tunnels between stops (and thus it seems plausible to name the trains after them) even though passengers only care about the stations.