Nobody said they were design as FP. I say that JS was function-first as that was the main construct. Sure, you can say functions as first-class objects, which is truly a painful twist of concepts if that's what you want to see. I know people really wanted to force JS constructs into object-friendly usage patters (prototype, anyone) but it's a stretch to say there were Java "strong" influences back in the day. Objects are Java's code and there were no such things then (scoped variables protected/private/etc and funny inheritance was actually a composition of functions).
Thanks for sharing that article, though from my perspective it basically enforces my point. Inheritance defines relationships between objects (which prevents code reuse outside of a given project) and moreover, the author makes a great point that there's a right way to use inheritance. But that definition is his own convention outside if the definition of inheritance itself. Almost every developer of a given seniority has a theory and practice about the "right" way to use, despite the shortcomings on reliability and maintainability - some of which comes exactly from the need to enforce a set of arbitrary conventions about the right way to tackle inheritance. You need but a slip of code review to go down a slippery slope towards messiness (not to mention once you setup a hierarchy, nobody will ever be able to change it - there's a basic tenet to uphold agility in development practices that says "if you're face with two solutions to a problem, go with the one that's easier to change later on").
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nobody said they were design as FP. I say that JS was function-first as that was the main construct. Sure, you can say functions as first-class objects, which is truly a painful twist of concepts if that's what you want to see. I know people really wanted to force JS constructs into object-friendly usage patters (prototype, anyone) but it's a stretch to say there were Java "strong" influences back in the day. Objects are Java's code and there were no such things then (scoped variables protected/private/etc and funny inheritance was actually a composition of functions).
Thanks for sharing that article, though from my perspective it basically enforces my point. Inheritance defines relationships between objects (which prevents code reuse outside of a given project) and moreover, the author makes a great point that there's a right way to use inheritance. But that definition is his own convention outside if the definition of inheritance itself. Almost every developer of a given seniority has a theory and practice about the "right" way to use, despite the shortcomings on reliability and maintainability - some of which comes exactly from the need to enforce a set of arbitrary conventions about the right way to tackle inheritance. You need but a slip of code review to go down a slippery slope towards messiness (not to mention once you setup a hierarchy, nobody will ever be able to change it - there's a basic tenet to uphold agility in development practices that says "if you're face with two solutions to a problem, go with the one that's easier to change later on").