5 ms·

JS isn't OOP and it doesn't need to be. Please read this instead: https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 https://medium

JS isn't OOP and it doesn't need to be. Please read this instead: https://medium.com/javascript-scene/the-two-pillars-of-javascript-ee6f3281e7f3 https://medium.com/javascript-scene/the-two-pillars-of-javas...

erikpukinskis 11y ago
If you're trying to say that OOP isn't the central organizing principle of JavaScript, then I 100% agree with you. Lambdas and closures are awesome. However, JavaScript does have the "new" keyword, and I would argue that constructors are quite central to JavaScript and good idiomatic JavaScript uses them. And it exposes YourConstructor.prototype, which I would argue is also useful. So I guess maybe you're saying something about the term OOP that I don't understand. Maybe OOP means "everything is an object" to you? Or it means multiple inheritance? I guess I don't understand the distinction you're trying to draw when you say "not OOP".
- EugeneOZ 11y ago
  Article of the same author, on the related subject: https://medium.com/javascript-scene/how-to-fix-the-es6-class-keyword-2d42bb3f4caf https://medium.com/javascript-scene/how-to-fix-the-es6-class...
- zachrose 11y ago
  There's a whole depth of abstractions that people imply when they talk about OOP in JavaScript. In my mind they go something like this. 1) Using object literals for values. 2) Using object literals with functions. 3) Using object literals with functions and calling them in contexts (`this`, `bind`, `apply`). 4) Using the `new` keyword. 5) Designing objects with inheritance hierarchies or prototype chains. 6) Designing mutable and stateful objects with indefinite life spans. I don't understand the arguments that classical-ish inheritance in JS is bad while prototypical inheritance is somehow better. I've worked in codebases that liberally extend objects into different types of objects with long prototype chains, and IMHO they suffered from the same problems that people complain about in classical inheritance: tight coupling, premature/wrong abstractions, gradual violations of open/closed, etc. Personally, I go through 1-4 liberally and 5 and 6 conservatively. IMHO, complaints about inheritance mechanisms seem to have something in common with the people who talk about the special needs of "large-scale applications". Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are? NB: It's entirely possible that I haven't run into the kind of complex requirements where liberal inheritance is a good fit. I'd be interested in hearing stories about when that worked out well.
  - grayrest 11y ago
    > Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are? The easy answer to this is that successful apps have a tendency to grow larger than expected and splitting them up requires care and lots of work. Class based inheritance provides a familiar way to split up the state space via encapsulation. It provides some boundaries instead of none and theoretically allows you to separate out your concerns and not have to think about the system-wide implications when writing code in your class. I'm in the functional camp and think classes aren't a great way to build software but I support the addition of `class` to ES6 since it shifts the ecosystem from a hundred slightly-incompatible versions to a single one. The mystery to me is why the people who advocate for JS classes are still writing JS rather than writing Typescript or Dart to further constrain their state space with a type system.
    - deleted 11y ago
      [deleted]
hughw 11y ago
I agree. JS is beautiful in the parts where it encourages functional, not object, programming. That link puts it nicely: "You're working in the phony version of JavaScript that only exists to dress the language up like Java." In the Mozilla article, I can hardly believe I'm reading discredited perennials like "OOP promotes greater flexibility and maintainability in programming ... Because OOP strongly emphasizes modularity, object-oriented code is simpler to develop and easier to understand later on." That was the promise, in 1985. The reality is, OOP has created a snarl of programs where mutable state is the defining characteristic, justified by a consulting industry that is more promotion than real, grounded theory. They live on.
- uname-s 11y ago
  The promise in 1985 was Smalltalk; the reality was Java. Your argument rests on an industry bait-and-switch.
  - Sanddancer 11y ago
    No, the reality is not just Java. It's Ruby, C#, Objective-C, Python, etc. Other languages have made object systems that aren't as ugly as Java's
