This is a short review of a book that some people like very much and
others dislike just as strongly.

Title   : JavaScript : The Good Parts
Author  : Douglas Crockford
Details : O'Reilly, 2008 (1st Ed), 153 pages, ISBN 978-0-596-51774-8.
Errata  : <http://oreilly.com/catalog/9780596517748/errata/>

I'll start by describing the content of the book, then follow this with
some unenthusiastic comments.

   Content

The preface says "This is not a book for beginners" and "This is not a
book for dummies".

Ch 1 says "The language described in this book is a proper subset of
ECMAScript." The subset consists of those parts he considers to be
'good'.

Ch 2 describes the language using Pascal-style syntax diagrams, but only
the 'good' parts. For instance, semicolons can't be omitted; names
(identifiers) can't start with underline; the statements inside if, for,
while, and do statements must be wrapped in curly brackets, with one
exception (else if).

Ch 3 describes objects and ways to access their contents. Object
literals are always used to create new objects.

Ch 4 describes functions and ways to use them, with subsections on
recursion, scope, closures, currying, and memoising (i.e. remembering
returned values for use in later calls). Throughout he emphasises that
functions are objects with methods that can be added to. Function
expressions are always used to create new functions, never declarations.

Ch 4 also describes exceptions.

Ch 5 describes three ways of implementing inheritance. Using
conventional constructors to do inheritance is deprecated as being ugly
and not really object-oriented.

Ch 6 describes arrays, with a complaint that they aren't designed for
speed, unlike other languages.

Ch 7 describes regular expressions in considerable, but not complete,
detail.

Ch 8 describes many of the methods available to Array, Function, Number,
Object, RegExp, and String objects.

Ch 9 discusses his coding style, much of which is built into the syntax
diagrams of Ch 2.

Ch 10 is a two-page essay on "beautiful features".

Appendix A describes the 'awful' parts of javascript and Appendix B
describes the 'bad' parts. These are the features of the language that
are not in the 'good' parts. For instance, optional semicolons are
declared to be awful and 'new' is declared to be bad.

Appendix C describes JSLint : a program that checks that javascript code
has been restricted to the 'good' parts and conforms to the style rules.
The errata contains a complaint that this appendix is already out of
date.

Appendix D repeats the syntax diagrams of chapters 2 and 7 in
alphabetical order and without any explanatory text.

Appendix E describes JSON (javascript object notation), a text format
for data interchange. Each data item is a javascript literal so making
it easy for javascript code to handle.

Appendix E includes a non-trivial example of javascript code in the form
of a recursive descent parser for JSON text.

   Remarks

1  Some of the 'good' parts are simply his preferred coding style.
Nowhere does he hint that perhaps other people's preferences could just
possibly be equally right.

2  He doesn't mention there were earlier versions of javascript that
didn't have features such as apply and hasOwnProperty.

3  He says that a property's value cannot be 'undefined'. This is
untrue. (p20)

4  He thinks that typing
   Thing.prototype.x = ... ;
is so ugly, and that doing
   Thing.method('x', ... );
is so much nicer. Especially when ... is a function expression. (p33)

5  Closures are not explained very well. Specifically, he doesn't
explain the meaning of 'bound to the variable' and similar phrases.
(p37..39)

6  He gives an example of conventional inheritance that is badly
designed and badly implemented, then uses it as an excuse to say that
constructor-based inheritance is ugly and not really OO, hence not
'good'. (A base instance is used as a prototype object; the base
constructor's code is rewritten in the derived constructor.) (p47..49,
54)

7  He doesn't mention the Date object.

8  "I *always* use blocks with structured statements" (his emphasis). It
seems he doesn't understand the subtle difference between always and
nearly always (else if). (p95)

9  Making it legal to omit semicolons is said to be a way to cope with
faulty programs. He does not even hint that some very vocal people
strongly object to using semicolons in scripting languages. Also, that
Netscape's JavaScript reference manual seldom used them. Likewise for
'var'. (p102)

10  He sometimes forgets to type 'new' when creating a new object, so he
strongly recommends that the use of 'new' should be avoided as much as
possible. Examples of ways to do this appear throughout the book. (E.g
the 'beget' function (p22)). They all look nasty. (p114)

11  In case 'new' is used he has a style rule, built into JSLint, that
forbids constructors being called as ordinary functions. This means that
the base constructor's work cannot be re-used in derived constructors.
(p114, p123)

12  He believes that blocks, { ... }, are not statements. This is a
distressingly common urban myth that is untrue in Algol, Pascal, Simula,
C, C++, Java, C#, and ECMAScript. (p118)

13  He prefers code to be flashy and obscure rather than simple and
clear. For instance, in the parser example of Appendix E there are four
pages of function definitions that are separated by commas because they
are all part of one large var statement. (If you add a function, will
you remember to put in the preceding comma?) (p140..144)

   Conclusions

Beginners should not read this book until they have gained more
experience, preferably including another programming language.

Non-beginners : read the book if you must but don't believe any part of
it without a lot of careful thought.

There is another side to his confidence. Crockford, through his
apparent conviction that his thoughts are superior to others, was one
of the main people, if not the main person, who put derailed
ECMAScript 4. It seems to me that *was* the right move and not many
people would have stood up against the momentum of ES4 so fearlessly.

