Apple’s explanation (and seemingly, justification) for this atrocity of a feature is that “content should move in the same directions as your finger”. Now that’s all well and good, except for one thing; there is no “finger” when using a mouse. Touch- and mouse-driven are distinct input paradigms.

Apple is correct in that in a touch-driven system content should indeed track in the same direction as the user’s finger moves. If a hypothetical touch-based interface were ever released which scrolled content in the opposite direction of the user’s finger, then people would say that it was broken. And rightly so. Moving content in the same direction as the touch is the intuitive operating mode of a touch interface.

Similarly, moving content in the opposite direction of the scroll (or more accurately, moving the scrollbar in the direction of the scroll) is the intuitive operating mode for a mouse-driven interface. And it follows that Apple’s mouse-driven interface in Lion is just as broken as that hypothetical touch-driven interface would be. By Apple’s logic scrollbars themselves should also be inverted, tracking from the bottom of the scrollbar to the top as the content scrolls from top to bottom. Confused yet? Apple’s blunder here is that they have conflated mouse-driven input with touch-driven input, without bothering to translate properly between the two.

As an interesting aside, a comparable analog to touch-style scrolling does exist in the mouse-driven paradigm; the drag operation. You’ve probably seen it in things like Adobe PDF documents, and it can also be observed on any scrollbar. In the drag operation you choose an anchor-point, and then that anchor point moves in the same direction that you move, and it all intuitively makes sense. The problem with scrolling using a scroll-wheel is that it has no anchor point from the user’s point of view (they have done nothing to nominate one, and the UI does nothing to indicate that one has been chosen). In the mouse-driven paradigm, scrolling is a distinct operation from dragging, and by conflating the two Apple has broken their interface. At least until they start incorporating a touch-screen into every computer they sell.

If Apple’s position is to be taken seriously, then we must accept that the current cursor position must always represent where the user’s “finger” is. There’s one major problem with that, however. With a mouse and cursor, the cursor never leaves the screen. And if the user’s finger is in constant contact with the screen, then why should there be a separate scroll operation at all? It would logically follow (since mouse-driven == touch-driven and cursor == finger in Apple’s world) that since a touch-point exists, and since it is moving, the content (all of it, everywhere) should simply scroll whenever I move the mouse (all the time, everywhere). But of course that is nonsense, and so is Apple’s “natural scrolling” mouse behavior. The mouse cursor is not a finger, it does not represent a finger, and its location is not where your finger is touching. Mouse-driven and touch-driven are different modes of operation, with different intuitive behaviors.

Thankfully, you can turn off “natural” scrolling and rid your OS of its nonsense. I’ll be happy to turn it back on when my mouse is replaced with a touch-screen display, but until that day comes you can forget about it. Apple, please stop trying to convince me that moving my mouse cursor around the screen is supposed to be the same thing as dragging my finger all over a touch screen. It isn’t, and I’m not stupid enough to be convinced that it is.

But sadly, Prototype decided to use ‘$()‘ as the name of their alias. And even worse, other frameworks have followed in this pattern, adding their own dollar functions that have semantics that can be completely different from the original ‘$()‘ introduced by Prototype. Consider jQuery, which introduces its own version of ‘$()‘ which can be used to find (and wrap and clone) elements in the DOM by a number of different criteria, but which sadly fails miserably when given a string containing a literal element id. This creates a lovely situation where now the developer cannot even guess at what ‘$()‘ is actually doing without first checking to see which framework is being used by the code. It also means that any code that was written using Prototype’s ‘$()‘ will be broken by including jQuery (and vice-versa).

“But that’s what ‘jQuery.noConflict()‘ is for”, you say. But you miss the point. It shouldn’t be necessary for ‘jQuery.noConflict()‘ to exist in the first place. If the jQuery developers hadn’t decided that it would be cute to define their own version of ‘$()‘, then jQuery would never conflict with anything except possibly an older version of jQuery. The thing that really baffles me is how so many developers (obviously talented developers, at that, considering the work that goes into something like Prototype or jQuery) can all decide that it is a good idea to try to lay claim to a name that exists in the global scope. Granted JavaScript does not have any concept of a proper namespace, but if jQuery limited itself to only setting properties on an object named “jQuery” and Prototype did the same on an object named “Prototype” and so on, the current JavaScript landscape would look ever so much more sane.

And of course, this says nothing of the ‘$$()‘ and ‘$F()‘ functions that were also introduced by Prototype (and the ‘$E()’ and ‘$ES()’ functions inexplicibly introduced by MooTools) and whose names are so semantically worthless that a developer has no hope of inferring their function without consulting the reference documentation. Which again can only be accomplished after checking the entire codebase to determine which framework it is that is defining these functions with its woefully awful naming convention.

