jonathan's blog

Background

There has been some discussion about the state and future of ActionScript 3 and the Flash player from the Flash/Flex community recently. Ted Patrick is spurring some of this discussion - kudos to Ted for touching the community and getting a great response - and others at Adobe have also taken part. Several articles have also been posted such as:

• Joa Ebert: This is an outrage
• Nicolas Cannasse: The failure of AS3 ?
• Andre Michelle: AS3 Failure?
• Nate Lokers: Flash Scheme, Lisp, and jQuery-like $ugar
• Peter Elst: Making the case for ActionScript
• Keith Peters has also been talking on Twitter about this.

I have come to Flash somewhat reluctantly, being a fan of open software and environments. I have done a share of Microsoft work in the ancient past, but I generally enjoy a more open environment such as Java, Ruby, Python, HTML, JavaScript, et. al. I use Flash (and selected it as a technology of choice when I was architecting for a massive new release of our market leading debt collection software at Ontario Systems) primarily because of its ubiquity, power, and consistency across platforms. Flash reigns because of these three factors and they are the most necessary places for Adobe to concentrate its efforts.

From the Java fan club to the latest dynamic cult

However, ActionScript 3 as a language is less than exciting to me, as I have sought to avoid the drudgery of Java in the past and have yearned for more dynamic alternatives in Ruby, Python, Objective-C, and even Lisp. It was for this reason that I began working on Red Sun, a project to port Ruby to the Flash VM. My initial work on Red Sun centered on generating SWF files from Ruby. I implemented a SWF parser and creator with support for creating and modifying the ABC sections and other critical sections of the file format. The SWF format is tag based, so I simply ignored and passed through sections my tool didn't comprehend. The ABC (ActionScript Byte Code) section was fully parsed and could be modified and written out. The tool could also generate a new SWF from scratch and translate simple Ruby code into ABC functions.

This route was extremely illuminating to my understanding of the Flash player, but ultimately I found it was too difficult to actually complete a reasonable implementation of Ruby in time for my presentation at RubyConf 2008. So, in a flurry of activity that I had between jobs I instead ported the MRI Ruby interpreter from C to ActionScript 3. This task was completed and using Red Sun you are able to run a significant portion of Ruby in the Flash VM. The major limiting factors remain:

1. Dependence on Ruby 1.9 to parse and compile Ruby code into Ruby bytecode
2. Poor coverage of the Ruby standard library (implemented in C and only small portions ported to ActionScript 3)
3. Little production testing and likely large memory leaks remain

The interest in Red Sun was decent for the conference, but really I don't think anyone has used it. I have received sporadic questions about getting it running but that is all. I know that much of this is my own fault due to lack of promotion or compelling examples, so I am not really frustrated or anything. I learned enough in that work about Ruby and Flash and writing languages to make the effort more than worthwhile.

There is a big difference in the Ruby culture of openness and the closed source Flash player culture. Also, Ruby is driven by developers, albeit creative ones, and not designers like the Flash world. Few full time Ruby developers are trying to generate interactive graphics experiments for the web or enterprise RIA solutions. I think in general the allure of Flash is small for Rubyists.

Flash Forward!

So what does my experience lead me to look forward to in the future of Flash? It is a difficult question, as there are countless frustrating limitations of ActionScript 3 in relation to Java or C#, not to mention dynamic languages and even JavaScript. As others have pointed out, ActionScript 3 is in a limbo between the dynamism of JavaScript and the structure of Java. The ActionScript 3 prototype is hampered to near-uselessness but we are missing important object oriented basics such as method overloading, true enums, covariant return types, etc.

In terms of my current "day job," I care about advancing ActionScript 3 so it is easier to use, and upgrading the capabilities of the Flash VM so we can do our job more effectively. Primarily, what I find as major issues are related to working with Flex and its love of private variables and deep class hierarchies. Flex 4 is addressing some of this and I think it will be a big improvement.

