5 ms·

This makes sad, as Douglas Crockford said in this recent talk > The prototypal school has a lot of advantages particularly compared to the classical school >

This makes sad, as Douglas Crockford said in this recent talk > The prototypal school has a lot of advantages particularly compared to the classical school > So in the classical school you have to create a classification of all the objects that are likely to be in your system. And, it's a lot of work to figure out what they all are and identify them and what their characteristics are and so on and then you have to determine how they are all related to each other, what’s going to inherit from what, what’s going to implement what, what’s going to interface with what, and that’s really complicated. And it usually happens at the beginning of the project before you fully understand what all this stuff means. So it’s likely your going to get the taxonomy wrong. It’s inevitable. > And then you’ve got two hard choices. One is you have to live with a broken taxonomy and if you do that then with each new class you introduce things get weirder and weirder because everything’s wrong, or you have to refactor and refactoring is hard and it’s error prone and it’s another world of hurt. > Those are your two choices and people who grew up in the classical school assume that’s just the way life is so no sense in complaining about it since that’s life. > But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it. > So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off) > And so that’s why I think classes in ES6 are a bad part because they lock you into that paradigm. > applause > So when you’re locked in a paradigm like that, when you can’t see past it, you just have no understanding how miserable you are. And you’ll never know until you change your model from https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s https://www.youtube.com/watch?v=bo36MrBfTk4#t=28m50s

jashkenas 12y ago
I don't mean to be argumentative (being argumentative on HN is so passé), but what you just quoted is so full of shit that I feel like someone is obligated to comment. In the prototypal model — as it exists in JavaScript — you do do all of that. You make a series of prototypes that you intend to use in your application, and those prototypes (or classes), serve as the effective taxonomy for many of the objects you're making in your app. Classes in ES6 are prototypes. They don't lock you into any such Java-esque paradigm unless you're going to be willfully ignorant about them. Please don't repeat baloney just because Crockford said it. --- For example, to be concrete: class Crockford { speechify() { return "...you're going to get the taxonomy wrong. It’s inevitable."; } } A class. A terrible, inflexible, prototype-destroying, paradigm-locking-in, JavaScript class. Eww, gross. But wait! What's this? Crockford.prototype.speechify = function() { return "...the shape of an object can change at any instant, because \ someone can fiddle with the prototype."; }; You can have your classical cake and eat prototypal cookies too. Because in any decent dynamic language, the two concepts are synonymous.
- greggman 12y ago
  It's not baloney IMO. As someone who's coded C since the 80s and C++ since the 90s I find JavaScript massively freeing. In C++ (and similar classical languages) in order to be able to pass in different implementations of a class you need to create a base class or interface. You don't need to do this in JavaScript. In JavaScript you can build objects on the fly. In fact he goes on to say > so I used to think that the important thing in JavaScript was prototypal inheritance I now think it is Class Free object oriented programing. I think that is JavaScript’s gift to humanity. That’s the thing that makes it a really interesting important language, is that it did that. That we can use functions in order to create objects and it simple and elegant and powerful and fast... And it's true. Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript. In my own experience I have a mutli-user networking system written in JavaScript and a library in C#. To reimplement the same things in JavaScript in C# is a huge amount of code bloat. I have to make classes and meta classes and all kinds of other indirection just so I can make an Event system that is generic. In JavaScript that's 2 or 3 lines That we don't actually need all the structure to get shit done is what people are finally coming to realize. The problem with 'class' in ES6 is that it will prevent people from learning this new, easier, faster, simpler way of working because instead they just bring the classical baggage to JavaScript. That's in fact what most programmers from classical languages do. It's what I did for years until I started actually grokking JavaScript. ES6 "class" will only make it take longer for people to actually get pass their old ways.
  - Touche 12y ago
    I think you're confusing this new Chrome-only thing with ES6 classes that just saves you from using a library to create constructor/prototype objects. In ES6 "class" is just a keyword that makes it easy to contruct objects that are very typical in day-to-day JS. Inheritance is already a thing that happens.
    - greggman 12y ago
      I'm not. See above, "class free object oriented programming". You don't need prototypical inheritance to have inheritance in JavaScript. Crockford gives examples. You don't need the "class" keyword. All it's going to do is steer people in the wrong direction.
