As with anything, "{insert-name-here} sucks" can be applied in plenty of scenarios. I consider myself competent in plenty of languages, including C# and Java. Recounting my experience with OOP languages, relative to the objections listed:
Regarding data objects to functionality: couldn't agree more, and that's why my data access libraries never contain anything of a functional nature within them. It's simply good practice, and makes for more maintainable architectures. Nothing about OOP prevents me from accomplishing this.
I've dealt with Date and Time objects plenty, and it turns out it's really no big deal. If you care about those things in terms of allocation to the heap and/or stack, there may be a point of consideration, but mostly it's just a matter of syntactical preference. It matters very little to any applications that I've participated in producing and maintaining.
Data-type definitions: the specific comment in the article refers to a location, as in a single file to locate data definitions. Again, this goes to code organization. Separation of concerns is good practice in many disciplines, and this is no different. If a person is sloppy with their code, it doesn't matter what type of language they use.
Private state: I'll refute the suggestion in the article that "OOP says to hide state." That's way too broad a brush stroke. The concept is encapsulation, and best practice says that the scope of state within an object refers only to itself. The article refers to system state, which is well beyond the scope boundary of a single object in OOP.
Again, these are all just tools to get a job done. How one uses the tool is the most important consideration.
Regarding data objects to functionality: couldn't agree more, and that's why my data access libraries never contain anything of a functional nature within them. It's simply good practice, and makes for more maintainable architectures. Nothing about OOP prevents me from accomplishing this.
I've dealt with Date and Time objects plenty, and it turns out it's really no big deal. If you care about those things in terms of allocation to the heap and/or stack, there may be a point of consideration, but mostly it's just a matter of syntactical preference. It matters very little to any applications that I've participated in producing and maintaining.
Data-type definitions: the specific comment in the article refers to a location, as in a single file to locate data definitions. Again, this goes to code organization. Separation of concerns is good practice in many disciplines, and this is no different. If a person is sloppy with their code, it doesn't matter what type of language they use.
Private state: I'll refute the suggestion in the article that "OOP says to hide state." That's way too broad a brush stroke. The concept is encapsulation, and best practice says that the scope of state within an object refers only to itself. The article refers to system state, which is well beyond the scope boundary of a single object in OOP.
Again, these are all just tools to get a job done. How one uses the tool is the most important consideration.