Old ASVGuy::SWFBlog at Typepad

Silverlight in the Past Tense... Another Flash Killer bites the dust!

Interesting news came from Microsoft's PDC (Professional Developers Conference): Microsoft: Our strategy with Silverlight has shifted, by Mary Jo Foley.

(Read more at Microsoft’s Silverlight dream is over, by Tim Anderson, or a summary at Is Microsoft Turning Off the SilverLight?, Harry McCracken).

In short, Silverlight is now retired from its position as Flash Killer, coined about 3 years ago. MS thinks HTML5 will be the webs future, and it will be sufficient. Silverlight lives -not officially dead but will transform-, just like .NET... Here is what I wrote in May 2007: Silverlight must Live!

Flash is stronger than ever, as proved by the recent Adobe MAX 2010, and another so called Flash Killer is now gone...

Update: More on the Web:

Is Silverlight Done? Microsoft Shift in Strategy to html5 at *drawlogic

Microsoft Has Seen The Light. And It’s Not Silverlight at TextCrunch

On the “death” of Silverlight by Keith Peters

PDC and Silverlight announcement at Silverlight Team Blog

Silverlight Questions by Scott Guthrie (Nov 4, 2010)

What MS guys say doesn't change the current situation a bit.

(Officially) Announcing Azoth [at version 1.02]

"Azoth is a free  'Alchemy Opcodes Injector', a Windows console (Win32 command-line) application, for AS3 Flash programming, that lets you replace method calls to a certain AS3 class (included with Azoth) with equivalent Alchemy opcodes in a SWF file. This provides superior performance for accessing a ByteArray as memory, than you can achieve with AS3 alone".

We released Azoth on April 20th - but didn't find time to announce it, officially. Philippe Elsass made the introduction better than I could, by also actually comparing currently available solutions. [AS3 – Fast memory access without Alchemy].

Yesterday we released 1.02 update, and now Azoth is officially announced. Hope you find it useful...

Today It's 10th Anniversary of ASV...

Yay! 10 years ago today ASV version 1.0, the first decompiler for Flash, was released.

One thing Twitter taught me is that long posts are not always the best, so I will keep this really short.

As @elsassph said: We're getting old :)

Prefixes vs. Namespaces... Conclusion

There are two sides of a coin. I'm not blinded by my bias against (custom) namespaces. I can't say the arguments of namespace solution supporters has no merit. And I'm a realist, what's done is done, I don't expect anyone at Adobe having a revelation after reading my posts. So why have I been posting about this, if this is beating a dead horse?

I'm not even a Flex guy, and I currently have no intention to become one. But for the future of Flash, I believe Flex should be as simple as possible and entry level should be lower. I also fear anything done "wrong" in Flex may find its way to Flash... Anyway...

I have a solution proposal, which I'd say will give us the best of both worlds.

When designing an application, when you can't really decide on something, you make it optional. (This may not be optimal but may be your only option).

Can we have the components in their namespaces (as they are now) and still ignore the namespaces?

- With prefixes, you'd have components in global namespace. This would give simplicity. You wouldn't need to use, think of (or really be aware of) namespaces. But prefixes create ugly names.

- With namespaces, you can have a better organization. Sometimes minor benefits are huge, like seeing contents of a namespace while coding, or avoiding ugly naming.

I want to keep this short, so I'm coming to the point.

I'm proposing: A special default component namespaces list, with overriding and hiding behavior.

- It's a special list of namespaces of components, that will be considered imported by default and as early as possible (meaning, if you have "mx" in the list [1], you can write "Button" -without a namespace- and it will mean "mx:Button").

- It will have overriding behavior. (meaning, if you have both "s" and "mx" in the list, you can write "Button" and it will mean either "mx:Button" or "s:Button" depending on the order of the list. If "s" is listed first, it will mean "s:Button", if there is no "Button" in "s", it will mean "mx:Button").

- It will have hiding behavior. (meaning, After a "Button" is first found in one of the namespaces in the list, other "Button" definitions will be ignored. Namespaces in the list will have priority over others -regular ones- and any name found in the list will hide further definitions. This way, you will be able to continue using names from the namespaces in the list without a namespace qualifier, along with the same names in other namespaces you use with namespace qualifiers: a "Button" with no namespace specified will always resolve to the same name [if found in one of the namespaces in the list]. If you need to use another "Button" you will need to specify the namespace for it, but not for both).

