|
Page 1 of 2 JavaScript should not be judged as if it was a poor version of the other popular languages - it isn't a Java or a C++ clone. It does things its own way. This is an extract from JavaScript Jems: The Amazing Parts.
Now available as a book from your local Amazon.
JavaScript Jems:
The Amazing Parts
Contents
<ASIN:1871962579>
<ASIN:1871962560>
<ASIN:1871962501>
<ASIN:1871962528>
Jem 0
Why JavaScript Is A Jem
“Better a diamond with a flaw than a pebble without.”
Confucius
JavaScript is a much under-rated language.
The reason is probably that it seems to be a scripting language, its name suggests it is, aimed at non-programmers. As a result many JavaScript programs are horrible to look at and use few of the more interesting language facilities. JavaScript can be written in a one instruction after another without functions or objects and it often is.
Beginners treat it as a natural progression from tinkering with HTML and often pick it up as they go along. As a result not only is the typical JavaScript program lacking style, it often doesn't work too well either.
Unfortunately other problems arise when the experts get hold of it. JavaScript so flexible that you can turn it into almost anything you want to – so you will find JavaScript cast as C, C++, Lisp, Java, Scheme, etc. It can be used in a procedural fashion, object-oriented, functional, declarative or any discipline you care to apply to it, admittedly with variable amounts of success.
To compound all of these problems the official specification is very poor and often gives little guidance on how the language should be used. All this leaves the poor programmer wanting to use JavaScript in elegant ways with no option but to wade through exemplar code, usually in the form of widget libraries or similar.
The truth of the situation is that JavaScript is the only commonly used language today that isn’t a clone of C++ or Java. It does things in a different way and this is both refreshing and educational. Its approach to objects is different. Its approach to data typing is different. Its approach to numerics is different. Its approach to asynchronous code is well … you guessed it … different.
In short, JavaScript is a jem because it is rare, sophisticated and much misunderstood. It has its problems, no question about it, but in most cases even its problems are the result of trying to do something difficult in a logical way.
The fact of the matter is that JavaScript isn't a crude scripting language with nothing but simple data types and basic verbs. It is a language with a philosophy and a style of its own. It even has a heritage in that it is based on Self, a prototypical object-oriented language, and Scheme, a functional Lisp derivative. It is more like Lisp than any other language and Lisp is held in much reverence by programmers who know it. Yet casual programmers who don’t really get to grips with JavaScript proper and programmers experienced in other languages tend to call it a crude scripting language with nothing to offer the world. But with parents like these JavaScript can hardly be called "just a scripting language". It would be unrealistic, however, not to recognize that the language had to cope with limited resources early in its development and responded to a demand for it to be dumbed down so that non-programmers might manage to make some use of it.
As a result JavaScript is flawed, but arguably it's still enough of a jem to admire.
Object-Oriented and Dynamic
So what is special about JavaScript?
This is a question that is really only answered by reading the rest of this book, but it is worth a summary.
The first thing to say is that it is object-oriented, but its objects are dynamic. That is, you can create an object and add methods and properties to it at runtime. Indeed, you can even remove methods and properties, making the JavaScript object completely plastic.
This in turn means that JavaScript has a very weak notion of type. As an object can morph from one "type" to another by gaining and losing properties as required, there is no real notion of a type hierarchy and no need for one. In addition, there is no need and no provision for the class/object distinction.
In traditional object-oriented languages, objects are created by first defining a class, i.e a blueprint for an object. Then you create an instance of the class, i.e. an object. This is not a bad way to work with static objects and it fits in well with strong static typing, which is an approach many programmers think is good.
JavaScript, on the other hand, simply allows you to create an object - without the need for a class to act as a template. Once you have the object you can modify it as required by adding properties and even removing properties.
Of course, there are many who judge this particular jem to be a dud. Most disciplines of object-oriented programming insist on strong typing where objects are defined by classes which cannot change dynamically. Classes can inherit from other classes and this leads to a type hierarchy.
In theory, type checking using this hierarchy can find many errors, but all the errors that it finds are fairly easy to find at compile time and the approach is still subject to runtime-type errors. The consensus is that this approach to objects is more robust, but it can be argued that it simply introduces another level of complexity without delivering any important advantages.
This is not a widely held point of view and many programmers will swear that strong typing has saved them on more than one occasion and doing without it would be difficult. The problem is that this is a comparison of finding an error with perhaps not-finding the error and in truth the error wasn't that hard to spot, with or without strong typing. You used the wrong object, property or method.
There is also the claim that strong typing makes big projects easier to handle. This is often true, but only when typing is used as an alternative to good documentation and programming standards.
|