Comments on: The change from Fx prefix to namespaces is an EPIC FAIL for Flex opportunity to concentrate on making Flex 3 to Flex 4 migration seamless http://aralbalkan.com/2202 Passionate geekisms. Fri, 19 Mar 2010 02:32:17 -0700 http://wordpress.org/?v=2.8.5 hourly 1 By: Flash community – moments of 2009 | Peter Elst http://aralbalkan.com/2202/comment-page-2#comment-258974 Flash community – moments of 2009 | Peter Elst Tue, 29 Dec 2009 13:41:41 +0000 http://aralbalkan.com/2202#comment-258974 [...] about Fx prefix versus namespaces in Flex [...] [...] about Fx prefix versus namespaces in Flex [...]

]]> By: Arnoud http://aralbalkan.com/2202/comment-page-2#comment-256209 Arnoud Tue, 16 Jun 2009 03:34:35 +0000 http://aralbalkan.com/2202#comment-256209 The decision was right to to use namespaces The decision was wrong to decide to release an unfinished product with missing components. I'd rather wait a bit longer for a complete release. But adobe needs to make money too... but it is nice that we can migrate one screen at the time as Stefan points out. I wonder how much migration i'll be doing anyway, There must be a really good reasons for it that canot be solved in flex3, otherwise flex3 will do. ah well, at least your blog post became EPIC, he he The decision was right to to use namespaces
The decision was wrong to decide to release an unfinished product with missing components.
I’d rather wait a bit longer for a complete release. But adobe needs to make money too…

but it is nice that we can migrate one screen at the time as Stefan points out. I wonder how much migration
i’ll be doing anyway, There must be a really good reasons for it that canot be solved in flex3, otherwise flex3 will do.

ah well, at least your blog post became EPIC, he he

]]> By: Stefan Richter http://aralbalkan.com/2202/comment-page-2#comment-256125 Stefan Richter Mon, 01 Jun 2009 20:43:26 +0000 http://aralbalkan.com/2202#comment-256125 I need to disagree with the main point of your argument Aral. I think that refactoring a Flex 3 application to Flex 4 (with the use of Spark components) *is* trivial. I'm very comfortable with the use of namespaces, after all that's what I'm used to as a Flex developer. Heck I can even migrate one class a day and my app will still compile and run just fine. How much simpler can it get? I need to disagree with the main point of your argument Aral. I think that refactoring a Flex 3 application to Flex 4 (with the use of Spark components) *is* trivial.

I’m very comfortable with the use of namespaces, after all that’s what I’m used to as a Flex developer. Heck I can even migrate one class a day and my app will still compile and run just fine. How much simpler can it get?

]]> By: Ben Stucki » More Flex 4 and the Boy Who Cried EPIC FAIL! http://aralbalkan.com/2202/comment-page-1#comment-256122 Ben Stucki » More Flex 4 and the Boy Who Cried EPIC FAIL! Mon, 01 Jun 2009 19:19:05 +0000 http://aralbalkan.com/2202#comment-256122 [...] use all the cool new features and components, but I didn’t go into a lot of details. However Aral’s blog does have information on what I might expect when I start to use spark components. Simply compiling [...] [...] use all the cool new features and components, but I didn’t go into a lot of details. However Aral’s blog does have information on what I might expect when I start to use spark components. Simply compiling [...]

]]> By: Natasha http://aralbalkan.com/2202/comment-page-1#comment-256116 Natasha Sun, 31 May 2009 17:08:31 +0000 http://aralbalkan.com/2202#comment-256116 > Simplicity is not something to be ashamed of. It does not make your Code Fu any less > if you have simple tools and languages to work with. Simplicity is what everyone wants and aims for, but speak for yourself Aral. I don't know what you are working and you certainly don't know what we're working on. In terms of natural language, speaking like a caveman may be simple, but it doesn't make it easy to communicate. A language like English is highly complex, but if you know it communicating becomes easy. Simplicity doesn't necessarily = easy and complexity doesn't necessarily = difficult. Many computer language features evolved to solve real-world problems. Faced with simple tools, people can and will do the most incredible things, in spite of their tools. But because I can hand-wash my clothes and would do just as good a job as the machine, would I want to? If someone else doesn't understand how to use the machine, my heart bleeds for them, but I've got better things to do with my time and the complex tools I have evolved in order to free me to get on with something meaningful. Complexity is nothing to be ashamed of either. With complexity I can build my own simplicity. That's what object oriented programming gave us. Or I can buy someone else's complexity to simplify my life. As the complexity of Actionscript has grown, our productivity has shot through the roof. > It [simplicity] just makes you all the more productive and lets you concentrate on crafting that > most important part of your application: the user experience. Kind of like building the space shuttle using stone age hammers and clubs would let them concentrate on the visual design? Sorry Aral. I respect you but this is all populist nonsense. > Simplicity is not something to be ashamed of. It does not make your Code Fu any less
> if you have simple tools and languages to work with.

