I saw a nice presentation from @brmichel at the San Francisco js meetup last night. His talk was entitled "Not JavaScript" and pitched the benefits of the Objective-J language over javascript. Objective-J has been around for a while, but it seems like there's a small resurgence in interest in compiling alternative languages into JavaScript. For the purposes of this post, I'm not talking about projects like pyjamas and GWT that compile exsiting languages into javascript, but new languages that were invented to solve some of the problems in javascript.
It seems like there's this new wave of projects like Objective-J, coffeescript, and lunascript which try to right some of the wrongs of js by inventing new syntax. I have to say that I'm down on this approach, thanks to the hard knocks I took at Laszlo Systems working on a Flex-like language for building rich internet apps called OpenLaszlo. Convincing developers to learn something new is difficult, and the further down the stack you go, the harder it is. Getting someone to adopt a new framework means making them read docs and learn new design patters, but getting them to adopt a new language means using new tools and learning new core semantics. I think that this is just too far to go for most developers, especially when there are solutions like Ruby on Rails that may not be perfect, but are good enough for government work.I suppose you could make the argument that you can forget about developer adoption – if your new language is good for your internal productivity, then it's good. But I would still question whether inventing a new language is the right place to attack most of these problems. I think that when people set off to develop a new language, it's fun yak-shaving adventure, and it seems like it'll only take a couple of months. What's hard to see at the outset is how much infrastructure a programming language requires, even if it's only used internally. Sure, the core developers at a company all use emacs and vim, but eventually you'll hire someone who needs an IDE. Then you'll also need docs, and building doc tools may be the hardest part of designing a language. You'll need your own debugger, and at some point, you'll also need to fix most of the leaky abstractions, where a single line of code compiles into some horribly performing worst-case in the compiled code, because we all know that if it's possible, someone will do it.
But by far the worst thing about new languages is the lack of components. It always killed me to tell Laszlo users that they couldn't really take advantage of the relatively large marketplace for Flash components, and that, later, we couldn't leverage all the work that the Flex team did in creating their widget set. This was hearsay, but I believe it: the crew writing the Flex components was much bigger than the core team. It makes sense: a few super-geeks can spec, develop, and maintain a well-tested and relatively bug-free compiler and minimal tool chain, but it takes an army to get the UI details of things like comboboxes and grids right. These components have two audiences – the end users, who expect them to be performant and intuitive, and the developers who expect them to have consistent, natural, and thin APIs. Of course, you can invent bridges between the new language and the old one (GWT has a hilarious "native code" feature that lets you write inline javascript) but if you do enough of that, what's the point of your fancy new language?
The ironic thing to me is that javascript is one of the most meta-programmable languages out there. You can extend the native types for crying out loud! With the exception of a few advanced features like destructuring bind, most of the good stuff can be implemented right in javascript. Every time I run jsdoc toolkit or use a Java library class, I'm glad to be working with standard languages that have mature tool chains.
[ptw, too lazy to create an account, but wanting to throw in 2p.]
ReplyDeleteAt the time, OpenLaszlo filled a void, so it was not so easy to see the faults you enumerate with the benefit of hindsight. Still, the designers (yourself included) _did_ try to leverage off of standards by basing their language on XML and Javascript. In that sense, OpenLaszlo was not a new language at all and there was reasonable expectation that any standard XML-grokking IDE would work. And Eclipse should have, except that Eclipse + OpenLaszlo + Tomcat + JVM exceeds (still to this day) the maximum VM allotment Windows will permit for a single process. Doh.
Not knocking anything you say, but as cool as Javascript is, it could be better, hence the ES5 and Harmony efforts. There has been some really hard work by those committees that should make the language even better. We might have been misled in trying to anticipate the O-O features that would come in Javascript, but our emulation of them _has_ made our own internal productivity much higher than it could be had we stuck with industry standard Javascript. There is a reason why O-O languages just won't go away, I think.
Hi Tucker. Thanks for dropping by. I didn't mean to denigrate the work we did at Laszlo, and this post makes it sound like we set out to develop a new language at Laszlo. In fact, we used XML and standard JavaScript, at a time when it seemed like the tooling for XML was going to explode. So it didn't feel like we were developing a new language. But I guess I think we found out that as soon as you have source code that can't be compiled/interpreted with a standard tool, you've got a lot of work to do.
ReplyDeleteAll I'm trying to suggest here is that, where possible at least, it's better to extend a runtime using existing syntax than by inventing new syntax. For instance, msjs has a feature that allows you to get all of the free variables for a function. This is obviously not part of the js spec, but it's presented like msjs.context.getFreeVariables(myFunction) and it returns a normal javascript object. I guess I'm also saying that nifty features like destructuring bind and coroutines are cool, but they can be simulated with closures, and their value isn't high enough to break compatibility with an existing language.