- The list can be empty, and you will get current behavior, hence it's optional

- Obviously, code written with namespaces will still work in any case, as before. The list will be used for resolving unqualified names.

I don't really know that much about Flex, so my solution is just theory, but makes sense to me (and it's not something I can take credit for, similar solutions are used in many places and it's not really something hard to think of). Assuming my solution really does make sense, I admit I don't have a clue where would be the appropriate place to define this list (in Flex/MXML).

We already have the namespace solution and all its benefits. With this list we can get additional benefits without really breaking anything and for the worst case, it is optional.

A newcomer will not have to deal with namespaces. If a "Form" component does not exist in "s", the one in "mx" can be automagically used. It will work exactly as if the components in the list are defined in the global namespace.

If the list solution turns out to be not ideal for whatever reason, how about this:

A feature to define just one namespace as default with hiding.

This will be like promoting that single namespace to global namespace level.

Normally, if you have the same name, say "Button", defined in more than one namespace in your scope, you have to use namespaces, because the compiler cannot know which "Button" you mean. So every time you use "Button" you will need to use the namespace, like "mx:Button" or "s:Button".

If there was a "default namespace with hiding", you could use the names in that namespace, without specifying any namespace. For other "Button"s, you would use the namespaces, exactly as before. With the default namespace set as "mx", you could use "Button" (which will resolve to "mx:Button"), and "s:Button" (and also "mx:Button" if you want though the namespace part would be redundant).

Then when you have Spark components namespace as the default, you won't need to use any namespace when using Spark components. It will be like the components are in the global namespace with no prefix. And this will be optional - if you see any drawbacks, you can just not use it.

This may even be an already existing feature I'm not aware of. Would any Flex guru care to comment?

[1] I'm assuming you know which namespaces I refer to when I mention "mx" and "s".

Prefixes vs. Namespaces... Why would the prefix solution have scaled better?

Update (2009/06/02): It turns out some of my understanding about this issue was wrong. I've never been a Flex guy. I will keep this post as is below. My current understanding is that "promoting components to the global namespace" was not a goal, but only a side effect. Albeit a very important one IMO. So, this post still has a point.

The prefix solution would have scaled better? Yes. And this does not contradict with what I wrote about how similar both are, in my previous post.

With current namespace solution, every new major component-set version will get a new namespace. Does that solution scale well? What will happen with the 100th major version? (I'm aware that probably we won't see 100 major versions, this is a way of thinking to test if the solution really scales or not).

How are major versions decided? Arbitrarily? It seems so, because you can mix both versions we have now. Maybe "arbitrary" is not the correct word, but I can say "not rationally from a certain point of view".

What will you do when you have 1.01 bug fix version of a single component? You will replace the old one (overwrite). OK, what will you do when you have the 1.3 version of the component that is not compatible with the old version? Overwrite and you will break old apps, rename and you will get a new component. OK, not a big deal. What will you do when you have version 1.9 of the component, which is not compatible with the old version and is on the verge of being a new major version? Is changing the version to 2.0 and opening a new namespace for new version of component the best solution?

