structured javascript

Structure
© Salem Eames

I just listened to the Jon Udell podcast interview with John Lam, which was quite interesting. Highly recommended. I do, of course, have a bone to pick.

At 9:52, the conversation turns to talk about JavaScript. John Lam says JavaScript is "a very difficult language for programming in the medium or the large and by medium and large I'm going to say applications which exceed 5,000 to 10,000 lines of code. Once my JavaScript gets up to that, I have a really hard time maintaining that stuff because modularity is definitely one of the things that isn't really all that well thought out in the JavaScript language. Which is much better in languages like Ruby and Python."

Now, John is certainly correct that JavaScript lacks language level modularity features like namespaces, packages, and class definitions. Typically, a 'class' is defined by creating a constructor function and adding methods to it by adding functions to the constructor's prototype. Packages and namespaces are defined as a top-level objects with the top-level package segment, with a field defined for the next package segment, and then recursing through the remainder of the package segments.

Class definition by running plain old code.

Some JavaScript libraries like YUI and dojo actually do have some code and conventions around defining such things.

So, note that. No language level modularity features like a 'package' and 'class' keyword. It's all dynamic. And perhaps some conventions provided by libraries you happen to be using.

Which is quite similiar to Smalltalk. There are no 'language level' features for defining classes. There is no 'class' keyword. Instead, to define a new class, I'd go into a class browser, and fill in a template like:

    Number subclass: #Fraction
        instanceVariableNames: 'numerator denominator'
        classVariableNames: ''
        poolDictionaries: ''	

This is a class definition. However, literally, it's a message send. A message sent to a class (Number) to create a subclass (Fraction) with two instance variables (numerator and denominator).

I don't recall anyone who ever bothered to learn Smalltalk having made claims that it wasn't modular. So I don't think having language level modularity features is a neccessity for making the language usage modular.

My reference to Smalltalk isn't entirely spurious given the recent news of Dan Ingall's Project Flair. As Tom Waits would 'sing' ... "What's he building in there?".

This leads me to a number of questions:

• Could we build a set of conventions around package/namespace/class/method definition that would be usable in a number of different contexts? IDEs, live class browsers, etc.

• What would it mean to build 'images' of code and data in JavaScript? By image I don't mean a .gif file, I mean a collected set of code and data serialized into one or more files. An 'executable unit' for a language interpreter.

• Could we get these things to work with the rather crude code injection apparatus we currently have for web applications (<script src=...>)?

• In the unspecified future, we'll have declarative language features in JavaScript. If you'd like to get a taste for what this might look like, right now, look no further than ActionScript 3 from Adobe. Do we want this? Do we need this?

• WWSD - What Would Self Do? Self is probably the best known prototype-based language. It would be interesting to go back and look at some of the Self stuff; it's been years for me.

intrinsic qualities

quality sky
© Bruce Turner

A couple of meta-programming links for you, from Ward and Kent, and a slightly related topic I recently ran into.

From Ward, a blog post titled 'Is "Agile" Too Easy?'. While Ward ends up talking about agile, what I found more interesting was the general concept of "the essence".

From Kent, a movie of a talk he gave titled "Ease at Work". I'm 100% certain I've never sat down and watched one hour straight of YouTube, till I watched this. When starting the last segment, I realized I should have watched it via the wii instead. Next time.

Both Ward and Kent are discussing some of the intrinsic qualities and mind-states of programmers. Interesting stuff. The kind of stuff we all know, but never really think about too much.

I ran into another one of these intrinsic qualities the other night when I attended the panel "Breaking Into the Game Industry" presented by the Triangle chapter of the IGDA. The triangle, as it turns out, is home to a large number of game companies. Three triangle-based game company execs were answering questions on how to get a job in the game industry. One meme that kept coming up, was that the companies were looking for people with "passion". They don't just want good technical people, they want good technical people who will love their job. Like the "essence", passion is something "we know when we see it", Gladwell-ian Blink style. Gaming companies have the luxury of making this an absolute requirement due to the large number of applicants they get to select from, compared to the rest of the software industry.

Regarding "essence" and "passion", these are obviously qualities we desire to have in our own jobs. But they also seemed like the distillation of the qualities we look for in potential new hires, in co-ops who may become new hires eventually, and future team-mates, whether you're adding to your team, or shopping for a new team to work with. Good, simple memes to keep in mind.

Kent's talk provides what I would consider some suggestions on maintaining the passion, or more pessimistically, dealing with passion-killing work habits, for those times when you don't happen to be on the 'genius' side of the roller coaster.