| OOP isn't perfect, but I don't think this post addresses any actual problems. > Since functions and data structures are completely different types of animal it is fundamentally incorrect to lock them up in the same cage. That's one way of looking at it, but definitely not the only right one. OOP implies that there are objects, just as in real world, that can act by themselves, on themselves (or, in rare cases, on others). I can't really see how `user.addPost(post)` or `file.append(str)` is inherently wrong. By the way, what would the "FP way" of expressing this be? > Everything has to be an object Uh, I didn't get what the criticism was. How is Erlang way of defining time any better than https://docs.oracle.com/javase/8/docs/api/java/time/package-... ? > In an OOPL data type definitions are spread out all over the place Because data type definitions are secondary to class definitions. It's how the paradigm works. You don't think about data types, you think about how classes interact with each other. > Suppose now I want to create some "time" object, where does this belong and in which object Again, look at https://docs.oracle.com/javase/8/docs/api/java/time/package-.... This class only extends the base Object class. > OOPLs say "hide the state from the programmer". The states is hidden and visible only through access functions. That's not what OOPLs say at all. The state of an object is "hidden" from other objects, but programmer should have no problem accessing it (hopefully their IDE will help). I'd also like to see how the author tackles UI programming in a stateless paradigm, let alone any performance-intensive tasks (for example, rendering in a real-time game). |