« I don't believe in NameSpaces | Main | Prefixes vs. Namespaces... You need to ask the right question to get the right answer... »
May 30, 2009
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).]
May 30, 2009 in Flash, Flex, Language design | Permalink
TrackBack
TrackBack URL for this entry:
http://www.typepad.com/services/trackback/6a00d8341c73d553ef011570b0c53e970b
Listed below are links to weblogs that reference Do you really have to give up standards for simplicity?:
Comments
I still dont see the problem with namespaces...
If you use a single namespace, you can continue using prefixes no problem...
However when 10 different developers make a component called SuperButton isn't creating a new namespace a much better faster more organized and elegant solution than renaming the whole thing?
The Fx prefix will work now, but as many people have said, then what.. Fx2, Fx3, Fx4?
That may still seem OK to you, your choice of course.
However all you have stated are your personal preferences, the more important thing is the reason behind your statements... care to state those?
-How are the problems artificial?
-How are namespaces deceiving?
-Namespaces weren't needed before they were invented, like hospitals werent needed before they were invented. We could just busy the ill people, see what a simple solution!
-Again WHY?
-What if you combine code from one application to another, and there are hundreds of collisions in names? rename? really?
Posted by: Xitij at May 30, 2009 12:06:59 PM
Hi Xitij,
Thanks for the comment. I considered writing a blog post about this, rather than answering here, but it turned out I don't have the time to work on writing a short version.
Then I wrote a long reply here, skipping some details. Then I deleted it because it was not good enough.
Maybe I will blog about all this in bits, in time.
So below is a very short reply, which may not be satisfactory, but will make my position more clear.
- When we name two different things the same, we need a context to differentiate them.
Name collisions are natural, they are everywhere and we can deal with them without thinking of namespaces. We deal with them naturally, without thinking, using commonsense.
In primary school, at the age of 5, me and other kids called our friends who had same common names, using either nicknames or by their family names. At that age, I didn't know about namespaces. I didn't have to.
In programming, usually file names, or even paths, solve the context problem.
When you import a file, you don't have to think you are importing the namespace of the file. Every file (or logical unit) already has a namespace assigned in a natural and logical way, which you don't have to think about.
A namespace is something a compiler deals with. Programmers deal with files. They shouldn't have to know about namespaces.
I'm totally OK with the concept of namespaces, solving name collision problems, *transparently*.
Namespaces, as I described above, solve name collision problems. You don't solve another problem using these namespaces.
- When I say namespaces are no good (not worth the trouble), I mean *custom* namespaces - "a namespace type" in a language, which you can use to create namespaces out of nowhere, not tied to a file etc. and which are not consistent with existing namespaces.
They are used for solving access/visibility issues. I think that kind of usage should be implemented in another way (necessary features for this currently does not exist in AS3).
They are used for overloading on steroids. I think this leads to bad programming practices. I also think even simple overloading is too powerful for a language like AS3.
They are used for solving certain name collision issues. But this is just because there is a namespace type. I also think there are better solutions for this kind of usage.
There are other uses, not really worth mentioning.
I think they are not worth the trouble, as they are in AS3. On the other hand, a full featured namespace manager object could be very powerful.
- In summary, I'm OK with namespaces that you don't have to know about, but not with solving issues using namepaces just because you have the type there in the language.
> The Fx prefix will work now, but as many people have said, then what.. Fx2, Fx3, Fx4?
If you will need to change the prefix, then when you use namespaces, you will need to change the namespace too.
If this is not the case, then this means this is not a namespace issue to begin with (and so using namespaces to solve it is not appropriate).
A custom namespace can be considered as a prefix, not in the actual name, but as a qualifier. Which way you prefer does not really make much difference, and I will prefer the simplest way every time.
The difference is that when you use custom namespaces rather than naming conventions like prefixes or suffixes, the compiler knows about them. This way, it can restrict access, or provide a simpler syntax. IMO access restrictions should be implemented in other ways, and I don't care much about any easy syntax. I'd prefer not having to think about namespaces than have their few benefits. (Also with namespaces, as in AS3, you can perform overloading, which I think leads to bad programming practices).
Best,
Burak
Posted by: Burak KALAYCI at May 31, 2009 3:33:33 PM
Hi,
Thanks for the explanation!
I am of course still not convinced, but I find your explanation satisfactory to the degree that i understand your position. Although it is not one I share.
Unfortunately for you a majority of people seem to feel namespaces are a better solution and you may lose out in the midst.
I guess it is about how each individual sees things...
Faced with the situation of two people with common names, I would see it as two people sharing the same name, however in different namespaces of their surnames, their families.
As such they can be called by their first name alone in their respective homes, but when mixed together they need to be fully qualified with their "namespaces".
There is no good solution and bad solution, different solutions appease different people.
You have a point when you say that it should be handled transparently. I think for the most part it is, however I dont have THAT much experience I guess.
Support for both, adding prefixes, which is basically renaming, and using namespaces is already there in the language.
I find namespaces better in this scenario due to the fact that new components are not being added, instead old ones are being replaced.
Posted by: Xitij at May 31, 2009 5:48:04 PM
