Interview: Jeremy Ashkenas Talks About CoffeeScript

Jeremy Ashkenas is the developer of CoffeeScript, a programming languages that compiles to JavaScript. Imagine JavaScript but with all the whitespace goodness of Python or Ruby.

Ashkenas works for DocumentCloud, a Knight Foundation funded organization, producing several open source projects including backbone.js and Underscore.js. He is a two-time winner of the Apps for America contest for his applications Know Thy Congressman and Quakespotter. He also created Ruby-Processing.

Sponsor

Sample CoffeeScript

Klint Finley: You work for DocumentCloud where you work on several open source projects. What made you decide to create yet another open source project in the form of create CoffeeScript on the side?

Jeremy Ashkenas: I’ve been working with JavaScript-heavy web applications for a while now, and the germ of the idea for something like CoffeeScript had been kicking around in the back of my head for a long time: A language that takes out the frustrating and overly verbose bits of JS, and provides a safer, briefer way to stick to the good parts.

There are many different ways to skin the JavaScript cat. I’d consider both CoffeeScript and Underscore.js to be two different approaches to the same sort of problem.

If the question is “why is CoffeeScript not a DocumentCloud project?” – it’s because I can’t justify using it for the main DocumentCloud development. Imagine trying to hire someone. “You’ll have to learn to use a new language that we made up…”

What is “literate-programming” and how did you get interested in it?

Literate Programming is an old (ancient) idea pioneered by Donald Knuth, who wrote a book with the same title. The idea is to write your source code as if it were an essay for a person to read, instead of a series of instructions for a machine to execute.

This involves trying to craft your code in a rhetorical style: introducing the big ideas, fleshing out the details in logical sections, referencing relevant portions… At the time, code was often written in a specific order of definition, and a large part of Knuth’s work involved “tangling” and “weaving” the code back into machine-order.

For an example of a Knuth-style program, check out his version of Adventure, in Fortran:

But the interesting thing about literate programming, especially these days, is the use of higher-level languages. Code is interesting as a form of written expression because it has a strange dual audience: you write text which is going to be read both by the machine, and the human reader. And you have to find a way to effectively address both at once.

The entire history of programming language evolution has been a story of being able to address the human reader more and more directly and the machine more and more indirectly as computers get faster and we’re able to get farther and farther away from machine code.

Literate programming is the explicit acknowledgement of this dual audience, and takes a stand on it: We’re going to address the human reader as best we can.

What’s next for CoffeeScript now that it’s passed the 1.0 mark?

Hopefully, stability and uptake. CoffeeScript has been very much a community effort. If you look at the contribution graph.

I’d like to see the language settle down, get all the edge cases in the syntax worked out, and see if we can shrink down and polish the compiler (although right now it’s only a bit over 2K lines of code).

For big features in the future, there are exciting things afoot with JavaScript engines providing better support for source-to-JS compiled languages. Mozilla is hoping to provide source-position mapping in a future version of Firefox, which would enable CoffeeScript to be used more directly, and more seamlessly, than at present. For example, line numbers in exceptions would correctly map to the original .coffee.

What advantage would using CoffeeScript give a developer over pure JavaScript?

There are a number of advantages (and disadvantages):

• You get to use a more succinct, consistent syntax – my CoffeeScript ports of JS libs often wind up with around 1/3 less code.
• You’re using a language that embraces the good parts of JavaScript while avoiding the snake pits: there’s no coercive equality, with(), prototype-chain-mucking-about, fall-through-switch-statements, incorrectly chained comparisons … and so on.
• The CoffeeScript you write ends up running as fast as (and often faster than) the JS you would have written.
• The main reason why CoffeeScript ends up being faster for many apps is that you can avoid slow forEach() statements, and get the speed of native for loops for many operations, without having to write it by hand.
• There are also a large number of helpful features in CoffeeScript: correct prototype-based-clases, comprehensions over arrays and objects, bound function literals, safe, lexical variables, destructuring assignment…

And the disadvantages?

The main disadvantage lies in introducing yet another compile step in between you and your JavaScript. We try to mitigate that disadvantage as much as possible by compiling into clean, readable JavaScript. And by providing conveniences like –watch, which can keep an entire directory of CoffeeScript files always up-to-date. Save a .coffee file, refresh the browser, and you’re good to go.

The other disadvantage is the same as using any other minor language: you’re going to have a hard time finding collaborators who already know CoffeeScript. But if you know JavaScript, you can probably pick it up (all of it) in an hour or two.

Do developers need to know JavaScript in order to learn CoffeeScript?

Yes. The underlying semantics of CoffeeScript are the same as JavaScript.
So the same tricks, tips, and techniques largely apply.

Does it play nice with frameworks like JQuery?

Yes. Very nice. Because the semantics are the same, CoffeeScript can interoperate seamlessly with any JavaScript project: Node.js, jQuery, Prototype, Narwhal, MooTools…

And, interestingly, the opposite is also true. Using a library that is written in CoffeeScript, from JavaScript — you would never know that it’s not a JS library, under the hood. This is one of the main differences from other compile-to-JS languages.

What are some of the most interesting projects you’ve seen created in CoffeeScript?

There are a number to browse around here… but my favorites:

• riak-js is a lovely Riak client
• stephank’s orona is an amazing HTML5 port of an old tank game. Full game here.
• Coffee-resque is a nice port of the popular Reque background job system.

What programming languages influenced the design of CoffeeScript?

It’s a bit of Ruby, a dash of Python, and a good part homebrewed. But we’re just talking about syntactic influence here. The actual working logic is 100% JavaScript. JavaScript also being a syntactic influence, naturally.

What is your favorite language besides CoffeeScript?

I really dig JavaScript, I have to say.

Awesome – that’s a wrap! Unless there’s anything else you’d like to say.

Just that it’s an exciting time for JavaScript in general. We have a bit of a perfect storm going on at the moment, with incredibly fast implementations. JavaScript is arguably the fastest mainstream dynamic language in existence, at this point. New server-side implementations in the form of Node.js. Great APIs for application building in the form of HTML5. And the willingness of browser makers to embrace experiments with compile-to-JS languages.

It’s totally not rocket science to try and work on a syntax for an existing language. A lot of folks who haven’t taken compiler classes in college think that trying to do a little language is impossible — and I’d like to disabuse them of that notion. The entire source code of CoffeeScript is annotated with explanations to try and make it easier for newcomers to see how the pieces fit together. I’m always encouraged to see lots of little languages sprouting up.

Discuss