

Bruce Eckel on JavaScript - tbassetto
http://www.artima.com/weblogs/viewpost.jsp?thread=329840

======
jsvaughan
From a synopsis of a Crockford presentation (here
<http://www.catonmat.net/blog/javascript-the-good-parts/>) here are some js
bad parts:

* Global variables.

Global variables make it harder to run independent subprograms in the same
program. If the subprograms happen to have global variables that share the
same names, then they will interfere with each other and likely fail, usually
in difficult to diagnose ways.

* Newlines get converted into semicolons. JavaScript has a mechanism that tries to correct faulty programs by automatically inserting semicolons. It sometimes inserts semicolons in places where they are not welcome.

* Operator typeof is not very helpful. For example, "typeof null" is "object", "typeof [1,2,3]" is also "object".

* Operator + adds numbers and concatenates. The + operator can add or concatenate. Which one it does depends on the types of the parameters. If either operand is an empty string, it produces the other operand converted to a string. If both operands are numbers, it produces the sum. Otherwise, it converts both operands to strings and concatenates them. This complicated behavior is a common source of bugs. If you intend + to add, make sure that both operands are numbers.

* Operators == and != do type coercion. Use of the === and !== operators is always preferred.

* Too many falsy values. 0, Nan, '' (empty string), false, null, undefined are all false.

* for ... in operator mixes inherited functions with the desired data members (it does deep reflection).

~~~
jashkenas
Nice list. One of the things that CoffeeScript manages to do, with greater or
lesser success, is to avoid many of these "bad parts":

* Global variables can no longer be created by accident ... you must explicitly `window.global = ...` them.

* Semicolons are gone, along with the headaches of automatic semicolon insertion.

* I'm afraid that not much can be done about `typeof` without a more invasive replacement, unfortunately.

* The + operator continues to work the same way.

* CoffeeScript does not have `==` or `!=`, only `===` and `!==` for strict equality comparisons. In the one location where `==` can be helpful, checking for either null or undefined, you may use the existential operator.

* When dealing with too many falsy values, there's an existential operator, which allows you to ask the question: Does this value exist? (Is this value not null or undefined?)
    
    
        name = ""
        if name?
          # Exists, so this will run.
    

* There's a shortcut to only list the "own properties" when iterating over the keys and values of an arbitrary objects, without including members from the prototype chain:
    
    
        for own key, value of object
          alert key + ": " + value

~~~
boucher
Amusingly (to me at least) the only thing Objective-J really addresses from
that list is 'typeof', which we have a much better replacement for :).

~~~
jashkenas
Nice! Got a link to the implementation, or more info?

