Linus Torvalds recently wrote a long rant rejecting a patch. Read it now.

Fellow Mozillian Nick Nethercote commented on that rant. Now read that.

I began commenting on Nick’s post, but my thoughts spiraled. And I’ve been pondering this awhile, in the context of Linus and other topics. So I made it a full-blown post.

Ranting is sometimes funny

Linus’s rants are entertaining, in a certain sense: much the same sense that makes us laugh at a teacher’s statement (to a student, if an odd one) in Billy Madison:

What you’ve just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul.

We’re entertained not because we approve of the teacher’s (or Linus’s) rants. We laugh because they’re creative. (Linus’s rants are creative, if not screenwriter-creative.) The flame can be an art form, even to flame war participants. My college dorm mailing list had regular flame wars (sometimes instigated or continued by regular trolls). I hated flame wars as a freshman. But eventually I grew to appreciate the art of the flame. In utter seriousness, that learning process was a valuable part of my college education, as it’s been for others.

(Yes, Billy Madison is low-brow humor. So are Linus’s flames, as entertainment. Not all humor must be high-brow.)

Even funny ranting is sometimes bad behavior

We also sometimes laugh because the behavior’s bad. (Humor’s core, I think, is a contradiction between expectation and reality. I highly recommend Stranger in a Strange Land for, among other things, its meditations on the nature of humor.) That’s one reason we laugh at the Billy Madison teacher-student interaction (allowing for its fictionality), and at Linus.

But somewhat pace Nick, I absolutely cannot equate laughing, or being entertained, with approval or celebration. This and this don’t celebrate ISIS, no matter ISIS appalls us. Naming Linus’s mail an “epic rant” doesn’t celebrate it. It’s just a description of five hundred over-the-top words when fewer words and less drama would have been better (as Nick observes). (At least one place calling the rant “epic” also linked this ironically-abusive decrial.)

Linux thrives despite Linus’s behavior, not because of it

Many of Linus’s rants are unacceptable. (I’ve seen a few that were overheated but not abusive.) Many developers weather them. But some developers have left the Linux community in response, when they wouldn’t have for gentler criticism. That’s a problem.

Linus gets away with bad behavior because: he’s abusive just infrequently enough; Linux has unusually high technical barriers to entry; it’s indispensable to many companies; and those companies fund development no matter Linus’s behavior. Linux led by Linus would have died already, absent these considerations. Linux is one of very, very few projects that can survive Linus’s abusiveness.

Linus is still very smart, and his rants can be right

I often recognize reasonable technical criticism beneath Linus’s rants. Regarding this patch, Linus is right. The proposed changes are harder to read than his suggestion — I’d reject them, too. I don’t agree with every Linus rant. But it’s normal to sometimes disagree even with smart developers.

What’s not normal, is being required to sift through abuse for usable feedback. It’s a skill worth having. If you can weather excess criticism from a coworker having an off day, you’ll be more productive. But it still shouldn’t be necessary (let alone routine), especially not for new open source contributors.

Conclusion

Linus is really, really smart. Because of that, and because Linux is really valuable, Linus unfortunately can keep being Linus. Barring a strongly-backed fork, nothing will change.

During at least five of the passengers’ phone calls, information was shared about the attacks that had occurred earlier that morning at the World Trade Center. Five calls described the intent of passengers and surviving crew members to revolt against the hijackers. According to one call, they voted on whether to rush the terrorists in an attempt to retake the plane. They decided, and acted.

At 9:57, the passenger assault began. Several passengers had terminated phone calls with loved ones in order to join the revolt. One of the callers ended her message as follows: “Everyone’s running up to first class. I’ve got to go. Bye.”

The cockpit voice recorder captured the sounds of the passenger assault muffled by the intervening cockpit door. Some family members who listened to the recording report that they can hear the voice of a loved one among the din. We cannot identify whose voices can be heard. But the assault was sustained.

