1) Object Oriented Programming is overrated and often not the most fitting choice.
2) Code does not mater, solving problem does.
3) We all loves our tools (ide, linter ...) but the fact that we search new one or way to make them better is a proof that in the end, they sucks one way or another.
4) Git is not that of a great tool. We use it more because it's the biggest on doing what it does.
5) JavaScript is ultimately misunderstood: it's not an OOP language, the core of it's object's model is prototype and lot of people try to make it otherwise.
6) I am being too much?
Anyway, it's not written in stone and only represent feelings of my present self (will be happy to discuss any point and even change my mind).
1) Depends a lot of what your code aims for. It is an MVP that will be erased after the startup gets funding or closes for the lack of funding? yeah, OOP or not doesn't matter.
2) Solving problems with the most optimal solution possible at the minimum cost possible. Taking into account that more than 95% (or more) of the cost of software is on the maintenance part (add this or that, change X and fix Y) and taking into account that OOP is the easiest way for most humans to work, this also clashes with point 1.
3) Is more a sign of how little we know about the art of solving complex abstract problems.
4) totally agree. And I would add that most of the problems it solves were introduced thanks to it.
5) what is an OOP language? a language that uses objects. What is an object? the representation using code of an abstract entity from a problem we are solving. Therefore for me, there is almost no language that isn't OOP. Most people call a language is OOP because it uses Classes but I find that way to simplistic.
6) Oh, no! please continue.
Anyway, it's not written in stone and only represent feelings of my present self (will be happy to discuss any point and even change my mind).
1) I totally agree. What I was trying to do (and it's not only OPP in fact, but a lot of stuff) is that we should use the right tool for the right job and not the shiniest tool because everyone love it.
2) I was trying to express that the beauty of your code and the absolute awesomeness that we can find in it is not as relevant that the problem you seek to solve.
3) That's an interesting thinking, I'll dwell in it someday.
4) Some other tools (like pijul) deserve a little lookup to broad a little the landscape of vcs.
5) I tend to believe that OOP is a paradigm revolving around object. It's not that objects exist in it but more than everything is done to promote them. For instance Java urge you to manage things through object. Object become de-facto the "orientation" taken by the language. Other paradigm, like functional or ECS, or not focus on object as a "core" concept of programing. As such, object are just a convenient way to pack data altogether in those paradigm rather by being the central gear of it. At least it's the way I see it.
5) JavaScript is an OOP language. It's object system comes from Self. Classes and objects aren't the point of object oriented languages. The key idea (at least according to Alan Kay, who we can probably take as an authority on the subject) was that you could summon mathematical structures into existence with almost nothing if you can orchestrate actors, each implementing their own language. Classes and methods on them were the particular implementation they arrived at for Smalltalk as an implementation of this.
It seems that I effectively used the wrong words here. JavaScript indeed use object. The object pattern is prototyping. But I still think that JavaScript is not "in essense" an OOP Language but a language proposing it: the language does not favorise the use of object and "this" does not refer to an object the same way that any other language (but the prototype it's currently called in) and does not make the thing easy.
We can object to that that functions are kind of "object" themselves.
I realize though that my knowledge on this particular subject is not that strong, so is my position on it. I'll check the work of Alan Kay that you mention earlier. Thanks a lot.
Clarification of my mention of Alan Kay: he invented object oriented programming along with the rest of the Smalltalk group at Xerox PARC.
this in JavaScript behaves the way it does in any other prototype based language (as I mentioned before, see Self). Self and its lineage were part of an attempt to make an even purer object oriented language that Smalltalk. In Smalltalk you had objects...but you also had classes, which were somehow different. They were objects, but were part of a totally different inheritance hierarchy. Self asked if the classes were really necessary, or if they were baggage carried over from earlier programming experience. The answer at this point is quite clear. Classes are unnecessary, but it's really hard to get people past the baggage and comfortable with conjuring objects directly.
For completeness, there's a third branch of object oriented programming represented by Common Lisp's CLOS based on structs and generic functions with multiple dispatch. It turns out to be an even more powerful approach, and this isn't a thing in that system at all. That branch, if you take it seriously and work out the mathematics, leads to Stepanov's work on generic programming and the C++ Standard Template Library.
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.
1) Object Oriented Programming is overrated and often not the most fitting choice.
2) Code does not mater, solving problem does.
3) We all loves our tools (ide, linter ...) but the fact that we search new one or way to make them better is a proof that in the end, they sucks one way or another.
4) Git is not that of a great tool. We use it more because it's the biggest on doing what it does.
5) JavaScript is ultimately misunderstood: it's not an OOP language, the core of it's object's model is prototype and lot of people try to make it otherwise.
6) I am being too much?
Anyway, it's not written in stone and only represent feelings of my present self (will be happy to discuss any point and even change my mind).
1) Depends a lot of what your code aims for. It is an MVP that will be erased after the startup gets funding or closes for the lack of funding? yeah, OOP or not doesn't matter.
2) Solving problems with the most optimal solution possible at the minimum cost possible. Taking into account that more than 95% (or more) of the cost of software is on the maintenance part (add this or that, change X and fix Y) and taking into account that OOP is the easiest way for most humans to work, this also clashes with point 1.
3) Is more a sign of how little we know about the art of solving complex abstract problems.
4) totally agree. And I would add that most of the problems it solves were introduced thanks to it.
5) what is an OOP language? a language that uses objects. What is an object? the representation using code of an abstract entity from a problem we are solving. Therefore for me, there is almost no language that isn't OOP. Most people call a language is OOP because it uses Classes but I find that way to simplistic.
6) Oh, no! please continue.
Words to live by.
1) I totally agree. What I was trying to do (and it's not only OPP in fact, but a lot of stuff) is that we should use the right tool for the right job and not the shiniest tool because everyone love it.
2) I was trying to express that the beauty of your code and the absolute awesomeness that we can find in it is not as relevant that the problem you seek to solve.
3) That's an interesting thinking, I'll dwell in it someday.
4) Some other tools (like pijul) deserve a little lookup to broad a little the landscape of vcs.
5) I tend to believe that OOP is a paradigm revolving around object. It's not that objects exist in it but more than everything is done to promote them. For instance Java urge you to manage things through object. Object become de-facto the "orientation" taken by the language. Other paradigm, like functional or ECS, or not focus on object as a "core" concept of programing. As such, object are just a convenient way to pack data altogether in those paradigm rather by being the central gear of it. At least it's the way I see it.
But my vision may be biased or even uterly wrong.
6) Ok...
7) Top 10 are overrated, top 7 is the way to go.
5) JavaScript is an OOP language. It's object system comes from Self. Classes and objects aren't the point of object oriented languages. The key idea (at least according to Alan Kay, who we can probably take as an authority on the subject) was that you could summon mathematical structures into existence with almost nothing if you can orchestrate actors, each implementing their own language. Classes and methods on them were the particular implementation they arrived at for Smalltalk as an implementation of this.
It seems that I effectively used the wrong words here. JavaScript indeed use object. The object pattern is prototyping. But I still think that JavaScript is not "in essense" an OOP Language but a language proposing it: the language does not favorise the use of object and "this" does not refer to an object the same way that any other language (but the prototype it's currently called in) and does not make the thing easy.
We can object to that that functions are kind of "object" themselves.
I realize though that my knowledge on this particular subject is not that strong, so is my position on it. I'll check the work of Alan Kay that you mention earlier. Thanks a lot.
Clarification of my mention of Alan Kay: he invented object oriented programming along with the rest of the Smalltalk group at Xerox PARC.
thisin JavaScript behaves the way it does in any other prototype based language (as I mentioned before, see Self). Self and its lineage were part of an attempt to make an even purer object oriented language that Smalltalk. In Smalltalk you had objects...but you also had classes, which were somehow different. They were objects, but were part of a totally different inheritance hierarchy. Self asked if the classes were really necessary, or if they were baggage carried over from earlier programming experience. The answer at this point is quite clear. Classes are unnecessary, but it's really hard to get people past the baggage and comfortable with conjuring objects directly.For completeness, there's a third branch of object oriented programming represented by Common Lisp's CLOS based on structs and generic functions with multiple dispatch. It turns out to be an even more powerful approach, and
thisisn't a thing in that system at all. That branch, if you take it seriously and work out the mathematics, leads to Stepanov's work on generic programming and the C++ Standard Template Library.