> The only book currently endorsed by c.l.j. regulars is:
> JavaScript: The Definitive Guide, 5th Edition By David > Flanagan ISBN:0-596-10199-6
That still isn't technically true, as there have been no such endorsements (in the sense in which the 4th edition was explicitly endorsed by at leas a handful of regulars). Still, I would be willing to go with that wording at present, if only to put a stop to the pointless quibbling. The 5th edition does not seem to be worse than the 4th so I think that those who did endorse the 4th would be as willing to endorse the 5th.
I think we are, once again, suffering from the obvious fact that those who are already familiar with javascript, web browsers and the DOM are not motivated to by and read reference works on the subject (and the book's authors are not motivated to pay such individuals to do reviews of their books, as the results will likely be heavily critical).
> Also by David Flanagan: JavaScript Pocket Reference, 2nd Edition. > ISBN 0-596-00411-7 for language and API reference alone.
> The errata should be considered a must read along with the book.
While pointing out that there is an errata is a good idea I think it would be good if the fact could better express that the errata will only contain corrections that the author is willing to recognise. For example, the subdivision of the book into 'core' and 'client side' javascript, justified in the first couple of editions, an anachronism by the 4th and a positive mistake in the 5th, is unlikely to ever be 'corrected' in an errata. And neither is much of the misleading and ambiguous terminology employed in the book, or the inadequate discussion of the use of - navigator.userAgent.
> > The only book currently endorsed by c.l.j. regulars is:
> > JavaScript: The Definitive Guide, 5th Edition By David > > Flanagan ISBN:0-596-10199-6
<snip>
> I think we are, once again, suffering from the obvious fact that those > who are already familiar with javascript, web browsers and the DOM are > not motivated to by and read reference works on the subject (and the > book's authors are not motivated to pay such individuals to do reviews > of their books, as the results will likely be heavily critical).
JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford, Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper, Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld. Reviewers of previous editions include Brendan Eich and Waldemar Horwat.
David Golightly wrote: > On Sep 1, 11:49 am, Richard Cornford wrote: >> FAQEditor wrote: >>> FAQ Update 9.85 Dated 2007-08-31:
>>> Section 3.1 changed to read:
>>> The only book currently endorsed by c.l.j. regulars is:
>>> JavaScript: The Definitive Guide, 5th Edition By David >>> Flanagan ISBN:0-596-10199-6
> <snip>
>> I think we are, once again, suffering from the obvious fact >> that those who are already familiar with javascript, web >> browsers and the DOM are not motivated to by and read >> reference works on the subject (and the book's authors are >> not motivated to pay such individuals to do reviews of >> their books, as the results will likely be heavily critical).
> JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford, > Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper, > Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld. > Reviewers of previous editions include Brendan Eich and > Waldemar Horwat.
In comp.lang.javascript message <Cq6dnclPf6lJHkXb4p2d...@giganews.com>, Fri, 31 Aug 2007 17:11:33, FAQEditor <clj...@comcast.net> posted:
For the next update, but needing no announcement,
>JavaScript: The Definitive Guide, 5th Edition By David Flanagan
by or David Flanagan's "JavaScript: The Definitive Guide", 5th Edition.
>The errata should be considered a must read along with the book.
----------- ... ugh!
>The errata should be read with the book.
Actually, the errata should be used to correct the book.
-- (c) John Stockton, Surrey, UK. ?...@merlyn.demon.co.uk Turnpike v6.05 MIME. Web <URL:http://www.merlyn.demon.co.uk/> - FAQish topics, acronyms, & links. Plaintext, quoting : see <URL:http://www.usenet.org.uk/ukpost.html> Do not Mail News to me. Before a reply, quote with ">" or "> " (SoRFC1036)
> David Golightly wrote: > > On Sep 1, 11:49 am, Richard Cornford wrote: > >> ... the book's authors are > >> not motivated to pay such individuals [who are already familiar with javascript, web browsers and the DOM] to do reviews of > >> their books, as the results will likely be heavily critical....
> > JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford, > > Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper, > > Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld. > > Reviewers of previous editions include Brendan Eich and > > Waldemar Horwat.
> Your point being?
> Richard.
The point being evident, that you claimed that the book's authors are not motivated to hire reviewers who are familiar with the subject matter. The above list of names would indicate to the contrary.
> On Sep 1, 1:59 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk> > wrote: >> David Golightly wrote: >>> On Sep 1, 11:49 am, Richard Cornford wrote: >>>> ... the book's authors are >>>> not motivated to pay such individuals >>>> [who are already familiar with javascript, web browsers >>>> and the DOM] to do reviews of >>>> their books, as the results will likely be heavily critical....
>>> JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford, >>> Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper, >>> Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld. >>> Reviewers of previous editions include Brendan Eich and >>> Waldemar Horwat.
>> Your point being? <snip> > The point being evident,
No it was not evident. Now you appear to be asserting that the above list represents individuals who are "familiar with javascript, web browsers and the DOM", though you have in no way demonstrated that.
> that you claimed that the book's authors
When did David Flanagan become the authors of javascript reference books?
> are not motivated to hire reviewers who are familiar > with the subject matter. The above list of names would > indicate to the contrary.
The above list says nothing about the motivations of the authors of javascript reference books (it just may say something about the actions of an author of a single javascript reference book).
> > On Sep 1, 1:59 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk> > > wrote: > >> David Golightly wrote: > >>> On Sep 1, 11:49 am, Richard Cornford wrote: > >>>> ... the book's authors are > >>>> not motivated to pay such individuals > >>>> [who are already familiar with javascript, web browsers > >>>> and the DOM] to do reviews of > >>>> their books, as the results will likely be heavily critical....
> >>> JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford, > >>> Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper, > >>> Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld. > >>> Reviewers of previous editions include Brendan Eich and > >>> Waldemar Horwat.
> >> Your point being? > <snip> > > The point being evident,
> No it was not evident. Now you appear to be asserting that the above > list represents individuals who are "familiar with javascript, web > browsers and the DOM", though you have in no way demonstrated that.
Likewise, you have in no way demonstrated your claim that the book's author is NOT motivated to pay appropriate subject-matter experts to review the book. In fact, by disputing that, you manage to undermine your own credibility by questioning the credibility of these well- known experts.
To name a few: Douglas Crockford - Senior JavaScript architect, Yahoo! Norris Boyd - creator of the Rhino JavaScript interpreter Peter-Paul Koch - freelance developer and established author of quirksmode.org Christian Heilmann - established web developer, standards advocate, and technical author Todd Ditchendorf - software engineer at Apple Computer, freelance developer, standards advocate
The supposed controversy lies in the lack of an objective standard for "quality" in this domain, though the best approximation we can achieve is by taking the words of established, creative, inventive, successful developers who have produced work and created software outside of esoteric examples and self-righteous language lawyering on Usenet. Perhaps I personally fall in that last category, or somewhere else, I don't know. But if you can't acknowledge the expertise of the proven experts, well, then, why should anyone listen to you?
> > are not motivated to hire reviewers who are familiar > > with the subject matter. The above list of names would > > indicate to the contrary.
> The above list says nothing about the motivations of the authors of > javascript reference books (it just may say something about the actions > of an author of a single javascript reference book).
The thread started in the particular, you brought it into the general, now I (though admitting a typo) have attempted to bring it back to the particular.
David Golightly wrote: > On Sep 1, 4:49 pm, Richard Cornford wrote: >> David Golightly wrote in message >>> On Sep 1, 1:59 pm, Richard Cornford wrote: >>>> David Golightly wrote: >>>>> On Sep 1, 11:49 am, Richard Cornford wrote: >>>>>> ... the book's authors are >>>>>> not motivated to pay such individuals >>>>>> [who are already familiar with javascript, web browsers >>>>>> and the DOM] to do reviews of >>>>>> their books, as the results will likely be heavily critical....
>>>>> JavaScript: TDG (5th ed.) was reviewed by Douglas Crockford, >>>>> Norris Boyd, Peter-Paul Koch, Christian Heilmann, Ken Cooper, >>>>> Todd Ditchendorf, Geoff Stearns, and Sanders Kleinfeld. >>>>> Reviewers of previous editions include Brendan Eich and >>>>> Waldemar Horwat.
>>>> Your point being? >> <snip> >>> The point being evident,
>> No it was not evident. Now you appear to be asserting that >> the above list represents individuals who are "familiar with >> javascript, web browsers and the DOM", though you have in no >> way demonstrated that.
> Likewise, you have in no way demonstrated your claim that the > book's author is NOT motivated to pay appropriate subject-matter > experts to review the book.
I did not make such a claim. I claimed that the authors of javascript reference books where not motivated to ... . The existence of reviews of a single javascript reference book (regardless of the supposed technical qualifications of the people responsible) does not speak for the motivations of the authors of javascript reference books in general, or actually say anything the motivations of David Flanagan (as his suggested involvement has only be implied).
> In fact, by disputing that,
Disputing what? That the list of individuals you posted does not necessarily represent a list of individuals "familiar with javascript, web browsers and the DOM"?
> you manage to undermine your own credibility by questioning > the credibility of these well- known experts.
> To name a few: > Douglas Crockford - Senior JavaScript architect, Yahoo!
Douglas has been contributing to this group for longer than I have. I have absolutely no doubt that his understanding of javascript, as a language, is second to none, but that is just one of the three criteria I stated.
> Norris Boyd - creator of the Rhino JavaScript interpreter
Again someone who can be expected to understand javascript as a language, but what does this qualification say about someone's familiarity with web browsers? How many browser use Rhino as a javascript engine? I can only name one.
> Peter-Paul Koch - freelance developer and established author of > quirksmode.org
I don't have time to go into the shortcomings of quirksmode.org here again.
> Christian Heilmann - established web developer, standards advocate, > and technical author
So that implies familiarity with the DOM, but necessarily javascript as a language or web browsers in general.
> Todd Ditchendorf - software engineer at Apple Computer, > freelance developer, standards advocate
Ditto.
I notice that you have not included Brendan Eich in this list. An undoubted expert in his own right, the last word on the implications of the implementation details of the javascript engine in Netscape/Mozilla/Gecko browsers on the execution of actual JavaScript(tm) code. But not necessarily someone who has anything useful to say on the on the subject of the issues of scripting for IE, Opera or the host of other non-Gecko browsers that exist.
> The supposed controversy lies in the lack of an objective > standard for "quality" in this domain, though the best > approximation we can achieve is by taking the words of > established, creative, inventive, successful developers > who have produced work and created software outside of > esoteric examples and self-righteous language lawyering > on Usenet.
An appeal to authority is always a poor criteria. But what a set of qualifications to choose? When, and in what sense does someone become "established"? Of what value is "creative" if the creations are in an unrelated area, and it is a pretty subjective criterion anyway. The same goes for "inventive". And if "successful developer" means 'well paid' then that certainly says nothing significant about pertinent expertise.
A much better starting point for considering someone's expertise in the pertinent areas is to look at their browser scripts and see how well/comprehensively it identifiers and handles/avoids the issues of cross browser scripting and how well it employs the language. There may be a great deal of subjective judgment in that, and much that can be expected to be the consequence of personal style, but there is also much to be learnt about the author's 'expertise' in the process.
> Perhaps I personally fall in that last category, or > somewhere else, I don't know.
And nobody else will know either until you start posting code instead of just talking about it.
> But if you can't acknowledge the expertise of the proven > experts,
In what sense am I not acknowledging the expertise of the "proven experts"? Where I am not already familiar I am asking to see some proof, and where I am familiar I am just questioning the applicability of the specific expertise to three criteria I proposed.
> well, then, why should anyone listen to you?
People have to make their own minds up as to who they are going to listen to.
>>> are not motivated to hire reviewers who are familiar >>> with the subject matter. The above list of names would >>> indicate to the contrary.
>> The above list says nothing about the motivations of the >> authors of javascript reference books (it just may say >> something about the actions of an author of a single >> javascript reference book).
> The thread started in the particular, you brought it into > the general,
I made a general statement about the authors of javascript reference books. General statements tend not to be true for all individuals who may seem be covered by the generality. Yet still we have a situation where the only contender for inclusion in the FAQ is Flanagan's book, and that is with all of its manifest shortcomings.
> now I (though admitting a typo) have attempted to bring it > back to the particular.
The particular that we might bring it 'back' to may be shortcomings of Flanagan's book. So, for example, last October when, in response to a question posted here on the XML HTTP request code published in the 5th edition, I pointed out that as implemented the code would fall foul of the IE (<=6) memory leak problem (along with some other issues) I was either correct in my comment or I was mistaken. The fact that the errata for the book now include all of the corrections I proposed suggests that my criticisms were valid and just. That memory leak issue, and the cause and effect relationships behind it, are hardly a recent discovery (I was posting demonstrations of the issue here back in mid 2003 and it was certainly a known (if a little misunderstood) issue at that time).
That was a real and demonstrable issue with Flanagan's book, and I can find plenty more of them, and back them up with reasoned argument and practical demonstration. It may be the case that Flanagan's book is the lest bad javascript book available by a very large margin (I have read sections of other javascript books where every statement made in entire chapters were factually false, so the quality of the competition is very poor) but if you propose a list of "expert" reviewers who read that book and (by your implication) fail to find fault with it I have reasonable grounds for questioning the applicability of the proposed "expertise" of those reviewers to the real world practice of browser scripting.
In comp.lang.javascript message <fbd94a$p05$1$8300d...@news.demon.co.uk> , Sun, 2 Sep 2007 04:02:44, Richard Cornford <Rich...@litotes.demon.co.uk> posted:
>That was a real and demonstrable issue with Flanagan's book, and I can >find plenty more of them, and back them up with reasoned argument and >practical demonstration.
To be constructive, you could do that, and send it to David Flanagan so that the Sixth Edition could be improved. His E-mail address is easy to find.
But, as regards the FAQ, that's a detail.
The FAQ maintainer seems to have wanted to say something equivalent to "The book ... is strongly endorsed by all experts in this newsgroup, being (when read in conjunction with its Errata) near enough perfectly accurate" - and cannot find anything to replace the ellipsis.
But that's not what the intended reader needs; all he needs is something like "One of the best books is ..." - and that ellipsis *is* replaceable.
In FAQ Section 3, before 3.1, there could be something like : "Be aware that no source will be absolutely reliable, and any source may become outdated."
The FAQ links to ECMA-262 3rd Edn, but lacks a reference to its Errata. Googling for "ecmascript errata" finds 80400 links, but happily the first is good.
>> That was a real and demonstrable issue with Flanagan's book, >> and I can find plenty more of them, and back them up with >> reasoned argument and practical demonstration.
> To be constructive, you could do that, and send it to David > Flanagan so that the Sixth Edition could be improved. His > E-mail address is easy to find.
We can easily test that proposition. If I open the 5th edition at some point (it turned out to be page 60) and start commenting on what I find:-
| Page 61; Table of JavaScript operators:- | | Operator Operand type(s) Operation performed | ----------------------------------------------------------- | . object, identifier Property access | [] array, integer Array index | () function, arguments function call | new constructor call Create new object | ++ lvlaue Pre-or post-increment(unary) | -- lvalue Pre- or post-decrement(unary) | - number unary minus(negation) | + number Unary plus(no-op) | ~ integer Bitwise complement(unary) | ! boolean Logical complement(unary) | delete lvalue Undefined a property(unary) | typeof any Return datatype(unary) | | ... | | instanceof object, constructor Check object type | in string, object Check whether property exists | | ... | | && boolean Logical AND | || boolean Logical OR | ...
The operands for the square brackets are object and string not array and integer, and the operation is property access. The above serves to fuel a common misconception that does not act to assist people learning javascript to understand what they are doing.
The grouping operator is absent for the list (parenthesised expressions).
Unary plus should not be ladled "no-op" as its type-converting side effects are the main reason for using it at all. That makes listing the operand types as 'number' a questionable act. Indeed, it could easily be argued that most of the types shown should actually be 'any', as very few operators are insistent on the actual type of their operands in javascript. The two logical operators being probably the worst offenders as examples of inappropriately labelled operand types (the right hand side operand is never type converted by a logical AND or OR operation).
Javascript has no integer types, but if the intention is to express the types that operands will be converted into then the assertion should be signed or unsinged (as appropriate) 32 bit integers, as javascript's numeric type can accommodate integers over a much greater range.
The action of the - delete - operator should not be labelled "Undefined a property" as that is not what it does. If you delete a property of an object and that object's prototype has an identically named property the original object still effectively has the property 'defined', it just does not actually have the property itself. It would be sufficient to say that the - delete - operator removes a property from a specific object, or attempts to, as it may not always succeed in the attempt.
The - typeof - operator does not return a "datatype" it returns a string (if "returns" is going to be used to stand in for "evaluates as" at all).
The listed operands of - instanceof - should be object (or, more correctly 'any') and function, as those are the real restrictions on the operation. And the operation should not be misleadingly described as "Check object type" given that objects don't have types in this sense and the object/function relationships tested by - instanceof - are amenable to dynamic manipulation at runtime anyway, making the outcomes potentially inconsistent over time and uncertain (neither of which fit at all well with the concept of an object's type).
| Page 62:- | | For example it is not possible to multiply strings, so the | expression "a" * "b" is not legal in JavaScript.
- which is simply not true. It is possible to multiply strings (at least it is possible for strings to be the operands of the multiplication operator, if often not meaningful), and the expression is completely legal in JavaScript, just of extremely questionable worth.
| Page 63:- | | Notice that the assignment operators, as well as a few others | operators, expect their left-side arguments to be lvalues. | lvalue is a historical term that means "an expression that can | legally appear on the left side of an assignment expression." In | JavaScript, variables properties of objects, and elements of | arrays are lvalues. The ECMAScript specification allows built-in | functions to return lvalues but does not define any built-in | functions that behave that way,
An example of imprecise wording. In context an "lvalue" is whatever David Flanagan chooses to assert it to be. The concept being ladled is what ECMA 262 names a "Reference type". The advantage of calling it a Reference type is that anyone can go to the specification, look it up, and then know precisely what it is that is being talked about.
So where the above says "variables, properties of objects and elements of arrays" the fact that both the scope chain resolution of Identifiers and property accessors result in reference types (always and only) explains why these things may be the left has side of assignment operations.
It also shows a factual omission, as grouping operations (parenthesised expressions) may also be the left hand side of an assignment, whenever the expression they contain evaluates as a Reference type. It would also be practical to argue that if "variables" are to be included in the list then (the Identifiers for) formal parameters and inner function declarations may also be the left hand side of assignments.
"Variables, properties of objects and elements of arrays" are, of course, all just properties of objects, making two items in that list superfluous. In terms of explaining the language it may be acceptable to include "variables" (and even use it as a shorthand for all Identifier resolution, including inner function declarations and formal parameters) but trying to enforce a distinction between properties of objects and array elements is another manifestation of the error in the table of operators on page 61 where bracket notation is misleadingly being associated with array objects only.
Built-in functions (as defined in ECMA 262, section 4.3.7) may not return a Reference type. The possibility that a function/method call could return a Reference type is reserved for host objects (Section 4.3.8), as is stated in Sections 8.7 and 11.2.3.
Now that is 600 words on just 4 pages. The book is 950 odd pages long, and that adds up to a lot of words and a lot of work writing them. If I am going to put that much effort into doing something for free I am going to do it where I have always prefer to do it. Right here on this group, in public, and not some private e-mail exchange where nobody else gets to comment on (or learn from) the exchange. If David Flanagan wants his ideas and his code critiqued he is at liberty to bring them here and present them to group as a whole, just like everyone else.
> But, as regards the FAQ, that's a detail.
> The FAQ maintainer seems to have wanted to say something > equivalent to "The book ... is strongly endorsed by all > experts in this newsgroup, being (when read in conjunction > with its Errata) near enough perfectly accurate" - and > cannot find anything to replace the ellipsis.
Are you saying that you have deduced that from something Randy has written? That would not be my interpretation of his posts on the subject. Though I am sure everyone would like to be in a position to be recommending a book because it was "perfectly accurate" or in some other sense good.
> But that's not what the intended reader needs; all he needs > is something like "One of the best books is ..." - and that > ellipsis *is* replaceable.
<snip>
But even that is misleading when a book gets to be "one of the best" by virtue of being the least bad.
> Built-in functions (as defined in ECMA 262, section 4.3.7) may not > return a Reference type. The possibility that a function/method call > could return a Reference type is reserved for host objects (Section > 4.3.8), as is stated in Sections 8.7 and 11.2.3.
Can you explain why this is?
> Now that is 600 words on just 4 pages. The book is 950 odd pages long, > and that adds up to a lot of words and a lot of work writing them. If I > am going to put that much effort into doing something for free I am > going to do it where I have always prefer to do it. Right here on this > group, in public, and not some private e-mail exchange where nobody else > gets to comment on (or learn from) the exchange. If David Flanagan wants > his ideas and his code critiqued he is at liberty to bring them here and > present them to group as a whole, just like everyone else.
The ecma262 manual is intended to be read by implementors. There is no user guide.
Making a user-friendly manual for javascript (and it's variants) would be a huge benefit to the community.
1) Thanks for the continued listing of the book in the FAQ. I appreciate the listing, even if it is only a citation as, as Richard would have it, "the least bad" book. Though I do like to believe that there are lots of good parts in the book, too :-)
2) I don't believe that a link to my blog is appropriate. Recently I've been blogging about Ruby the most, and also Java, with little JavaScript content. I do think that, for purposes of identification, it would be valuable to link my name to my website (which happens to be a blog). That way I won't be mistaken for the conservative political blogger, for example, who shares my name.
3) The JavaScript pocket reference is probably out of date, and while I appreciate the listing, you might consider removing that link. (Though the regular readers of this group might have a more well- informed opinion about whether it is still a useful work.)
4) Richard: thank you for your feedback but please keep in mind that my book is not intended to replace the specification. You appear to be an expert who can read and learn things from the spec. The table of operators you have critiqued remains from early editions of the book, and I've never been quite satisfied with it. You make a number of good points about it. Many of the points you raise cannot be addressed in tabular form, however. And some of the points you raise are judgment calls in which I have made a different judgment than you. For example, I don't consider parentheses used for grouping to be operators, so I didn't include them in the table.
5) David Golightly cites the list of technical reviewers for my 5th edition. It is an impressive list, and I was very happy to have such luminaries review the book. Nevertheless, the fact that they agreed to do a technical review cannot be taken as their endorsement of the book. Brendan Eich did offer an endorsement of the first or second edition of the book, and that endorsement still appears on the back cover.
>Dr J R Stockton wrote: >> Richard Cornford posted:
>>> That was a real and demonstrable issue with Flanagan's book, >>> and I can find plenty more of them, and back them up with >>> reasoned argument and practical demonstration.
>> To be constructive, you could do that, and send it to David >> Flanagan so that the Sixth Edition could be improved. His >> E-mail address is easy to find.
>We can easily test that proposition. If I open the 5th edition at some >point (it turned out to be page 60) and start commenting on what I >find:- >| Page 61; Table of JavaScript operators:- >| ... ...
Waste of space; there is no doubt that you could and would comment at length. That is of no use unless DF reads it. As a failed FAQ maintainer, it ill behoves you to be over-critical of a successful author.
>> But, as regards the FAQ, that's a detail.
>> The FAQ maintainer seems to have wanted to say something >> equivalent to "The book ... is strongly endorsed by all >> experts in this newsgroup, being (when read in conjunction >> with its Errata) near enough perfectly accurate" - and >> cannot find anything to replace the ellipsis.
>Are you saying that you have deduced that from something Randy has >written?
Since I know RW only by his writing, that must necessarily be the case.
> That would not be my interpretation of his posts on the subject.
And that can be equally true.
>Though I am sure everyone would like to be in a position to be >recommending a book because it was "perfectly accurate" or in some >other sense good.
That's why I thought RW would like to do so.
>> But that's not what the intended reader needs; all he needs >> is something like "One of the best books is ..." - and that >> ellipsis *is* replaceable. >But even that is misleading when a book gets to be "one of the best" by >virtue of being the least bad.
Do not compare the benefits of using Flanagan with the benefits of using the book that you might have written; compare it with the benefits of using no book.
But I wrote, and you quoted, "something like". You might prefer "One of the less bad ..."
>> Built-in functions (as defined in ECMA 262, section 4.3.7) may >> not return a Reference type. The possibility that a >> function/method call could return a Reference type is reserved >> for host objects (Section 4.3.8), as is stated in Sections 8.7 >> and 11.2.3.
> Can you explain why this is?
No. I can tell you why programmer defined functions cannot ever return a reference type, but if you want to know why the specification only admits that possibility for host objects you would have to ask its authors. It seems an arbitrary decision, but not an unreasonable one.
>> Now that is 600 words on just 4 pages. The book is 950 odd >> pages long, and that adds up to a lot of words and a lot of >> work writing them. If I am going to put that much effort into >> doing something for free I am going to do it where I have always >> prefer to do it. Right here on this group, in public, and not >> some private e-mail exchange where nobody else gets to comment >> on (or learn from) the exchange. If David Flanagan wants his >> ideas and his code critiqued he is at liberty to bring them >> here and present them to group as a whole, just like everyone >> else.
> The ecma262 manual
It is not a manual, it is a specification.
> is intended to be read by implementors.
Yes it is, but not exclusively. Anyone wanting to understand the behaviour of the language would be well advised to read the specification that dictates that behaviour.
> There is no user guide.
Not explicitly for ECMAScript. There are JavaScript(tm) user guides. But then programming languages don't really have 'users', the people using a programming language either are programmers or have a very unrealistic attitude towards what they are doing.
"User" is a term better reserved for the unfortunate individuals on the receiving end of the things created by programmers. That is place where letting 'user friendly' become synonymous with 'idiot friendly' isn't necessarily such a bad idea.
> Making a user-friendly manual for javascript (and it's variants) > would be a huge benefit to the community.
<dflana...@gmail.com> wrote: > Allow me to weigh in here on my book.
> 1) Thanks for the continued listing of the book in the FAQ. > I appreciate the listing, even if it is only a citation as, > as Richard would have it, "the least bad" book.
I usually write, "the least bad javascript book by a very large margin", which is precisely what I think of the book. The completion is so bad that if a book on javascript is wanted/needed then the definitive guide is the only real candidate to be that book (even given my extensive reservations about the book). And I can certainly appreciate that books will be wanted; to be able to read from paper, read in bed, outside, on the train, and so on. Portable computers may eventually rival books in their versatility but they are not even close yet.
> Though I do like to believe that > there are lots of good parts in the book, too :-)
There are.
> 2) I don't believe that a link to my blog is appropriate. > Recently I've been blogging about Ruby the most, and also > Java, with little JavaScript content. I do think that, > for purposes of identification, it would be valuable to > link my name to my website (which happens to be a blog). > That way I won't be mistaken for the conservative > political blogger, for example, who shares my name.
That my not be too practical at present. While HTML allows a name to link to a web site the FAQ is also posted to the group in text form. In order to avoid having to versions (with all the problems of keeping two versions up to date in parallel) the actual FAQ is an XML file that can be transformed into HTML or text. Currently the XML does not have facilities to allow contained text to be presented as links in HTML and differently presented in text format. Such changes to the XML have been proposed but acting on them also means re-coding the various scripts that use the existing XML so it is not a step that can be taken lightly.
> 3) The JavaScript pocket reference is probably out of date, > and while I appreciate the listing, you might consider > removing that link. (Though the regular readers of this > group might have a more well- informed opinion about > whether it is still a useful work.)
There never was that much support for the idea of including it in the first place.
> 4) Richard: thank you for your feedback but please keep in > mind that my book is not intended to replace the specification.
But also, I assume, not intended to contradict the specification.
> You appear to be an expert who can read and learn things > from the spec.
If so, then only through making the effort to do so. The specification is undoubtedly an obscure document that takes time and work to understand. Other sources can tell you how things work in javascript, but the specification can tell you _why_ they behave that way, precisely. For example, it is easy to say that with - someFunction(anObjecct.someMethod) - if - someFunction - calls its argument directly the - this - value inside the call to that function will never be - anObject -, but the things that makes that statement a certainty are step 2 in the 3rd algorithm and step 3 in the 4th, in section 11.2.4 of ECMA 262, 3rd Ed.
The 'whys' of the language's behaviour dictate its possibilities, and perceiving the possibilities on offer is a pre-request for fully exploiting the language.
The specification also provides an unambiguous set of terminology for use when talking about javascript. It is very easy for anyone who wants to throw any terms they like into a discussion of javascript; 'stack frames', 'scope blocks', 'call objects', 'lvalues', 'execution contexts', and so on. And of those terms only statements about javascript employing only 'execution context' could be judged true or false by anyone, because it is a term that is from the languages specification and its role in the language has a precise definition. The other terms may be used with intended meaning, under some unstated misconception or in a deliberate attempt to impress the uninformed with jargonise. All become possible because in relation to javascript the are inherently ambiguous terms.
> The table of operators you have critiqued remains from early > editions of the book, and I've never been quite satisfied with it.
As does the division of the book into 'core' and 'client-side' javascript.
> You make a number of good points about it. Many of the points > you raise cannot be addressed in tabular form, however.
So maybe some of the assertions do not belong in the table at all. The details I did not show, the precedence, the order of operand evaluation (rtl or ltr), plus categorisations such as 'unary', 'binary', etc. make sense in a table, others could maybe be left until the explanatory text for the operator.
And it is an absolute mistake to be labelling bracket notation property accessors as 'array indexing' (and to repeat and re-enforce that misconception throughout the rest of the book). It is no coincidence that the FAQ has to explicitly re-enforce the property accessing role of bracket notation. The harmful consequences of the misconception you promote have dogged this group for longer than I have been writing javascript.
Javascript has no Array-specific language syntax apart from array literals. Bracket notation property accessors are only used to access array elements to the exclusion of dot notation because an 'array index' can never qualify as an Identifier and so cannot follow the dot in a dot notation property accessor.
> And some of the points you raise are judgment > calls in which I have made a different judgment than you. > For example, I don't consider parentheses used for grouping > to be operators, so I didn't include them in the table.
<snip>
Listing the grouping operator as an operator is a matter of judgment. The specification categorises it as such, but thinking about parenthesising (sub)expressions as using an operator is not going to contribute anything much to learning a programming language.
The other points I made are much less a matter of judgment. It is in the nature of programming languages to be consistent, and to be precise. It should be expected that an explanation of a programming language also be consistent, preferably be precise and certainly be factual.
> >> Built-in functions (as defined in ECMA 262, section 4.3.7) may > >> not return a Reference type. The possibility that a > >> function/method call could return a Reference type is reserved > >> for host objects (Section 4.3.8), as is stated in Sections 8.7 > >> and 11.2.3.
> > Can you explain why this is?
> No. I can tell you why programmer defined functions cannot ever return a > reference type, but if you want to know why the specification only > admits that possibility for host objects you would have to ask its > authors. It seems an arbitrary decision, but not an unreasonable one.
> >> Now that is 600 words on just 4 pages. The book is 950 odd > >> pages long, and that adds up to a lot of words and a lot of > >> work writing them. If I am going to put that much effort into > >> doing something for free I am going to do it where I have always > >> prefer to do it. Right here on this group, in public, and not > >> some private e-mail exchange where nobody else gets to comment > >> on (or learn from) the exchange. If David Flanagan wants his > >> ideas and his code critiqued he is at liberty to bring them > >> here and present them to group as a whole, just like everyone > >> else.
> > The ecma262 manual
> It is not a manual, it is a specification.
> > is intended to be read by implementors.
> Yes it is, but not exclusively. Anyone wanting to understand the > behaviour of the language would be well advised to read the > specification that dictates that behaviour.
> > There is no user guide.
> Not explicitly for ECMAScript. There are JavaScript(tm) user guides. But > then programming languages don't really have 'users', the people using a > programming language either are programmers or have a very unrealistic > attitude towards what they are doing.
> "User" is a term better reserved for the unfortunate individuals on the > receiving end of the things created by programmers. That is place where > letting 'user friendly' become synonymous with 'idiot friendly' isn't > necessarily such a bad idea.
User can mean more than one thing. Don't misinterpret.
If I wrote a class and published it, other developers could use my code; they'd be the users.
When I write a program that runs in a web browser, I am using javascript. When I am called by a recruiter, they will ask me: "Do you use [insert_programming_language_here]?"
> > Making a user-friendly manual for javascript (and it's variants) > > would be a huge benefit to the community.
Awesome that you could drop in and comment. Definitely plenty of good parts in your book. There is good reason that it's the most highly regarded/endorsed JavaScript book in existence.
I know you're busy with Ruby and real world stuff as well, but I feel strongly about this issue
ECMA 262 needs a user manual.
Java has one; it's called the JLS (Java Language Specification). It's easier to read than the ECMA 262 spec.
If ECMAScript had a manual full of examples, there would be a lot less confusion among us javascript developers; it would be easier to clear up confusion/misunderstanding. We'd all be able to scream at implementations when they we're wrong.
The lack of a manual for JavaScript is the largest reason that JavaScript is "the world's most misunderstood programming language."
Here's another quote from Doug's website:
"... Substandard Standard
The official specification for the language is published by ECMA. The specification is of extremely poor quality. It is difficult to read and very difficult to understand. This has been a contributor to the Bad Book problem because authors have been unable to use the standard document to improve their own understanding of the language. ECMA and the TC39 committee should be deeply embarrassed. ..."
I don't agree with Doug on all things, but this is one thing that I do agree on, and strongly. We all know Doug knows JavaScript.
dflana...@gmail.com said the following on 9/3/2007 5:27 PM:
> Hi All,
> Allow me to weigh in here on my book.
> 1) Thanks for the continued listing of the book in the FAQ. I > appreciate the listing, even if it is only a citation as, as Richard > would have it, "the least bad" book. Though I do like to believe that > there are lots of good parts in the book, too :-)
You can please some of the people all of the time. You can please all of the people some of the time. You can't please all of the people all of the time :)
As for the FAQ Entry, I don't see your book coming out of it any time in the near future.
> 2) I don't believe that a link to my blog is appropriate. Recently > I've been blogging about Ruby the most, and also Java, with little > JavaScript content. I do think that, for purposes of identification, > it would be valuable to link my name to my website (which happens to > be a blog). That way I won't be mistaken for the conservative > political blogger, for example, who shares my name.
If I remember right, when the blog address was added you were blogging about the book. The link to it has been removed from my local copy and will be removed from the online copy of the FAQ sometime this week.
> 3) The JavaScript pocket reference is probably out of date, and while > I appreciate the listing, you might consider removing that link. > (Though the regular readers of this group might have a more well- > informed opinion about whether it is still a useful work.)
Nothing quite like an author suggesting you not recommend his own book. The reference to it has been removed locally and will also get removed this week from the online version.
<dhtmlkitc...@gmail.com> wrote: > On Sep 3, 5:13 pm, Richard Cornford wrote: >> <dhtmlkitc...@gmail.com> wrote: <snip> >>> The ecma262 manual
>> It is not a manual, it is a specification.
>>> is intended to be read by implementors.
>> Yes it is, but not exclusively. Anyone wanting to understand >> the behaviour of the language would be well advised to read >> the specification that dictates that behaviour.
>>> There is no user guide.
>> Not explicitly for ECMAScript. There are JavaScript(tm) user >> guides. But then programming languages don't really have 'users', >> the people using a programming language either are programmers >> or have a very unrealistic attitude towards what they are doing.
>> "User" is a term better reserved for the unfortunate individuals >> on the receiving end of the things created by programmers. That >> is place where letting 'user friendly' become synonymous with >> 'idiot friendly' isn't necessarily such a bad idea.
> User can mean more than one thing.
Most terms can mean more than one thing, but it is useful for communication if they are used to mean a specific thing in particular contexts. Programmers and users have a particular, and important relationship. So it is not a good idea to attach the label 'user' to both parties in that relationship.
> Don't misinterpret.
Avoid being ambiguous and I will not have the opportunity.
> If I wrote a class and published it, other developers could > use my code; they'd be the users.
If by 'class' you mean some structure defined in javascript source code then the only way in which they could 'use' it would be in writing a computer program, and the person writing a computer program is a programmer, whether they like it or not.
> When I write a program that runs in a web browser, I am > using javascript.
And you are also then a person engaging in programming; a programmer.
> When I am called by a recruiter, they will ask me: > "Do you use [insert_programming_language_here]?"
Seems unlikely. The question "do you know [insert_programming_language_here]?" would be more reasonable.
>>> Making a user-friendly manual for javascript (and it's >>> variants) would be a huge benefit to the community.
>> <snip>
>> Which community would that be?
> web-developers/javascript developer community.
<snip>
So that would be a purely rhetorical "community", as significant as talking of 'a hat wearing community'.
It would be trivial to argue that anything that made learning javascript easier would act to harm such a rhetorical community; In a free market economy supply and demand relationships influence pricing. If the supply of javascript programmers is less than the demand for javascript programmers the remuneration they can achieve (on average) will rise. If the supply of javascript programmers rises, and particularly if it rises to exceed the demand for them, their average remuneration will fall. Your community will suffer if all of its individual members experience a relative fall in their income.
It may be the case that individuals who what to learn javascript, or better understand it, may benefit form having access to better sources of information. More is not necessarily the same as better, and as many web-based javascript (indeed web development in general) 'tutorials' demonstrate, sometimes nothing would be better than what is available (as that would avoid people having to unlearn what they thought they had learnt from other people's misconceptions and bad practices).
Dr J R Stockton said the following on 9/2/2007 4:10 PM:
> In comp.lang.javascript message <fbd94a$p05$1$8300d...@news.demon.co.uk> > , Sun, 2 Sep 2007 04:02:44, Richard Cornford > <Rich...@litotes.demon.co.uk> posted: >> That was a real and demonstrable issue with Flanagan's book, and I can >> find plenty more of them, and back them up with reasoned argument and >> practical demonstration.
> To be constructive, you could do that, and send it to David Flanagan so > that the Sixth Edition could be improved. His E-mail address is easy to > find.
> But, as regards the FAQ, that's a detail.
As regards the FAQ, the entry is staying the way it is for now.
> The FAQ maintainer seems to have wanted to say something equivalent to > "The book ... is strongly endorsed by all experts in this newsgroup, > being (when read in conjunction with its Errata) near enough perfectly > accurate" - and cannot find anything to replace the ellipsis.
Contrary to what you may think, may want to think, believe or want to believe, I wrote exactly what I meant to write. And nothing you think that I "seem to have wanted to say" will change it. Nor is there an ellipsis in what I wrote.
> In comp.lang.javascript message <fbfm4v$c10$1$8300d...@news.demon.co.uk> > , Mon, 3 Sep 2007 01:57:03, Richard Cornford > <Rich...@litotes.demon.co.uk> posted: >> Dr J R Stockton wrote: >>> Richard Cornford posted: >>>> That was a real and demonstrable issue with Flanagan's book, >>>> and I can find plenty more of them, and back them up with >>>> reasoned argument and practical demonstration.
>>> To be constructive, you could do that, and send it to David >>> Flanagan so that the Sixth Edition could be improved. His >>> E-mail address is easy to find. >> We can easily test that proposition. If I open the 5th edition at some >> point (it turned out to be page 60) and start commenting on what I >> find:-
>> | Page 61; Table of JavaScript operators:- >> | ... ... > Waste of space; there is no doubt that you could and would comment at > length. That is of no use unless DF reads it. As a failed FAQ > maintainer, it ill behoves you to be over-critical of a successful > author.
YSCIB. And, Richard is not a "failed FAQ maintainer" as you like to throw around. Richard did more for the FAQ in the time I he maintained it than you have done in your entire time in c.l.j. And, no matter how many times you write it, it won't make it true.
>>> But, as regards the FAQ, that's a detail.
>>> The FAQ maintainer seems to have wanted to say something >>> equivalent to "The book ... is strongly endorsed by all >>> experts in this newsgroup, being (when read in conjunction >>> with its Errata) near enough perfectly accurate" - and >>> cannot find anything to replace the ellipsis. >> Are you saying that you have deduced that from something Randy has >> written?
> Since I know RW only by his writing, that must necessarily be the case.
Your powers of deduction are flawed then. All it takes is to read what I write and comprehend it to know exactly what I meant and wrote. From your past posts, it is obvious that you fail to understand what I write and mean by what I write.
Why have you posted a message that appears to be intended as a response to David Flanagan as a reply to my message (Message-ID: <fbi7vh$51u$1$8300d...@news.demon.co.uk>)?
On Sep 3, 5:13 pm, "Richard Cornford" <Rich...@litotes.demon.co.uk> wrote:
> The specification also provides an unambiguous set of terminology for > use when talking about javascript. It is very easy for anyone who wants > to throw any terms they like into a discussion of javascript; 'stack > frames', 'scope blocks', 'call objects', 'lvalues', 'execution > contexts', and so on. And of those terms only statements about > javascript employing only 'execution context' could be judged true or > false by anyone, because it is a term that is from the languages > specification and its role in the language has a precise definition. The > other terms may be used with intended meaning, under some unstated > misconception or in a deliberate attempt to impress the uninformed with > jargonise. All become possible because in relation to javascript the are > inherently ambiguous terms.
Respectfully, I disagree. Had the spec been better written, book authors like myself could use the terminology from the spec. It was a conscious choice to use terms other than those from the spec, but it is a choice I stand by
> > The table of operators you have critiqued remains from early > > editions of the book, and I've never been quite satisfied with it.
> As does the division of the book into 'core' and 'client-side' > javascript.
This is also a decision I stand by strongly. The core language is formally specified and can be used outside of browsers, such as to script Java 6. The client-side portion is clearly distinct and I think it ought to be covered separately. The 4th edition introduced a distinction between traditional client-side JavaScript and the DOM. That distinction ceased to be relevant and those two sections have been re-integrated in the 5th edition.
