Neil Mix

If you ever take the time to read through grandmaster chess games, you’ll find that once a player obtains a substantial material advantage (takes a rook, bishop, or knight, for example) the other player resigns immediately. While most inexperienced players in this position choose to fight it out, grandmasters know that once there’s a disparity in power, the game is over. Why is this?

To find out, look forward to the endgame. At the start of a game, the loss of a bishop doesn’t represent an overwhelming power differential between players. In the endgame, a bishop advantage is overwhelming.

Let’s give each piece a value representing the destructive power it wields on the board: pawn: 1, knight: 3, bishop: 4, rook: 6, queen: 10, king: 2. Starting a game by removing one player’s bishop yields difference of 4 in power, with a power ratio of 42/46, a difference of about 9.5%. Now let’s say we continue the game exchanging pieces equally between players, down to a king and a pawn for each side, plus the bishop advantage one player started with. The difference in power is still 4, but the ratio is now 3/7, or 230%.

So as the number of pieces on the board decreases, the disparity in power between players grows. Thus if you obtain a power advantage early in a game, your best strategy for the rest of the game is not to play to win, but to tie. In other words, make sure that every piece you lose is matched by an equal loss by your opponent. Taking this to its logical conclusion, you can seek out equal exchanges. Put your pieces on suicide missions, trading pawn for pawn, rook for rook, etc. Such exchanges are pointless tactically, but strategically valuable. Each exchange brings you closer to the endgame where your power differential is overwhelming.

When you employ this “equal exchange” strategy, your opponent’s job is immensely more difficult. Not only must your opponent find a way to win a piece from you (just to break even) while defending against attacks enhanced by your power advantage, but your opponent must also dodge any attempts at self-sacrificing equal exchanges. It’s too much to defend against.

The equal exchange strategy isn’t sexy or exciting. It’s a grind-it-out, lengthy process (especially when your opponent is unaware of what you’re doing). But it works every time, and it’s easy to do.

So why is this post titled Chess and Politics? Because you can draw a direct analogy to the current Democratic presidential primary between Clinton and Obama. The pundits were looking to see if Obama would strike a knockout blow last Tuesday with the Texas and Ohio primaries. He did, but the pundits don’t realize it yet. It’ll take a few weeks to sink in. Here’s why:

1. Texas and Ohio were the only states remaining big enough to provide a significant shift in the difference between delegate counts.
2. The total shift resulting from those primaries was less than 10 delegates.
3. The Democratic party’s super delegates won’t go against the will of the voters. Not this year, not this election.

All this sets up the equal exchange strategy for Obama. All he needs to do is make sure pieces are removed from the board nearly equally for each player the remaining primaries. Each time this happens, Obama’s power relative to Clinton grows.

Obama’s no longer playing to win, he’s playing to tie. And that is much easier to do. Of course anything can happen in politics (which is what the Clinton camp is depending on at this point). But I think it’s fair to say that if Obama isn’t able to get the nomination with his current advantage, then he probably wouldn’t make a good presidential candidate.

I haven’t posted in a while. Rather than list off a litany of lame excuses (why should you care?), I’ll just share one activity that’s taking up some time for me these days:

We’ve already set a new record for snowfall this year. And being of contrarian nature, I choose not to own a snow blower since shoveling is amongst the only exercise I get. (Sure beats sitting at a desk all day every day.)

But this is getting out of hand. By my estimates, I’ve shoveled around 200 cubic yards of snow this winter. That would fill 13 dump trucks, or 5,000 shovel scoops. The neighbor kids have taken to using our snow mounds for sledding.

Only another month or so to go. Next year I’m getting a snow blower.

Buried in this Reuters article is a paragraph stunning in its implications for journalism, even if only by accident:

Kerviel could not be reached for comment. A headshot of him cut from a trading Website showed an earnest-looking young man. At the start of the afternoon, when his identity was revealed, he had 11 friends listed on the facebook.com social website. That number later dropped to four.

I’m speechless. Welcome to the social web?

The title of this article is (of course) referring to the browser DOM. Don’t get me wrong, the DOM abstraction was a great invention. IE4 was incredibly innovative, the progenitor of Ajax as we know it today.

