I have been using JavaScript for years, but never, ever taken the time to actually learn and understand it. The result? For years I have been selling JavaScript short of what it can be.
I came to start using JavaScript for the same reason that many classically trained programmers end up using it: out of necessity. Unlike the desktop, when it comes to browser-based applications JavaScript has had a virtual monopoly (although recent projects such as Silverlight are attempting to amend this). On the desktop, you can choose the language that is most appropriate for what you want to do. On the browser, you are forced into using JavaScript. I don’t like being forced to do anything. Strike one against JavaScript.
Next, after deciding that you need to use JavaScript, the next thing you do is take a look at some code. The usual train of thought is then: "This looks (syntactically) like Java and it has the word Java in title, therefore this must be like Java." Those familiar with Java know that Java’s object-oriented and inheritance model is at its core. Naturally thinking that JavaScript must also have objects and inheritance, you go searching and find none (or at least none that look like how you think they should look). Immediately you consider JavaScript as a bastardized, neutered version of Java. Strike two against JavaScript.
Lastly, you start actually programming in JavaScript. You never actually take the time to learn the language since you already know the syntax (C-style), and there are only a few standard libraries. Quickly you run into some of the horrible features of JavaScript (such as the global variable model), and turn up your nose. You end up doing most of your program using Google by searching for snippets of code that you string together. Somewhat amazingly, it actually works and you end up with a mutt-of-a-program that does more or less what you want. However, compared to your familiar, rock-solid, beautiful Java class hierarchy, your JavaScript code looks like it will fall over if you look at it. Strike three, JavaScript is out.
And this is exactly how I thought up until recently, and it is why I now owe JavaScript an apology. A couple of years ago I decided it would be a good exercise to learn Lisp. At the University of Waterloo we were classically trained in procedural languages (notably C/C++ and Java), but were only briefly introduced to functional programming languages (a few days on Scheme were tacked onto the end of our compilers course). Knowing that learning Lisp would be a challenge, I bought
Practical Common Lispby Peter Seibel. In the chapter dealing with Lisp’s idea of object orientation, the author
writes:
You should note at the outset that Common Lisp's object system offers a fairly different embodiment of the principles of object orientation than many other languages. If you have a deep understanding of the fundamental ideas behind object orientation, you'll likely appreciate the particularly powerful and general way Common Lisp manifests those ideas. On the other hand, if your experience with object orientation has been largely with a single language, you may find Common Lisp's approach somewhat foreign; you should try to avoid assuming that there's only one way for a language to support object orientation.
Indeed, Alan Kay, the inventor of Smalltalk, is reported to have said, "I invented the term object oriented, and I can tell you that C++ wasn't what I had in mind."
I am not going to go into any detail as to Lisp’s idea of OO, but what was important for me here was realizing that C++ and Java’s way of handling OO (and many other things) was only one way, not the way. Although I have not gone on to use much Lisp for my day-to-day programming, the act of learning Lisp has changed my programming style more than anything else.
Douglas Crockford is the senior JavaScript developer at Yahoo!, the ‘discoverer’ of
JSON , and well respected as an authority on JavaScript. I began to see more and more references to him describing
JavaScript as the most misunderstood language . One particular thing he said stood out to me:
JavaScript's C-like syntax, including curly braces and the clunky for statement, makes it appear to be an ordinary procedural language. This is misleading because JavaScript has more in common with functional languages like Lisp or Scheme than with C or Java. It has arrays instead of lists and objects instead of property lists. Functions are first class. It has closures. You get lambdas without having to balance all those parens.
JavaScript like Lisp? Nuh-uh. Or so I thought.
I began to look more into JavaScript’s concepts of objects (using prototypes), and with my new-found tolerance for different type of object orientation, I began to see how it not only made sense, but how beautiful it could be. Lambda functions and closures could be used for all sorts of things. JavaScript wasn’t unexpressive; I had simply been programming it in the wrong style!
JavaScript’s final pardon from me came after reading Douglas Crockford's ,
JavaScript: The Good Parts. In that book Crockford admits the many faults of the language, suggesting that developers should program using only a subset of the language that specially avoids the bad parts of the language. Just because a language has a feature doesn’t mean you have to use it. In the C world, many people will avoid the use of the
gotostatment, and fall-through switch statement for this exact reason. I would suggest that Crockford’s book is an absolute must-read for anyone who truly wants to understand JavaScript on its own terms.
JavaScript, I am sorry.
