I don't like computers.

Category: Flash Player

Stand up AGAINST Generics/Concurency in Flash Player

I’ve just read Joa Ebert’s excellent post “This is an outrage”  about the Flash platform. I totally agree on the big picture but don’t like some language proposals. As my tiny little contribution, I’d like to dissect and reassemble some often heard wishes for the ActionScript language.

Reading about generics and concurrency in Flash Player makes me nervous. I have read many wishes about those two features but never found a very precise description of what they really want. I fear that many think of language features found  in C++, C# or Java. The problem I have with those languages is that the language complexity reduces massively developer efficiency and effectiveness. Why do so many developers flee to Ruby, Python, Scala  or F#? How can ThoughtWorks state that they are  roughly two times faster in developing with a language that has no generics but the feature is still high on the wish list for ActionScript?

Generics

Please correct me if I’m wrong but you could not do more with generics in ActionScript. So we are talking about a usability feature for the developer, right? Instead of endless castings and writing tests, the compiler could do some of this work. But do generics really make you write and much more importantly read ActionScript code faster? If I think of Java 1.6 generics, my answer is certainly no and that’s the reasons why I’m against generics as known in Java.

However, I see some areas where type safety increases developer productivity. Vector is a great example and like Joa, I’d like to see some more native collections in Flash Player that use generics. But besides those exceptions, I don’t need generics.

Concurrency

I see two feature requests in concurrency: The first one is run time performance. The number of CPU cores is going to increase steadily and developers can only leverage several cores in PixelBender in Flash Player 10.  I think of PixelBender as a machine that launches as many thread as there are pixels in the output. Everything is finally joined when jumping back to ActionScript. So basically, we have already concurrency for a dedicated purpose. Sure, Flash Player needs to be able to leverage several cores (as it is already today) but I’d prefer if the VM could take care of concurrency. While writing code, I don’t want to think in CPU cores but in my business domain. Though I must admit that I don’t know anything about the feasibility of such an approach.

The second feature in concurrency are parallel tasks in an application. For example, saving data to a server and updating the display could run in parallel. The developer needs to control these parallel tasks. I know Java reasonably well and I fought trough Java Concurrency in Practice which I recommend. However, if it takes a book of 400 pages to know the basics of concurrency, the feature is never worth the pain of learning it. I would argue that concurrency introduces a level of complexity that nobody can master in a mid-sized project anymore. You just happen to fix known issues but you can not validate it. Testing concurrency is not even in its infancy.

That’s the reason why I plea for a much simpler solution compared to the implementation in Java. Maybe having a fixed number of e.g. 4 threads makes it a lot easier. Or maybe making all accesses synchronized per default and defining the exceptions is something to consider; I don’t know. I don’t pretend to know a great solution, I only know that I don’t want any solution I know today.

Bonus feature: Overloading

While allowing to apply all standard namespaces to constructors reduces complexity in ActionScript, overloading certainly adds more complexity. What’s the benefit instead of handling the different types in the constructor or method itself like in e.g. Python? If we had powerful pattern matchers like Scala has, I could easily live without overloading. Pattern matcher could also play a major role in solving “generics task”.

About Complexity

I find the comment of Lee Brimelow brings it to the point: “…there is also a huge segment of the community who is still really struggling with moving to AS3 as it is now“. For example, I would argue that probably half of all Flex developers are not aware that they create a potential memory leak when referencing objects in an array. They don’t care and they shouldn’t. Adding those features mentioned above will make even more people write buggy code.

Better and faster results

What makes me faster in reading and writing is rather for example type inference and tweaking the functional programming approaches. Which example do you understand faster?


//ActionScript 3
var vw:Car = new Car()
var cars:Vector.<Car> = new Vector.<Car>
cars.push(vw)
readyToDrive = cars.every(function(car:*, index:int, arr:Array):Boolean {
return Car(car).hasEnoughOil
})

or

//ActionScript 2010
vw = new Car()
cars = new Vector.<Car>
cars.push(vw)
readyToDrive = cars.every(return car.hasEnoughOil)

Some more spontaneous thoughts for language improvements:

  • Like in Dictionary, allow weak references in many places.
  • I’m not sure about adding [Mixin]. Haven’t thought through it yet.
  • {} should become in most situations optional as the semicolon is today.
  • If you care about raw performance, use Alchemy, write bytecode with the help of the excellent haxe project, launch a job for PixelBender or pray that the compiler gets more love by Adobe. It’s also clear that AVM2 needs to speed up as well. But don’t clutter ActionScript with pure performance features. After all, ActionScript is just a layer above byte code that should increase developer productivity (performance improvements from the compiler seem too far away).
  • (Sorry, this is my personal, pretty much hopeless fight :) What the community could already do today is dropping this silly ;;;;;;;;;; at the end of each line. It’s just visual clutter and about as useful as adding “//end of line” at each line end.

Finally

My point is that ActionScript should not blindly chase any other language. Adobe should only add language features if they either increase developer productivity or enable new possibilities for the Flash Platform including run time performance. And of course, only after a thorough discussion in the community before implementing.

But at the end of the day, I preferred to use Python or Ruby to program Flash and leave the stalled ECMA standard behind. Hey, maybe Adobe pops up with an equally solid APython or ARuby compiler at MAX?

Mocking in Flex/ActionScript has arrived: mockito-flex

The announcement of Google Chrome OS is certainly a big bang in the IT world. However, this didn’t made my day but the public release of mockito-flex. It’s been quite painful to create mock objects up to now in Flex. mock-as3 was best until I read on InfoQ about mockito-flex. It’s based on asmock but the syntax feels very much like mockito for Java (which is in my opinion the best mock library in Java). The documentation is still sparse, so below are all the things I need to know:


given(mockie.foo(10)).willReturn("10")
given(mockie.foo(10)).willThrow(new Error("oups"))
given(mockie.foo()).will(new GenericAnswer(incrementCounter))
verify().that(array.push("1"))
verify().that(array.pop())
verify().that(mockie.baz(eq("one"), any()))
verify().that(mockie.baz(argThat(new GenericMatcher("two", contains)), eq(10)))
verify(never()).that(testClass.foo())
verify(times(3)).that(testClass.foo()) // atLeast(4), atLeastOnce(), once()

Follow

Get every new post delivered to your Inbox.