3 ms·

Whole OOP is "wrong". It was "right" up to about early 90ies, given the average application size and hardware. The moment CPU's started scaling with cores and C

Whole OOP is "wrong". It was "right" up to about early 90ies, given the average application size and hardware. The moment CPU's started scaling with cores and CPU started running hundreds of instructions per memory read, and applications started being bigger than few tens of KB - cornerstones of OOP (dynamic polymorphism, code attached to data, per-object access control) started actively working against developers.

deorder 9y ago
It is not "wrong", but it is being "overused". I had been fixing people their broken OOP code for about 10 years (diamond problem, spaghetti code, too much coupling etc.). People seem to abuse it in every way they can. I personally do not like how code is often not separate from the data as well. That is why i like C. I can have my data structure and just add functions that can operate on those data structures outside of the data structure itself without worrying about coupling code to the data. Extra functions that can operate on the data may as well be inside a dynamically loaded plugin. Not feeling forced to put everything that can operate on a single instance of the data inside the same class. Not feeling forced to create a separate class to add methods that can operate on multiple instances of the data and hardcoding multicore support inside of it. The new C++ (and Nim) have the notion of concepts which can mostly replace the many ways OOP was being abused. It is similar to type classes in Haskell. I advice you to read Alexander Stepanov's books. You can have a data structure in a class, add certain concepts that the data structure supports and then create separate functions which can operate on these concepts outside of the class / object.
- machinedgod 9y ago
  I'm not sure I'd agree with initial statement (and by this I literally mean - "I am not sure", its not a figure of speech). I agree with everything else you said, but the way I see it - when a paradigm cornerstone itself starts getting in the way of code organization, then that's a clear sign that paradigm itself is 'wrong', or more precisely, wrong when applied to this set of problems. Oooooooh, look at that, I understand now what you meant :-D Regarding your second paragraph - this is, looking from efficiency standpoint, the best approach. Additional gain is in access control: it becomes flat (ie. module-controlled), rather than having a class hierarchy in between, and then using messy constructs such as interfaces/mixins to achieve both code and type inheritance. Raise hands if you ever ended up in situation where you have to convert from one type to another, while the actual data they carry are precisely the same. Raise hands if you ever had to pollute an interface or a parent class with extra data, because a subclass somewhere contains exact data needed at the other part of the chain. This is friction - and it works against the developer/team. The larger the software, the worse it gets; it doesn't have to be that way. Anyways, regarding last two points - yes, I'm very familiar with parametric polymorphism (it is a sole reason I use C++ for work, over C), and I have than half a decade of Haskell experience behind me. Trying to shift into Rust lately - its easier to find jobs.

deorder 9y ago

It is not "wrong", but it is being "overused". I had been fixing people their broken OOP code for about 10 years (diamond problem, spaghetti code, too much coupling etc.). People seem to abuse it in every way they can. I personally do not like how code is often not separate from the data as well. That is why i like C. I can have my data structure and just add functions that can operate on those data structures outside of the data structure itself without worrying about coupling code to the data. Extra functions that can operate on the data may as well be inside a dynamically loaded plugin. Not feeling forced to put everything that can operate on a single instance of the data inside the same class. Not feeling forced to create a separate class to add methods that can operate on multiple instances of the data and hardcoding multicore support inside of it. The new C++ (and Nim) have the notion of concepts which can mostly replace the many ways OOP was being abused. It is similar to type classes in Haskell. I advice you to read Alexander Stepanov's books. You can have a data structure in a class, add certain concepts that the data structure supports and then create separate functions which can operate on these concepts outside of the class / object.

machinedgod 9y ago
I'm not sure I'd agree with initial statement (and by this I literally mean - "I am not sure", its not a figure of speech). I agree with everything else you said, but the way I see it - when a paradigm cornerstone itself starts getting in the way of code organization, then that's a clear sign that paradigm itself is 'wrong', or more precisely, wrong when applied to this set of problems. Oooooooh, look at that, I understand now what you meant :-D Regarding your second paragraph - this is, looking from efficiency standpoint, the best approach. Additional gain is in access control: it becomes flat (ie. module-controlled), rather than having a class hierarchy in between, and then using messy constructs such as interfaces/mixins to achieve both code and type inheritance. Raise hands if you ever ended up in situation where you have to convert from one type to another, while the actual data they carry are precisely the same. Raise hands if you ever had to pollute an interface or a parent class with extra data, because a subclass somewhere contains exact data needed at the other part of the chain. This is friction - and it works against the developer/team. The larger the software, the worse it gets; it doesn't have to be that way. Anyways, regarding last two points - yes, I'm very familiar with parametric polymorphism (it is a sole reason I use C++ for work, over C), and I have than half a decade of Haskell experience behind me. Trying to shift into Rust lately - its easier to find jobs.