6 ms·

Whoop-dee-freakin’-doo??? Sure there's a zillion frameworks and patterns for shoehorning OO into JavaScript. But the point is, ES6, is standardising it. That

Whoop-dee-freakin’-doo??? Sure there's a zillion frameworks and patterns for shoehorning OO into JavaScript. But the point is, ES6, is standardising it. That means libraries going forward will assume this is the way it's done and build on top of it. It gives them more expressive power and better inter-op. Also, default params are long overdue but I'm not sure that makes them "so what". I'd rather avoid mangling the arguments array in some awkward if statements. Bottom line, there's a lot of things about JS that aren't great, but it's what all the browsers actually run so we're kind of stuck with it and any improvements are welcome. (Even if you use something like ClojureScript or CoffeeScript, JS is still the target language and the runtime. Improvements and standardisation matter.)

JackMorgan 12y ago
I think he means OO adds unnecessary complexity, hence the "bad bet".
- phpnode 12y ago
  ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that people are doing that already.
  - chriswarbo 12y ago
    I somewhat agree, but "adding tools" at the language level doesn't come for free: it causes an explosion in the number of interactions to keep track of. How do classes interact with prototypes? How do they interact with lexical scope? How do they interact with exceptions? etc. The egregious part is that, by turning something into a language feature, those who don't use it are often forced to take it into account in their code; especially library authors.
    - phpnode 12y ago
      > those who don't use it are often forced to take it into account in their code; especially library authors. No, `class` is syntactic sugar for the most common way of doing classes in ES3 and ES5. There is no semantic difference between: function Thing () {} Thing.prototype.greet = function () { alert("hello"); }; and class Thing { greet () { alert("hello"); } } They are the same, so it introduces no new traps for library authors.
      - antimagic 12y ago
        About the only thing that might be interesting to see is how constructor parameters are handled. With the prototyping system, I consider it to be a bug to initialize members in the constructor - if you always just call an 'init' method straight after construction (typically chained, much like in Objective C - var thing = new Thing().init(param); ) then protyping is very simple and does nothing surprising. It's only if you really really really want to have RAII that things become complicated...
  - rtpg 12y ago
    Just because a tool is in a box doesn't mean its useful. Considering the relative cleanliness, refactorability of code coming from the functional world (see Haskell and the like), it is debatable whether OOP is a "good" style to develop at all! If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles.
    - phpnode 12y ago
      > If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles. Sorry but that's total nonsense. For instance, node.js makes heavy use of classes, as does Backbone, Ember, React, etc
      - phpnode 12y ago
        To whoever downvoted me, am I wrong? Please explain.
        Demiurge 12y ago
        Most of the time downvoting stands for 'Your comment hurts my feelings.' This comment will be very light gray ;D
    - Demiurge 12y ago
      Just because it's possible to write a program without a tool, doesn't mean it's more productive. Functional programming doesn't even directly oppose OOP, it opposes imperative. It is absolute basics of CS that there is data and logic and many problems are easy to reason about as logic modifying data (state). OOP is a tool that allows to encapsulate some data and logic that go together. Functional programming doesn't allow you much more than that. Just because you may (or may not) end up decomposing a program into the smallest units of logic, doesn't mean you've done something useful, or clean.
      - tel 12y ago
        Without backing a horse exactly: * FP as I understand it doesn't much oppose imperative or even most of OO. It opposes non-composability using discipline from pure/total languages. * Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that (ADTs, existential types, modules, what-have-you do it fine if not far better). The remaining 90% may be a waste or actively harmful. * FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely. This may end up being some kind of full-scale OO, I'm eager to try to find places where it does, but so far it hasn't ever. As a meta note, "my kind of FP" is the Haskell type of purity and other such nonsense.
chriswarbo 12y ago
How exactly can OO be "shoehorned" into a language which is already OO?
- CmonDev 12y ago
  He meant proper OO as opposed to the shanty prototype one.
  - jbergens 12y ago
    The problem is for anyone who sees prototype OO as a better solution. They kind of give their blessings to the other OO, which is a bit sad. (edit: spelling)
    - cgcardona 12y ago
      I see it the other way--prototype OO was given the blessing of the Creators of the language back in the mid 90s when it was created. Though the people who 'get' prototypes swear that they're the greatest paradigm ever you will still get a huge amount of people coming in from other languages which find the prototype chain awkward and prefer to think in complex class hierarchies. These people who choose to create their abstractions out of classes are in no way 'wrong.' To each their own. Adding `class` syntactic sugar is just standardizing on something which many people already do every day.
  - chriswarbo 12y ago
    Since you've not defined it, I'll assume "proper OO" is referring to Alan Kay's formulation: http://c2.com/cgi/wiki?HeInventedTheTerm http://c2.com/cgi/wiki?HeInventedTheTerm In that case, his opinion on class vs. prototypes is that it misses the point: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-... As an aside, prototypes are strictly more powerful than classes, so they're no "shanty": http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De... (esp. section 6)