Touche 12y ago
ES6 classes are just syntactic sugar for constructor/prototypes like we write them today. You can mutate them as much as you like.
- greggman 12y ago
  not in SoundScript they aren't
  - UberMouse 12y ago
    Pretty sure they still are syntactic sugar for prototypes, just like in ES6. But SoundScript enforces that you cannot modify prototypes. There's not really a problem with that, it's doing it for speed. So it's not for your average Javascript app where performance doesn't matter as much.
adamlett 12y ago
I feel like the concepts are being abused here. Prototypical — at least in my understanding — refers to a mechanism of inheritance or delegation, and not as Crockford uses the term to the way you build your objects. Confusingly, JavaScript didn't even have prototypical inheritance until relatively recently, because even though every object had a prototype, it couldn't be set or changed on an individual basis, but was determined solely by which Constructor (read: Class) that created it, which made JavaScript's inheritance mechanism essentially indistinguishable from the classical, albeit with more obscure nomenclature.
bad_user 12y ago
I don't get it. I know how prototypes in Javascript work, I can agree that you get a certain degree of flexibility that you don't get with class-based languages, which sometimes is useful, however people are still modeling classes in Javascript and people blaming education have the burden of proof - show problems that could have been solved with classes, but that were solved with a "class free" design instead. And heck, I'll go further - in my mind, both class-based and prototype-based OOP, at least as present in Javascript or other mainstream languages, sucks because it mixes data with behavior and still suffers from the expression problem, because while you can take any object and modify it for a new interface, a process called monkey patching, that's just a terrible way of doing it. OOP as a means to achieve polymorphism is simply inadequate for many use-cases. Sometimes it is much better to have type-classes (or similar, like protocols in Clojure). So you know, comparing 2 ways of dealing with OOP, misses the point that OOP on the whole is not enough, even broken as some would say.
- masklinn 12y ago
  > I can agree that you get a certain degree of flexibility that you don't get with class-based languages That's not even the case. Not in Javascript anyway. The only thing you get is not having a separate hierarchy of class objects.
  - kybernetikos 12y ago
    Most class based languages won't let you inherit from an instance, and many won't let you use the same techniques you use to inspect or constrain instances to inspect or constrain classes.
munificent 12y ago
> You just make an object, if you don’t like the way it works you make another one and that is literally it. This is, like jashekanas eloquently puts it, so full of shit. You're still creating a bunch of objects. Unless you are a mashocist (or a sadist, if other people have to maintain your code), you are still going to want to reuse methods between those objects. Once you do that, you have to have some organization between what gets reused how. Sure, prototypes give you more freedom to define different ways of organizing and reusing behavior across objects. In practice, single-delegation actually works pretty well most of the time. > So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off) It's not that you don't have to create a taxonomy in JS. It's, "First you have to conceive and implement the very idea of a taxonomy itself. Then you get to use that to create a taxonomy." You need to reuse code somehow. Figuring out a scheme for doing that is metaprogramming. JS basically says, "Well, you have to do this metaprogramming before you can get to the task you actually care about." Using classes (or any other baked-in reuse scheme like parent slots in Self) just means the language has done the metaprogramming for you and you can use it out of the box. The flexibility JS gives you is nice when the language's built-in mechanisms for code reuse aren't a good fit. But, so far, most homegrown code-reuse-systems don't seem to be that much better than what classes (with maybe some mixin or trait special sauce on top) provide.
- drapper 12y ago
  > You're still creating a bunch of objects. Unless you are a mashocist (...) you are still going to want to reuse methods between those objects. Aaaaaaand solution for that doesn't have to be a class (or something pretending to be a class), but for example a collection of functions/methods that you attach to an object, so you for example assign behaviour to data. This is something that Reginald Braithwaite for example advocates.
  - taco_emoji 12y ago
    That's called "composition over inheritance" and OO languages are perfectly capable of it.
