Adventures in ActionScript

I've been a professional programmer all of my adult life. In the past, I have used a succession of FORTRAN/Algol-derived procedural languages (BASIC,Pascal,C,C++) to accomplish my work, with occasional forays into Assembly and more exotic territory, e.g. Prolog, LISP, and FORTH. Most of what I have written could be characterized as filters, that is, programs or modules which accept a single well-defined input and create a single well-defined output. This lead me to the point where I wrote the ActionScript code generator for Adobe LiveMotion 2.0. A compiler (of which the code generator is a critical component) is definitely "the mother of all filters". I definitely enjoyed the work, but once LiveMotion 2.0 shipped, Adobe decided to lay off the team, and as it turns out, that was the last time I did traditional programming work.

Now I am working for a startup called Applied Messaging Corporation, where I was hired primarily on the basis of the ActionScript knowledge I acquired by writing the code generator at Adobe. Applied Messaging is building a networked enterprise-level application using a very wide set of technologies, and Flash MX is one of them. I am now part of a team which is building a rich client interface for the product in Flash and ActionScript. I've spent about eight months there now, and it's given me a unique perspective on using ActionScript on a daily basis to build a real application.

Macromedia has been positioning Flash MX as a development platform for some time now, and their story gets better with each new release. However, they're not really there yet.

To a Designer, trained in art, photography, or video production, Flash is a fantastic if tempermental tool, and ActionScript is a revelation. In its traditional application sphere of interactive animations, Flash and ActionScript do a wonderful job, especially among its target audience. I've seen people do fantastic things with Flash. Take Eric Dolecki, for example. He's one of my coworkers, he's a wizard with Flash, and he's a great example of Flash's target audience.

ActionScript was designed (like JavaScript, its source) to be a scripting language. When you want to do something simple, with a minimum of fussy overhead, it's a great tool. ActionScript is easy to learn and easy to use in projects without a lot of complexity. The language is essentially untyped and the scoping rules are liberal, meaning it isn't terribly picky about how you declare or use your variables. The runtime is garbage collected, so the programmer doesn't have to worry too much about the details of allocating and cleaning up objects. It's robust in the face of missing objects or null references; most of the time Flash will just fail silently. The point of the language is to stay out of your way and let you code something up quickly and effectively, and it succeeds brilliantly at doing what it was designed to do. Its simplicity and ease of use have another virtue: the language doesn't intimidate or frustrate designers, many of whom have never written any programs, in any language, before they were exposed to ActionScript. This is all for the good, and I'm all for it.

The trouble, of course, is that with success comes new demands. Now that Flash has achieved ubiquity, it has become very attractive as a platform to build and deploy applications in. And once you've built and deployed simple applications, you start to want to build and deploy more complex applications. And that's where the trouble with ActionScript begins.

[next post: ActionScript applications are slow, and brittle wrt design or requirements changes.]