If the developers of Prototype, jQuery, Mootools, and the like wanted to turn JavaScript into an unreadable and unmaintainable mess of a language like Perl, then I applaud them for their efforts. But if not then I call them all out on their atrocious naming convention and design decisions. There is no excuse for this nonsense. If you’re building a JavaScript library or framework, then pick a reasonable “namespace” to use for it. This namespace should be the only thing that you bind in the global scope. Everything else that is part of your library should be bound as a property inside of this namespace. And there should be no automatic creation of shorthand aliases in the global scope.

I don’t think this is too much to ask. And of course, any developer that wants to use a global shorthand alias can always do:

window.$J = jQuery;
window.$P = Prototype.$;  //or:  window.$P = document.getElementById;

It takes all of one line of code to set up an alias. But when you start doing this automatically for everyone that uses your framework you create nothing but problems. Especially when you jump on the bandwagon and choose the same crappy shorthand alias names that other frameworks are already using.

There is absolutely no reason why multiple JavaScript frameworks should all be competing over the same terrible function names. This isn’t a contest to see who can break the most legacy code, or who can come up with the most obtuse API. They do have such contests if you are interested in such a thing, but this is not one of them. The only thing accomplished by parading the dollar sign around as an example of a well-chosen function name is an increased brittleness in the code that glues together the majority of our modern websites. It muddies semantics, and creates cases where completely unrelated libraries are not easily compatible with each other, and where simply importing a new library can cause existing code to break. Even worse, some novice developers get the wrong idea from all those dollar signs flying around think that they need to (or should) prefix all of their function names with “$”. So let’s put this bad practice to bed before it’s too late.

So please, can well all stop writing frameworks that give people the impression that calling a function “$”, “$$”, “$ES”, or “$anything” is a good idea? Is it so difficult to choose a reasonable namespace, minimize the number of things that you declare in the global scope, and allow the developer to define a global shorthand alias for this-or-that utility function if they decide they want to? I think not.

int* pointer1;
int *pointer2;

Both lines are equivalent as far as the compiler is concerned, but when a human being parses these lines intuitively, they say slightly different things. The first line parses as “create a variable called ‘pointer1‘ that is of type ‘int*‘”, while the second line comes across as “create a variable called ‘*pointer2‘ that is of type ‘int‘”. One of these interpretations matches the semantics of the language and what the compiler actually does when it processes this code, and the other does not. If you are familiar with pointer types, then you know which is which, and if not then I’ll just tell you that it’s the first version. The first line of code is the correct way to declare a pointer.

Sadly, current coding conventions actually favor the second line. The wikipedia page on this subject even attempts to justify this backwards way of declaring a pointer with the explanation that “when the program dereferences the pointer, it has the type of the object to which it points”. That may hold true in simple cases such as the above example, but now consider the following:

int *functionThatReturnsAPointer();

Am I declaring here a function such that “when the program dereferences [it], it has the type [int]”? No. Even if that made the slightest bit of sense semantically given that trying to dereference a function with the unary ‘*‘ operator is incorrect, it is not what I’m doing. I’m declaring a function that has a return type of ‘int*‘. Not a return type of ‘magic value that if I put a star in front of it will give me an int‘. If we move to a language with slightly different syntax, like Objective-C, the problem with the convention becomes even more pronounced. For instance:

- (NSString*) toString;   //this is a valid function declaration in Objective-C
- (NSString) *toString2;  //this will make the Objective-C compiler very, very sad

- (void) functionWithAString: (NSString*) string;   //also valid
- (void) functionWithAString2: (NSString) *string;  //not a chance

Objective-C does an excellent job of highlighting the problem with the standard convention because in Objective-C the return and parameter types in function declarations must be enclosed within parenthesis. And the asterisk must be included in the parenthesis with the name of the type, because it is part of the type of the object, and not part of its name as the standard convention tries to imply.

And that’s the other half of the justification that is used to defend the standard convention; that by “hiding” the pointer type so that it looks like part of the variable name developers (in particular, novice developers) can use pointer types without having to really understand or think about pointer types. This is bad for a couple of reasons. First off, it’s trying to twist the semantics of the language in a way that is not accurate. And more importantly, it discourages (and/or delays) developers from taking the time to understand what pointer types are and how they work. Yes, pointers can be confusing, but if you’re going to work in a language that includes them then you need to understand how they work. How they really work; not just how a confusing coding convention tries to make it seem like they work.

So at the end of the day, the asterisk character in C and C-like languages is part of the type being declared and not part of its name, and it’s time to start putting it where it belongs; with the type. A bad convention should not be allowed to stand just because it is the convention. Write code that intuitively matches its semantic meaning in the language, not code that is designed to trick people who don’t really understand how pointers work into being able to work with them anyways.

Lastly, and only somewhat tangentally, the following are all examples of very bad coding style, and you should not write code like this no matter where you put your asterisks:

int x, y;    //no
int *x, y;   //bad
int* x, y;   //not any better
int *x, *y;  //you get the idea... 
int* x, *y;
int x, *y;

Instead, simply do like so:

int x;
int* y;

It’s not like you pay by the newline when you write code. Limit your variable declarations to one-per-line. Trust me, you’ll write more readable code that way.