Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Book Review: Eloquent JavaScript: a Modern Introduction To Programming

samzenpus posted about a year ago | from the read-all-about-it dept.

Books 107

Michael Ross writes "Of all the computer programming languages, JavaScript may be enjoying the most unprecedented renaissance ever. Once derided as a toy language suitable only for spawning bothersome popups in browser windows, JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side. One way to get started learning this ubiquitous language is the book Eloquent JavaScript: A Modern Introduction to Programming." Read below for the rest of Michael's review.Written by Marijn Haverbeke, the book was published by No Starch Press on 3 February 2011, under the ISBN 978-1593272821. On the publisher's page for the book, visitors will find the table of contents and some reviews. (My thanks to the publisher for a review copy.) The author's book website offers much more, including HTML versions of the book (whose content differ from the print edition), errata (applicable only to the first printing of the paper edition), and an interactive code sandbox where you can run the examples (or at least some of them).

At a slender 224 pages, this volume might at first glance appear inadequate for covering such a sizable and rich language as JavaScript — and yet the table of contents suggests otherwise, with a dozen chapters covering language basics, functions, objects, arrays, error handling, functional programming, object-oriented programming, modularity, regular expressions, web programming, the DOM, browser events, and HTTP requests. In addition, readers may be reminded of how much information Kernighan and Ritchie were able to pack into the 228 pages of the first edition of their classic The C Programming Language.

Following a pleasant introduction, the first three chapters present the basics of JavaScript. In the first one, the author presents the language's fundamental grammar, specifically: values, data types, arithmetic operators, expressions, variables, control statements, the JavaScript environment, and program structure. The material assumes no prior knowledge of computer programming or even data representation.

In the second chapter, the author does a thorough job of explicating all aspects of functions, including definition form and order, variable scope, arguments, the call stack, closure, and other topics. The subsequent chapter addresses an area important to any programming language, namely, data structures — which in JavaScript are of two varieties, objects and arrays. The author illustrates some best practices, such as modularizing code.

Most programming books underemphasize or even completely neglect the critical topic of error handling, and thus it is encouraging to see the author of this book address it, as early as Chapter 4. He focuses on exception handling, and also touches upon the value of unit testing (incorrectly termed "automated testing"). The subsequent chapter describes functional programming, which is not to be confused with procedural programming, but rather refers to combining functions in order to achieve higher levels of abstraction in one's code, thereby reducing its size and better exposing its functionality amidst the syntactical clutter. One apparent technical flaw is the claim that, in HTML documents, the special characters <, >, and & always must be replaced by their entity values, even when surrounded by whitespace characters (page 78). (Incidentally, any book that mentions the KGS Go Server can't be all bad.)

Object orientation is the subject of the sixth chapter, the longest in the book. Despite the author's efforts, this material will likely prove to be the most challenging to readers, given the numerous idiosyncrasies of JavaScript's objects and their built-in methods. The next chapter explores a related topic, modularity, which unfortunately is not supported natively by JavaScript; the author presents some ideas to work around this limitation.

Of all the data processing performed by web sites and apps, a significant portion of it is text manipulation, where the use of regular expressions can be extremely valuable, despite the potential pitfalls. This is tersely covered in Chapter 8, which, in my opinion, should instead be located far earlier in the book, after the discussion on strings. The next chapter is a fast-paced examination of just some of the key aspects of client-side scripting using JavaScript. The only confusing portion is the reference to "the document tag" (page 155), with no explanation as to what that is. The last three chapters continue the discussion of in-browser programming, focusing on the Document Object Model (DOM), browser events, and HTTP requests. Some of the material feels dated, but it is a decent survey of relevant information.

The narrative is well written, aside from the use of long dashes when semicolons are called for and the occasional strange phrasing, such as "two backslashes follow each other" (page 12). Also, the book contains several erratum, most of them a simple mismatch of singular and plural forms: "The example show" (page 11), "executing a statements" (20), "is a special kind of objects" (46), "special type of objects is" (68), "with is em" (89; should read "is em"), "than of an" (90; should read "than an"), "new type of objects" (123), "used as to map" (146), "on [the] current field" (185), and "touched on [in] Chapter 9" (190).

The author wisely makes use of numerous examples, which are of two types: Most if not all of the fundamental concepts are illustrated with pithy examples — particularly in the first half. In Chapters 3, 5, 6, and 11, the author utilizes extended, fictional examples. Some readers may argue that these longer ones are excessively so — especially the terrarium — but there are many nuggets to be found in those pages. In fact, the book overall is largely free of fluff.

In terms of technical information, the book does not attempt to cover all the details of the language itself. Readers will appreciate that the author does not shrink from pointing out the weaknesses in JavaScript, as well as explaining the problems they may cause. One blemish is that many of the small sections of code contain a mixture of complete lines of code as well as standalone expressions (in bold), and usually those expressions are terminated with semicolons, giving them the appearance of lines of code. No doubt some readers will be confused by this convention.

From a production standpoint, the text is quite readable, except for the quite annoying and obvious problem that the font to indicate in-line source code looks almost identical to the non-code text font. There are few diagrams and even fewer screenshots, but that poses no difficulties.

At times this book is even fun to read, partly because of the use of non-silly humor, especially in the two examples of the eccentric (and cat-centric) aunt, and an unsocial reclusive programmer (imagine that).

If you choose to start your JavaScript journey with this book, it can quickly teach you a lot of technical information (relative to its size), and also programming wisdom.