- oldmanjay 11y ago
  You're vastly overstating what you consider the "reality" of object oriented programming. Systems designed to be OO from the beginning are clearly massively successful at producing incredibly complicated software. The paradigm has not been discredited despite your assertion or your personal idea of beauty.
  - Jweb_Guru 11y ago
    So have procedural and functional systems. What is your point? There's no practical evidence that those projects were successful because of OOP, and there's no theoretical basis for believing it either. In the meantime, object-oriented programming languages require one to make some pretty uncomfortable tradeoffs (for example, it makes type inference undecidable and practically requires virtual dispatch), so even if they are just a noop, we should still avoid it whenever possible.
uname-s 11y ago
Smalltalk has always had lambdas in the form of block objects. It uses them everywhere and for everything, even implementing control flow constructs like if/then/else and while. It also uses them to implement Lisp-style higher-order iterators like mapcar (collect:), reduce (inject:into:), and remove-if-not (select:), which though possible in JavaScript (see Prototype.js), is generally uncommon because JavaScript's lambda syntax has historically been the most verbose of any dynamic language. Anyone who claims lambdas are somehow new to or incompatible with OOP clearly doesn't understand OOP, since lambdas have been an integral part of the most influential pure OO language (Smalltalk) for 40 years.
- jwdunne 11y ago
  I've also seen very simple object systems built purely using closures in Lisp. I can't remember where I've seen it, but it usually involves the bank account example. Since no other Lisp features were involved,until you start glossing over with macros, this could be replicated in JS. It'd look strange but it's certainly possible, e.g: var savings = account(200); savings('deposit')(200); console.log(savings('amount')); // should print 400 savings('withdraw')(200); console.log(savings('amount')); // should print 200 If you can build an OO system in terms of lambdas and closures, does it mean the two are incompatible? I don't think so.
  - spdegabrielle 11y ago
    I think it's this one http://okmij.org/ftp/Scheme/oop-in-fp.txt http://okmij.org/ftp/Scheme/oop-in-fp.txt
  - spdegabrielle 11y ago
    Better link http://okmij.org/ftp/Scheme/#pure-oo http://okmij.org/ftp/Scheme/#pure-oo
- lispm 11y ago
  Though it does not have lexical scope / closures for 40 years.
Kiro 11y ago
This article needs some code examples. Read it through and still not sure how to do this.

erikpukinskis 11y ago

If you're trying to say that OOP isn't the central organizing principle of JavaScript, then I 100% agree with you. Lambdas and closures are awesome. However, JavaScript does have the "new" keyword, and I would argue that constructors are quite central to JavaScript and good idiomatic JavaScript uses them. And it exposes YourConstructor.prototype, which I would argue is also useful. So I guess maybe you're saying something about the term OOP that I don't understand. Maybe OOP means "everything is an object" to you? Or it means multiple inheritance? I guess I don't understand the distinction you're trying to draw when you say "not OOP".

EugeneOZ 11y ago
Article of the same author, on the related subject: https://medium.com/javascript-scene/how-to-fix-the-es6-class-keyword-2d42bb3f4caf https://medium.com/javascript-scene/how-to-fix-the-es6-class...
zachrose 11y ago
There's a whole depth of abstractions that people imply when they talk about OOP in JavaScript. In my mind they go something like this. 1) Using object literals for values. 2) Using object literals with functions. 3) Using object literals with functions and calling them in contexts (`this`, `bind`, `apply`). 4) Using the `new` keyword. 5) Designing objects with inheritance hierarchies or prototype chains. 6) Designing mutable and stateful objects with indefinite life spans. I don't understand the arguments that classical-ish inheritance in JS is bad while prototypical inheritance is somehow better. I've worked in codebases that liberally extend objects into different types of objects with long prototype chains, and IMHO they suffered from the same problems that people complain about in classical inheritance: tight coupling, premature/wrong abstractions, gradual violations of open/closed, etc. Personally, I go through 1-4 liberally and 5 and 6 conservatively. IMHO, complaints about inheritance mechanisms seem to have something in common with the people who talk about the special needs of "large-scale applications". Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are? NB: It's entirely possible that I haven't run into the kind of complex requirements where liberal inheritance is a good fit. I'd be interested in hearing stories about when that worked out well.
- grayrest 11y ago
  > Why not just make smaller apps, or make smaller things that compose with less knowledge of where they are? The easy answer to this is that successful apps have a tendency to grow larger than expected and splitting them up requires care and lots of work. Class based inheritance provides a familiar way to split up the state space via encapsulation. It provides some boundaries instead of none and theoretically allows you to separate out your concerns and not have to think about the system-wide implications when writing code in your class. I'm in the functional camp and think classes aren't a great way to build software but I support the addition of `class` to ES6 since it shifts the ecosystem from a hundred slightly-incompatible versions to a single one. The mystery to me is why the people who advocate for JS classes are still writing JS rather than writing Typescript or Dart to further constrain their state space with a type system.
  - deleted 11y ago
    [deleted]

