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:

• They don’t integrate into native JavaScript debugging facilities. You have to create your own facilities instead. This is the most often overlooked aspect of creating your own language. Writing a parser and interpreter are only the beginning. In order to use your PLIAWP, developers will need error messages with meaningful line numbers, stack traces, syntax-aware editing, graphical debuggers, etc. These are must have features if you want your PLIAWP to achieve anything better that esoteric status.
• Performance is going to take a hit. If you write an interpreter, you’re looking at an order-of-magnitude slowdown, minimum. If you compile to JavaScript, you’ll do a bit better. But JavaScript’s string-handling facilities vis-a-vis parsing aren’t speedy. Plus, for any language meaningfully different from JavaScript, there’ll be a performance tax trying to fit your language’s runtime into the JavaScript runtime.
• JavaScript is already a powerful language. What does your language do that JavaScript can’t? Is it really worth forcing developers to learn a new syntax or runtime while giving up the comfort of their existing developer tools?

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

• It’s fun.
• It expands the shared knowledge of what’s possible on the web, pushing the limits of what we know how to do.
• It’s incredibly educational.
• Did I mention that it’s fun?

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:

1. The PLIAWP must be significantly different from JavaScript. (Think Java versus Haskell different.) While nice syntax has its appeal, that’s not enough to justify the overhead of a full language implementation.
2. A program written in the PLIAWP must not be trivially convertible into a JavaScript program. (A different way of stating the above point.)
3. The PLIAWP must solve a specific problem that JavaScript doesn’t solve easily. (If the term “Domain-Specific Language” is coming to mind right now, that’s no coincidence.)
4. The PLIAWP must be developer-friendly, or at least clearly on the path to developer friendliness.

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.

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.

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.

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?

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…

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 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.

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?

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.

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.