Simplicity is what everyone wants and aims for, but speak for yourself Aral. I don’t know what you are working and you certainly don’t know what we’re working on. In terms of natural language, speaking like a caveman may be simple, but it doesn’t make it easy to communicate. A language like English is highly complex, but if you know it communicating becomes easy. Simplicity doesn’t necessarily = easy and complexity doesn’t necessarily = difficult.

Many computer language features evolved to solve real-world problems. Faced with simple tools, people can and will do the most incredible things, in spite of their tools. But because I can hand-wash my clothes and would do just as good a job as the machine, would I want to? If someone else doesn’t understand how to use the machine, my heart bleeds for them, but I’ve got better things to do with my time and the complex tools I have evolved in order to free me to get on with something meaningful.

Complexity is nothing to be ashamed of either. With complexity I can build my own simplicity. That’s what object oriented programming gave us. Or I can buy someone else’s complexity to simplify my life. As the complexity of Actionscript has grown, our productivity has shot through the roof.

> It [simplicity] just makes you all the more productive and lets you concentrate on crafting that
> most important part of your application: the user experience.

Kind of like building the space shuttle using stone age hammers and clubs would let them concentrate on the visual design?

Sorry Aral. I respect you but this is all populist nonsense.

]]> By: Aral http://aralbalkan.com/2202/comment-page-1#comment-256111 Aral Sat, 30 May 2009 13:11:49 +0000 http://aralbalkan.com/2202#comment-256111 @Keith: Please read my note regarding the definition of migration. Simply compiling a Flex 3 app with the Flex 4 SDK is not migration. Refactoring your Flex 3 application so that you can enhance it with Spark components is not trivial and that's the definition of migration that we need to adopt as that's the real-world use case for migration (it doesn't matter whether or not you can compile your Flex 3 app with the Flex 4 SDK if the first Flex 4 feature you're going to use is going to require a far more extensive refactoring of your codebase to migrate it to a Flex 4 project utilizing both libraries.) @Keith: Please read my note regarding the definition of migration. Simply compiling a Flex 3 app with the Flex 4 SDK is not migration. Refactoring your Flex 3 application so that you can enhance it with Spark components is not trivial and that’s the definition of migration that we need to adopt as that’s the real-world use case for migration (it doesn’t matter whether or not you can compile your Flex 3 app with the Flex 4 SDK if the first Flex 4 feature you’re going to use is going to require a far more extensive refactoring of your codebase to migrate it to a Flex 4 project utilizing both libraries.)

]]> By: Dan Orlando http://aralbalkan.com/2202/comment-page-1#comment-256110 Dan Orlando Sat, 30 May 2009 13:01:39 +0000 http://aralbalkan.com/2202#comment-256110 Aral, your points are all completely legitimate in both the original and updated posts. I agree that its time to move on as well, and focus on whats really going on... Moreover, I agree that there is a core underlying issue architecturally, and it has been made clear to me personally that the product managers are aware of this "Epic Fail" - and by the way, exaggeration or not, I like the extreme nature of that verbiage. For petes sake, that little 2-word phrase attracted more attention than any blog titles I've seen in a hell of a long time! (lol). More importantly, the attention is warranted. Based on my studies, it is questionable as to whether or not the use of namespaces in this context is consistent with the original intent of namespaces in the first place, and I have yet to hear any disagreement from anyone on that. Generally, a namespace is an architectural tool to be used during application development in order to avoid conflict with the naming conventions of the framework. They're not meant to separate code libraries within the framework itself. Like I said though, I'm pretty sure everyone involved with the Flex SDK team is aware of this, and I would not be surprised if Flex 5 is a complete overhaul of the framework. Aral, your points are all completely legitimate in both the original and updated posts. I agree that its time to move on as well, and focus on whats really going on… Moreover, I agree that there is a core underlying issue architecturally, and it has been made clear to me personally that the product managers are aware of this “Epic Fail” – and by the way, exaggeration or not, I like the extreme nature of that verbiage. For petes sake, that little 2-word phrase attracted more attention than any blog titles I’ve seen in a hell of a long time! (lol).