hughw 11y ago

I agree. JS is beautiful in the parts where it encourages functional, not object, programming. That link puts it nicely: "You're working in the phony version of JavaScript that only exists to dress the language up like Java." In the Mozilla article, I can hardly believe I'm reading discredited perennials like "OOP promotes greater flexibility and maintainability in programming ... Because OOP strongly emphasizes modularity, object-oriented code is simpler to develop and easier to understand later on." That was the promise, in 1985. The reality is, OOP has created a snarl of programs where mutable state is the defining characteristic, justified by a consulting industry that is more promotion than real, grounded theory. They live on.

uname-s 11y ago
The promise in 1985 was Smalltalk; the reality was Java. Your argument rests on an industry bait-and-switch.
- Sanddancer 11y ago
  No, the reality is not just Java. It's Ruby, C#, Objective-C, Python, etc. Other languages have made object systems that aren't as ugly as Java's
oldmanjay 11y ago
You're vastly overstating what you consider the "reality" of object oriented programming. Systems designed to be OO from the beginning are clearly massively successful at producing incredibly complicated software. The paradigm has not been discredited despite your assertion or your personal idea of beauty.
- Jweb_Guru 11y ago
  So have procedural and functional systems. What is your point? There's no practical evidence that those projects were successful because of OOP, and there's no theoretical basis for believing it either. In the meantime, object-oriented programming languages require one to make some pretty uncomfortable tradeoffs (for example, it makes type inference undecidable and practically requires virtual dispatch), so even if they are just a noop, we should still avoid it whenever possible.

uname-s 11y ago

Smalltalk has always had lambdas in the form of block objects. It uses them everywhere and for everything, even implementing control flow constructs like if/then/else and while. It also uses them to implement Lisp-style higher-order iterators like mapcar (collect:), reduce (inject:into:), and remove-if-not (select:), which though possible in JavaScript (see Prototype.js), is generally uncommon because JavaScript's lambda syntax has historically been the most verbose of any dynamic language. Anyone who claims lambdas are somehow new to or incompatible with OOP clearly doesn't understand OOP, since lambdas have been an integral part of the most influential pure OO language (Smalltalk) for 40 years.

jwdunne 11y ago
I've also seen very simple object systems built purely using closures in Lisp. I can't remember where I've seen it, but it usually involves the bank account example. Since no other Lisp features were involved,until you start glossing over with macros, this could be replicated in JS. It'd look strange but it's certainly possible, e.g: var savings = account(200); savings('deposit')(200); console.log(savings('amount')); // should print 400 savings('withdraw')(200); console.log(savings('amount')); // should print 200 If you can build an OO system in terms of lambdas and closures, does it mean the two are incompatible? I don't think so.
- spdegabrielle 11y ago
  I think it's this one http://okmij.org/ftp/Scheme/oop-in-fp.txt http://okmij.org/ftp/Scheme/oop-in-fp.txt
- spdegabrielle 11y ago
  Better link http://okmij.org/ftp/Scheme/#pure-oo http://okmij.org/ftp/Scheme/#pure-oo
lispm 11y ago
Though it does not have lexical scope / closures for 40 years.

Kiro 11y ago

This article needs some code examples. Read it through and still not sure how to do this.