I’m now on Twitter

I’m still trying to get the feel of it, but I’ve decided that I like it. You can follow me or tweet me a welcome.

Thanks to the warm welcome I have already received.

BTW, ‘Go screw yourself Apple‘*.

Misc. 2 Comments

Happy New Year!

Happy New Year! [end of post]

Click to continue reading “Happy New Year!”

Misc. Comments Off

‘Apple App Store is an ongoing karma leak’

"How did Apple get into this mess? Their fundamental problem is
that they don't understand software."

An excellent essay by Paul Graham.

Misc. Comments Off

Prefixes vs. Namespaces… Conclusion

… So why have I been posting about this if this is beating a dead horse? I have a solution proposal, which I’d say will give us the best of both worlds…

Click to continue reading “Prefixes vs. Namespaces… Conclusion”

Flash, Flex 3 Comments

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

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.

Click to continue reading “Prefixes vs. Namespaces… Why would the prefix solution have scaled better?”

Flash, Flex 1 Comment

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

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.

Click to continue reading “Prefixes vs. Namespaces… You need to ask the right question to get the right answer…”

Flash, Flex 4 Comments

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).]

Flash, Flex 3 Comments

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 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.

Flash, Flex 8 Comments

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'…

Flex 3 Comments

Accessibility: Is a CC button deaf-friendly?

You learn something each day, sometimes it has a big impact.

Suppose you are designing a FLV video player. Unless the player is to be extremely simple, you will want to support displaying closed-captions/subtitles, either because you are truly accessibility conscious and care about it, or, because you find the idea of displaying subtitles for a foreign language movie cool. Surely, you will want to cover all bases.

Lets start adding captions support to the design:

  1. You will need to have a button, labeled 'CC', that toggles display of captions.
  2. Not all FLVs will have associated captions, so a feature can be to hide the CC button (rather than displaying it in disabled state) when there are no captions available. This will also provide more space for other controls, a slider may benefit from the extra space. [1]
  3. Some people will want to start with captions-on, so you will provide the programmatic interface to start with the CC button already clicked once.

Can you think of any other option? (Other than supporting multiple language tracks) Anything missing?

Until some minutes ago, I wouldn't know the missing option, and the CC button would be the symbol of my accessibility support.

Missing option is having captions on all the time without the CC button to turn them off.

What good is that for? Obviously you could have thought about this, but why would you want it?

Because, at a site for the deaf (which is what accessibility is really all about in this case), a CC button is not considered deaf-friendly. Captions must be present and displayed at all times [2].

Just like the way you (and I) think, 'let's not display the CC button because there won't be captions for some FLVs', you should also think, 'let's not display the CC button because there are times there will be captions all the time and they will never be turned off'.

A FLV player with a CC button, sure, is accessible. But if you really care about accessibility, you should have the option for not displaying that button.

That's what I learned today, from one of our Captionate [3] customers, who is creating web sites targeting deaf consumers, and who himself is also deaf. He is passionate about this. For him, it's not an option to have the CC button displayed, it's inappropriate, it's not deaf-friendly, end of story.

Could I ever, by myself, have thought about supporting captions without a CC button? Maybe… Could I ever have shared the passion about this? I don't think so.

Nothing is as simple as it looks, accessibility included.

[1] Obviously, if you have designed a player that works with different skins, you will want to have skins without a CC button (no captions support) and skins with a CC button that support captions. For the sake of this discussion, this is irrelevant.

[2] 'They can embed captions onto video in that case' will be too shallow thinking,

[3] We do not provide a player for deploying captioned FLVs with Captionate. We do not have a FLV player product.

Captionate, Flash, MG , , Comments Off
WordPress Loves AJAX