Despite the fact that ActionScript has a couple of major glitches and missconceptions I think there are also a couple of great key features that force you to write better applications due to the language design.
First of all we have to aknowledge that ActionScript has some great features. Those include implicit getters and setters or method closures for instance. Java 7 will have method closures finally after a lot of argy-bargy about their complexity et cetera. ActionScript developers are used to method closures and are buddy-buddy with them since Flash 4 I think.
But what is the real advantage of ActionScript? Here are my thoughts.
-
Poor Performance
Yes. We have been educated to optimize the hell out of our code. We have been educated to think about our code and how it performs. We have been educated to be creative with our tools, to tinker around. I know that this is not something to be essentially proud of but it led to a lot of creative and astonishing experiments. If you would tell a Java programmer you are still developing object pools they will laugh at you for a good reason. This is where the poor performance is annoying but something is very important: the potential. Think with the mind of a carpetbagger. Shares on the stock-market that never have a downturn are less interesting because there is less profit potential. So why am I talking about this? It is quite simple: Flash has still a lot of potential for growth. Flash did not pass its zenith already like other virtual machines. This makes me very optimistic for the future. There is still so much potential for the growth in performance and I think that Apparat has shown this as well.
-
Forced Asynchronism
ActionScript has no ability to perform blocking operations (despite of AIR). This makes every application responsive. If you load files from an external source like a URL your application will stay responsive because you have to add listeners that react on certain events. I know this is somtimes cumbersome but every good application should make use of asynchronous IO for instance. If people are lazy they will simply spawn a new thread to perform blocking operations which is also okay but less performant. Usually the simple example is a server where you would spawn a new thread for every client. This is the worst you can do and Java tackles this issue with its NIO. However a lot of people do not make use of NIO because they think it is hard to use for common tasks.
-
Events
Events are a great way to achieve concurrency. Some people call this immutable message passing. If your events do not contain state or are immutable, you have a powerful system to tackle concurrency. Basically this is what the EventDispatcher is all about. You add listeners for certain messages to a dispatcher and then you react on a message when it is dispatched to you. Again we have been educated to use a system which forces us to write responsive applications that is not based on synchronization and locks like Java or C++. If Adobe decides to implement multithreading in the Flash Player I hope they will choose to implement the approach of Erlang which is all about immutable events and event dispatchers. The only difference is that Erlang programmers call them actors.
This post is not an ode to ActionScript. There are still major issues like the lack of parameterized types. But I do think that there is a lot of potential. We can grow with the language and we can tackle upcomming issues. Concurrency is one of them, limited resources on a mobile device are another one.
I’m not at all convinced that “an advantage of ActionScript (AS) is that its rubbish and so can only improve” is a particularly compelling argument for AS. And the lack of optimisation and performance problems are not the fault of AS, they are the fault of a poorly implemented compiler and the Flash player.
Also it is easy to write unresponsive AS, despite there being no blocking features. The lack of concurrency adds to the problems of that unresponsiveness. If I load a large file and want to parse it in some way, I can’t do it in a background thread. So to parse the file without impacting performance, I have to construct an asynchronous multi-stage parsing scheme, which greatly increases the chances of bugs.
If/ when the flash player supports multiple threads, I don’t want to have to use events, actors, rendezvous etc. I want transactional memory. Forget functions as first class objects, closures and real properties as advantages over Java: transactional memory would really give AS a genuine advantage.
I agree with you David. Maybe I should have stated more clearly that I see those as advantages because they are design principles. Other problems like poor performance can be fixed by the VM and compiler in the (near) future for you. Missing concurrency is one of my biggest complaints as well. But the fact that IO is (nearly) always non-blocking is great. Yes, “while(true) {}” will freeze any Flash application but that is not the point.
Having an STM is great but you would have to decide very careful how it is implemented. Blocking or non blocking, pure or not?
Honestly I don’t find Events system a strong side of AS3. No they are good but kind of far from perfect… I find that they bring problems often with some things.
For example in large projects with Flash pretty often problem is that one object A uses object B that was used by object C before. And object C have registered some listener on B and haven’t cleaned it properly. Then when A does something with B C gets event. Usually it is caused by bad programming where some event listener was not removed but it is pretty common problem. Solving it by just AS3 event system looks like a lot of lines of code of adding listeners and removing them which makes it hard.
Currently am playing with different ideas of writing my custom Event managers that have different function for adding and cleaning groups of listeners. For example like that:
addEventListener(listenerOwner, listenerFunction, dispatcher, eventType)
Then I have methods like cleanOwnerEvents(owner) which removes all listeners from all objects to which owner had added listeners. Or cleanDispatcherEvents(dispatcher) that cleans all event listeners that were added to this dispatcher. But those two add opposite problem of removal of listener that should have not been removed in some other context this code does not know of. Well for that I have cleanOwnerEventsOnDispatcher(owner,disaptcher) which removes all events added by owner from dispatcher. Also I have methods that take in array of owners, dispatchers, event types and listeners in different ways. Makes code a lot smaller and easier to manage but it is still not perfect. But that’s something I learned trough recent years to use. New developers will use original functions, and they will make mistakes, and I will be looking for a bug that was caused by that.
There are other problems with Flash Events too though they are less problematic, like they are little bit not versatile in some cases and they are not really that fast.
On other hand I think only language I was using much in recent years was C#(though a lot less then AS3) and their events model is not really that better. It probably performs better and has less problems in some cases but brings their own set of compromises and tricky situations as far as I can tell.
Has anyone noticed the new project in Adobe’s Bug and Issue Management system called Sherlock?
Here’s a link:
https://bugs.adobe.com/jira/browse/SHERLOCK
This is the description of the project:
“Sherlock is the cross team collaboration to improve the Flex and ActionScript compilers. Bugs in this project will eventually be transfered to either the Flex SDK or ASC project as the code is committed back to the working trunk.”
Looks like this project only started this February and I think something like this is long overdue. That said, because it’s new it unfortunately won’t be ready until next release cycle (CS6? Flex 5?) that we see any gains, as I don’t imagine there’s time to add any improvements to Flash CS5 or Flex 4.
+1 for parameterized types. We’re desperately needing them.
I’m not sure that we can compare Erland actors and AS3 events. Actors have been designed to be able to process operations in parallel. Events are just ignoring the parallelism issue because Flash is single threaded.
Events are just a way to implement asynchronous notifications, but are actually not very elegant since you need to deal with all the listeners while actors offer a way to write async code as much easily as you would write synchronous code. Look at Scala actors for an example ;)
Sorry for the double post.
I also definitely disagree that poor performances is a good thing. Whatever the performances of a language/VM, you will have to find tricks to push it further. Having good performances from the beginning is better than having to reinvent the wheel in order to build a car…
Nicolas, I did not want to say that we should use the EventDispatcher class and just make it multithreaded. I doubt that we will reach the elegance of Scala anytime soon.
But if Adobe would provide some syntactic sugar for an ActionScript actor-like implementation the good thing is that a lot of developers are already used to that. That is what I want to say.
I know that saying bad performance is good is a bold statement. But think about it. You do not have to reinvent the wheel all the time. For a lot of stuff performance is good enough. Java however which was suffering from “poor” performance as well made a jump with a high cost. The VM startup and warmup time. I think that this is one of the biggest reasons why noone uses Java applets any more. Starting an applet takes still so much time. One effort of JavaFX is to reduce that time of course. But that was one tradeoff for better performance.
We can improve the performance of Flash applications a lot by improving the compiler without touching the VM at all. Isn’t that fantastic? And we can get much better performance by fixing simple (and complex) things in the Flash Player. This is great; stagnation is not great. And we have suffered from stagnation in the past two years at least. 2010 will be (hopefully) the year of Flash Player performance improvements.
Yes, ActionScript 3 is really a wonderful language. And I vote for the fact that if implementing multi-threading, there must not be shared state or data or varaibles, just like Erlang. Everything must be via message passing. I’m waiting to see such a innovative feature to be added to ActionScript. I wanted to see Erlang features added to AS.
Next Adobe needs to improve its Virtual Machine.
Can Adobe work with hardware vendors like ARM to incorporate the improved AVM into the hardware just like Jazelle?
Flash is a wonderful platform to work with. :)
–
Jaseem V V