JavaScript, Design Patterns Approach to Computer Language Tutorials

xah thoughts extempore, episode №201311202224, on design patterns idiocy, review of Nicholas C Zakas's JavaScript book.

so, i started to read a second js book, the one by Nicholas C Zakas. He was lead dev from yahoo.

starting with, the chapter on objects, which is the most confusing part of JavaScript.

now, clearly, his approach is idiotic.

in Flanagan's js book (the rhino book) [see JavaScript Book by David Flanagan, and Man-made Complexity in Computer Language] , he focuses on the language. That is, what it is, what happens when you type xyz. It is, in a sense, deciphering a mathematical system. Programing languages are exactly that, a math system of sorts. So, in Flanagan book, the chapter on object has these section titles: creating objects, querying and setting properties, …, property attributes, object attributes, obects methods. All these things are items in the JavaScript language. The book covers what the language does.

now, many other books, are idiotic that try to throw in “engineering methodologies”. Zakas's book is that like. His chapter on object has titles like these: factory pattern, constructor pattern, combination constructor/prototype pattern, dynamic prototype pattern, parasitic constructor pattern, durable constructor pattern, pattern ya mom.

Zakas book is not bad. Aside from the “patterns” approach, it's rather solid. It's always good to have different perspectives on a language. However, his “software engineering” approach is simply misleading. Here's a concrete example. Excerpt:

The constructor property was originally intended for use in identifying the object type. However, the instanceof operator is considered to be a safer way of determining type. Each of the objects in this example is considered to be both an instance of Object and an instance of Person, as indicated by using the instanceof operator like this:

His remark on instanceof operator is technically incorrect. Because the instanceof operator actually checks the prototype chain, and isn't about data type or class/constructor type at all.

[see JS: instanceof Operator]

of course, he is aware of that, because later in the “Parasitic Constructor Pattern” section, he remarks:

A few important things to note about this pattern: there is no relationship between the returned object and the constructor or the constructor's prototype; the object exists just as if it were created outside of a constructor. Therefore, you cannot rely on the instanceof operator to indicate the object type. Because of these issues, this pattern should not be used when other patterns work.

the results of this “software engineering” approach is that it tries to force a language into a elusive “software engineering” perspective, resulting confusion. It's like trying to explain the solar system with earth-centric view. Instead of the simple model of planets revolving around the sun, it tries to see them revolve around earth, resulting complicated paths of epicycles. [see Epicycloid and Hypocycloid]

JavaScript the language, does not have such things as “patterns” or “constructors”. It just have hash table, parent hash table, and a link between them. You can start with your “software engineering patterns” to explain JavaScript in a contorted way. Or, you can explain things as it is and use it to build any model you want.