In response, Jarrah immediately began to roll the airplane to the left and right, attempting to knock the passengers off balance. At 9:58:57, Jarrah told another hijacker in the cockpit to block the door. Jarrah continued to roll the airplane sharply left and right, but the assault continued. At 9:59:52, Jarrah changed tactics and pitched the nose of the airplane up and down to disrupt the assault.The recorder captured the sounds of loud thumps, crashes, shouts, and breaking glasses and plates. At 10:00:03, Jarrah stabilized the airplane.

Five seconds later, Jarrah asked,“Is that it? Shall we finish it off?” A hijacker responded, “No. Not yet. When they all come, we finish it off.” The sounds of fighting continued outside the cockpit. Again, Jarrah pitched the nose of the aircraft up and down. At 10:00:26, a passenger in the background said, “In the cockpit. If we don’t we’ll die!” Sixteen seconds later, a passenger yelled, “Roll it!” Jarrah stopped the violent maneuvers at about 10:01:00 and said, “Allah is the greatest! Allah is the greatest!” He then asked another hijacker in the cockpit, “Is that it? I mean, shall we put it down?” to which the other replied, “Yes, put it in it, and pull it down.”

The passengers continued their assault and at 10:02:23, a hijacker said, “Pull it down! Pull it down!” The hijackers remained at the controls but must have judged that the passengers were only seconds from overcoming them. The airplane headed down; the control wheel was turned hard to the right. The airplane rolled onto its back, and one of the hijackers began shouting “Allah is the greatest. Allah is the greatest.” With the sounds of the passenger counterattack continuing, the aircraft plowed into an empty field in Shanksville, Pennsylvania, at 580 miles per hour, about 20 minutes’ flying time from Washington, D.C.

Jarrah’s objective was to crash his airliner into symbols of the American Republic, the Capitol or the White House. He was defeated by the alerted, unarmed passengers of United 93.

Destructuring in JavaScript

One new feature in JavaScript, introduced in ECMAScript 6 (formally ECMAScript 2015, but it’ll always be ES6 in our hearts), is destructuring. Destructuring is syntactic sugar for assigning sub-values within a single value — nested properties, iteration results, &c., to arbitrary depths — to a set of locations (names, properties, &c.).

// Declarations
var [a, b] = [1, 2]; // a = 1, b = 2
var { x: c, y: d } = { x: 42, y: 17 }; // c = 42, d = 17

function f([z]) { return z; }
print(f([8675309])); // 8675309


// Assignments
[b, f.prop] = [3, 15]; // b = 3, f.prop = 15
({ p: d } = { p: 33 }); // d = 33

function Point(x, y) { this.x = x; this.y = y; }

// Nesting's copacetic, too.
// a = 2, b = 4, c = 8, d = 16
[{ x: a, y: b }, [c, d]] = [new Point(2, 4), [8, 16]];

Ambiguities in the parsing of destructuring

One wrinkle to destructuring is its ambiguity: reading start to finish, is a “destructuring pattern” instead a literal? Until any succeeding = is observed, it’s impossible to know. And for object destructuring patterns, could the “pattern” just be a block statement? (A block statement is a list of statements inside {}, e.g. many loop bodies.)

How ES6 handles the potential parser ambiguities in destructuring

ES6 says an apparent “pattern” could be any of these possibilities: the only way to know is to completely parse the expression/statement. There are more elegant and less elegant ways to do this, although in the end they amount to the same thing.

