Neil Mix

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:

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

This entry was posted on Tuesday, May 20th, 2008 at 12:01 am and is filed under Engineering, JavaScript.