More importantly, the attention is warranted. Based on my studies, it is questionable as to whether or not the use of namespaces in this context is consistent with the original intent of namespaces in the first place, and I have yet to hear any disagreement from anyone on that. Generally, a namespace is an architectural tool to be used during application development in order to avoid conflict with the naming conventions of the framework. They’re not meant to separate code libraries within the framework itself. Like I said though, I’m pretty sure everyone involved with the Flex SDK team is aware of this, and I would not be surprised if Flex 5 is a complete overhaul of the framework.

]]> By: Keith Peters http://aralbalkan.com/2202/comment-page-1#comment-256109 Keith Peters Sat, 30 May 2009 12:43:34 +0000 http://aralbalkan.com/2202#comment-256109 Seems to me that one of your big points is that this is going to be difficult for people to figure out and "all the more confusing for people new to the Flex platform". But people have shown that it's trivial to compile a Flex 3 app in Flex 4, and not too hard to migrate a relatively simple Flex 3 app to Flex 4. Isn't this most likely the kind of thing "people new to the Flex platform" are going to be doing? Or, if they are really new, they are just going to be starting straight from Flex 4. Yes, I guess a hugely complex app will be more difficult to port over, but give people some credit. They had the smarts to create a hugely complex app. I'm sure they will be able to grasp the concept of multiple name spaces. Seems to me that one of your big points is that this is going to be difficult for people to figure out and “all the more confusing for people new to the Flex platform”. But people have shown that it’s trivial to compile a Flex 3 app in Flex 4, and not too hard to migrate a relatively simple Flex 3 app to Flex 4. Isn’t this most likely the kind of thing “people new to the Flex platform” are going to be doing? Or, if they are really new, they are just going to be starting straight from Flex 4.

Yes, I guess a hugely complex app will be more difficult to port over, but give people some credit. They had the smarts to create a hugely complex app. I’m sure they will be able to grasp the concept of multiple name spaces.

]]> By: Aral http://aralbalkan.com/2202/comment-page-1#comment-256108 Aral Sat, 30 May 2009 12:30:40 +0000 http://aralbalkan.com/2202#comment-256108 Note: article updated, "EPIC FAIL" retracted; let's move on and address the core issue here which is that making Flex 3 to Flex 4 migration seamless is in all our interests. As such, please read the note at the top of the post and also my follow-up post. Thanks! Note: article updated, “EPIC FAIL” retracted; let’s move on and address the core issue here which is that making Flex 3 to Flex 4 migration seamless is in all our interests. As such, please read the note at the top of the post and also my follow-up post. Thanks!

]]> By: Erwin Verdonk http://aralbalkan.com/2202/comment-page-1#comment-256105 Erwin Verdonk Sat, 30 May 2009 12:08:22 +0000 http://aralbalkan.com/2202#comment-256105 Aral, instead of blazing your frustration to the community like this, can you give us some concrete examples to your problem? What do you file under "extensive namespace changes"? Really, I think you're making this way bigger than it is :). Aral, instead of blazing your frustration to the community like this, can you give us some concrete examples to your problem? What do you file under “extensive namespace changes”? Really, I think you’re making this way bigger than it is :).

]]>