Thoughts on Flash

I’ve been doing quite a bit of ActionScript coding recently, trying to complete a game I started some months ago.  More than anything, I need to complete a project.  I’ve been directionless for far too long, which has contributed to my recent mental state.  Focusing on this game–on completing the game–has helped me start to regain a little balance.  Although I’d like something to become of the game, the most important part right now is completing it.

The ActionScript language itself, as I’ve mentioned before, is quite reasonable; in most cases, a joy to work with.  It has rough edges, as do all programming languages, but overall I very much enjoy working with it.  The Flash environment, too, is nice, but I’m continually bumping my head against the “this isn’t Windows” problem.  The Flash model is fundamentally different than Microsoft Windows and, whereas there are many similarities, the differences sometimes confound me.

The Flash event model, for example, is much closer to X Window than to Microsoft Windows.  Although I think I prefer the Flash model, my unfamiliarity with it has been the source of many head-scratching moments.  It does slow down the development process, but I also have very much enjoyed learning new things.

What’s giving me trouble right now is that the Flash APIs don’t appear to include the concept of a modal dialog box.  The Flex framework does, but at a cost.  Even the smallest Flex program is over 100 kilobytes in size.  Any meaningful program that uses Flex will quickly suck in more than 200 kilobytes of framework code.  That’s just too much.  My game, which does not use Flex, is only about 220 K in size.  That includes all of the sounds and artwork.  Using Flex would probably double the size of my program.

Some may think it’s silly, what with the wide availability of broadband Internet access, to be worried about adding 200 kilobytes to the download.  Afterall, bandwidth tests on my connection here at home report a download speed of about 600 kilobytes (yes, bytes, not bits) per second.  So 200 K takes roughly 0.33 seconds to download.  And 200 K means almost nothing in terms of storage these days, when computers regularly come with 80 gigabyte drives.

There is an issue on the server end, though.  Bandwidth charges start to add up when thousands of people download a program that’s twice the size that it has to be.  It’s hard to say if that’s really an issue.  Some providers give two gigabytes of bandwidth per month with their basic hosting packages.  It would take 5,000 downloads to exceed the limit.

Some of my reluctance is undoubtedly aesthetic–the old assembly language programmer in me who hates to see all those wasted code bytes.  Whatever the case, I’ve committed to making this game without using Flex.  After that’s done, I’ll re-evaluate my options before tackling another Flash project.

More on ActionScript

I’ve been working with ActionScript almost every day for a month now, and have grown to like it a lot.  It was touch and go there for a while for several reasons.

First, the development environment is primitive by today’s standards.  My development environment consists of TextPad and the command-line Flash compiler.  I set up a TextPad macro to invoke the Flash compiler and–this was a big surprise–the output is displayed in an editor window.  I can click on an error message to be taken to the offending line of code.  But that’s about as “integrated” as the development environment gets.  Testing is done in a browser window and debug output is sent to a log file.  I almost have real-time debug output in that TextPad will prompt me to reload the log file when it changes.

All the niceties of Delphi and Visual Studio are missing, though.  I don’t have a visual control editor or source-level debugger, and the Flash compiler is slow.  Glacial, even, compared with any other compiler I’ve used in the past 15 years or so.  Documentation consists of an HTML Language Reference and a bunch of disconnected PDF files.

With all that you’d think that I’d hate working with Flash, but I don’t.  I’m finding that I don’t really need–or in many cases even want–all that stuff.  I’m finding that I use fancy development tools as a crutch and I often let the compiler do my thinking for me.  Not so with the ActionScript apps I’m writing.

I know that there’s Flex Builder–the Eclipse-based IDE that I can download from Adobe’s Web site.  I played with it briefly but didn’t like it.  As with any IDE these days, you have to marry the darn thing in order to be productive, and I’m not entirely certain that marrying Eclipse would make me any more productive than I am already.  Besides, Eclipse is a reasonably good generic IDE, but not terribly good as an IDE for any specific product.

The other thing that almost turned me off of ActionScript is that it’s a scripting language that’s masquerading as a programming language.  Yes, I know that sounds kind of snobbish.  In my years of programming I’ve found that scripting languages are fun to play with for a while, but after the initial excitement wears off the little annoyances and odd language warts turn in to major headaches.  And ActionScript is a scripting language–it’s based on JavaScript.   Sure, it’s compiled into intermediate code and (I think) JIT compiled at run time, but there’s still the ability to have untyped variables and do type resolution at run time.  Those things are nice when used intelligently, but they also can result in very difficult bugs.

I’m finding that in most cases the language is strongly-typed, but the ability to get around that is very useful when writing real programs.  Used correctly, what I have is the best of both worlds:  a language that catches most of my stupid blunders at compile time, but allows me to shake off the straightjacket when I need to.  The large runtime library provides all the neat containers and other low-level things that I’ve come to appreciate with Delphi and .NET, and like those two environments I can create and use new components without trouble.  In short, I really like ActionScript and enjoy working with it.  It has faults like any other language, but so far I haven’t seen anything fatal–certainly it’s much better than JavaScript or VBScript.

ActionScript 3: No pass by reference

When you first start learning a new development platform, the learning curve looks more like a learning cliff:  you have to assimilate a huge amount of information up front in order to become even marginally productive.  My current knowledge of ActionScript 3 is about where my knowledge of .NET was four years ago.  I’m just barely able to put together a working program.

Today I was wondering how to pass parameters by reference in ActionScript 3, and came across an odd design decision: all parameters are passed by value.  I know that the documentation says that objects are passed by reference and primitives are passed by value, but in reality everything’s passed by value.  An object is a reference, so what you’re really passing to a function is a pointer.  In this respect, ActionScript is like C except that in C you can pass a pointer to a value type.

Nomenclature notwithstanding, the odd design decision here is that it’s impossible for a function to change the value of a primitive type (Boolean, Number, int, uint, and String) that’s passed as a parameter.  The function can change the value locally, but the global copy of the parameter is not affected.  Ever.

Exceptions to rules make for confusion, and this is one thing that’s going to confuse a whole lot of programmers.

ActionScript 3 regular expressions

I’ve been playing around with the new Flash 9, learning a bit about programming in ActionScript 3.  This new version of ActionScript is a real programming language with a real object model and other things that we’ve come to expect from environments such as Delphi, Java, and .NET.  I only have a couple days’ experience with it, so I don’t have a lot to report yet, but we did run into an interesting oddity when splitting a string using regular expressions.

The String class has a function, split(), which will split a string into substrings by dividing it wherever the specified delimiter occurs.  The delimiter parameter is usually a string or a regular expression.  So, these two statements should give the same results:

var words:Array = str.split("\r\n");    // delimiter parameter is a string
var words:Array = str.split(/\r\n/);    // delimiter parameter is a regular expression

We use the above code to split a loaded text file (loaded into a single string) into an array of lines.  The two versions do in fact give the same results, but the regular expression version takes much, much longer.  We loaded a file that contains 400 words and both statements return immediately.  With a file of 10,000 lines, the string version is still instantaneous, but the regular expression version takes about five seconds.  Even with 180,000 lines, the string version is immediate.  We gave up on the regular expression version after over five minutes.

A .NET program that loads a file and splits the lines using regular expressions is instantaneous, so I don’t think that I’m expecting too much by wanting the Flash version to perform similarly.

I poked around with the regular expression options for a while and got nowhere.  What concerns me isn’t so much the speed, but that the time required does not increase linearly with the number of items in the list.  Somebody at Adobe needs to take a look at their regular expression matching algorithm.