What seems to be more important than changing ActionScript 3 are the broader issues such as performance, a global error handler, and possibly threading. Although everyone that begs for threading needs to consider the complete and utter breakage that will occur if it is enabled. If you think it is difficult to write asynchronous code, it is much more difficult to write proper multithreaded code. I see Flash and Flex code that will regularly break when multithreaded that used to make me cringe, having come from an inherently multithreaded server environment and also time working with Java. The Flash VM will be forced to break locks to keep from stalling the VM and that could easily cause major issues.

Speed improvements both to the AVM2 and to rendering would be one of the biggest attractions to keeping developers and designers on Flash. On a competing platform I have built effect mockups and received them from designers that had to be scaled way back for performance. This was extremely irritating and destroyed our vision. We were used to designing for Flash and this platform just couldn't keep up with our creative vision. I hear people ditching Flash for Silverlight for this very reason. C# does have some nifty language features, but you can still argue for Flash in general until performance kills you (which is rare, but happens).

Personal aspirations with Flash

I don't expect Adobe to create a language that I love, given the current direction, but fixing a few issues and spending their time on performance could really be a boon for the life of Flash. Adobe has put a lot of effort into MXML and it's easy and flexible binding is a great tool for building a DSL. Degrafa and Axiis are prime examples of the power of MXML. If Adobe can push the performance of the ActionScript generated by the compiled MXML it could be a saving grace.