Michael Ross is a freelance web developer and writer.

You can purchase Eloquent JavaScript: A Modern Introduction to Programming from amazon.com. Slashdot welcomes readers' book reviews (sci-fi included) -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×

107 comments

Sorry! There are no comments related to the filter you selected.

Points at Javascript (0)

Anonymous Coward | about a year ago | (#44287495)

Hideki!

Re:Points at Javascript (1)

flimflammer (956759) | about a year ago | (#44289979)

No, Chii. That's Javascript.

Accidentally apropos Freudian slip? (5, Funny)

c0d3g33k (102699) | about a year ago | (#44287511)

Read blow for the rest of Michael's review.

No matter how eloquent it is, Java(ECMA)Script still blows.

Re:Accidentally apropos Freudian slip? (1)

war4peace (1628283) | about a year ago | (#44287801)

"Read blow for the rest of Michael's review."

I interpreted it as "Michael's review is blow, thou have been warned!"

mutually exclusive terms (0)

Anonymous Coward | about a year ago | (#44290555)

"Eloquent" and "Javascript" can only be logically combined if one includes a single "not" in there somewhere.

Re:Accidentally apropos Freudian slip? (1)

rsborg (111459) | about a year ago | (#44290919)

Read blow for the rest of Michael's review.

No matter how eloquent it is, Java(ECMA)Script still blows.

Laugh (or cry) all you want - it's taken over the web, and will take over the world. EMCAScript is getting better every year, it's got functional features, prototyping a la Self, is extensible as hell and has the most deployed interpreters/VMs (and JITs) in the world. With NodeJS and BackboneJS it's going to take a chunk out of server-side programming as well.

Yeah, JS is shit, just like HTML. It's also the lingua-franca of the modern web (along with HTML, of course) and it's growing faster than C or Java (leave alone C# or ObjectiveC)

Read blow? (1)

mark-t (151149) | about a year ago | (#44287567)

Wasn't that a movie with Johnny Depp about cocaine smuggling or something?

I mean, I suppose to could have been based on a book by the same name, but I have no idea what that has to with Javascript.

Oh dear. (4, Insightful)

Anonymous Coward | about a year ago | (#44287609)

JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side

"Technology". It's just another interpreted language with a 'C' like syntax. It only caught on because of marketing (it had 'Java' in its name) and that was the only client side language at the time.

Yeah, it's great to have one language for front and back, but JavaScript?

I don't want to live on this planet anymore.

Re:Oh dear. (-1)

Anonymous Coward | about a year ago | (#44287659)

Please frame your complaints in the form of pros/cons or valid attacks on the language instead of cheap rhetoric with no citations.

Re:Oh dear. (5, Funny)

bonehead (6382) | about a year ago | (#44287729)

Please frame your complaints in the form of pros/cons or valid attacks on the language instead of cheap rhetoric with no citations.

Pros: None.
Cons: JavaScript sucks donkey balls.

Re:Oh dear. (1)

jkflying (2190798) | about a year ago | (#44287885)

Goat balls too, or so I hear.

Re:Oh dear. (1)

Anonymous Coward | about a year ago | (#44288001)

That is a pro, not a con. If your server room ever ends up containing a donkey with dry balls, you will be happy when Javascript takes care of that instead of you.

Re:Oh dear. (0)

Anonymous Coward | about a year ago | (#44289091)

Pros: Its better than Python, because some of us actually like to see where our control characters are.

Re:Oh dear. (1)

dkf (304284) | about a year ago | (#44293997)

Pro: Deployed everywhere, so you can use it.
Con: Deployed everywhere, so we're stuck with it.

Re:Oh dear. (0)

Anonymous Coward | about a year ago | (#44298813)

I'll just leave this excerpt from my bug testing yesterday here:

http://cl.ly/image/25232j46183C

Translation:

Wat?

Re:Oh dear. (2)

bmk67 (971394) | about a year ago | (#44287849)

No. Around here we frame our posts in the form of car analogies.

Do try to keep up.

Re:Oh dear. (4, Informative)

ArcadeMan (2766669) | about a year ago | (#44287753)

What do you mean by "it was the only client side language at the time"?

It's still the only choice.

What exactly is javascript helping to do there? (0)

waterbear (190559) | about a year ago | (#44287925)

... the only client side language ...

So have I got this straight, does that mean it's the only way webpage owners can download loads of code on to my computer and run it, when all I did was click to view their page?

When exactly did they get the right to do that?

-wb-

Re:What exactly is javascript helping to do there? (2, Insightful)

Anonymous Coward | about a year ago | (#44288087)

When exactly did they get the right to do that?

You gave them that right by running a program configured to request said code and run it whenever you click a link. If you order a PB&J sandwich and don't tell them to hold the peanut butter because you have a peanut allergy, that is not a case of peanuts being force upon you. Just as you could tell people giving you food not to give you anything with peanuts in it, you could set your browser (or pick a different one) so as to not request that code.

Re:What exactly is javascript helping to do there? (1)

ATMAvatar (648864) | about a year ago | (#44291381)

If you order a PB&J sandwich and don't tell them to hold the peanut butter because you have a peanut allergy, that is not a case of peanuts being force upon you. Just as you could tell people giving you food not to give you anything with peanuts in it, you could set your browser (or pick a different one) so as to not request that code.

To bring your analogy into present-day, everything on the menu has peanuts in it. You can order water, but peanut oil might have accidentally gotten onto the glass.

There are precious few websites anymore that work completely with JavaScript disabled.

Re:What exactly is javascript helping to do there? (0)

Anonymous Coward | about a year ago | (#44296009)

You can order water, but peanut oil might have accidentally gotten onto the glass.

Because if you turn off JavaScript, it might still sneak by and run?

It is kind of a fact of life that if you have certain aversions, you will miss out on a lot, more than probably necessary, because other people move on with life and don't always take things into consideration (especially when it is a choice and not a health issue). Still, it is one thing to complain about a lack of contact as opposed to complaining something is being force upon you against your right when you ran a program that explicitly requests what you want to avoid. You could likewise complain that the internet forces images on you that may be risk being disturbing because you open random websites with a program that will load whatever images they send out.

Re:What exactly is javascript helping to do there? (1)

Arker (91948) | about a year ago | (#44288943)

When you made the mistake of pointing a web browser at their site without making sure that javascript execution was disabled or controlled in some other way first.

Re:What exactly is javascript helping to do there? (0)

Anonymous Coward | about a year ago | (#44288995)

When you started using a computer... which uses code to do things. :/

Re:Oh dear. (2)

MrBandersnatch (544818) | about a year ago | (#44289297)

Almost but not quite: I've been working with CoffeeScript which "compiles" to JavaScript and combined with JQuery its actually nice to work with....as long as one remembers to be exacting in commenting method parameter and return types. Exacting...

Re:Oh dear. (1)

starfishsystems (834319) | about a year ago | (#44289439)

Never heard of Java applets?

Re:Oh dear. (1)

dingen (958134) | about a year ago | (#44289633)

Yeah, I believe that was the second time Java didn't catch on, right after it failed the first time in embedded systems and before it failed the third time in desktop applications.

Re:Oh dear. (1)

starfishsystems (834319) | about a year ago | (#44292657)

So you're saying that it didn't exist / wasn't available / doesn't qualify as a "client side language"?

Strange definition.

Re:Oh dear. (0)

Anonymous Coward | about a year ago | (#44293205)

Not requiring a plugin is *very very* important for "deploy to basically every modern computer connected to the web"..

Re: Oh dear. (1)

dingen (958134) | about a year ago | (#44293749)

The number of systems with Java enabled in the browser is rapidly declining.

You really can't depend on Java being available in a client when developing a web application these days, especially if you're also targetting mobile devices (and with the popularity of iPads these days, you probably are).

Re: Oh dear. (1)

Fab774 (2977619) | about a year ago | (#44300169)

The number of systems with Java enabled in the browser is rapidly declining.

This is sad. I guess I'll have to port to HTML5 my super cool Java boids applets from 1998.

Re:Oh dear. (0)

Anonymous Coward | about a year ago | (#44292979)

It drives me nuts that in all these years, the only valid token for the language= value in the <script> tag is "javascript". I mean, the parameter was added for a reason. I mean couldn't Google and Firefox just decide to synchronize browser releases with Python support or something?

Re:Oh dear. (0)

Anonymous Coward | about a year ago | (#44291753)

You forgot the most important Pro!

Pro: You won't have to pay your programmers for long.

Cons: It keeps getting harder and harder to find new programmers...

Big difference here . . . (4, Insightful)

Mitchell314 (1576581) | about a year ago | (#44287727)

In addition, readers may be reminded of how much information Kernighan and Ritchie were able to pack into the 228 pages of the first edition of their classic The C Programming Language.

Yeah, but C doesn't have nearly the amount of junk as Javascript. One of these languages you can comfortably make a cheat-sheet notecard carrying a comprehensive overview of the language, as well as some of the common libraries. The other has the words 'java' and 'script' in it.

Re:Big difference here . . . (1)

yathaid (2106468) | about a year ago | (#44288417)

That is the point. Knowing this much of the language, "the Good Parts" is enough to be productive and not screw up. Until you dig deeper and learn the bad parts and why they are bad.

Re:Big difference here . . . (4, Interesting)

siride (974284) | about a year ago | (#44288865)

It's so easy to stray into undefined behavior with C. The language is full of gotchas. Sure, the tip of the iceberg could fit on a notecard or two, but the messy details sure as hell won't. They have whole FAQs for that: http://c-faq.com/ [c-faq.com] .

Re:Big difference here . . . (1)

ATMAvatar (648864) | about a year ago | (#44291407)

I don't remember C or C++ having these kinds of gotchas [wtfjs.com] .

Re:Big difference here . . . (1)

siride (974284) | about a year ago | (#44291517)

I'm sorry, I wasn't aware that the fact that JS also has some gotchas (many of which are not really gotchas at all, or only happen because of trying to break the language intentionally) means that C and C++ don't have any gotchas. C has a gotcha where a pointer to a freed object can lead to writing over other objects and only seeing the damage appear way later in unrelated parts of the program. There are few gotchas in JavaScript as pernicious as just that one. The JS gotchas in your page are all fairly local, at least.

Re:Big difference here . . . (1)

phantomfive (622387) | about a year ago | (#44291879)

C has a gotcha where a pointer to a freed object can lead to writing over other objects and only seeing the damage appear way later in unrelated parts of the program.

Yeah, and in Javascript you can try to insert an object into another object, overwriting an object that was there originally, and only seeing the damage appear way later in unrelated parts of the program.

In practice neither of these cases happen very often.

If you're really having trouble, try writing a function like this, and never use free():
void myFree(void **ptr) {
free(*ptr);
*ptr = NULL;
}

Problem solved.

Re:Big difference here . . . (0)

Anonymous Coward | about a year ago | (#44293211)

I just started doing c/c++ this year and quickly came up with that. It's amazing that most code doesn't seem to do this.

Re:Big difference here . . . (1)

Anonymous Coward | about a year ago | (#44299009)

There is no such thing as C/C++. In C++ you wouldn't do this kind of nonsense. You would use a unique or shared pointer, depending on your needs.

Re:Big difference here . . . (0)

Anonymous Coward | about a year ago | (#44293435)

C has a gotcha where a pointer to a freed object can lead to writing over other objects and only seeing the damage appear way later in unrelated parts of the program.

Look at https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Object/create. Use it and then you don't have to worry about overwriting.

Cezary Tomczyk,
http://www.ctomczyk.pl/

Re:Big difference here . . . (1)

drinkypoo (153816) | about a year ago | (#44289055)

Yeah, but C doesn't have nearly the amount of junk as Javascript. One of these languages you can comfortably make a cheat-sheet notecard carrying a comprehensive overview of the language, as well as some of the common libraries.

And then you would still be in a position of reinventing things which people do all the time which are provided by Javascript.

C is cool, C is great, C is wonderful, C does not serve all purposes and it probably never will. But never say never.

Re:Big difference here . . . (0)

Anonymous Coward | about a year ago | (#44289471)

C does not serve all purposes and it probably never will.

For that we have C++.

Compatibility? (1)

Anonymous Coward | about a year ago | (#44287733)

The fun part about Javascript is the browsers incompatibilities.

Wait, did I say fun part? I meant the most horrible and annoying part.

Enjoy your 200 KB javascript libraries to code without going insane, you jackasses.

Signed,
a C programmer using microcontrollers.

Re:Compatibility? (1)

bhcompy (1877290) | about a year ago | (#44288395)

Browser incompatibilities, but also browser compatibility. The fact that it doesn't require anything special, just a browser, is why it continues to pervade everything web related.

Re:Compatibility? (1)

Tablizer (95088) | about a year ago | (#44289381)

The fact that it doesn't require anything special, just a browser, is why it continues to pervade...

Make that three browsers because as a user if it doesn't work in Chrome you try it in FireFox, and if it doesn't work in FireFox you try it in IE.

JavaScript in browsers must be a job-creating stimulus or something, because we get paid to play Whack-A-Mole with browser compatibility.

Sure, it pays the bills, but at the cost of gray hair and sunken hollow bloodshot eyes.

Re:Compatibility? (0)

Anonymous Coward | about a year ago | (#44289219)

Enjoy your 200 KB javascript libraries to code without going insane, you jackasses.

OMG! 200KB? Who has that kinda space sitting around.

Re:Compatibility? (1)

flimflammer (956759) | about a year ago | (#44290011)

The point is everything but the physical disk space. The added time it takes to process, compile, and run, added to the rest of the website. Especially when it comes to mobile platforms.

Re:Compatibility? (0)

aztracker1 (702135) | about a year ago | (#44290481)

In most cases those aren't JavaScript incompatibilities... those are BROWSER incompatibilities... I *REALLY* wish people could understand the difference.

Re:Compatibility? (0)

narcc (412956) | about a year ago | (#44294099)

They understand, they just choose to ignore that uncomfortable fact. See, bashing popular languages makes them feel smart and important. Repeating the most common complaints, right or wrong, is easy and they're not likely to get called out if they're wrong. Even if they do, they're very likely to get the "its' a common misconception" response. No big deal.

Finding and articulating actual problems is very difficult -- and they risk real criticism if they're wrong. They know better than to risk their ego!

Renaissance of a toy language: still a toy. (2, Insightful)

Anonymous Coward | about a year ago | (#44287739)

Seeking eloquence in javascript is much like finding elegance in PHP, or expressiveness in COBOL, or clarity in BASIC. All of them are widely used, hugely popular in their day and with us still. None of them are really any good in any objective sense beyond massive doses of AOL. But mere popularity really doesn't embody anything but wide use. Not quality, not usefulness, not maintainability, not robustness, nothing but the bare fact that many people try to use it. If there's anything to be inferred from this at all, it's something that says dark things indeed about the thought processes, their quality and utility, their ability to achieve, in most of the population. Best not go there, citizen. Here's a happy pill. Enjoy!

we had losers like you back in the 90s (1)

Anonymous Coward | about a year ago | (#44288029)

meanwhile the web keeps moving forward. JavaScript has its place just like any technology and can be similarly misused.

Re:Renaissance of a toy language: still a toy. (2, Informative)

Anonymous Coward | about a year ago | (#44288301)

I think the main benefit of Javascript, and perhaps the reason behind ubiquity, is how forgiving it is. It's fun and easy to learn because, instead of failing to compile and generating 52 errors, Javascript will happily print out numbers like strings and add words to numbers, cheerfully hide global variables with local ones without complaint, and do all manner of weird, often unwanted behaviors, while still *kinda working*, at least enough to get you to keep screwing with it. If Ruby shipped in browsers and did DOM manipulation, I'm sure everyone would switch overnight, but Javascript is right there, in every browser, waiting for anyone with a text editor and a dream, to ruin that dream.

Re:Renaissance of a toy language: still a toy. (3, Insightful)

BlackHawk-666 (560896) | about a year ago | (#44288679)

C has scope rules that hide global variables when local ones are declared in scope also. C can also do all manner of weird and often unwanted things.

The main difference is that C can't be programmed by the monkeys who usually slap web pages together...it's just too exacting, while Javascript can. Famously, you can shoot yourself in both the foot and the face at the same time in C. Javascript doesn't even have a trigger let alone any ammo in the chamber.

Re:Renaissance of a toy language: still a toy. (1)

TechyImmigrant (175943) | about a year ago | (#44289617)

>I think the main benefit of Javascript,..

No. It's because it's the only client side option in browsers.

Re:Renaissance of a toy language: still a toy. (1)

aztracker1 (702135) | about a year ago | (#44290495)

Okay, so create a Ruby -> JS transpiler... there are plenty out there for other languages (Dart, CoffeeScript, TypeScript etc) that many people seem to be perfectly comfortable with... Oh yeah, you still have the DOM problems, which are emphatically *NOT* part of the JavaScript language.

Re: Renaissance of a toy language: still a toy. (2, Interesting)

Anonymous Coward | about a year ago | (#44289211)

are you joking? javascript, when used the way it was meant to be used - as an object-oriented language with protoypal inheritance - is *extremely* elegant. yes, there are some messy parts and a severe lack of decent string and array functions, but the language itself is incredibly flexible and powerful. especially when using a framework (currently i'm fond of angularjs), it's a pleasure to write javascript for the web. quickly becoming one of my favorite languages.

i don't know any GOOD web developers who don't like javascript (i realize this is just an anecdote). i think most of the hate it gets comes from people who either a) aren't very familiar with it, b) don't develop for the web, or c) are paranoid about their browsers executing code (which has nothing to do with the language itself).

Re: Renaissance of a toy language: still a toy. (0)

Anonymous Coward | about a year ago | (#44289873)

You have Stockholm Syndrome for Programmers. I'm told I'm a good web developer - my paycheck suggests I may be. I've been doing it since the mid 90s, and have an MSCS. I HATE that bastard tongue. I need to use it, but I don't LIKE using it. I feel like I'm being held hostage by the browsers.

Re: Renaissance of a toy language: still a toy. (1)

TechyImmigrant (175943) | about a year ago | (#44290107)

Can you extend this argument to JS+DOM?

No, you can't because DOM is not a thing of beauty.

Re: Renaissance of a toy language: still a toy. (1)

Seraphim_72 (622457) | about a year ago | (#44300373)

Since when was JavaScript Object Orientated? Out of the box it sure isn't. Yes there are kludges to make it *look* OO, but OO it ain't.

Coming soon from No Starch Press (1)

Anonymous Coward | about a year ago | (#44287761)

Relaxing Employee Performance Reviews and Easy 1000-ft Gain Backpack Hikes.

Re:Coming soon from No Starch Press (0)

Anonymous Coward | about a year ago | (#44293125)

1000-ft gain is actually pretty easy. Most such hikes don't even warrant a backpack. More like a daypack. Just speaking up for the segment of Slashdot that likes to get outside in the big blue room. That'd be the "wears hiking shoes all the time, as if a mountain is suddenly going to spring up in the server room" geek stereotype as opposed to the "big fat load that gets winded going up stairs" geek stereotype.

Irony much? (1)

Anonymous Coward | about a year ago | (#44287795)

the book contains several erratum, most of them a simple mismatch of singular and plural forms

Er, the plural of erratum is errata.

Re:Irony much? (0)

Anonymous Coward | about a year ago | (#44288487)

I, for one, can't abide the tedia of self-appointed grammar genii.

Re:Irony much? (0)

Anonymous Coward | about a year ago | (#44289375)

and umm... those were errors, not errata

Re:Irony much? (1)

ebno-10db (1459097) | about a year ago | (#44289429)

the plural of erratum is errata

Or erratums.

Just because we imported the word from Latin 400+ years ago, is no reason to keep using the Latin style pluralization. In the spirit of being even more pretentious by recommending a less pretentious style, there is a general trend to consider it correct to use, or even preferable to use, English style pluralization for words that English imported from Latin and Greek. May it be so for many milleniums.

http://www.memidex.com/erratums [memidex.com]

Re:Irony much? (0)

Anonymous Coward | about a year ago | (#44290105)

> Just because we imported the word from Latin 400+ years ago, is no reason to keep using the Latin style pluralization.

I partially agree. Pluralize in English style for true imports, but erratum isn't an imported word, it's a Latin word. We already have the perfectly good English word "error." You can feel free to use erratum instead of "error," but if you do, you should probably use the Latin plural as well. Better yet, skip the pretension you spotted and just say "errors."

Security (1)

0xG (712423) | about a year ago | (#44287835)

Most programming books underemphasize or even completely neglect the critical topic of error handling, and thus it is encouraging to see the author of this book address it

Most programming books underemphasize or even completely neglect the critical topic of security, and thus it is discouraging to see the author of this book fail to address it,

Renaissance? (0)

Anonymous Coward | about a year ago | (#44287839)

It's not a renaissance.. it's the start of a new dark age.

I'm a fan of javascript (3, Funny)

The End Of Days (1243248) | about a year ago | (#44287889)

And I'm doubly a fan knowing that so many of you whiners hate it. Makes me feel like I must be doing something right.

Word, testify! (1)

Medievalist (16032) | about a year ago | (#44288545)

I'm a fan of javascript... And I'm doubly a fan knowing that so many of you whiners hate it. Makes me feel like I must be doing something right.

That's pretty much how I feel about PHP.

Re:I'm a fan of javascript (0)

Anonymous Coward | about a year ago | (#44288833)

Nope you're just a tard.

Eloquent JavaScript?? (0)

Steve_Ussler (2941703) | about a year ago | (#44288335)

JavaScript is many things...eloquent...not!

I see what you did there. (2)

AkkarAnadyr (164341) | about a year ago | (#44288585)

Also, the book contains several erratum, most of them a simple mismatch of singular and plural forms:

A sentence with a 'single errata' contains a mismatch between Latin and English singular and plural forms also too (moreover in addition).

Re:I see what you did there. (1)

phantomfive (622387) | about a year ago | (#44289849)

Is that you, Eliza?

Re:I see what you did there. (0)

Anonymous Coward | about a year ago | (#44291455)

Lordy, I get tired of hearing people say "this phenomena" and "this criteria." If you're trying to sound smart, I suggest not sounding stupid.

9/10 eh? (0)

Anonymous Coward | about a year ago | (#44288705)

I actually read that book, or tried to. As an intro to programming any language it sucked. Hard. It's soo wrapped up in trying to be eloquent that it misses teaching you the basics! No one who doesn't know javascript to begin with would give that book a decent rating.

Re:9/10 eh? (1)

parkinglot777 (2563877) | about a year ago | (#44298329)

I actually read that book, or tried to. As an intro to programming any language it sucked. Hard.

I completely agree with you for this! I have read the whole book to see how it is written. There are so many points that the author did NOT thoroughly describe or even misleads.

Before I go into the book, I want to talk about an issue that JavaScript introduces and I did not realize the changes -- variable scope. It used to be that the keyword 'var' is to declare a variable and the variable will live through out its scope. Not anymore, except between functions! Everything now becomes global and you do not need the 'var' keyword! (You do not need a semicolon at the end of the line either but for the sake of clarity.)

// Browser: Firefox 20.0 and Chrome 25.0.1364.160-0ubuntu0.10.04.1
// OS: Ubuntu 10.04
a = 7; // new variable, declare as global
function RunThis() {
var a = 1; // expect to be local
b = 100;
alert("Before Outside a/b: "+a+"/"+b) // 1/100, OK
if (true) { // force going into a scope
var a = 99; // expect to be local
var b = 9; // expect to be local
alert("After Inside a/b: "+a+"/"+b); // 99/9, OK
}
alert("After Outside a/b: "+a+"/"+b); // 99/9, shouldn't it be 1/100 ???
callAnother();
}

function callAnother() {
b = 77;
alert("See a/b: "+a+"/"+b); // 7/77, OK
}

This is a very dangerous change that could get those who come from compiled language programming in trouble, and vice versa. As you can see that 'var' keyword is now pretty much useless. The author said "The word var is used to create a new variable," which is no longer true from the example above (everything becomes a varible after an assign symbol -- '=').

Next issue with the book is some functions that are used through out the book -- print(), show(), and load(). I am not sure whether these functions are available in server-side version (i.e. Node.js), but they are NOT standard or working functions as the author claims. The print() function is a built-in and will pop up the "print" dialog on the browser. The alert() function is preferred to display whatever as a pop up on a browser. The author uses the alert() function here and there. The show() and load() functions are not built-in/standard; however, both can be found on JQuery which is a delivertive work of JavaScript!

Next, the author talks about how to initialize array and object. The author does NOT talk about variation of array initialization until later! One way to initialize an array object is on page 42 ([]), and the other is on page 118 (new Array() or new Array(length)). But then the author doesn't explain that specifying array length in JavaScript may not give much benefit if the array is not huge/complex or there are not many array manipulations (which is usually the case) because JavaScript will automatically extend the length of an array.
a = [] // []
a[3] = 12 // [undefined, undefined, undefined, 12]
a = new Array(4) // [undefined, undefined, undefined, undefined]
a[3] = 12 // [undefined, undefined, undefined, 12]
a["1"] = 7 // [undefined, 7, undefined, 12]

The same issue applies to Object ({} on page 39 and new Object() on page 104). The use of array and object may be overlapped but the author does not talk about advantages/disadvantages which would lead to different purposes of use.

When the author talks about Object ({}) and gives an example of creating a date object using Object and class Date (page 48-49), it misleads the readers! The book transition jumps from a simple object to a (built-in) class object without any explanation.
// using Object --> Object { year=1980, month=2, day=1}
var when = {year: 1980, month: 2, day: 1};
// using Date object --> Date {Fri Feb 01 1980 00:00:00 GMT-0800 (PCT)}
var when = new Date(1980, 1, 1);
They both are not equivalent at all!

The book has a chapter about error handling which is good, but the author does NOT really handle errors properly. Any unexpected behavior is usually called a bug. If the author wants to talk about handling errors coming from user input, then it is extremely difficult to deal with because of the nature of JavaScript - loose type. If the author wants to deal with it, then the chapter may talk about type checking instead. The author suggests to put an explicit comment for argument type instead of explain what type checking is.

Another example of so called "error handling" in the book is actually the logic flaw of programming. The author talks about a function which returns value of the last element of a passing array (page 59). By default the function returns 'undefined' value. When passing an array with 'undefined' value in the last element, the function returns the same value as its default value -- undefined. This is NOT an error but a logic flaw!

Last issue I want to rant about is the flow of the book. For example, when the author attempts to explain about loop in a section, it explains only 'while' and 'for' loop. It does not mention about do-while until much later (in Appendix 1). The same goes to if-else and switch statements. Also, the author does not explain that the 'break' statement is not needed in the 'default' condition.

In conclusion, the author is trying to cover too much more than he/she can handle. As a result,the author gives little to no depth to each topic he/she is talking about. This is a very bad practice because those who learned from this book will have to re-learn again (big time) when they try to go further in programming career. Even though it is nice to see someone trying to write a book about JavaScript, but claim to be eloquent or gets very high rating is not realistic.

Can't wait for the sequel... (1)

CCarrot (1562079) | about a year ago | (#44288841)

"Top 500 Oxymoronic Book Titles"

Eloquent Javascript, indeed...

Down right insulting. (0)

Anonymous Coward | about a year ago | (#44288939)

Calling JavaScript a programming language is an insult to real programmers everywhere.

I mean, I respect C/C++, Python, C#, even Java to some extent, along with many other respectable languages, but JavaScript? It's just not a real language.

Even Visual Basic is real compared to JavaScript.

Re: Down right insulting. (0)

Anonymous Coward | about a year ago | (#44289295)

in what ways is it not a real language? i use it every day to build fast web applications, and the code is very clean and elegant. seems real to me.

Re: Down right insulting. (0)

Anonymous Coward | about a year ago | (#44290485)

and the code is very clean and elegant

Which probably means it doesn't work on a wide-scale (outside your lab or company standards) because REAL web JS is filled with version-specific work-arounds and goofy tweaks that make Go-To's look friendly and inviting in comparison.

First Choice? (1)

cfulton (543949) | about a year ago | (#44289089)

JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side.

I call bullshit!

Anti-JavaScript Rant (4, Interesting)

Tablizer (95088) | about a year ago | (#44289289)

JavaScript is rapidly developing into a first-choice web technology on both the client side and the server side.

It's only used on the client-side because developers have no other choice, practically speaking. It's the only client-side language supported in most browsers. It's only client-side competitor, Flash scripting, is being killed by Apple and Google. (Java applets always sucked too much to be considered a valid competitor.)

And people want to use it on the server-side because they want to leverage their existing client-side programming knowledge, NOT necessarily because JavaScript is the best language for the job. (Although, it is fairly well-suited for small and medium custom applications.)

I really like dynamic languages and have nothing against them when used for the appropriate task. However, large complex graphics/GUI libraries are NOT the right place for a scripting language. Past a certain size and complexity, it's time for the "anal" features of compiled and type-heavy languages.

It's time we blow up JS+DOM and do HTTP-friendly GUI's right. The industry has been trying for 15 years to get JS+DOM right, and it still blows almost as much as the DLL-Hell of early desktop GUI's. The only saving grace is that we can install 3 different browsers such that it will probably work in at least one. But this triple dripple is simply an insane workaround to insanity.

Let's get the right language for systems programming, and the right GUI primitives that take care of much of the grunt-work of GUI-ness such that the client language doesn't have to carry most of the load.

Blow it up and do it right! If you can't get it right in 15 years, you likely won't get it right in a thousand, or at least I don't want to wait that fucking long.

I also suggest having a standardized single rendering engine rather than Apple making one, Microsoft another, Google yet another, Mozilla yet another, etc. Standards are too vague and difficult to write clearly in English, so let the lone implementation determine subtle specifics instead of each vender doing it slightly different such that something breaks on one or the other because something is 0.000001 pixels further left than the testing platform.

Let's stop beating a dead jsHorse.

Re:Anti-JavaScript Rant (1)

k6mfw (1182893) | about a year ago | (#44289719)

Blow it up and do it right! If you can't get it right in 15 years, you likely won't get it right in a thousand

I don't know much about java or script or javascript but I like what you said. For past 15 years there has been various scripting stuff comes and goes. Some browsers will work, then they won't then later the same browser can display a webpage. Standards are vague ( and we all know what standards are, ability to choose from several).

Re:Anti-JavaScript Rant (0)

Anonymous Coward | about a year ago | (#44289891)

You must be one unhappy person, browsing the web all day at work with such horrible tools.

SchrodingerScript (1)

Tablizer (95088) | about a year ago | (#44290451)

Yes. Where is this grand Wonderland of yours where it all just works (or at least breaks consistently). I wanna go there now!

Current browsers are powered by drunk Schrodinger cats on treadmills.

Or do you think GUI's in general are a hard problem to get right on a mass scale? Most GUI idioms have been around for 20+ years , so it's not like it's a moving target (although portables are stirring things a bit).

Re:SchrodingerScript (1)

dkf (304284) | about a year ago | (#44293991)

(although portables are stirring things a bit)

Not that hugely. They only really change a few things, of which the most notable ones are the lack of a continuously present pointer and the different set of events. If your GUI doesn't depend on tracking unclicked mouse motion, you can probably transition relatively easily.

Re:Anti-JavaScript Rant (1)

phantomfive (622387) | about a year ago | (#44293447)

It's time we blow up JS+DOM and do HTTP-friendly GUI's right.

If you want an historical example of people trying this, go look at ADA. You will see what kinds of challenges will come up, and maybe you'll think of ways to overcome them.

Re:Anti-JavaScript Rant (0)

Anonymous Coward | about a year ago | (#44293453)

It's only used on the client-side because developers have no other choice, practically speaking. It's the only client-side language supported in most browsers.

No other choice? Take a look at NodeJS [nodejs.org] .

Cezary Tomczyk [ctomczyk.pl]

Re:Anti-JavaScript Rant (1)

sribe (304414) | about a year ago | (#44297031)

No other choice? Take a look at NodeJS [nodejs.org].

Please explain in exactly what way Node.js offers an alternative to javascript on the client side; go ahead, we're waiting ;-)

Re:Anti-JavaScript Rant (1)

Tablizer (95088) | about a year ago | (#44301543)

And there's also the problem with the messy DOM. It's not just JavaScript.

Re:Anti-JavaScript Rant (0)

Anonymous Coward | about a year ago | (#44293895)

Standards are too vague and difficult to write clearly in English, [...]

Objection! Thousands, hundreds of thousands of standards exist and have many, many more working implementations. They're in use everywhere, and by and large they work just fine. They're in place for everything from, say, nuts and bolts sizes and threading, to, say, oh, the C++ standard. That they don't work well for the web isn't because of them being standards. It's because various actors are messing with the idea of having standards.

The trouble with web standards like W3C produce becomes readily apparent when you try to implement them for a browser, say. Then it turns out they're entirely written for the "web author", not for the browser implementer. And then there are numerous parties (including *cough* a convicted monopolist with well-known embrace, extend, extinguish tendencies *cough*) who do their damnedest to implement what's written juuuust so that websites "developed" for their browsers "look right" and don't for any other, especially not for their closest rival.

If you're interested, take the C++ standard and compare with the HTML standard. Look at what sort of language you see. One is precisely enough worded to implement a C++ compiler. The other isn't clear enough to write a workable browser with.

The problem is the ecosystem and the standards body and the resulting shoddy work. The idea of having standards itself is fine everywhere else. Well, almost. There's OOXML, but really, that's another attempt at subverting the idea of having standards, and was rammed through by massive lobbying and gaming the voting rules of the standards bodies involved.

What you're suggesting is describing a single standard in code--it'll still be a standard because it's the one reference implementation everyone is supposed to use. That approach has drawbacks, for example it makes for really inflexible code. What should happen is that documentation and code agree, and currently they don't for "the web" because vagueness in documentation and code that's deliberately taking advantage of that.

I agree we need better standards, but I don't agree they must be in code, and neither do I agree that the problem is too hard to tackle in English.

Re:Anti-JavaScript Rant (1)

Tablizer (95088) | about a year ago | (#44301517)

Programming languages may be sufficiently describable via English, but graphics and GUI's seem to be a different animal. It's hard to treat many features independently such that describing all the possible interactions and potential overlap behavior may be too much for text.

And how does a reference standard make for "inflexible code"?

Javascript is pretty much what it needs to be (0)

Anonymous Coward | about a year ago | (#44290631)

Which, is honestly a good thing. It's easy to use which means more of the public can use it. There's no licensing fees. It actually progresses, instead of dying. You never need to worry about compiling it or making an application. It's just really really simple; I'm at a loss for why you'd want anything running in a browser to be anything else. The web is supposed to be a platform for everyone, and I can't think of a quicker way to seal it off then to make it strongly typed and require a compiler.

Beyond that, it's a fairly strong language. You have inheritance and the ability to use functions as first class objects. In many ways it inherits from Lisp, a wonderful programming language, and isn't remotely related to javascript except in the style in which you can choose to write it.

The only thing that is unfortunate about it, is the need to import every script individually into your webpage, which of course takes extra hits unless you jam it all minified into one file. As far as things working slightly differently from browser to browser, that's generally not javascript but the graphics engines in the browsers themselves that would exist with out without javascript.

Anyhow, I was mildly amused at the efforts to disparage this language above. Donkey Balls and all; quite convincing for some of you I'm sure.

Re:Javascript is pretty much what it needs to be (1)

sribe (304414) | about a year ago | (#44297111)

Anyhow, I was mildly amused at the efforts to disparage this language above. Donkey Balls and all; quite convincing for some of you I'm sure.

While the strengths you describe are all true, you conveniently ignore a few well-know problems--or are ignorant of some of the more sophisticated points. For instance, the rules regarding scope and closures and when "this" is captured are bad mistakes, just a complete fucking mess. The several flat-out errors in the design of this language are very well known and widely discussed, such that in any reasonably sophisticated discussion of javascript people often take that knowledge for granted. I don't know if you're disingenuous or just uninformed, but either way you're wrong.

The second I quit using it. (0)

Anonymous Coward | about a year ago | (#44291705)

I forget everything.

Unit testing THE PROPER TERM? (1)

bussdriver (620565) | about a year ago | (#44299057)

The terms in this field are MADE UP and then popularized by people who love new terms so they can sound smart with more jargon to confuse the masses with their "brilliance".

Automated Testing is what it is and it existed before Unit Testing. We really must cut down on the huge number of terms we adopt in this profession and when we do, it should be something that isn't so removed from reality.... like Unit Testing or cookies...

We should shun people who mindlessly go around enforcing these new terms onto others, especially ones as young as Unit Testing.

Wizard Talk (0)

Anonymous Coward | about a year ago | (#44297065)

I know why I started to work with JavaScript. I got sick of back end wannabe wizards telling me things were not possible. So I did them myself. JavaScript is a big fat middle finger in the face of the conceited wannabe computer scientists who mask their lack of empathy, imagination and flexibility with arrogance and overcomplicated UML speak.

"erratum" (1)

xandroid (680978) | about a year ago | (#44301411)

"the book contains several erratum, most of them a simple mismatch of singular and plural forms:"

i lol'd

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>