Object destructuring patterns present somewhat less ambiguity than array patterns. In expression context, { may begin an object literal or an object destructuring pattern (just as [ does for arrays, mutatis mutandis). But in statement context, { since the dawn of JavaScript only begins a block statement, never an object literal — and now, never an object destructuring pattern.

How then to write object destructuring pattern assignments not in expression context? For some time SpiderMonkey has allowed destructuring patterns to be parenthesized, incidentally eliminating this ambiguity. But ES6 chose another path. In ES6 destructuring patterns must not be parenthesized, at any level of nesting within the pattern. And in declarative destructuring patterns (but not in destructuring assignments), declaration names also must not be parenthesized.

SpiderMonkey now adheres to ES6 in requiring no parentheses around destructuring patterns

As of several hours ago on mozilla-inbound, SpiderMonkey conforms to ES6’s parsing requirements for destructuring, with respect to parenthesization. These examples are all now syntax errors:

// Declarations
var [(a)] = [1]; // BAD, a parenthesized
var { x: (c) } = {}; // BAD, c parenthesized
var { o: ({ p: p }) } = { o: { p: 2 } }; // BAD, nested pattern parenthesized

function f([(z)]) { return z; } // BAD, z parenthesized

// Top level
({ p: a }) = { p: 42 }; // BAD, pattern parenthesized
([a]) = [5]; // BAD, pattern parenthesized

// Nested
[({ p: a }), { x: c }] = [{}, {}]; // BAD, nested pattern parenthesized

Non-array/object patterns in destructuring assignments, outside of declarations, can still be parenthesized:

// Assignments
[(b)] = [3]; // OK: parentheses allowed around non-pattern in a non-declaration assignment
({ p: (d) } = {}); // OK: ditto
[(parseInt.prop)] = [3]; // OK: parseInt.prop not a pattern, assigns parseInt.prop = 3

Conclusion

These changes shouldn’t much disrupt anyone writing JS. Parentheses around array patterns are unnecessary and are easily removed. For object patterns, instead of parenthesizing the object pattern, parenthesize the whole assignment. No big deal!

// Assignments
([b]) = [3]; // BAD: parentheses around array pattern
[b] = [3]; // GOOD

({ p: d }) = { p: 2 }; // BAD: parentheses around object pattern
({ p: d } = { p: 2 }); // GOOD

One step forward for SpiderMonkey standards compliance!

Last time I gave my last pre-opinion thoughts on the Texas specialty license plate case, Walker v. Texas Division, Sons of Confederate Veterans, whose oral argument I attended in March. The other case I saw that day, San Francisco v. Sheehan, was recently decided. Today I discuss the opinions in that case.

Ninth Circuit overturned, film at 11

My dismissive suggestion that San Francisco would win because Ninth Circuit and qualified immunity was on target. The Court ruled, 6-2, that the officers should receive qualified immunity — giving the win to San Francisco.

The Americans with Disabilities Act and accommodating the disabled

Recall that Justice Scalia and others alleged that San Francisco had improperly changed its argument from the time it got the Supreme Court to hear the case, to when it presented its formal argument. San Francisco initially argued that the Americans with Disabilities Act categorically didn’t require officers to accommodate armed and violent suspects who are disabled. But then later it argued that the ADA didn’t apply specifically to Sheehan, because she had posed a “direct threat”.

Every justice agreed that San Francisco’s tactics precluded the Court from deciding whether the ADA applied to armed and violent disabled suspects. So that’s still an open question awaiting a case properly presenting it.

Disposing of the rest of the case

But then what happens to the case and its remaining questions, if the ADA question is dismissed? The six-justice majority decided that the officers deserved qualified immunity. Justice Scalia, joined by Justice Kagan, argued that San Francisco shouldn’t be given a win for “snookering” the Court, when the Court wouldn’t have answered the qualified immunity question if presented alone. Instead the Court should have dismissed the entire case, leaving San Francisco to its loss in the Ninth Circuit.

Thoughts

I previously wasn’t entirely certain that San Francisco had changed its argument. But in light of the Court’s unanimous agreement on the matter, and in light of other commentary, it seems clear that it did.

I wasn’t aware the Court could dismiss “half” a case; that seems reasonable for the ADA question. For the remainder of the case, I think I lean toward Scalia’s and Kagan’s view. It’s unfair to parties in cases to allow one side to make an argument, then not be held to that argument come decision time. But I didn’t trace the majority’s cites far enough to conclude that its position was definitely wrong, so count my agreement with Scalia and Kagan as only tentative.

Next time, discussion of the ultimate opinion in Walker v. Texas Division, Sons of Confederate Veterans. The case is still pending, so I can’t yet say when that post might be ready.