coldtea 12y ago
>But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it. Yeah, which goes to show you shouldn't listen to Douglas Cockford. First, what he describes is playing in a REPL at best. You don't just "make another [object] if you don't like the way the fist one works" when you write a program, unless you write a structureless blob. You still have to think about your objects and/or inheritance chain, be it prototypal or not. Second, ES6 classes are nothing more than syntactic sugar over barebones prototypal inheritance. Third, you already do all that stuff in JS. You have to write a lot of boilerplate code (and usually everyone does a slightly different version) to get the same end result.
randomguy7788 12y ago
although i agree somewhat, prototypal inheritance does nothing to help solve the taxonomy. the article below i think explains the situation much better: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...

jashkenas 12y ago

I don't mean to be argumentative (being argumentative on HN is so passé), but what you just quoted is so full of shit that I feel like someone is obligated to comment. In the prototypal model — as it exists in JavaScript — you do do all of that. You make a series of prototypes that you intend to use in your application, and those prototypes (or classes), serve as the effective taxonomy for many of the objects you're making in your app. Classes in ES6 are prototypes. They don't lock you into any such Java-esque paradigm unless you're going to be willfully ignorant about them. Please don't repeat baloney just because Crockford said it. --- For example, to be concrete: class Crockford { speechify() { return "...you're going to get the taxonomy wrong. It’s inevitable."; } } A class. A terrible, inflexible, prototype-destroying, paradigm-locking-in, JavaScript class. Eww, gross. But wait! What's this? Crockford.prototype.speechify = function() { return "...the shape of an object can change at any instant, because \ someone can fiddle with the prototype."; }; You can have your classical cake and eat prototypal cookies too. Because in any decent dynamic language, the two concepts are synonymous.

greggman 12y ago
It's not baloney IMO. As someone who's coded C since the 80s and C++ since the 90s I find JavaScript massively freeing. In C++ (and similar classical languages) in order to be able to pass in different implementations of a class you need to create a base class or interface. You don't need to do this in JavaScript. In JavaScript you can build objects on the fly. In fact he goes on to say > so I used to think that the important thing in JavaScript was prototypal inheritance I now think it is Class Free object oriented programing. I think that is JavaScript’s gift to humanity. That’s the thing that makes it a really interesting important language, is that it did that. That we can use functions in order to create objects and it simple and elegant and powerful and fast... And it's true. Look at the mocking libraries for JavaScript. They're sooooooooo much easier to write than anything for classical languages because it's so easy to do in JavaScript. In my own experience I have a mutli-user networking system written in JavaScript and a library in C#. To reimplement the same things in JavaScript in C# is a huge amount of code bloat. I have to make classes and meta classes and all kinds of other indirection just so I can make an Event system that is generic. In JavaScript that's 2 or 3 lines That we don't actually need all the structure to get shit done is what people are finally coming to realize. The problem with 'class' in ES6 is that it will prevent people from learning this new, easier, faster, simpler way of working because instead they just bring the classical baggage to JavaScript. That's in fact what most programmers from classical languages do. It's what I did for years until I started actually grokking JavaScript. ES6 "class" will only make it take longer for people to actually get pass their old ways.
- Touche 12y ago
  I think you're confusing this new Chrome-only thing with ES6 classes that just saves you from using a library to create constructor/prototype objects. In ES6 "class" is just a keyword that makes it easy to contruct objects that are very typical in day-to-day JS. Inheritance is already a thing that happens.
  - greggman 12y ago
    I'm not. See above, "class free object oriented programming". You don't need prototypical inheritance to have inheritance in JavaScript. Crockford gives examples. You don't need the "class" keyword. All it's going to do is steer people in the wrong direction.

Touche 12y ago

ES6 classes are just syntactic sugar for constructor/prototypes like we write them today. You can mutate them as much as you like.

greggman 12y ago
not in SoundScript they aren't
- UberMouse 12y ago
  Pretty sure they still are syntactic sugar for prototypes, just like in ES6. But SoundScript enforces that you cannot modify prototypes. There's not really a problem with that, it's doing it for speed. So it's not for your average Javascript app where performance doesn't matter as much.

adamlett 12y ago

I feel like the concepts are being abused here. Prototypical — at least in my understanding — refers to a mechanism of inheritance or delegation, and not as Crockford uses the term to the way you build your objects. Confusingly, JavaScript didn't even have prototypical inheritance until relatively recently, because even though every object had a prototype, it couldn't be set or changed on an individual basis, but was determined solely by which Constructor (read: Class) that created it, which made JavaScript's inheritance mechanism essentially indistinguishable from the classical, albeit with more obscure nomenclature.