I have been researching the possibility of creating an expressive language that is also efficient and interactive for visual experimentation. I then to think that the Flash player is the best environment for it, since sharing via the web is so ubiquitous. Processing already exists for offline rendering and I don't have any hope or desire to compete with it, but I don't think it works so well for integrating into the web (it does offer the best applet experience I've seen, however). The major downside of working in Flash is performance and device access. There are popular workarounds for accessing devices in AIR, but if my work will run in AIR and use a custom language I would rather just build a native executable.

The bottom line

I will favor Flash as long as the install base stays as high as it as and as long as it is fast enough to be compelling above Silverlight, JavaFX, and JavaScript solutions. The community can work around language frustrations and even build better frameworks alongside Flex or as replacements to Flex. Adobe can benefit from all of this excitement as long as the player remains the dominant technology.

Corey Haines stopped by and paired with me on Monday, 12/13/2008, this week. We had a great time talking and hanging out, as well as working on the Red Sun Ruby Flash VM for several hours. We implemented the core trappings for exception handling which was a major missing feature in the VM. We had a long talk about software craftsmanship and the journey that we take in our line of work.

I think the most important lesson that we felt was that a range of experience and interest is beneficial for a craftsman. We both traced some of our best learning and growing experiences back to interacting with key individuals. I also saw again how my path as a developer has been rather erratic as I've worked in significantly different environments with very different goals and deliverables. Overall, I think this has benefited me as a developer as I've been exposed to people with very different mindsets over the years.

Corey posted the video interview on his pair programming tour site earlier today. It was very interesting pairing with someone when the majority of the work was of the kind that was new to the pair. I haven't done a lot of pairing in my career (unfortunately). It's probably obvious to you if you've paired much, but even though Corey probably doesn't know ActionScript 3 well, and has not used C significantly, he was able to point out errors that I would have missed until either compile or execution. It also helped me to explain what I was doing as I went along. It forced me to have a reason for the things that I did.

The downside of this project in particular is that it doesn't lend itself well to Test Driven Development. I know some may argue that everything can be TDDed, but this is a unique kind of project. I am essentially re-implementing Ruby 1.9 (MRI/YARV) in ActionScript 3. This means that I copy, line-for-line, the C code into ActionScript, translating the idioms as I go. This means, as I explained/rationalized to Corey, that I can write large chunks of code without tests - even code that isn't yet running. The benefit of doing this is that when another part of the system gets implemented, those earlier parts will just work, assuming I did it right. Also, the goal for testing is to ruby RubySpec against Red Sun, and at that point I will have lots of failing tests to fix!

When I started working on Red Sun I didn't do this. I only implemented the functions and parts of functions that seemed essential at the moment. This led to significant slowdown and confusion later in the project. My partially complete method was now passed different arguments and data such that it exercised the alternate, unimplemented code path. I found it better to implement as much as possible of each function whenever I encountered the function, and to stub broken paths with verbose error messages or exceptions to point them out should they later execute.

I was very happy that Corey came and I am planning on posting some more insights from our discussions over the next few weeks. I was very happy that we got exceptions implemented. I intentionally skipped all of the exception handling code before RubyConf 2008 because I was afraid of getting stuck in it and having a broken implementation. I haven't implemented all of the various control flow interrupting operations (such as redo, break, and next), but raise and rescue are working pretty well. If you're interested in Red Sun, you can view the video of Red Sun Introduction by Confreaks from RubyConf 2008.

Thanks again for coming Corey! I hope there can be more people who take this journey and they can stop by Muncie if they do.

I am speaking at 360|Flex San Jose in August and you should come! 360|Flex is a great conference that really supports the Flex community. It's a great place to meet other developers (and even some designers), to learn, and to have a great time. I'll be talking about the Flex SDK source code and how to improve your development by reading it (and understanding it).

I'll be discussing the class hierarchy, the internal compositional classes, and the importance of interfaces. I will tear apart some components and offer suggestions on using them and better ways to design similar components. I will touch on the Flex component lifecycle, skinning, inheritance, custom components, list classes, and containers.

Lastly, I will discuss the Flex SDK API, how it is written today, how it will be evolving in Flex 4/Gumbo and what else Adobe needs to change! I will explain ways to use more DRY (don't repeat yourself) development practices using better componentization and compositional classes.

I plan to post some more teasers on my blog (http://jonathanbranam.net) so people who don't know who I am or what I'm talking about can get a better sense of the session and why they should (or shouldn't) come.

This is an application I built that functions as an address book, a phone using Ribbit, and a 3d Mii Editor (like on the Nintendo Wii) for the people in your address book. The address book can also load your contacts from Facebook using the "Little People" application that I wrote. The Miis are rendered in full 3d using a custom combination of Degrafa and Papervision3d.

This is the MiiCall application.

Further implementation details in the full post.

This is an implementation that brings Degrafa geometry into Papervision3d. I implemented a new Renderable in Papervision org.papervision3d.core.render.command.RenderDegrafa which transforms a set of Degrafa definitions into 3d render commands. These are located in the org.papervision3d.core.geom.renderables package.These are then rendered at runtime (as vectors, not using bitmaps at all) by the org.papervision3d.materials.special.DegrafaMaterial. I also implemented an early version of the Degrafa Transformations to support various modifications of the geometry at runtime.

The demo application for both is DegrafPaper3d and Degrafa Transformations Demo. A (slightly) more beautiful example is the Mii Call demo, which uses this technology to draw the features on the Mii's faces.

Read the full post for more implementation details and the story behind this.

This post is a necessity, I guess, to claim my blog on Technorati. It would be nice if they had a method that didn't involve writing a post that goes in my RSS.

Technorati Profile

Oh, well.

Interactive Information Design Patterns for RIAs

Designing applications which convey rich information to users is difficult. We now have at our hands the ability to display massive amounts of data using rich graphics in a web browser. Unfortunately, most designs end up as a series of line charts or data grids. We need to develop and learn a new library of interactive information design patterns that facilitate a two-way conversation between users and the application.

Sorry to all who tried to register to post comments. I recently changed my domain over to http://jonathanbranam.net from http://sspeare.com and I didn't get a new reCAPTCHA key. It was denying requests from this domain. The problem should be fixed now.

I guess that's another reason to get some other form of site contact running soon. In the meantime, if you need to contact me jonathan @ this domain will work.

Sorry!

The story so far: In the beginning the Universe was created. This has made a lot of people very angry and has been widely regarded as a bad move.

- Douglas Adams

Programming visuals, games, UI, HCI, software design, and language (as in the English language) have long been subjects of interest for me. Working at Cynergy Systems means that I can focus on using Adobe Flex to pursue these interests. This website is an outlet for me to share my thoughts with the Universe, whether or not you think it was a bad move to create it in the first place.