Bruce Eckel on JavaScript

http://www.artima.com/weblogs/viewpost.jsp?thread=329840

by tbassetto • 15 years ago

78 56 15 years ago

artima.com

Hrundi• 15 years ago

> JaveScript is an Abomination

Ouch

demallien• 15 years ago

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.

sorbits• 15 years ago

Same guy also did a hasted post criticizing Ruby¹ so I wouldn’t really put anything into his “first look” at a programming language.

¹ He removed his first post and did a less negative follow-up: http://www.artima.com/weblogs/viewpost.jsp?thread=146091

macavity23• 15 years ago

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!

tbassetto• 15 years ago

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• 15 years ago

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.

mmahemoff• 15 years ago

"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.

jwilliams• 15 years ago

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• 15 years ago

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• 15 years ago

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.

T-R2• 15 years ago

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

s/Javascript/Brainfuck

It's not all bad, but even overlooking Standards and DOM issues, the language itself has some not insignificant, bug causing issues, as brought up in some other comments. Compiling into a strict subset of an interpreted language shouldn't be considered a sufficient alternative to a real VM, or a language without those flaws.

pietro2• 15 years ago

ActionScript has changed a lot. ActionScript 3 shares a core with JavaScript, and it still supports closures and prototype-based inheritance. If you insist. But the thing is, nobody uses those features anymore. Class-based inheritance and encapsulation are so much nicer to use. Most modern ActionScript 3 code looks like Java.

geraldalewis• 15 years ago

ActionScript 2 & 3 have a bunch of features being proposed for future versions of JavaScript: constants, parameter defaults, rest params, proxies, weak maps, binary data, private/protected/internal access modifiers. Also has an optional type annotation system (types are an actual part of the language in AS3), automatically-bound functions (AS3), and a Class system. Prototypes and closures are still present in the language (I still use them a lot, but many AS3 programmers do not). (It sounds like parent is familiar with AS (and the question may have been rhetorical), but I included the above list for those who are interested in the differences.)

Having said all that, I don't believe those features are what the author prefers about the Flash environment. It seems Mr. Eckel is: * lamenting the loss of `packages` (AS3; AS2 had namespaces for Classes) as I surmised from the closures section (closures as a way of creating private members) * in need of a good framework for building GUIs (he stated he liked Flex [a framework for AS]; though many good GUI frameworks exist for JS) * has bought into the popular opinion that JavaScript is a broken and bad language (though many of the same issues plague AS; in fact, despite what the article may imply, AS and JS share the same way of creating a scope [via functions, not by blocks])

I agree that Mr. Eckel did not succeed in making any clear points. Writing this comment was especially difficult because the article was unfocused. It was not the usual quality I expect from a front page HN post.

deferredviod• 15 years ago

is he trolling?

sturadnidge2• 15 years ago

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.

pietro2• 15 years ago

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.

sturadnidge2• 15 years ago

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.

Tichy• 15 years ago

He should have stayed with Java.

jsvaughan• 15 years ago

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).

ajuc2• 15 years ago

IMHO the worst problem with JS is too losely defined standard - typeof on array or on function on some implementations return Object, on some other something different, you often have to check for type of argument (when coding function that would be overloaded in languages that support this concept), and properly doing this is pain (checking is something is array is often done by checking if it has "length" property!).

Still, JS is perfect example of how important closures are for programming language - they make very bad language acceptable.

masklinn7• 15 years ago

> typeof on array or on function on some implementations return Object, on some other something different, you often have to check for type of argument

You should not be using `typeof` on object types (and this includes functions) anyway. Use `instanceof`.

> and properly doing this is pain (checking is something is array is often done by checking if it has "length" property!).

This really checks if something is array-like (for instance the jQuery object would pass this "test", even though it's not an array. Likewise for `arguments` or a NodeList)

masklinn7• 15 years ago

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

I disagree with that, actually. I like that many Python objects can be used in a boolean context and behave sensibly, and that this behavior is accessible to user-defined-types.

On this point, Javascript annoys me because on some things it works as Python (empty string) whereas in others it does not (empty array).

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

It does not do any reflection, really. It just iterates on all enumerable properties of the object, inherited or not.

benatkin2• 15 years ago

It's nice how Python has "is False". In JavaScript it's "=== false". The python version reads a lot better IMHO.

T-R2• 15 years ago

The worst part about these issues is that they aren't consistent, and fail completely silently. Global variables cause heisenbugs - you'll only notice when there's a collision, such as after compressing your script. The ==/!= operators and falsy values just put you on the wrong side of an if-statement. The for...in operator sometimes just loops a few extra times. The coercion and overloaded + operator will just sometimes give you a wrong number if you forget to caste an input:

    "25"+5 = 255
    ("25"+5)/5 = 51

masklinn7• 15 years ago

> The worst part about these issues is that they aren't consistent, and fail completely silently. Global variables cause heisenbugs - you'll only notice when there's a collision

Firefox has had the ability to warn about implicit globals for quite some time now, and strict mode will error out when encountering an implicit global being created.

reichstein• 15 years ago

Actually the problem with automatic semicolon insertion (ASI) is the opposite: It sometimes doesn't insert one where you expect it. ASI only inserts a semicolon when not inserting it would give a syntax error. It's the cases where a newline was really intended to end a statement, but doesn't, the bites you. Example ()creating a generator: var gen = null (function() { var ctr = 0; gen = function() { return ctr++; }; })(); Seems simple, but actually tries to call null as a function.

Also, the + operator doesn't treat all non-numbers as strings. It tries to treat all non-strings as numbers, if possible. Only if that fails does it try them as strings. If either argument is then a string, it does concatenation.

jashkenas3• 15 years ago

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

boucher3• 15 years ago

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 :).

podperson4• 15 years ago

I agree with most of Crockford's recommendations (and use jslint) but it's impossible to create a controlled experiment in which JavaScript was created without globals (or globals requiring declaration and locals being implicit) and inferred end-of-statement and find out if it would have been as popular. Globals make total sense to newbies, and avoiding them is not hard if you're not a newbie.

(HyperTalk, if I recall correctly, had local variables by default and global variables explicitly, and was -- I think -- even more newbie friendly than JavaScript, so it's possible that JavaScript might have thrived.)

It's not like coding in ActionScript is noticeably more pleasant than coding in JavaScript despite being controlled by a single vendor. And the dedicated ActionScript editor in Flash is far more annoying than a simple text editor.

Anyway, "abominable" is a ridiculous word for a language that has so many broadly consistent implementations, is so approachable, and yet supports so many modern programming concepts with a compact and approachable syntax.

masklinn7• 15 years ago

> (HyperTalk, if I recall correctly, had local variables by default and global variables explicitly, and was -- I think -- even more newbie friendly than JavaScript, so it's possible that JavaScript might have thrived.)

That's what Python does, it has its own severe failings (especially when the language is lexically scoped). I like dynamically typed languages, but I've come to the conclusion that scope inference is terrible, and variable scoping should always be explicit (and probably statically checked as well), trying to infer variable scope will fail silently and badly.

va_coder• 15 years ago

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

nirvdrum3• 15 years ago

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.

yid2• 15 years ago

"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.

d0m• 15 years ago

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.

nirvdrum3• 15 years ago

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.

podperson4• 15 years ago

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• 15 years ago

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

akdetrick• 15 years ago

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

_urga• 15 years ago

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 {".

funkah• 15 years ago

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.

Bruce Eckel on JavaScript

Related Stories