J
John G Harris
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.
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.
