3 ms·

Perhaps the author ought to spend some time reading a book like JavaScript Allongé and learn how Functional Programming in JavaScript is done ;-) https://leanp

Perhaps the author ought to spend some time reading a book like JavaScript Allongé and learn how Functional Programming in JavaScript is done ;-) https://leanpub.com/javascriptallongesix/read https://leanpub.com/javascriptallongesix/read

lostcolony 11y ago
Sarcasm aside, I know raganwald (you?) can approach things functionally. :P My comment isn't to imply he can't (nor that I'm particularly good at it), nor to imply anything about his choices when writing code (as I said, he correctly notes that this is an issue when trying to write class-centric OOP in Javascript; this says nothing about his views on whether class-centric OOP in Javascript is a good idea or not). And, certainly, come ES6, mixins get some language help with Object.assign. My point is simply that if in ES5 you have to fight this much with the language to try and shoehorn it into a particular paradigm, maybe you've picked the wrong paradigm for that language. And the fact so many people try, and so many authors have written ways to try and shoehorn that paradigm into the language (as it stands at ES5), tells me that it -really- is probably not the best choice. And the insistence in doing so seems like a misplaced "make it behave like Java" that brought to mind that URL I linked. That's not to say thinking about it isn't itself a worthwhile endeavor. That's not to say that seeing that it can be done in Javascript isn't a point in Javascript's favor. That's not to say there isn't a demand by people for the language to behave this way, and that others understandably try to meet that demand. But it is to say that it's solving a problem that is self-inflicted, by dint of choosing to use classical inheritance in a language that was designed to support prototypal inheritance.
- braythwayt 11y ago
  It’s a question of taste. To me, hierarchies of classes are not very JavaScript, but mixins written as decorators are very JavaScript. To me, overriding functions and calling `super` is not very JavaScript, but writing function combinators like `before` and `after` is very JavaScript. To me, JavaScript is about composing bunches of single-responsibility things, not writing big things. So to my taste, mixins and decorators are in a deep way, strongly related to functional programming, while the sugar for stuff like classes and special syntax for getters and setters is not.
  - lostcolony 11y ago
    That's fair, and I'd agree that mixins and decorators can be more closely related to FP than I initially took them for. I just tend to keep my objects as, basically, structs, and functions bound outside of them, rather than treating them as objects, so questions of composability in such a manner don't come up. Rather than have to write a lot of abstracted out code to support mixins, and then know what assumptions a mixin has about the object choosing to mix it in, there are instead just functions; you want them then reference them, and what they take is spelled out (somewhat more) clearly in the function header, if you can pass in the right arguments, the function can be reused. If you want a set of functions that all work together, then composition, sharing state, etc, falls on you, rather than being implicit in assumptions the mixin and mixing class may make about each other. As you say, a question of taste (especially as to what steps you take to avoid those assumptions). But that said, I've done similar things in merging two objects prior to serializing them out across a REST endpoint. So there it was less a design consideration of composable function containers, and more one of data transformation (not that they're separate beasts; functions as data and all that), but at the same time a lot of the complexities were avoided.

lostcolony 11y ago

Sarcasm aside, I know raganwald (you?) can approach things functionally. :P My comment isn't to imply he can't (nor that I'm particularly good at it), nor to imply anything about his choices when writing code (as I said, he correctly notes that this is an issue when trying to write class-centric OOP in Javascript; this says nothing about his views on whether class-centric OOP in Javascript is a good idea or not). And, certainly, come ES6, mixins get some language help with Object.assign. My point is simply that if in ES5 you have to fight this much with the language to try and shoehorn it into a particular paradigm, maybe you've picked the wrong paradigm for that language. And the fact so many people try, and so many authors have written ways to try and shoehorn that paradigm into the language (as it stands at ES5), tells me that it -really- is probably not the best choice. And the insistence in doing so seems like a misplaced "make it behave like Java" that brought to mind that URL I linked. That's not to say thinking about it isn't itself a worthwhile endeavor. That's not to say that seeing that it can be done in Javascript isn't a point in Javascript's favor. That's not to say there isn't a demand by people for the language to behave this way, and that others understandably try to meet that demand. But it is to say that it's solving a problem that is self-inflicted, by dint of choosing to use classical inheritance in a language that was designed to support prototypal inheritance.

braythwayt 11y ago
It’s a question of taste. To me, hierarchies of classes are not very JavaScript, but mixins written as decorators are very JavaScript. To me, overriding functions and calling `super` is not very JavaScript, but writing function combinators like `before` and `after` is very JavaScript. To me, JavaScript is about composing bunches of single-responsibility things, not writing big things. So to my taste, mixins and decorators are in a deep way, strongly related to functional programming, while the sugar for stuff like classes and special syntax for getters and setters is not.
- lostcolony 11y ago
  That's fair, and I'd agree that mixins and decorators can be more closely related to FP than I initially took them for. I just tend to keep my objects as, basically, structs, and functions bound outside of them, rather than treating them as objects, so questions of composability in such a manner don't come up. Rather than have to write a lot of abstracted out code to support mixins, and then know what assumptions a mixin has about the object choosing to mix it in, there are instead just functions; you want them then reference them, and what they take is spelled out (somewhat more) clearly in the function header, if you can pass in the right arguments, the function can be reused. If you want a set of functions that all work together, then composition, sharing state, etc, falls on you, rather than being implicit in assumptions the mixin and mixing class may make about each other. As you say, a question of taste (especially as to what steps you take to avoid those assumptions). But that said, I've done similar things in merging two objects prior to serializing them out across a REST endpoint. So there it was less a design consideration of composable function containers, and more one of data transformation (not that they're separate beasts; functions as data and all that), but at the same time a lot of the complexities were avoided.