why Notebook Margins ? 

On Flash

On Flash5 Application Interfaces My response to the question "Is actionscript a real programming language" (in regard to Flash5) I see this as an important topic as the past ten years I have had to navigate the issue a lot from both sides of the fence and I still see it key in the question of how much of my personal development efforts now and in the future should go towards flash or Java or C++, or now even RISC. How Actionscript compares to the other programming languages is important as it may give us ideas as to how to draw from the various methodologies that folk have worked so hard on in the past 30 years of language development. Both the strengths and weaknesses of actionscript rely on how it relates to these other tools environmentally. Why are scripting languages so often used for general purpose multimedia environments? Because they can successfully utilize encapsulation for complex objects at runtime. Why do they frequently omit type checking? Because types can tie systems down to static areas of influence and the world is a dynamically changing thing. The same issues that folk argue about with TCL/TK apply to scripting languages like Javascript and Actionscript. In the end it becomes an issue of programmer productivity. True type checking can help find bugs, but so can it add complexity and inflexibilty to a system at a time where flexibility is key because entropy is high. So what heuristic would you use to evaluate programmer productivity? Here is mine. You want to 1) reach the largest distribution with 2) the greatest capability that you can. You want to be able to 3) reuse code as much as possible. And you want to be able to structure things so you have 4) as few fixed points as possible. By fixed points I mean the actual number of places that you have to type something in, making it fixed. When you choose an object name or number of parameters, it becomes a fixed point. In 1) distribution and 2) capability Flash rules. In terms of system level things like 3) code reuse and 4) fixed points, it still lags far behind. Flash is to my mind, after only HTML and email, the next most capable distribution mechanism on the planet. It is capable of doing 80% of what you might need for most applications. That is just tremendous in my mind. It can't access the operating system directly and many standard interface elements need to be custom built. Video and 3d are outside it's focus, but other than that you are only limited by your knowledge and time. When I say that it's distribution mechanism is larger than anything done in C++ or Java it is simply because of C++'s memory management and Java's lack of ubiquity across platforms. Mac users may be comparatively small in number but they are very significant in terms of size of distribution because with distribution capability ubiquity is more strategically important than absolute numbers over the long run. If you can develop to the Mac audience as well as PC and Unix you are better prepared for any operating system shifts that may occur in the future. I remember about 8 months ago now, someone poo pooing Flash for audio work "use Java" for that he scoffed. Well the Java2 audio engine won't work on old Macs. How can you say something like that seriously? Comparing the ease of distribution of audio content via flash compared to even any of the MP3 Players, they all have onerous download and setup needs, 3MB for Realplayer 6MB for Quicktime, Even WinAmp lite is about 3 times the size of the entire Flash activeX control. If your're not concerned about distribution, you are living in the wrong age. Having said that, on some other issues, Flash is much less strong. The bigest problems with Flash from a systems perspective are, 1) documentation, 2) debugging, 3) version control and 4) programmer collaboration. To alesser degree code reuse is a problem, though ultraedit (et al) can help. Overall In these areas Flash compares poorly with Java or C++.I remember being told of a professor who wrote a complete programming language that was a one month graduate assignment using lex and yacc in 3 hours. That's the goal. To have so few fixed points that you can create a Flash app with a simple mechanism like lex and yacc in 3 hours out of existing components. I can see this happening. As a whole, I hope that the direction they go with in Flash 6 is to keep the same v5 .swf player and only work on improving the editing environment in these areas. But that points out the other posible negative in developing with Flash. Every year's effort's could likely useless after a new version comes out. I created a bunch of string based data structures with Flash4 and when Flash5 came out, i threw most of it away. What about Ack now? Are Macromedia improving their object event handling as we speak? Maybe. And maybe it will be very similar in design or maybe not. It's hard to know with such a moving target. 1) Documentation. It would really help to have a tool like Javadoc to automate the creation of documentation. Currently I use a tool like ioDebug (though nothing as nice) to view stuff in execution, one thing I would like to add to it is a function that allows you to output html descriptions of objects and their structures via the fsCommand interface to Javascript. Generating HTML documentation files in a new window that you can save on your hard drive, for reference. But a real automatic document generator and formater like JavaDoc would be the goal. And nobody is likely to do it if Macromedia doesn't. 2) Debugging. That Jon Williams had to create ioDebug is 'nough said. 3) Versioning. The binary file format of .flas will continue to make it difficult to implement verision control unless future versions of Flash add versioning to the authoring environment. 4) Libraries and smartclips have their own limitations. One per timeline? As a result of no standard coding practices many folk are probably recreating the same things with minor differences which is certainly not the goal. This is where flashcoders is doing a good job by focusing on the nuanced syntax issues, but in general Flash coders are weaker on consistency than those using other languages. With consistency, the goal is to get to higher and higher levels of abstraction and then code reuse, but that requires formal mechanisms for communicating style and structure and without that it flounders at the group level. Having said all that, Java and C++ tools are still going in the direction of creating development environments that do large parts of the work for them in order to get the same kind of productivity that multimedia developers have been enjoying for years. Wizards, visual editing tools, round trip UML-To-Code generation tools. But the more they catch on, the more they will inherit the same sorts of issues. Though the larger markets and text based origins tend still to ensure that it's easier to build a "real" or complete system, it will be expensive and code reuse gets the same kind of hit as mentioned for us now in #4 above because the Javabeans created in VisualAge will still be different from those created in some other IDE at some point of configuration and this inevitably bleeds back into design choices. Linguistically About the programming language itself, it's anything but a toy. On the contrary the imperfections of the object system and execution sequence make it pretty hard to structure and code a program without the syntax becomming pretty esoteric. Type checking. Typeless is good, but a lint like facility and better style guidelines would be welcome. Regular expressions. The lack of regular expressions certainly makes Actionscript open to the argument of "less real", but there is no reason that you couldn't build a regular expression component If you really want one. However Actionscript is very flexible due to it's untyped nature. It supports functional programming as well as it does object based programming. And yet is is still more directly like a tape machine with important sequencing needs (like loading and variable updating). And the ability to do elegant inheritance can become overly complex or break down easily if you use complex object structures because of inconsistencies between a movieclip, an object, a button or a movieclip being used as a mask. Functional objects and dynamic arrays are very flexible for creating data structures and a lot more fun than ones in C which are tied to memory addresses. I believe that with a unification function, actionscript could support a declarative logical style of programming as well as an object based or functional one. Look at Branden's eventEngine code as an example. There are parts of it that look like functional code and parts that use a declarative style. Finally I think that Flash is unique in it's similarity to Turing Machines and culturally if we were focusing on programs that can be automatically archived the core structure of Flash would probably make it easier to universally archive flash files than more platform specific ones.

References and Linkages