Monday, May 07, 2007

structured javascript

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:

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.

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.