"John G Harris" <j...@nospam.demon.co.uk> wrote in message
news:8E0bVrInWNWKFw0J@J.A830F0FF37FB96852AD08924D9443D28E23ED5CD...

At least now I have a better understanding of what can and can't be done in
JavaScript and the limitations of the objects that are available in various
contexts. I have been able to use it to write a simple JS which makes an
HTML index.htm file I can use for directory listings on my website. The
code is available at:
http://mysite.verizon.net/peschoen/Muttley/!MakeIndexHtm.js.
The files in that directory are mostly pictures of my dog Muttley.

Errors include
  * getYear -> 0-99
  * 20th-centade bias
  * months misnumbered
  * separate routines for LCT & UTC
  * undefined strings
  * bad input strings
  * no real ISO support
  * inherited, rather than well-chosen, zero
  * neither it nor Last-Modified is used for document.lastModified

Book Reviews are at least one of :
  * unsupported conclusions
  * too brief to be useful
  * too long for the FAQ

I agree that String is a bad part.  Consider this function:
     var gotcha = function(obj){
         obj.x = 1;
         return obj.x === undefined;
     };

Now solve, for x, the equation:
    gotcha(x) === true;

Any such x is a good candidate for being a bad part.

I think it is helpful and necessary for those with experience and
knowledge in an area to separate out the good from the bad, and do so
in a biased manner. A "survey" of a language, or broad overview, is
helpful in some cases, but it's generally not what book-readers want,
and is most useful for academic purposes. What people (book buyers/
readers) want most is for someone who has gone through all that work
themselves, and can "short-circuit" the learning process by just
teaching the good stuff. In effect, "Don't teach me everything, just
teach me what I need to know!"

It can be difficult for anyone learning a language (especially js,
given its history, its many poor implementations, and the many
misconceptions about it) to sort through all the mess to figure out
what they should and shouldn't do. I am thankful that someone like
Crockford is able to say "listen, rather than show you everything in
js just so you have a full understanding of the language, I'm going to
cut out the stuff that you'll be better off not using to begin with,
and focus from the beginning on doing things in a way that will give
you less trouble."

Even though he puts forth his own personal preferences, I say that's a
_good_ thing. It is certainly not perfect, and you or anyone else is
welcome to write a book about your preferred approach also. But, being
someone very knowledgeable about the language, I would trust that he
would get it mostly right. Or at least right enough to not throw
someone completely off-base. You have some complaints about minor
things, but they are nothing compared to the severe errors pointed out
in a book by John Resig, for example! If someone new to js is looking
for advice, and a path to follow, surely he would be better off having
read a book like this than one of the many others that are far worse.

And then, once a person has adopted good habits (even if they are not
exactly as you would recommend) they will be in a better position to
decide on their own if they would like to tweak them later. At least
they started on solid ground. That's a lot better than starting in a
sea of confusing, conflicting information about js and trying to
figure out who knows what they are talking about and what bits are
important.

  <snip>

I think that teaching people to use base instances as prototype objects
is unforgivable, especially when you're described by O'Reilly as the
world's foremost living authority on JavaScript.

Stroustrup describing C++ managed to show good examples without being a
dogmatic bigot.

Exactly. But my point is that he doesn't mention Date anywhere even
though he mentions other things he considers to be useless.

Another error is the use, in method names and documentation, of "UTC".
"UT" would have been up-to-date and accurate (but too like "UTC").
"GMT" should have been used.

   <snip>

What does
   obj = 25.3;
   obj.x = 1;
actually mean? According to Crockford, numbers have methods but this is
another urban myth. Primitive values don't have anything to hang
properties onto. What happens is that the statement is first translated
into
   ( new Number(obj) ).x = 1;
Now we have an object on the left and it is meaningful to add an 'x'
property to it.

What about
   return obj.x === undefined;
then? This is first translated into
   return ( new Number(obj) ).x === undefined;
as before and then executed. The value returned is 'true' because the
new number is a different Number object. The first Number object was
thrown away because it wasn't assigned to anything. The second Number
object doesn't have an 'x' property.

The Boolean, Number, and String constructors aren't much use to
programmers but they made it easy for the language to behave as though
primitive values have methods.

As discussed before, the proposed concise surrogate term for "Foo instance",
"Foo object", is only a little bit less confusing as it can still refer both
to an object constructed with the object referred to by `Foo', and to the
constructor itself.  With respect to DOM APIs and other multi-level
inheritance hierarchies, there are even three meanings attached to it, the
third being "Foo.prototype is in the prototype chain of said object".

typeof xyz == 'string' || xyz instanceof String

Fair enough.  Consider the right-hand an "instance."

X.prototype = new Y();

As for 'base instance', suppose one lump of code creates objects that
have all the methods and data properties of objects produced by another
lump of code, plus some more. If you're thinking OO then obviously the
first lot of objects inherits a specification from the second lot of
objects, and the first lot are called derived, and the second lot are
called base. Obviously, an object belonging to the second lot is a base
instance.

It's not a good idea to use a base instance as the prototype object for
the derived instances. Instead, a separate lump of code should be used
to create the prototype. This lump of code presumably creates only one
object, but it is still reasonable to call the object an instance (of
the separate lump of code).