But as the Ajax evolution continues on, I keep waiting for a “killer” UI platform that nudges us back toward the simplicity of HTML markup. Remember that? Back in the early days of the web you wrote server-side “scripts” that generated markup on-the-fly. Some people naively thought that manually generating HTML with C/Perl/whatever was OK. Others realized that you could incorporate read-only processing instructions in the markup, rather than markup in your application code, and thus was born tools like Velocity, TAL, and other such templating systems. It wasn’t hard to see the value of these tools, how much better than the alternative, how much easier than stateful programming.

Eventually the abstractors barged in, tried to change HTML to XML, tried to change templating to XSL. And they had…mixed…success.

And meanwhile we got sick of having to go back to the server and regenerate pages every time our customers did something interesting. We wanted small, nay miniscule, updates that allow us to do more with less. And thus Ajax was born.

But what a diversion! What happened to that simple markup we used to write? The server-side frameworks didn’t have enough time to sort out their differences, to evolve to the right level of simplicity. Yet we’ve already moved on. The clarity of execution flow in generating a web page? Gone. The simplicity of learning curve? Absent.

Am I the only one who yearns to circle back?

Here’s the problem as I see it: the UI I’ve coded, what you see on the screen, is a reflection (some would call it a transformation) of the data sitting in memory in my JavaScript objects. So why is it that every time the data changes I have to go twiddle something in the DOM? Shouldn’t that just happen automagically?

Why should I have to wrap my head around two UI representations, the markup and the DOM? Markup is easy to read but captures a small sliver of the UI gestalt. The DOM captures everything else, but sits in memory. Can’t it all just be markup, so that I don’t have to spend so much time visualizing data structures whose only representation is either in code or in Firebug?

The DOM is hot property, a cool kid these days. So it won’t surprise me if this plea falls on deaf ears. But I believe that the world could use UI that is described rather than commanded, stateless rather than iterative, that puts the V back in MVC.

I can’t help but feel we’re moving inexorably in the wrong direction, bit-by-bit, and no one is noticing.

And so I sit waiting patiently, occasionally scheming…

Dan discussed “flow” recently and made some observations that stunningly mirror my own life. Quoth Dan:

I’d deliberately side-stepped IM and Twitter, but without consciously noticing it, I let my email and blogs reading habits — distractions on their own — to become interrupts…Previously, I’d get to the end of the day and feel unsatisfied. One of the ways I feel satisfied when I’m creating and learning, so I’d go looking for something new to read about in blogland and, before I knew it, it’d be 1:00am.

Dan plans to re-arrange his life so that all of his activities — work or leisure — are broken into uninterrupted chunks. That means scheduling time to check email and read blogs, rather than letting such activities creep in throughout the daily routine.

I’m so sympathetic to this it hurts. But I have a problem: my workday tasks contain empty space. Much of my worktime consists of the following cycle:

1. think
2. write
3. compile
4. test

Steps 3 and 4 are mostly automated, so they don’t require a lot of active engagement. Furthermore, they take time enough that it’s difficult to sit and stare at the screen and wait for them to finish without doing something else. But they’re not long enough to really dig in and engage in other work-related tasks.

So I often fill my time in steps 3 and 4 with activities like emails or a blog reading. (For example, I’m writing this amidst build-and-test cycles.) But I find the context switch to be tiring by day’s end, thus leaving me in what I call “disphoria” — an over-stimulated, partially-connected brain-state that’s productive but unfulfilled and disorienting. Exactly what Dan describes.

So what does one do during these empty mid-task moments? Meditate?

I’ve always thought that there’s a convenient symmetry between generators and Erlang-style processes. So it’s neat to see that Alex Graveley has been exploring Erlang-style “concurrency” in JavaScript by piggy-backing off my generator based “threading” library.

I sometimes wonder what it would take to expand JavaScript generators to become truly concurrent. Maybe something as simple as a “start” method on a generator object:

function myConcurrent(param) {
  yield wasteTime(param);
}

let gen = myConcurrent(someValue);
gen.start();
let result = wasteMoreTime();
result += gen.next();
gen.close();

where start() causes the generator to begin execution concurrently, and next() or send() act like a thread join.

It’s such a small but powerful extension. It seems appealing up-front, but the devil is in the details. What’s the memory model? Much of Erlang’s appeal stems from its shared-nothing semantics. How would you replicate that with JS generators? Enforce pass-by-value? If next() and send() join, then how exactly do we get the Erlang-style message passing going?

Or maybe there’s no enforcement of shared nothing and caveat emptor? But then you need synchronization for shared objects. Blech.

