incubator-flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <>
Subject Re: Starting with the Whiteboard Code
Date Wed, 08 Feb 2012 05:59:39 GMT

On 2/7/12 8:51 AM, "Michael A. Labriola" <>

>>> So yeah, I'm all for some byte-code optimizations and some fudging of the
>>> language rules (so you really can inline a constant), but I am still hoping
>>> a class definition will be same everywhere so newbies have fewer >>things
>>> learn to be successful with Flex.
> Understood but I think that's where we disagree and so be it. I think that it
> is important to newbies can pick up a language and certainly don't wish to
> exclude anyone. However, I think when you design a language or framework
> around the newbie requirement we get something else. I think we need advanced
> features that advanced developers find powerful, useful and interesting.
I would argue that approachability for newbies is what has made HTML/JS so
popular.  I think we need popularity in order to get buzz that opens
opportunities for new work and ensures community longevity.  A smaller
community of high-end specialists have an uphill battle to fight for
mindshare.  But for sure, we need to make sure you can do really advanced
things as well.

> When we target 
> newbies from the language side, I think we end up with a language used by
> newbies and ignored by more advanced devs.
ActionScript is designed to be a language used by newbies.  I'm not sure how
much we want to become more strict like Java unless it provides significant
performance gains.
> To me, whether or not the bytecode maps back to a class cleanly is a thing
> most newbies will never know.
To me, a newbie will quickly become intermediate-level because he/she
doesn't have to learn about AOP and other advanced topics, and then will
need to debug an app (with a debugger, not trace statements).  I've yet to
ship anything without having to debug into it, and I think it is important
to be able to understand the application behavior.  Productivity is a
strong-suit of Flex, especially for intermediates.
> A framework, to me, needs
> to be as flexible as possible to let people find the end goal and apply it as
> they see fit. 
Agreed, but IMHO, it has to be simple not only so it can be understood by
newbies and intermediates (and me), but also so it can be shippable.  Spark
was a better architecture than MX, but the fact is, it took too long to
create components in Spark.
> I only bring these points up
> as I sometimes feel there is a knee jerk reaction, this is not specific to you
> Alex, to doing things differently than they were... I think a few radical
> advances while keeping the same general usability and functioning of the
> framework could breathe a lot of new life into it.
My goal in these discussions is not to try to kill these ideas, mainly to
point out the counter-arguments and explain some history.  I am all for
radical change, I'm planning a full re-write as you know.

I still believe we are working with a constrained environment and techniques
you might find in Java can't be universally implemented in AS. And, that
approachability is important, but we absolutely have to make it possible to
polish advanced applications by allowing for optimization by experts.  My
prediction is that we will end up with a composition-based framework that
doesn't use AOP in the components and infrastructure commonly used by
newbies and intermediates, but makes it possible for advanced users to use
it on the edges and in their code.  I would argue the same for concurrency
if we ever get to leverage it.

But only time will tell...

Alex Harui
Flex SDK Team
Adobe Systems, Inc.

View raw message