Comment by WilliamLP | Hacker News Reader

Comment by WilliamLP | Hacker News Reader

With JavaScript, there is an interesting contrast between what its fans say are its strengths and what battle-hardened experience actually requires you to do.

For example:

- Prototype object systems are great... except don't actually use this, it doesn't really work. Use our simulation of a classical object system instead.

- Lambdas are wonderful and powerful when combined with closures... except they leak memory. Don't use them, but declare named functions.

- The 'this' parameter was a stupid idea. Use it as little as possible, except when absolutely necessary.

- Be really conscious all the time, because of a stupid and misguided semi-colon insertion feature that will mess you up.

- Don't bother trying to use anything other than C style for loops over collections. They mess you up.

- The dynamic type system is nice... however experience shows us that what we really want is actually a static system, so JavaDoc types of everything with a cumbersome and extremely verbose syntax instead.

- Extending prototypes of existing objects is an amazing and powerful feature. Please don't ever use it.

You've set up a straw man argument. Where are these JavaScript fans who are pointing to several well-known problems with the language (e.g. semicolon autoinsertion, the for-in loop, the poorly-thought-out type system) and saying they're JavaScript's strengths? No-one is saying the language doesn't have flaws.

JavaScript's strengths are that it's small and surprisingly powerful and flexible, in spite of its design mistakes.

(N.B. The bug with closures is associated with a problem in a single use case with IE6's garbage collector, and Microsoft patched it two-and-a-half years ago.)

N.B. The bug with closures is associated with a problem in a single use case with IE6's garbage collector, and Microsoft patched it two-and-a-half years ago.

Are you sure about that? From what I understood they couldn't patch it because some major unnamed web sites actually relied on DOM elements not being cleaned up to work properly.

http://blogs.msdn.com/b/ericlippert/archive/2003/09/17/53028...

As of IE 7, I remember I still had to close out memory leaks on some code that was binding an event to a DOM node.

That blog post shows their workaround for faulty GC caused problems, not that correct GC wouldn't work.

My guess is that forced DOM tear-down broke cross-frame/window references. This is not necessary in implementations that let GC clean up DOM nodes.

Prototype systems are great. I use them all the time, even in other languages. Extending prototypes of existing objects is amazing and powerful, and can be used for some beautiful data structures.

> Extending prototypes of existing objects is amazing and powerful

What can you do with it that you can't do in class-based OO languages?

Nothing you couldn't do in assembly. Just easier and more elegant.

Could you give an example? I'm curious, because I've never found any difficulties subclassing in a class-based language.

What extra does prototype-based subclassing give me?

UI example from NewtonScript http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.96.... (pdf)

Found it useful, thanks.

Leaky closures are not JS "feature", but a bug in one implementation (IE<8's GC doesn't clean up cycles). Other browsers handle that fine.

Similarly object enumeration is tricky business because implementations don't agree, especially IE<9 doesn't support DontEnum attribute properly.

Type systems can be debated endlessly. In this case I think Google's choice might be motivated by GWT (avoids impedance mismatch with Java).

There is nothing wrong with extending the prototypes of objects, as long as they are objects you own. Don't modify what you don't own is sound advice that applies to many things. I wish they went into detail on what the problem is with multi-level prototype hierarchies.

Reply on news.ycombinator.com