

Evolution of a Prototypal Language User - telemachos
http://blog.izs.me/post/4731036392/evolution-of-a-prototypal-language-user

======
ntoshev
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"?

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

~~~
calebmpeterson
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.

~~~
olavk
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.

~~~
chc
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.

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

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

------
ichverstehe
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>

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

~~~
olavk
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.

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

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

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

------
russellallen
7\. Learn Self :)

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

~~~
zefhous
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>