What will you do when you have major updates of some components, but not all? Put the new components in a new namespace, and let users use the current (but old) version components from the previous namespace? (This is the current situation - namespace soup in formation, it's manageable for now).

Namespaces, are like file system folders, that's how I visualize them most of the times.

Namespace solution does not scale as a whole, it does not take care of name collisions caused by minor updates, it doesn't really take care of major updates.

Actually, I think this could be a text book example of a solution which does not scale well at all.

"Put the new files into a new folder" is a simple solution (so far, so good). You can't expect it to solve all your problems, you can't expect it to scale well. It just keeps your root folder clean and, yes, it provides some level of organization, though I'd call more arbitrary than rational.

And this is the current policy, thanks to community feedback.

Is there a better solution? I think there is, and if prefixes were used, that solution would have been reached inevitably.

Global / top / root namespace is not different than other namespaces, but in one aspect. You can have only one of it.

My better solution applies to all namespaces, including the global namespace. (That's a good sign that the solution makes sense).

Here's is the solution:

- Have current version of components in one namespace.
- If there's an update to a component, that is not compatible with the current version or if you need to keep the old functionality for some reason, move the old component to a new, child, namespace. (Remember the XML class?)
- That's it. What's left is just deciding on a naming convention for new namespaces, which will host old versions.

This way, current version of components are always in a single namespace. One namespace to rule them all, no need to deal with multiple namespaces. (And if you use the global namespace [1], no need to deal with any namespace at all).

You may think that this solution can cause problems when migrating old code. Every solution has its drawbacks. You have to prioritize your goals. It may seem it's better to have old code compile as it did and then upgrade to new components step by step, or, maybe it's easier using new components by default and then fixing any problematic areas and even falling back to older versions if necessary...

Some code was compiled with a certain version at a certain point in time... I don't consider it as the top priority, to be so much backwards compatible that it should compile the same now and ever, without any effort.

Backwards compatibility is a tricky subject, I'm all for backwards compatibility, but when not done wrong.

This solution scales well, because you don't have to know about any other namespaces unless you need to use an older version of a component. If you have a total breaking change with the whole component set, not compatible with the older version in any way, then you should move the old version to a new namespace and have the new version where it should be (that is, the one and only namespace where you have your current version). Not a special case. Simple and simply beautiful.

(You can still apply this solution to the current namespace components are in),

Anyway, you can argue if this solution is better or not (I really don't have the time to elaborate on this at the moment).

If prefixes were used, in the global namespace, this solution would be implied, as you can't open another global namespace for a new set of components, and it will easily occur to anyone having Fx2, Fx3, whatever prefixes is not a good solution. (But somehow people think having new namespaces like s1, s2... is better [2], or will not ever happen - and you could have chosen a one letter prefix too).

In summary, IMO namespace solution not only ruined the initial goal (of promoting components to the global namespace), it ruined the way how new components should be handled. Welcome to the namespace soup!

[1] Obviously I'm assuming there will be one set of components in primary use.

[2] With namespaces, compiler can ease some syntax issues. Nevertheless, if you are in a position to use Fx3 as a prefix, then s3 would be the correct corresponding namespace name to use.

Prefixes vs. Namespaces... You need to ask the right question to get the right answer...

Update (2009/06/02): It turns out some of my understanding about this issue was wrong. I've never been a Flex guy. I will keep this post as is below. My current understanding is that "promoting components to the global namespace" was not the goal, but only a side effect. Albeit a very important one IMO. So, this post still has a point.

Without any rant on (custom) namespaces, here's why I think using prefixes would have been the right decision, and probably the only viable choice.

First of all, using prefixes (or suffixes or any other naming convention) is not too different than using a namespace.

With prefixes, you are creating a namespace yourself without the compiler knowing about it. With namespaces, compiler knows about this, so it can provide some minor benefits in return (like access restrictions, or some easy syntax).

That's all the difference there is, other than of course you may think namespaces are neater.

Many file systems solve name collision issues using folders/directories. Folders (read namespaces) are helpful for organizational purposes too. You may prefer all your files in a single folder, or you may create folder in folders in folders until each final folder contains a single file. That usage is not related to solving name collision problems.

You don't usually think about namespaces when using folders, like "Now, I'm copying this file into this folders namespace", you just "copy the file into a folder". In the real world, we name different things the same all the time, and we solve name collision issues that follow without thinking about namespaces.

In nearly all computer languages, there are namespaces that the compiler or interpreter deals with whether you are aware of it or not.

So, if namespaces are already in the language, when can a prefix be a better solution? Is this just a personal preference (ignoring minor benefits each provide)?

Let me first state again that there are no problems with using prefixes that would be a disadvantage for long term use, that namespaces don't have, as far as name collisions are concerned, because they are not that different. (If there comes a time you feel you need to change the prefix like to Fx1 or to Fx2, that's also exactly when you would be changing the namespace if you used namespaces).

The Right Question
I'm not a Flex guy. As I see it, on the surface, the question asked is/was:

"There may be a name collision issue, how should it be fixed? Using prefixes or namespaces?"

And the natural answer is "Why not use namespaces? Their main use is avoiding name collision issues and they are there in the language".

But why was there a possibility of name collisions, in the first place?

You don't have name collision issues everyday, because usually the languages provide default namespaces using the file system structure, this handles them well and transparently. AS3 and similar languages use the whole path from the root, so you cannot have files in arbitrary folders. In many languages, only file name is used. In that case, you can put your files in arbitrary folders as you like, but you cannot have two files with the same name in the same project.

So the question asked as "Namespaces or Prefixes?" needs more context, to get the right answer rather than a generic one.

Components were being promoted to the global - root - top namespace, where you wouldn't have to state the namespace at all. Identifiers in that namespace are first class citizens and this was a worthy goal.

When I had an Amstrad CPC464 as a kid (and a VIC20 before that), some of my friends had Spectrum 48Ks, some had Commodore 64's. To us, the computer was the keyboard. And, well, it was.

When I first heard about C, from a friend, he said: "Everything in C are functions, so cool. The language does not have any features, you use external libraries for everything". For us, at the time, a language was something that came with a standard library built into that language, just like having the computer built-in in a keyboard case.

Most of the time languages do have standard libraries, or certain built-in objects etc. You may see the difference, but you may also think of them as a part of the whole language experience, as a part of the language.

Functions you use without using a namespace, can be seen as a part of the language itself. This is not too wrong, with every class or function you write, you are extending the language (in a sense).

So, some class being promoted to the special, top namespace is something important. This is like not like moving a class from this namespace to that other ordinary namespace...

 - GOAL: Promote these classes to the top, global namespace.
 - OK, but what if we have a name collision issue there.
 - Prefixing should solve this 99%.
 - OK, but we have namespaces to solve name collision issues. They will also solve the issue 99%, and they are neater.
 - Sure, but what was the GOAL again?

You see, if your goal is promoting some names to the special top namespace, you cannot solve any name collision issues you anticipate, by putting them in another namespace.

So, the question is not about prefixes vs. namespaces. Using another namespace is not a viable option for solving name collision issues in this case.

The correct question is: "Should certain components be promoted to the top/global namespace?". Using namespaces is just giving up on the idea. It's a defeat. Assuming, you want to do the change, because you don't like using prefixes, and because you care about name collision issues, you just abandon the feature.

You may argue that top/global namespace should be kept clean. I have a lot to say on that too, but in another post, if I can find the time.

Do you really have to give up standards for simplicity?

Yes, absolutely, when it makes sense to do so.

I'm amazed how humans seek approval of an authority and feel comfortable when they have it.

Lets take W3C recommendations. A committee decides on something and many people think of them as rules, laws (kind of like god made), they do not try to understand the reasoning behind them, they just accept them as they are.

I have blogged about this before. According to my criteria many W3C 'standards' are totally wrong, and to my surprise it's no secret how they do things and why. Still, many people don't want to think one step further. I believe many will have agreed with me, if they really gave a minute of thought on the subject.

(BTW, Scott Adams' Power of Ridiculous Reasons is a good read).

What are standards? Why are the standards as they are? Why is something a standard?

QWERTY keyboard layout was designed to slow the typer (at the time of mechanical typewriters, to avoid jams). It's the standard layout many of us still use, though we will like to type faster and there's no jamming issue with our current computer keyboards.

If faster typing is your goal, when you hit the QWERTY layout barrier, you should question the standard. What was the reasoning, did it ever make sense, does it make sense now?

I can agree to disagree - afterall, we are all different, we can't agree on everything. But defending an argument by mentioning 'standards' really doesn't make an impression on me.

I value simplicity. If some standard is making things unnecessarily complicated (when there's a clear simple choice with no drawbacks), I will question the standard first rather than give up simplicity.

Of course, I'm not saying that simple is always better:

"Make everything as simple as possible, but not simpler." -  Albert Einstein

You have to recognize it when it is better, and not simpler than necessary.

Einstein also said:

"Any fool can make things bigger, more complex, and more violent. It takes a touch of genius -- and a lot of courage -- to move in the opposite direction."

And while at it, the following is one of my favorite quotations, from Einstein:

"Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."

[This post is not an answer to another post - hence no link. It's just that a sentence in a blog post inspired me to write about this. Still let me state what I think about namespaces vs. prefixes again:

- IMO Namespaces do not solve any real problem. They solve artificial problems.

- There's something that looks elegant and cool about namespaces, just like some furniture that looks great but has awful functionality. Deceiving, I say. Must think one step further.

- Using a prefix is inherently simpler and better than using namespaces. (Assume there was no namespace type. If a simple prefix solves the problem, you don't need namespaces at all).

- As I don't think namespaces are any good, and should not ideally be in a language as a type, even without any context, if one solution makes use of namespaces and the other does not. I'd say that the other solution is better.

- When you need to use a prefix, you just do it. There is no problem to write home about. Even if you think there is a problem, it exists only for a tiny moment until you realize you can use a prefix. Prefixes are not features of a language, they are just naming conventions. What do you do when you realize you have redefined a local variable named "a" a second time, and the compiler is not happy about it? Define namespaces to fix the name collision, or, just rename the new variable "a" to "b"?

- I value backwards compatibility very much (maybe more than most). But you don't have to be consistent if you are moving forward. (Take AS1/2 and AS3. Flash player runs AS1/2, but AS3 is not consistent with AS1/2).]

I don't believe in NameSpaces

I've been professionally programming for more than 20 years [1] and I've never needed to use a namespace.

I do know what a Namespace is. I think I shouldn't have.

Rarely, when the compiler cannot figure out what variable or function I'm referring to, it just signals an error and I fix this by writing the qualified name. That's all there is and there should be to it.

Of course namespaces can be there as leaked abstractions of implementation details. Ideally, a programmer should not know about them [2].

Why? Because, they don't help much, don't have much use, They are extra things to learn and complicate things unnecessarily. (Objects as abstractions actually help programming, Namespaces don't). (And there are XML namespaces, which I don't like in a different way).

Namespaces in a programming language solve an artificial problem and they create a bigger problem than they solve.

Still you may like them. But if that's the case, can you tell me how these fit in a scripting language that doesn't have a pointer type or memory management (by user)?

The first time I heard about 'Advanced' data structures called linked lists(!), I was surprised but later this made sense [3].

ActionScript should be simple. A namespace soup complicates things without much, if any, benefit in return. I don't think any language needs a spelled out Namespace type but scripting languages more so [4].

But we do have namespaces in AS3. I'm not proposing that they should be removed (Backwards compatibility is important). They just should not be made to look like a fundamental property of the language. Someone who has never heard of namespaces should be able to program in AS with no side effects caused by language design. This will make AS better than the rest [5].

Luckily, currently the situation is not hopeless, you can do without namespaces most of the time. What I'm afraid is the future directions.

I call namespaces  the unnecessary evil ...

[1] Actually 21. I've programmed in Basic, Z80 and 80x86 assembly, C, C++, Delphi Pascal and briefly in Cobol, Fortran, Lisp and Prolog. I won't bother listing numerous scripting languages.

[2] C++ has many features that many programmers don't know and care about. You can do without them and this is totally OK with me.

[3] Linked lists are simple data structures, not advanced.

[4] In AS3 there are some features that make use of namespaces which IMHO should have been implemented in other ways.

[5] Computer language design is my hobby. It's one of the two subjects I feel like I'm truly qualified to talk about. Of course, you are free to disagree. But my thoughts on language design has many years of background and it's unlikely that I will change my opinion on namespaces.

The change from Fx prefix to namespaces is an EPIC FAIL for Flex

I borrowed the title from Aral's original post, couldn't think of a better one.

I don't know Flex as much as some do, but I know other things and I know Aral. So what can I add to his excellent post?

People defending the change mention a voting by community. I have a problem with this.

Public/community vote at best can get you to the mean. If you have no idea, no vision, just listen to the community and you will soon become the average.

Leading products are not developed this way. True leaders don't work this way.

You should have a vision and you should evaluate each change according to that vision. If you want to sell more products and make more money, in the short term, (or if you have no vision of your own) it's fine to be lead by the community.

Sometimes you act against the wishes of the community, that's when truly wonderful things happen, and the community appreciates it in the end. Of course, this is the risky option, but it's the only option that may bring those results.

As Aral mentions, simplicity is a key factor. The problem is not 'not making things more complicated', it is ' making thing simpler'. AS3 already has a steep learning curve compared to easy use nature of AS1/2. This is a problem on the table, that hasn't been addressed yet (I expected at least some work towards this with CS4).

Both Adobe and Microsoft tried to beat Flash in the past, and failed miserably. You can't beat MS by trying to be more like MS. You can't beat Java or .Net by trying to be more like them. Does Flash/Adobe wants to beat Java in the first place? Do they have the vision? I've been losing my faith in that lately.

Addendum:

I must add, I don't think 'Fx' was a good choice as a prefix. Too long and sounds like 'effects'...

What's wrong with the Flash Platform?

When Microsoft bought FoxPro, leading database app of the day, in 1992, I remember, an intriguing question among programming community and geeks was whether MS will use the Watcom compiler, which was used for building FoxPro to that day, a compiler which was state of art at the time and better, or, use their own inferior MS compiler to build the next version of FoxPro... I never followed-up, and don't know the answer, still the question remains as a fundamental one. (FoxPro was later renamed as Visual FoxPro and died in 2007 at version 9).

A platform needs to be taken seriously. For quite some time Flash (whatever you meant by it) was seen as a toy for creating animations for the web, including the ones that made you look for the 'skip into' link and really annoying advertisements that hid content. Most of the time this was true.

Things improved in time, but it's always hard to change initial perceptions.

I'm now skipping pages of info that may bring the reader up to date with Flash history, for the sake of coming to my point.

I may be seeing what is not there... But I see the Flash Platform as the main platform of the future: OS-wise cross-platform, on both desktop and web, and on other devices... "Flash Platform" is not "Flash" (whatever you understand by it). You can't consider something as a platform just because you can write RIAs for it or it has a desktop component, or just because you have a few different editions. It's bigger than that. It has to be...

Java started with the promise of making apps that you write once and run everywhere. As I see it, it failed to achieve this. I see Flash replacing Java, achieving this initial goal. I see Java (not JavaFX) as a rival to Flash as a platform...

The developer types who were expected to jump into Flash train with Flex were mainly Java developers, as Java is also a scripting language, just like actionscript.

How do you convince a Java developer that Flash (platform) is better? Will you have any answer when he reminds you that 'recommended professional developer tool', now named 'Flash Builder', is just a plug-in for Eclipse [1], which is build primarily in Java? Will you have an answer when he mentions that the AS3 compiler is also build in Java?

If I were a Java developer, at best I'd say Flash might be better for 'animation and stuff' only. If Flash Platform relies on Java, then it's inferior to Java, as a platform, no need for further discussion.

I don't think embracing Java is an option for Flash Platform. Flash will be the platform of choice and the better one, or it will be a toy animation platform (with some scripting capability). I don't consider being open source or not coming from MS as valid reasons for embracing Java. Also I cannot picture a stable co-existence, with similar usage ratios, being 'second best' is not an option I will be content with.

With AS3 and JIT, as I had written before, I was hoping the AS3 compiler would be in AS3... AFAIK, this has not happened yet. For this reason, professionally as a programmer, I don't consider actionscript as mature. If actionscript is a serious language (even though it's a scripting language), it has to have a compiler written in actionscript (this is my idea for maturity, you are welcome to disagree).

As I see it, for success, Flash Platform should get rid of any reliance on rival platforms (Java, .Net etc.) as soon as possible. (3rd party tools are OK, after all, they are additional tools. I think a platform should provide at least basic building tools, sufficiently advanced, that does not rely on rival platforms. [As soon as possible may mean years - but I believe this should be the agreed goal]).

Silverlight is not a rival to Flash Platform, .Net is. Silverlight is the toy animation [2] part of (web part of) .Net Platform. I believe Flash, as a platform, should have bigger goals than beating that.

People ridiculed Microsoft, when they used Flash rather than SilverLight for promoting some stuff. I'm surprised I'm not seeing anyone mentioning Java use with Flash. Is Java a better programming platform, and Flash Platform is really only a sub-platform for animation (and maybe minor RIA stuff)? Is this the planned and expected future role for the Flash Platform?

Is it because it's so obvious that Flash will ditch Java use when the time comes, that nobody mentions it? or are my expectations for the Flash Platform unrealistically high? I wonder.

I can write more, but I think I made my point.

Watcom C compiler went to Open Source heaven in 2000. Borland C++, which was considered better than Microsoft Visual C++ compiler (MSVC) by many in its time, died even before Watcom. Whatever route MS took then, when building next FoxPro version in 1992 doesn't really matter now. Today, MSVC is alive as it can be at version 10 (as preview, to be released)...

(And I now think blogging more is sure to make me unpopular, so I will stop).

[1] I don't mean to show disrespect to "Flex Builder" developers (both actual developers and people using it). Sorry if I sounded rude,  it was to make my point clear. I think "Flex Builder" should be a native or Flash application, in principle. I don't 'demand' it to be done 'now', but I believe this is something everybody involved should know and agree and expect as a realistic future goal: A better IDE than Eclipse in every way, written in actionscript, running way better than any Java app can run, in Flash VM... (Same applies for the AS compiler).

[2] Obviously SilverLight (or Flash) is more than just a 'toy for animation'. The usage is for making my point, hopefully, more clear.