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'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 80×86 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.

Colin Moock‘s article at Inside RIA, titled ‘The Charges Against ActionScript 3.0‘ is a must read, especially if you are a Flash developer still trying to migrate to AS3 and find it hard.

The article is really about shortcomings of Flash CS3, rather than AS3, and it has good tips for AS1/AS2 developers.

I agree with 99.9% of what Colin says there.

AS3 made Flash harder to learn. If you are not a Java programmer, I think you’ll agree.

I personally don’t like Java or ECMAScript, not any more than I like XML. But sometimes you have no choice and all in all, AS3 is a fine scripting language, clearly better than AS2 but with a steeper learning curve, for which most Flash developers don’t have the time for.

[I had very high hopes for AS3 until I saw the compiler done in Java. I hoped it would be done in AS3. I still hope there will be an AS3 compiler written in AS3 soon, all Java will be ditched from Flash platform and people will call AS3 the better language and Flash as the platform that replaced Java, accomplished what Java never was able to do (write once, run everywhere, for starters)].

With AS3, Flash got closer to Java developer types, but became harder for the Flash developer types. My understanding was that Flex would handle the Java developer types and RIA end, Flash (the authoring tool) would stay as easy as before. This didn’t happen.

One commenter says:

‘:) this was the same thing we talk to colleagues about the changes to
AS3. The think we do is to make some wrapper object witch gives me some
of the good old functionality from AS2.’

Colin’s article has a getURL replacement AS3 function, which I will start using immediately. Colin says on()/onClipEvent() functions should be back (in an improved form) and Flash should convert to AS3 when exporting. I think that should be the way to go. Flash CS3 already converts timeline code to a class behind the scenes, why not exploit this approach more? Flash, with AS3, should be as easy to use as before, as much as possible. Otherwise lots of Flash developers will be out. (Sure, there may be other, easier to use tools but if Flash authoring tool loses ground, it can’t be good).

Another commenter says:

‘I think most of us who do AS3 40hrs a week for a living just wrote our own libraries to make this stuff easy again.’

‘I don’t want to switch to Flex.  If I have to go to flex why not just use silverlight.’

SWF format has been open since version 3, 1998. It was again May as far I can remember. Now 10 years later, restrictions on using the format is removed, effective as of today, May 1, 2008.

Previous license restrictions were for creating SWF players, creating SWF files was never restricted. I think this was a good idea at the time, nobody wanted multiple incompatible SWF/Flash Players around, also considering the fact that SWF version 3 even had a Java edition player. Now the technology is mature at version 9 – and as I’ve said 10 years has passed. I personally don’t see any danger of multiple browser players gaining ground.

(Another good consequence of this is that you no longer need Adobe Reader to view the SWF specs, Foxit reader now works just fine).

The news came with Adobe Open Screen Project announcement.

Here are relevant links:
SWF Specs at Adobe SWF Tech Center
FLV/F4V Specs at Adobe FLV Tech Center
AMF Specs
ActionScript VM2 Overview (AS3 specs) (PDF)

[F4V is the file extension for HD Flash video, mp4. There's also F4P, F4A and F4B. For playing F4V, Flash player 9.0.115.0 (Flash Player 9 update 3 - MovieStar- released on December 4, 2007) or later is required. Current version of the Player is 9.0.124.0, released on April 8, 2008]