An interesting thought experiment. To be clear, there’s no talk of anything like this (AFAIK) amongst the JavaScript language designers. Just a random Friday daydream.

If it’s a good idea, go ahead and do it. It is much easier to apologize than it is to get permission.

- Admiral Grace Hopper

Auto-updating software is neat. It saves the customer from painful manual updates, and it helps the vendor by keeping people up-to-date with their software.

Unfortunately, the auto-update feature got off to a bad start in UI. Due to mindless follow-the-leader mentality, it’s had a hard time recovering ever since.

Case in point:

While this is an extreme case, it also illustrates a problem that we’ve all had with auto updates, namely how they manage to interrupt at the most inopportune times.

The problem boils down to 2 factors: a) permission, and b) timing. A little forethought solves both problems fairly easily, but bad precedent of previous implementations casts a long shadow.

Programmers often get snagged on the concept of permission. The (non-conscious) line of thought is: we wouldn’t want to disappoint someone, so let’s make sure it’s OK before we proceed. What’s missing is opportunity cost: people like having their chores done for them. By thinking that doing-without-consent is risky, we miss the opportunity to make the customer to be pleased as punch that someone is quietly getting-things-done for them.

Early on in the history of software auto-updates, someone decided that it was very important to interrupt the customer to make sure that they don’t object to having their software updated. Early versions of auto-updates went something like this:

• start the app
• app says, “Updates to your software may be available. Would you like me to go check?”

First off, how lazy! This comes straight from the playbook of how to ruin your career: when a simple but helpful task needs doing, check with your manager before doing anything. He or she will be impressed with the amount of reassurance and micro-management you require.

At some point someone realized, “hey, that’s kind of annoying.” And thus the auto-update question was no longer asked on startup, but instead asked at some random time on some random interval — but the same time and interval each time, so as not to be confusing.

Did you see the bait-and-switch? The problem was with asking too much permission. But “fix” was to change the timing. I quoted the word “fix” because the solution didn’t improve things much. We went from an annoying every-time-I-start-the-app question to an annoying randomly-interrupt-me-in-the-middle-of-my-workday question.

After a while, someone made the startling realization, “hey, we could check for updates automatically!” No doubt someone objected that permission should be asked first, but thankfully the objections were overridden. So now we have: randomly-interrupt-me-when-updates-are-available. Which is better. And this is pretty much state-of-the-art for auto-updates these days.

But we’re not quite there yet, are we?

So what to do?

1. Just grab the update already! Beg forgiveness rather than ask permission.
2. Don’t interrupt me while I’m working! Wait until the next time the app is started, then perform the update and let your customer know what you’ve changed.

So now we’re at: annoying-interruption-on-startup-only-when-updates-have-been-made. But how annoying is the interruption, really? Presumably you’ve got great new features for your customer that they’ll be happy to hear about. Perhaps rather than being annoyed, your customers will feel pleasantly surprised by the gift of new features they’ve received this morning. Your software just made their lives easier, on multiple levels.

Still sound too aggressive, too risky? Consider this: there’s already strong precedent for the auto-update process I described, just not on the desktop. It’s on the web. Websites don’t ask permission before updating the software. (They can’t, really.) In some cases, when the updates are really big, they might let you know about the changes your first time in. (And occasionally they may provide a graceful “downgrade” to the old version if you protest.)

But most of us never really noticed this subtle distinction between desktop and web auto-updates. That’s because we’re too sympathetic to the underlying technology. But when we wipe the technical details away (as we should when designing our UIs), the truly-auto-update isn’t so scary after all, now is it?

Here’s a little something I’ve seen around the web a few times:

What does this mean to you? What pictures form in your head when you see this?

Now before anyone accuses me of being naughty, I can assure you that this is a Safe-For-Work post. The story behind this image is hardly controversial.

If the phrase “rollover for more” seems perfectly innocuous to you, stop for a moment and consider how your grandmother would react if you told her to “rollover for more.” Mmmmmaybe you aught to find a way to reword this.

Brendan has written up an extensive, detailed post making his case for the need for ES4.  It’s a good read.  I think he makes a strong case.

I fear that it may be too nuanced to be consumed and condensed into “sound bytes” appropriate for the political firestorm that is underway. This is not “light” reading.

In other words, it takes time for the gestalt of ES4 to sink in.  If you read the post and find it not to your liking, put it away and come back later. Write some JS code, think about the difficulties you’re facing.  Perhaps some “aha!” moments will ensue. For me, the essence of ES4 didn’t kick in for a long time — several months.  Your mileage may vary.