bad_user 12y ago

I don't get it. I know how prototypes in Javascript work, I can agree that you get a certain degree of flexibility that you don't get with class-based languages, which sometimes is useful, however people are still modeling classes in Javascript and people blaming education have the burden of proof - show problems that could have been solved with classes, but that were solved with a "class free" design instead. And heck, I'll go further - in my mind, both class-based and prototype-based OOP, at least as present in Javascript or other mainstream languages, sucks because it mixes data with behavior and still suffers from the expression problem, because while you can take any object and modify it for a new interface, a process called monkey patching, that's just a terrible way of doing it. OOP as a means to achieve polymorphism is simply inadequate for many use-cases. Sometimes it is much better to have type-classes (or similar, like protocols in Clojure). So you know, comparing 2 ways of dealing with OOP, misses the point that OOP on the whole is not enough, even broken as some would say.

masklinn 12y ago
> I can agree that you get a certain degree of flexibility that you don't get with class-based languages That's not even the case. Not in Javascript anyway. The only thing you get is not having a separate hierarchy of class objects.
- kybernetikos 12y ago
  Most class based languages won't let you inherit from an instance, and many won't let you use the same techniques you use to inspect or constrain instances to inspect or constrain classes.

munificent 12y ago

> You just make an object, if you don’t like the way it works you make another one and that is literally it. This is, like jashekanas eloquently puts it, so full of shit. You're still creating a bunch of objects. Unless you are a mashocist (or a sadist, if other people have to maintain your code), you are still going to want to reuse methods between those objects. Once you do that, you have to have some organization between what gets reused how. Sure, prototypes give you more freedom to define different ways of organizing and reusing behavior across objects. In practice, single-delegation actually works pretty well most of the time. > So you can tell people from the classical school “You don’t have to do all of that” and they go “Yea, I hear ya, but you still have to do it” and you say “no, you don’t have to do it” and they go “yea, yea, yea” (blowing you off) It's not that you don't have to create a taxonomy in JS. It's, "First you have to conceive and implement the very idea of a taxonomy itself. Then you get to use that to create a taxonomy." You need to reuse code somehow. Figuring out a scheme for doing that is metaprogramming. JS basically says, "Well, you have to do this metaprogramming before you can get to the task you actually care about." Using classes (or any other baked-in reuse scheme like parent slots in Self) just means the language has done the metaprogramming for you and you can use it out of the box. The flexibility JS gives you is nice when the language's built-in mechanisms for code reuse aren't a good fit. But, so far, most homegrown code-reuse-systems don't seem to be that much better than what classes (with maybe some mixin or trait special sauce on top) provide.

drapper 12y ago
> You're still creating a bunch of objects. Unless you are a mashocist (...) you are still going to want to reuse methods between those objects. Aaaaaaand solution for that doesn't have to be a class (or something pretending to be a class), but for example a collection of functions/methods that you attach to an object, so you for example assign behaviour to data. This is something that Reginald Braithwaite for example advocates.
- taco_emoji 12y ago
  That's called "composition over inheritance" and OO languages are perfectly capable of it.

coldtea 12y ago

>But in the prototypal school you don’t do any of that. You just make an object, if you don’t like the way it works you make another one and that is literally it. Yeah, which goes to show you shouldn't listen to Douglas Cockford. First, what he describes is playing in a REPL at best. You don't just "make another [object] if you don't like the way the fist one works" when you write a program, unless you write a structureless blob. You still have to think about your objects and/or inheritance chain, be it prototypal or not. Second, ES6 classes are nothing more than syntactic sugar over barebones prototypal inheritance. Third, you already do all that stuff in JS. You have to write a lot of boilerplate code (and usually everyone does a slightly different version) to get the same end result.

randomguy7788 12y ago

although i agree somewhat, prototypal inheritance does nothing to help solve the taxonomy. the article below i think explains the situation much better: https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-object-algebras-to-finally-tagless-interpreters-2/ https://oleksandrmanzyuk.wordpress.com/2014/06/18/from-objec...