Life Codecs @

Ruminations. Reflections. Refractions. Code.

Jul 22, 2012 - how to software dev

Javascript Core Concepts

Alex Russell’s Google I/O 2011 Learning to Love Javascript video is probably the best Javascript core concepts videos I have seen to date. While I still find the boilerplate required to model what other languages have built-in annoying, the elegance and hackery of building sophisticated things from a small, composable featureset is very neat.

I also love that syntactic sugar is acknowledged to be of use to avoid this boilerplate and unnecessary overload of existing keywords. 60000 incompatible ways to do modules has always been one of my pet peeves for something so fundamental. Javascript in this sense has a case of The Lisp Curse. I do understand that essentially the JS people wish to avoid changing syntax for compatibility, however I think at some point this reticence gets a bit much. Given the alternative browser languages coming up, CoffeeScript being the most mainstream, followed by the Dart initiative, I’d say we have hit that point. Admittedly, Dart is somewhat different, apart from syntactic constraints, it is also attempting to make semantic changes for performance optimisation purposes. CoffeeScript is much more about solving the problem at hand.

“De-Sugaring” as discussed, is the way to go to keep the language core small while allowing more syntactic support. Something like CoffeeScript essentially does this — people should still learn the Javascript core, IMO, before learning CoffeeScript to appreciate the elegance of both languages.

More generally, I had an aha-moment when closures were restated as behaviour that hold on to some state — an inversion of how most of us OO-language users think. This fits very well with my renewed understanding of closures as “closing over” a bunch of state — closed over vars do not go out of scope while the closure is alive. That local vars went out of scope once the function/method completed in many languages, in retrospect, has been the main thing that stopped me from fully “getting” closures when I first looked at it. Then again, it is a subtlety that I had failed to fully appreciate even in Java which does have limited closure support via returning class instances from functions that can reference local vars, so long as they are marked final. By implication, the objects referenced by those vars do not go out of scope whilst the class instance returned holding on to them is alive.

Second satori: As stated above, “the elegance and hackery of building sophisticated things from a small, composable featureset is very neat”, but the syntax is annoying — a language with macro facilities (various LISPs), provides both this composable core, and a unified, extensible syntax. Pretty amazing. In case of LISP, non-syntax really. If only I could get used to the gazillion parentheses of LISP.

Somewhat less elegant than macros (but I love the idea nevertheless) is Groovy‘s parser/compiler hooks which essentially allow you to transform your own syntax/constructs into plain ol’ Groovy at various compilation phases of the program. This is how Groovy allows arbitrary DSLs that do not fit its grammar, a famous example being the Spock Testing Framework.