Evolution of a Prototypal Language User | Hacker News Reader

Evolution of a Prototypal Language User

blog.izs.me

64 pointstelemachos21 comments

I don't actually write object oriented (class-based or prototypal) code in Javascript, I write functional code instead and it seems to work well. Am I missing something? Any examples of "actual applications that are best modeled with prototype chains"?

In general I've found that Javascript suddenly becomes a very awesome and even understandable language once you start using it as functional.

This has been my general experience too. I've found myself taking Crockford's description of "Scheme in C's clothing" to heart. I treat object's more as first-class maps/associative arrays - much in the same way that maps are first class in Clojure - than I do as proper OOP objects.

Functional JavaScript is exciting and maleable to me, which is a breath of fresh air after (still) waiting so long for proper closures and anon functions in Java.

This is a semantic quibble, but I disagree that objects in JavaScript are any less proper OO just because they are implemented as associative arrays. JavaScript is a fundamentally OO language in a way Scheme is not - for example all built-in types in JavaScript are objects with methods.

I think OO is getting a bad name due to people annoyed with Java, and functional is hip these days. But JavaScript is still an OO language.

I think you're a little bit eager to defend JavaScript's OO credentials here. Nobody said anything like "objects in JavaScript aren't proper OO" or "JavaScript is not an OO language." Caleb said that he prefers to use a functional style of programming in JavaScript and tends to treat objects as simple maps.

Glad to see that my explanation wasn't hopelessly incomprehensible.

Now if only JS supported immutability... I think I'll go learn some more Clojure. :)

In ECMAScript 5 there is support for immutability with Object.seal(), Object.freeze() and Object.preventExtensions()

You are right. Apparently I cant read.

no problem at all-happens to me regularly

> This is a semantic quibble, but I disagree that objects in JavaScript are any less proper OO just because they are implemented as associative arrays. JavaScript is a fundamentally OO language in a way Scheme is not - for example all built-in types in JavaScript are objects with methods.

Not even a semantic quibble - more like me poorly expressing my typical use of objects in JavaScript. I agree - objects in JS are full objects. I just tend to limit my use of them to the associative array realm...

> I think OO is getting a bad name due to people annoyed with Java, and functional is hip these days.

Agreed. I've written ~250K lines of Java (real-time, highly parallel and concurrent systems with hardware accelerated UI) in the past 3 years and love many things about the language and (especially) the JVM. FP is certainly in vogue right now - and for mostly good reasons. Hopefully as the pendulum swings we'll end up with a healthy middle-of-the-road approach which incorporates OO and FP. After all, closures are a poor man's object and objects are a poor man's closure.

> But JavaScript is still an OO language.

Most certainly! I was just highlighting the ability to (mis)use it as a functional language. Though as a functional language its lack of immutability is a double edged sword...

Maybe that's what should be filled in where the author says "I’m really wondering what’s next on this list".

But I don't think it's the logical next step in the evolution described - it's rather what happens if you learn Lisp or Haskell or so and then revisit your javascript practises.

Maybe your own code is functional, but the DOM and browser API you interact with is a prototype-based object model. A JavaScript application is basically event handlers attached to the DOM/browser framework, and you produce output by changing properties on these objects. So I don't think you can escape the OO paradigm.

(In most cases you don't need to know if the DOM is class based or prototype-based though. It only matters if you use advances features like modifying the prototype of an element.)

Even if you work outside the browser, you still have to work with the basic types like arrays in a OO manner.

Prototypes are, unfortunately, a bit convoluted in JavaScript. In Io[1], on the other hand, their beauty are readily apparent.

[1] http://www.iolanguage.com/scm/io/docs/IoGuide.html#Objects

Many people have tried to make javascript function with traditional OO inheritance, which makes me wary. Do people try to do this because they find the prototypal model unfamiliar? It seems so.

I was hesitant to get into OO style in PHP and even Python, because it seemed to me to be over-applied. While classic inheritance and objects are useful, they're not the answer to everything, as most readers of HN probably agree. I'm glad to see more people embracing JS's prototypal nature.

One reason is perhaps that the prototypal patterns has not been that well supported in JavaScript.

For example the use of constructor functions and the "new" operator parallels classes in traditional OO. A perhaps more "prototypal" approach would be to define instances by using object literal syntax. But the object literal syntax does not allow one to define the prototype, so it is more limited than using constructors.

One of the proposed extensions in the abandoned ECMAScript 4 proposal was to allow prototype definition in object literals, like:

  var obj = { x : 10, __proto__: protoobj };

This would make prototypal inheritance more natural, since you don't need the constructor as an intermediate step.

ECMAScript 5 has the method Object.create which creates a new instance with the given prototype:

    var obj = Object.create(protoobj, {x: 10});

But this is not yet widely supported, while "new" has been in the core since day one.

Basically the JavaScript language has been slow to fully embrace its prototypal nature.

True, the object instantiation syntax has been bizarre from the beginning. That's created a lot of confusion and workarounds.

For me, step 3 was the overuse of nested closures to store state. More elegant in many ways, but at a significant cost in performance.

I think one mistake of JavaScript was to hide the __proto__ property on objects. (In some implementations it is exposed, but it is not part of the standard.) This makes the concept of inheritance somewhat opaque, and makes it hard to e.g. forward calls to an overridden method.

7. Learn Self :)

7. Use an MVC framework (like Backbone) and forget all about it!

Yes, using Backbone is convenient and great. But instead of using it and not worrying about the details why not read the annotated source and learn something?

http://documentcloud.github.com/backbone/docs/backbone.html

Reply on news.ycombinator.com