What’s Wrong with OOP and FP

[Chris]

On Thursday, 14 November 2013 at 10:51:31 UTC, Paulo Pinto wrote:
> On Thursday, 14 November 2013 at 10:01:34 UTC, Jacob Carlborg 
> wrote:
>> On 2013-11-14 10:37, Don wrote:
>>
>>> I just can't escape the feeling that class-based runtime 
>>> polyphorphism
>>> is almost never an ideal solution, and that most of the 
>>> benefits and
>>> success of OOP languages comes from things other than OOP 
>>> itself. And I
>>> think it's because OOP is philosophically nonsense -- in the 
>>> real world,
>>> similarities between things are everywhere, but almost none 
>>> of them are
>>> is-A relationships.
>>
>> I think the most useful parts of OOP is encapsulation and have 
>> the data and methods in the same place.
>
> Actually no different than using ADT (Abstract Data Types) 
> popularized by modular languages like Modula-2, with the added 
> benefit of type extension and polymorphism.
>
> Just because OOP has objects in the name, it doesn't need to be 
> real objects, but concepts actually.
>
> The main problem was that OOP productivity was oversold hype, 
> in the same vein as web 2.0, cloud computing, agile and 
> whatever might come next. People need to sell books and 
> certifications.
>
> And that the early OO design approaches focused too much in 
> implementation inheritance instead of interfaces and delegation.
>
> --
> Paulo

I agree that encapsulation and having logic and data in the same 
place is a nice feature of OOP. Also, OOP is a tool that helps to 
create an architecture or an infrastructure like 
Data-Controller-Components, which is quite useful. However, it 
happens again and again that a program gets tangled with 
inter-dependencies. No matter how careful the planning is, as in 
"this component (class) doesn't need to know anything about 
XYZ.". Sooner or later there will be a case where this is no 
longer doable. There are valid solutions like proxies etc. but 
still it somehow doesn't feel right.

At the moment I'm using a mixture where I use structs and ranges 
for tasks that can be performed independently, like for example a 
filter that removes comments from a text file. There is no need 
to put that behavior into a class. In other words it's a "blind" 
component, that doesn't need to see anything else but the 
incoming text. Being "blind", it can be reused out of the box. 
OOP is still useful for having a central data pool (resources) 
that can be accessed from anywhere by any component - if needs be 
- delegating tasks etc.

This said, I sometimes have to implement an initially "blind" 
component (struct, range) as an internal class to get the 
references that exist within the class that uses it. This, or 
pass the data to the component (bah!). Either way, it creates 
dependencies. I tend to blame myself (bad planning, insufficient 
understanding of the matter), but I wonder whether it is possible 
at all to have a reasonably complex program without 
inter-dependencies of some sort, FP or OOP. Is there, in reality, 
only a certain amount of really independent components, whereas 
the bulk of the program is invariably inter-dependent to varying 
degrees?