GOTO Addendum

With all this talk of GOTO, it’s suddenly occurred to me that ActionScript has a direct, higher-level version of GOTO that causes Flash projects to succumb to the same problems as those affected by the original.

Do gotoAndPlay() and gotoAndStop() ring any bells, anyone? Dijkstra’s commentary on how a dynamic, running process can be conceptually connected to static source code essentially describes the same relationship between a Flash animation and its keyframes. And old Flash code that uses gotoAndPlay() extensively experiences the exact same pitfalls that old programs did that extensively used GOTO.

In fact, I completely agree with EWD- that although these functions are extremely useful, the quality of a Flash program generally correlates with the frequency of gotoAndPlay() and gotoAndStop() in its source code. I know this from personal experience; it wasn’t until I expanded my knowledge of ActionScript and began using structured code that I could really achieve anything in the medium.

I’ll even go one step further and say that the reason why most people look down their noses at ActionScript is because more often than not, ActionScript programmers will hack together a system that relies on gotoAndPlay(). Had we been less dependent on that function earlier on, perhaps Flash would have been more generally adopted as an application platform.

That said, I know for a fact that there are elegant ways to code with gotoAndPlay(). Jared Tarbell’s ActionScript 2.0 projects at levitated.net are perfect examples of how timeline dependence can be a weird type of art form. There is something physical about using GOTO; it gives code an intricacy, because it reduces readability.

EWD was a highly analytical computer scientist; I wonder if he’d have been willing to see source code as a kind of art. I really wish I could have had that discussion.


You can leave a response, or trackback from your own site.

Leave a Reply