The problem with Flex wasn't its design, it was how buggy all of the edge cases were. Sound files randomly being replaced, weird compile errors that go away once you reset, code generation errors fixed by adding comments, occasional minute long compilation times, out of memory errors (again, reset the computer).
Frankly, complete rewrites under these circumstances are a cop out. It's an easy but ineffective path. What they should be doing is unit tests, isolating bugs and strictly controlling quality. Common bug reports should be triaged, rather than ignored (it's not uncommon to have a bug, and find a set of posts years old discussing workarounds). All it would take to fix Flex would be the will to do it.
The rewrite will have a whole different bunch of issues, and be similarly problematic. It's not like Flex was a bad apple in a bunch of well engineered Adobe software.
Same here!! One of my startups failed because we chose Flex/AIR as the development platform. Nearly tripled our development time, working around bugs in the platform.
I've been writing in ActionScript 3/Flex for more than 3 years now and I don't really understand your problems. There never was a compiler bug that completely prevented me from doing my work. There always were easy workarounds to everything. The community is huge. I could always find the answer either by reading the documentation or googling.
Sincerely, compared to C++/Qt/WxWidgets, Python/Qt, Swing and even HTML/jQuery Adobe Flex was the most productive environment for frontend and desktop development for me.
It sounds that you did not have a prior experience in Flex otherwise you would know the kinks of the platform. I would say that it was not the choice of Flex that killed your startup but the uniformed choice of a technology that you never had a prior experience with.
3 years huh? I reckon you have never worked with Flex 2/3 then? The incident I am quoting is over 4 years old and I understand things may have improved with Flex 4. Specifically the Spark library drastically improved UI performance. However for us early adapters its too little too late. A Java backend with a Swing or HTML/JS front end is the safest route to go when programming for multiple platforms.
I have 3 years doing full time Flex development. Have yet to see these problems. We deploy to Windows/Linux and Flash Player has been the closest to write once/run anywhere that we've seen. We have nothing but good things to say about Flex development.
I've been using Haxe for several years. I heartily recommend it, even outside of Flash and JS targets where it's strongest. The compiler is very solid. You can still expect to be filling in some gaps in library support - but the other side of that is that it's often very straightforward to appropriate code written for your target platform and use that instead.
Interesting. I should note that most of this stuff (optimization, etc) is available through Haxe. Haxe can also compile to Javascript, iOS & Android; targeting just Flash is risky at this point.
Just to add to this. For mobile compilation targets, Android, Blackberry, iOS and webOS, support is added through the Haxe NME framework: (www.haxenme.org/).
Haxe doesn't provide those compilation targets on its own.
I'm surprised that when I look at Haxe's showcase (http://www.haxenme.org/showcase/) - most apps there are only available on a small subset of the platforms Haxe compiles to.
I don't know what to make of this change. I always assumed goto was something you designed into your language from day one, rather than bolted on in day 4000 or so. Can someone more familiar with language design (or the target use cases--I presume high-performance game programming?) comment on this further?
Hmmm, Isn't this late by about 7 to 8 years. We've been asking, requesting and begging them, (while Flash was till with Macromedia) to improve the compiler, make it faster. One of the dreaded thing about Flash was that we have to wait for minutes while it compile. We dreaded the notion of pressing "Ctrl+Enter" on the keyboard.
MTASC by Nicolas Cannasse, came to our rescue and it was a good one - super fast. Nicolas is also behind haXe.
27 comments
[ 3.4 ms ] story [ 74.1 ms ] threadhttp://haxe.org/
The AS3 compiler in Flex is junk. My buglist over the three years I used it was nearly 100 items long. I don't know of a single unfixed issue in Haxe.
Plus, if you write the code properly, you can port it to nearly a dozen platforms (serverside, plus all of the ones on http://haxenme.org).
I don't make Flash games any more except for hobby projects, but migrating off of Flex was the best decision I ever made.
https://cwiki.apache.org/FLEX/falcon-overview.html
Frankly, complete rewrites under these circumstances are a cop out. It's an easy but ineffective path. What they should be doing is unit tests, isolating bugs and strictly controlling quality. Common bug reports should be triaged, rather than ignored (it's not uncommon to have a bug, and find a set of posts years old discussing workarounds). All it would take to fix Flex would be the will to do it.
The rewrite will have a whole different bunch of issues, and be similarly problematic. It's not like Flex was a bad apple in a bunch of well engineered Adobe software.
That's me when I remind myself of Flex development.
Edit: I don't disbelieve you just, wow, that is amazingly bad.
Sincerely, compared to C++/Qt/WxWidgets, Python/Qt, Swing and even HTML/jQuery Adobe Flex was the most productive environment for frontend and desktop development for me.
It sounds that you did not have a prior experience in Flex otherwise you would know the kinks of the platform. I would say that it was not the choice of Flex that killed your startup but the uniformed choice of a technology that you never had a prior experience with.
Same goes for the example apps I've seen at Corona's case studies (http://www.coronalabs.com/resources/case-studies/) and Appcelerator's Titanium showcase (http://www.appcelerator.com/thinkmobile/showcase). Admittedly most of Appcelerator's apps in the showcase are compiled for both platforms but they also have by far the smallest amount of showcase apps.
> ...
> * The function does not contain any activations
Does this mean that a function can't be inlined if it calls other functions?
Known issues: Flex compilation is not supported.
So much for multi-threaded compiling. Pfff. I guess we will just wait until the open-source people do it, sometimes next year?
MTASC by Nicolas Cannasse, came to our rescue and it was a good one - super fast. Nicolas is also behind haXe.
http://www.mtasc.org/ http://haxe.org/
The IDE is what needs demolishing and rebuilding properly.