The only reference I found to it is this thread:
[http://groups.google.com/group/objectivej/browse_thread/thre...](http://groups.google.com/group/objectivej/browse_thread/thread/f7489e3d71ee95f)

~~~
boucher
You're not going to like it :)

Rather than use typeof, CPObject has a runtime feature for asking about its
class
([https://github.com/280north/cappuccino/blob/master/Foundatio...](https://github.com/280north/cappuccino/blob/master/Foundation/CPObject.j#L179)).

Because we also do "toll-free bridging", you can ask if strings are CPStrings,
numbers are CPNumbers, and arrays are CPArrays (though we don't toll free
bridge null to CPNull, which we probably should).

~~~
jashkenas
[https://github.com/280north/cappuccino/blob/master/Foundatio...](https://github.com/280north/cappuccino/blob/master/Foundation/CPObject.j#L164-173)

Nice. Pure class-object-reference equality up to the root. Won't work calling
functions across windows, but who cares.

~~~
boucher
So, we actually have this feature where we "bridge" windows: you can basically
tell a CPWindow to map to an actual browser window. And we implement it as a
display only thing, so all of your actual code runs in the parent browser
window and just manipulates the DOM elements in the child window. It doesn't
completely work in IE I think, but I haven't tried in a while (it's kind of an
experimental feature, but it's been in the release for a while).

------
jwilliams
Not sure I follow the logic of this article - starts with closures, moves on
to somehow conditionally endorse Flex/ActionScript, references you off
elsewhere without being specific, talks about closures again, then complains
about standardisation with Browsers in general (W3C and CSS) included.

What's the beef here? Does ActionScript (JavaScript's ECMAscript cousin)
provide something that JavaScript should have? Admittedly ActionScript does
hide a lot of the nastier parts of prototypical inheritance / closures / etc
from you, but you also lose a bit of power in that. From a pure language point
of view the two also have a lot in common.

Part of the argument is around standardisation and varying implementations -
and on the same for the APIs rather than the language - but that's another
debate entirely... and probably one that has little to do with the use of
closures.

Probably some valid points here, but I can't see it making any conclusion to
take away.

~~~
ryan-allen
I'd say that's classic Eckle.

Take pity on the man, he's coming to terms with his irrelevance. I read his
books, they were rubbish. You don't teach programmers Java by starting off
with polymorphism. You don't offensively pepper example code with unit tests
to make sure the code in your book works.

Tripe such as that he has written here is the kind of talk that had poor old
JavaScript derided for years. Correct me if I'm wrong, but JavaScript always
had closures, it always had anonymous functions, it always had objects and its
for in loop, and functions were always objects! The fact it has a 'new'
keyword is because of Java bozos completely missing all the points of
JavaScript's features and demanded some familiarity.

The fact something such as CoffeeScript can generate running, valid JavaScript
is a testament to it's flexibility.

The truth is that there's an awful lot of complexity left to capitalise on,
and I'm not sure why he's complaining. He's been capitalising on it for years.

So while some people will still listen to him and avoid these new hipster
technologies, other developers are busy paving the new way and building cool
things. The tech we have ain't that bad.

~~~
j-kidd
I beg to differ. It is a good article, and it makes me want to buy and read
Javascript: The Good Part.

Other people have recommended me the book before, but they were just hipsters
who just follow whatever technology that is regarded by other hipsters as
cool.

If you read some pages and go "WTF?! This JavaScript is a helluva bad
language. WTH is the good part?", the hipsters will just come back with "Dude,
you just don't get it".

By opting for "Hell yeah, the language is super bad", Bruce Eckle presented a
strong case why the book is a required reading.

~~~
euroclydon
"JavaScript: The Good Parts" : The Good Parts:

1) Explaining the language syntax and structure.

2) Exposing all the little gotchas in the language.

"JavaScript: The Good Parts" : The Bad Parts:

It's too opinionated. Crockford has this style of presenting multiple ways of
doing things, e.g. inheritance, culminating with _his_ cute little way.

I'm not surprised a Java developer would love the book, because Crockford
evaluates the merit of the strategies he presents by how close they come to
implementing Java in JavaScript.

I've written my first large JS application over the past year and by far, my
biggest struggles have been with performance, documentation, and catching
nasty syntax errors. Private variables and information hiding? Not so much.

What's helped me the most is dumping all of Crockford's opinionated
suggestions, and using the Closure Compiler. I get great static code checking
for errors, and their JSDocs are top notch. JSDoc won't work with functional
inheritance, only prototypical, but the tradeoff is totally worth it, because
I get beautifully formatted HTML docs for all my code.

~~~
yid
Re: closure compiler, not to mention dead code removal, type checking,
conditional compilation via @define, function inlining, and a configurable
flood of useful warning and error messages. I, too, dumped Crockford for
Closure on a large web app and have been thrilled.

------
sturadnidge
Disappointing post from someone who really should know better - he confuses
JavaScript with the DOM and other things in several places (i mean really...
is he suggesting that JavaScript should have some native capability to
"include standard headers and footers on a web page"?). Maybe a better title
would be "Bruce Eckel on the W3C / DOM", as that seems to be the primary
target of his negativity.

Every language has bad parts. If you're going to call something an
abomination, you should at least take the time to understand what you are
talking about first, lest your opinion be cast aside as another uninformed
rant.

~~~
pietro
He used the lack of standardized ways of inserting headers and footers as a
example of the ineffectiveness of the W3C, not as part of his critique of
JavaScript.

~~~
sturadnidge
Yeh that's kind of my point though... it's pretty much just a jumbled rant and
somehow JavaScript wound up being the target for the headline.

------
mmahemoff
"Interestingly, the Google Apps Scripting language appears to be a (civilized)
form of JavaScript, and it looks very powerful"

This doesn't really compute. Google Apps Script is a (very cool) JavaScript
API to interact with Google Apps. It's not a replacement for JavaScript, it's
not a language at all.

"you read it you begin to understand why it's taken so long for AJAX libraries
to appear"

It _did_ take a long time, but libraries have been around for many years now
(e.g. Dojo since 2004 and jQuery since 2006).

Saying that, the article has a valid point about the language being hard to
use without such libraries. The trends in the video he linked to ("Learning to
Love JavaScript") will begin to address that, but it will take time. There's
the risk of browser fragmentation and the large legacy base.

------
tbassetto
For a newcomer, it's clear that JavaScript's inconsistencies between browser's
implementations is a real burden. I learned to love JavaScript, but I'll not
ask everybody to do so.

~~~
locci
FWIW, javascript implementations all behave very similarly surprisingly. There
are some quirks of course, like JScript not accepting trailing commas, not
allowing array like access to strings and leaking out the names of named
function expressions, or like some nastiness in IE behaviour with the global
object and window.

Especially considering the history of javascript, it's a miracle we're having
it this good. Not so much with the DOOM.

------
jorangreef
After starting out with Ruby, I now prefer Javascript to Ruby for a number of
reasons, not least performance, clarity, ubiquity, and expressive power.

Sometimes I think the detractors are more upset with their own lack of
facility in Javascript relative to their proficiency in something else, than
with flaws in the language itself.

A penny for every "accidental global variable" and "ugly {".

------
podperson
So JavaScript (or is it "JaveScript" is an "abomination" but we should mourn
Flash?). Oh wait, it's the browser implementation that's the problem.

Argh.

------
pandeiro
Tl;dr: "I need to learn a new language and it's different than Java, Python,
and C++. WAAAHHHHHHH"

~~~
akdetrick
Every problem in computer science can be solved with blaming the programming
language.

------
Hrundi
> _JaveScript_ is an Abomination

Ouch

~~~
demallien
Sure, but the guy freely admits that he is not yet very experienced with
Javascript. My own personal experience with it was definitely love/hate for
the first 6 months or so, but once I started figuring out what idiomatic
Javascript looks like, it started seducing me. My current project is a roughly
50/50 split of Javascript and C - at the start I preferred to do things in C
if possible, and avoid Javascript, but now the reverse is true.

~~~
macavity23
My JavaScript experience was similar. I blame it on the name, stupid as that
sounds, because the first thought of a newbie is likely to be 'Oh, this is
like Java'.

As JavaScript syntax is similar to Java at a glance, this leads one to try and
write Java-like programs, which end up being a hideous mess, because of course
JavaScript is _nothing_ like Java. Once you get the light bulb moment when you
realise 'hey, this is Lisp!' (though an extremely limited Lisp), your approach
to the language changes instantly, and it actually becomes quite elegant in
its own way.

Also, JQuery. JQuery, JQuery, JQuery. Removes entirely all the browser-
dependent annoyances and all the DOM annoyances. Don't even think of writing
JavaScript in web pages without it!

~~~
ludwigvan
> My JavaScript experience was similar. I blame it on the name, stupid as that
> sounds, because the first thought of a newbie is likely to be 'Oh, this is
> like Java'.

Even worse, because JavaScript is one of the few languages that people think
they can use without actually learning it, because it was somehow designed to
be that way: an easy to use scripting language. Copying and pasting small
snippets from the Web adds insult to injury, so that someone might claim to
know JavaScript after working out some issue with the help of a JQuery plugin
(Not that I'm against JQuery, I use it and love it, I'm talking about people
not learning JavaScript at all, due to the easiness of JQuery possibly.)

The thing to realize is, as you mentioned, and as Crockford says, JavaScript
is Lisp in C's clothing; I'm not sure where Eckel got the idea that JavaScript
is an abomination, reading Crockford's book should make someone think that
JavaScript is an elegant language.

------
va_coder
Let the code speak for itself: V8, Node, jQuery, Underscore, CoffeeScript, etc

~~~
nirvdrum
Aren't like half of those projects designed to normalize the language? And a
third of them are actually written in C, not JavaScript? I guess your comment
is technically neutral, so I don't really know what point you were trying to
make. But I assumed it was a refutation of the article.

~~~
yid
"normalize" is a relative term. Does CPAN normalize Perl? Does STL normalize
C++? The prevalence of a suite of libraries and tools is a _good_ thing.

~~~
nirvdrum
Perhaps "language" was the wrong term, but "execution environment" might work.
jQuery allows one to treat browsers uniformly so you're not dealing with DOM
quirks all over the place. CoffeeScript is designed to basically replace
JavaScript syntax. CPAN wouldn't really be a fair comparison, but boost would
be.

------
funkah
He's not really wrong about anything, but none of this is novel or insightful.
We're all set on "JaveScript[sic] is an Abomination" and "CSS -- who thought
that was a good idea?" rants.

That last quote just makes him sound crotchety. I guess he wants all these
dang web developers to get off his lawn.

------
deferredviod
is he trolling?

------
Tichy
He should have stayed with Java.

------
d0m
Disapointed by Bruce Eckel :-/

Javascript != Java; it doesn't mean it's an abomination. I do agree that there
are pitfals.. but damn, get over it as it's such a beautiful language. I love
JavaScript.

I feel like the guy just read the book of Crockford and just got it all wrong.

~~~
nirvdrum
While he did write the Java books we're all familiar with, Bruce has abandoned
that language and doesn't speak kindly of it. He's largely been all-in with
Python, although he recently had some kind things to say about Scala. In any
event, I'm quite certain he's decidedly not looking for anything that looks
like Java.

