Neil Mix

My good friend Dan Grigsby has a new blog: Mobile Orchard. It’s all about iPhone development. He’s started up a podcast series kicking things off with Hampton Catlin, creator of the iPedia app. Check it out, it’s good stuff. Dan has a keen eye for what developers like and need. I’m looking forward to seeing what Mobile Orchard holds in store.

When I was at The Ajax Experience this past week, a couple different people asked my opinion on ES-Harmony (and the demise of ES4). And then I remembered that my poor blog has been quite lonely lately.

So here’s my thoughts, pretty straightforward: I’m glad to see everyone moving in the same direction. I think ultimately it was the right decision, but I feel a bit disappointed too. My understanding of what happened is that some of the core foundation of the design — namespacing and program units — proved unworkable under extended scrutiny. And without them it was thought that a clean slate with lessons learned would be best. This was a “good” reason for ES4 to fail, and there’s a subtle point in this: the design process worked as intended! Unlike some have claimed, there was no intent to “rush” ES4 to standardization. Instead, there was steady, iterative work using a reference implementation and real-world implementations to gather experience. And in time it was discovered that certain features came at too great a cost. Better to find that out now than later — which is how it’s supposed to work, isn’t it?

I look forward to what ES-Harmony will bring, and ES-3.1 can’t get here soon enough. (As in, the design for it *should* have already been completed. *cough*) I sense some “hardliner” stances may be unfolding with regard to ES-Harmony, which would certainly prove to be a bad thing. I hope I’m mistaken about this.

I’m going to be in Boston starting tomorrow for The Ajax Experience. (I’m speaking on Wednesday…first time…yikes!) If you happen to be there and want to meet up, drop me a line.

It’s been an amazing week.

I’ve been fairly silent lately, largely because I’ve been working on Pandora for the iPhone. Not only has the work been keeping me busy, but we decided to keep a low profile until we were ready to launch. The silence has been tough because there’s just so many great things to say about the application and the iPhone platform.

Last week we finally pulled away the veil, and the response has been outstanding. This is easily the most successful product launch I’ve ever been a part of.

So if you have an iPhone, check out our app. I may be biased, but I think it’s pretty sweet. ;)

And here’s the best part: if you don’t have an iPhone, maybe we’re already available on your existing phone. We’ve been invested in mobile Internet radio for a while now. It’s nice to see that investment pay off.

When is it appropriate to implement a programming language to run in a web page?

I’ve been contemplating this lately as the number of programming-language-in-web-page projects (henceforth referred to as PLIAWPs) has multiplied. I really enjoy language implementations, especially in a language like JavaScript where doing so can be exceedingly concise. So I certainly understand the motivation for writing your own PLIAWP. But is it useful?

On the down side, PLIAWP implementations carry heavy baggage with them:

But it’s not all bad. There are definitely some plusses to building a PLIAWP:

But I didn’t mention useful, now did I.

So when does a PLIAWP emerge graduate from interesting to useful? There’s no easy formula, but here’s a few standards I’m sticking to these days:

A while back I built my very own PLIAWP, plus a few similar experiments since. With a couple years reflection since that time, I find it interesting to consider which PLIAWPs meet my standard of usefulness and which fail. GWT passes, generic Ruby/Python/LISP/whatever retreads fail. John Resig’s fabulous processing.js almost passes (more on that in a second), Narrative JavaScript fails.

That’s right, my own pet project fails my own standard. I started Narrative JavaScript with the intent to build something useful. In the end, it turned out esoteric. It addressed in part each of the above benchmarks, but not strongly enough to warrant the effort required for adopting my little PLIAWP. I’ve since learned new programming techniques to mitigate the problem I set out to solve, such that the burden of the developer-unfriendly PLIAWP world makes Narrative JavaScript untenable for real-world projects.

Does that mean I regret building it? Absolute not! I learned a *ton* about programming, computers, and computation from my failed experiment. And I had fun in the process. It was absolutely worth it, and I hope to try again someday when the demands of fatherhood and a successful startup subside enough to give me a little breathing room. Language implementation is a thrill.

So it was with great joy that I watched John launch his processing.js project. He is a budding (if not already great) master at work, unleashing creativity meshed with engineering know-how. It’s truly great stuff, a pleasure to watch. As stated above, I’m not sure the PLIAWP meets my usefulness standard, but I don’t think that matters. I don’t want to rain on this parade. In time, he and others may realize that processing.js would be better off as a highly-tuned JavaScript API than an in-page DSL. But why hurry to that point. Let’s explore this world a bit longer, push the limits a bit further.

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:

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:

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:

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:

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?