JackMorgan 12y ago

I think he means OO adds unnecessary complexity, hence the "bad bet".

phpnode 12y ago
ugh, really sick of this meme. OO is a tool in the box, it's useful a lot of the time, sometimes it isn't. The reason ES6 introduces the `class` keyword is that people are doing that already.
- chriswarbo 12y ago
  I somewhat agree, but "adding tools" at the language level doesn't come for free: it causes an explosion in the number of interactions to keep track of. How do classes interact with prototypes? How do they interact with lexical scope? How do they interact with exceptions? etc. The egregious part is that, by turning something into a language feature, those who don't use it are often forced to take it into account in their code; especially library authors.
  - phpnode 12y ago
    > those who don't use it are often forced to take it into account in their code; especially library authors. No, `class` is syntactic sugar for the most common way of doing classes in ES3 and ES5. There is no semantic difference between: function Thing () {} Thing.prototype.greet = function () { alert("hello"); }; and class Thing { greet () { alert("hello"); } } They are the same, so it introduces no new traps for library authors.
    - antimagic 12y ago
      About the only thing that might be interesting to see is how constructor parameters are handled. With the prototyping system, I consider it to be a bug to initialize members in the constructor - if you always just call an 'init' method straight after construction (typically chained, much like in Objective C - var thing = new Thing().init(param); ) then protyping is very simple and does nothing surprising. It's only if you really really really want to have RAII that things become complicated...
- rtpg 12y ago
  Just because a tool is in a box doesn't mean its useful. Considering the relative cleanliness, refactorability of code coming from the functional world (see Haskell and the like), it is debatable whether OOP is a "good" style to develop at all! If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles.
  - phpnode 12y ago
    > If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles. Sorry but that's total nonsense. For instance, node.js makes heavy use of classes, as does Backbone, Ember, React, etc
    - phpnode 12y ago
      To whoever downvoted me, am I wrong? Please explain.
      - Demiurge 12y ago
        Most of the time downvoting stands for 'Your comment hurts my feelings.' This comment will be very light gray ;D
  - Demiurge 12y ago
    Just because it's possible to write a program without a tool, doesn't mean it's more productive. Functional programming doesn't even directly oppose OOP, it opposes imperative. It is absolute basics of CS that there is data and logic and many problems are easy to reason about as logic modifying data (state). OOP is a tool that allows to encapsulate some data and logic that go together. Functional programming doesn't allow you much more than that. Just because you may (or may not) end up decomposing a program into the smallest units of logic, doesn't mean you've done something useful, or clean.
    - tel 12y ago
      Without backing a horse exactly: * FP as I understand it doesn't much oppose imperative or even most of OO. It opposes non-composability using discipline from pure/total languages. * Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that (ADTs, existential types, modules, what-have-you do it fine if not far better). The remaining 90% may be a waste or actively harmful. * FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely. This may end up being some kind of full-scale OO, I'm eager to try to find places where it does, but so far it hasn't ever. As a meta note, "my kind of FP" is the Haskell type of purity and other such nonsense.

chriswarbo 12y ago

How exactly can OO be "shoehorned" into a language which is already OO?

CmonDev 12y ago
He meant proper OO as opposed to the shanty prototype one.
- jbergens 12y ago
  The problem is for anyone who sees prototype OO as a better solution. They kind of give their blessings to the other OO, which is a bit sad. (edit: spelling)
  - cgcardona 12y ago
    I see it the other way--prototype OO was given the blessing of the Creators of the language back in the mid 90s when it was created. Though the people who 'get' prototypes swear that they're the greatest paradigm ever you will still get a huge amount of people coming in from other languages which find the prototype chain awkward and prefer to think in complex class hierarchies. These people who choose to create their abstractions out of classes are in no way 'wrong.' To each their own. Adding `class` syntactic sugar is just standardizing on something which many people already do every day.
- chriswarbo 12y ago
  Since you've not defined it, I'll assume "proper OO" is referring to Alan Kay's formulation: http://c2.com/cgi/wiki?HeInventedTheTerm http://c2.com/cgi/wiki?HeInventedTheTerm In that case, his opinion on class vs. prototypes is that it misses the point: http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-October/017019.html http://lists.squeakfoundation.org/pipermail/squeak-dev/1998-... As an aside, prototypes are strictly more powerful than classes, so they're no "shanty": http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/Delegation.html http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De... (esp. section 6)