Doug misspeaks, Brendan responds forcefully, Chris weighs in, Brendan lashes out some more, and Dion naively asks, “can’t we all just get along?”

*sigh*

Ok, here’s what happened according to the record:

• ES4 design starts in October of 2005
• Doug (Yahoo) joins the discussion in June of 2006, is worried about Microsoft’s support
• Pratap (Microsoft) goes on record in July of 2006 saying that ES4 will be in IE after version 7
• Design continues unabated
• Doug and Pratap registers concern about the size of the spec in March of 2007
• An ES 3.1 proposal is made in April of 2007, but work stalls
• A few weeks ago, Doug states that TG1 is “split” on ES4 at the The Ajax Experience conference (a statement that’s not necessarily accurate)
• Some interpret his remarks as saying there’s a secret coalition between Adobe and Microsoft to force ES4 through and co-opt the standards process
• Acrimony erupts

What really happened, near as I can tell (warning, speculation ahead):

• Pratap wasn’t in close communication with his developers and superiors internally at Microsoft early on in the process. Once he finally got feedback internally, he found out that they didn’t like it. Stuck between a rock and a hard place, he tried to work out a compromise resolution in “ES 3.1″, but people further up the chain at Microsoft caught wind of what’s going on in ES4 and put on the brakes. Microsoft went into radio silence until everything spilled out onto the web.
• Brendan sees what’s coming, and knows it’s not good. If Microsoft has put the brakes on ES4, it means they’re going to split off and go in they’re own direction. He’s concerned because it puts the future of web application development in jeopardy. This is looking all-to-familiar to him, so he responds with vigor to try and “rally the troops” to fight an unfair turn against several years of dedicated, hard work. His responses are clearly filled with heartfelt passion.
• Chris’s job is as much political as it is technical. And he’s reeeally good at it. His job is to make sure that Microsoft has a valid stance in the eyes of web developers, even when opposing viewpoints are valid. It’s his job. He may truly believe everything he’s saying; then again, he could be putting up cover for a deeper strategy internally at Microsoft. We can’t know, because he gets paid well to speak well, and he’s good at it.

My thoughts:

• On purely technical grounds, ES4 is an excellent proposal. It is well-engineered, precise, and balanced. (It is also extremely nuanced, which makes it hard to judge at-a-glance. This is not “a new Java.”)
• Brendan’s passion is coming off as wild-eyed fanatacism. This is turning lots of people off. Is this a political, personal, or technical battle to him? It’s hard to tell from the tone of his comments. Now, where’s that middle ground again?
• Chris Wilson is smooth. He’s got a silky smooth voice, and gosh darn it if I don’t just want to be his friend, even if I don’t trust him.
• Chris wants: stability, interoperability, security, and functionality, in that order. Yet after repeated requests to provide specific, detailed, technical reasons why ES4 doesn’t address all four of those priorities (which it does, IMHO), no answer. I have yet to see a single detailed explanation of how ES4 would “break the web.” Not from Chris, Doug, or anyone else at Microsoft. Would love to see such discussion, truly. Send me links if you know of any.
• Abject fear is not constructive criticism, and it’s not a strategy. There has got to be discussion about the flaws of this proposal that goes deeper than “I’m afraid of it.”

And if you think there’s some safe “middle ground,” I can only say: I doubt it. Language design (or at least, *good* language design) takes a long time, and Microsoft hasn’t even started drafting their ideas yet. Even if they truly believe that what they’re doing is the right thing for the web, by forking now they’re damning the web to stalled evolution and non-interoperability for at least the next 5 years, probably longer. (It’ll take 1-2 years to get the forked version out the door, another 1-2 years before any convergence between browsers can happen, and another 1-2 years before there’s significant market share for interoperable code. And that’s best-case.)

So think about that before weighing in against ES4. Do you want the status quo for the next 5+ years? I sure don’t.

In parting I’ll point out: no design will be liked by every developer, and that’s precisely the problem here. Not everyone can get what they think is best in this case. But, without support from all vendors, *no one* will get what they think is best. All vendors participated without reservation in the ES4 design until March of 2007. And even after reservations were spoken, no active participation to resolve the outstanding issues has occurred since. Given that, it hardly seems fair to say that ES4 is attempting to do something that will “break the web.” Quite the opposite.