[mmahemoff]

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]

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

[phpnode]

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]

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]

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

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]

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.

[klibertp]

> it is debatable whether OOP is a "good" style to develop at all!

You've drank way too much Kool-Aid here.

First of all: there are many different styles of OO, some more cumbersome than others, some so far removed from "classic OOP principles" that it takes effort to see how are they related. It's utterly useless to talk about "OOP style" as if it was a well defined, canonical set of rules - because it's not.

Second: there's nothing that makes OOP and FP be in opposition to each other. You should be aware - and if you're not, you should feel ashamed - that closures, one of basic FP tools, were supported in Smalltalk 20 years before Haskell.

Third: just as with OOP, things coming from FP are not uniformly "better" in any sense. Just as with every other paradigm, FP languages frequently have features needed only because they are FP. It makes very little sense to adopt those. Many really interesting features meant for solving real problems (and not for solving problems with a paradigm) are steadily coming to non-FP languages anyway.

> If I look at most of the libraries commonly used in production JS, pretty much none of them apply classic OOP principles.

Once again: either you have no idea what OOP is or you have no idea how JS libraries look like. For every http://ramdajs.com/docs/ you get hundreds libraries which implement their own kind of OO, starting from jQuery and Backbone.

[tel]

To be clear, "closures" are merely an implementation of lamdbas which were invented in the 30s. I wouldn't mention it except you're trying to shame someone for not "knowing" that Smalltalk beat Haskell to the punch despite both of them borrowing from a much richer history.

To drive the point home, you can implement lamdbas (and thus Haskell) without using closures. In fact, this is easy in a pure language since bindings are static. One way to do this is to compile the language into a basis of combinators like SKI. These no longer have any notion of binding so we don't need closures. Likewise, you could compile it into a categorical semantics and maybe implement this on FPGAs—again, no need for closures.

Lamdbas are merely a syntax and theory. Closures are merely one interpretation given a Von Neumann machine.

[klibertp]

I happen to know all this; what I wanted to stress is not the nature of closures, which is exactly as you say, but that they were used since long ago in a "purely object oriented" languages, which - AFAIK - are not meant to implement lambda calculus in any shape or form.

GP wrote that - in short "everything in OOP is bad, let's use FP only". I responded with an argument that, in fact, certain OOP languages used FP features long before Haskell (because that's the example GP provided). I don't think the fact that closures are just one interpretation of an abstract concept of "lambda" is very relevant to this argument.

And about "shaming" people: I meant to gently point out that advocates for some cause should at the very least get their facts straight. Bashing some concept without knowing it well is the thing I objected to, a "not knowing it well" part by itself wouldn't be anything one should feel ashamed of.

[phpnode]

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

To whoever downvoted me, am I wrong? Please explain.

[Demiurge]

Most of the time downvoting stands for 'Your comment hurts my feelings.'

This comment will be very light gray ;D

[Demiurge]

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]

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.

[Demiurge]

>FP as I understand it doesn't much oppose imperative or even most of OO

I think this is definitely true, if you take 'oppose' as 'incompatible'. If we look the design concept and plot them, there will be axes, and I think this is what we'll see.

>* Even if you want to encapsulate data and logic together like you suggest, you only need to buy 10% of OO to get that

That's also true, but it's not an argument against the seed of usefulness of the 10%. We have kitchen sinks because people pick and choose features at will.

>* FP, as I practice it, means using the simplest possible thing in a world where simple things compose nicely.

Same here, and everyone should practice this when they look at any function, or object method, trying to make it as atomic as possible.

> This may end up being some kind of full-scale OO

I don't think it's any more useful shoehorning a program into "everything objects" more than "everything is functions".

My point was to say that the core goal of OOP is a great one, it simply codifies something that people have done in C when they put structs and procedures in the same header file. Let's not throw the baby out with the bath water.

[chriswarbo]

> Functional programming doesn't even directly oppose OOP, it opposes imperative.

Just to be pedantic, OOP is (a kind of) imperative programming: goals are achieved by performing a sequence of actions in the world. In functional programming, goals are achieved by defining values; the evaluation order is an implementation detail.

It could be argued that OOP is "more imperative" than, for example, procedural programming, since in an OOP approach, "the outside world" includes everything other than the current object (due to dynamic dispatch).

[CmonDev]

"pretty much none of them apply classic OOP principles"

Most of them are forced to be using some poorman's OOP. See Angular 1.x vs Angular 2.0. OOP is always around the corner, even if it is standard DOM.

[chriswarbo]

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

[CmonDev]

He meant proper OO as opposed to the shanty prototype one.

[chriswarbo]

Since you've not defined it, I'll assume "proper OO" is referring to Alan Kay's formulation: 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-...

As an aside, prototypes are strictly more powerful than classes, so they're no "shanty": http://web.media.mit.edu/~lieber/Lieberary/OOP/Delegation/De... (esp. section 6)

[jbergens]

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]

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.