in reply to Re^3: I dislike object-oriented programming in general
in thread I dislike object-oriented programming in general
You missed a word.
It is the hype that that is annoying and counter productive. Not the technologies, which are generally perfectly sound when used appropriately. The problem comes when they becomed hyped to the point that all data has to be stored in a RDBMS; and whenever anything isn't in a DB, the file must be XML.
You arrive at the point where people starting stuffing binary object--images for example--into RDBMSs. Despite that they are entirely opaque to relational logic when stored this way devoiding the primary benefit. Despite that RDBMSs are usually pretty inefficient at storing and handling blobs.
And you end up with programming languages for performing manipulations of XML, written in XML. Ie. XSLT and XPATH. A program that can be written as a one-liner in Perl becomes ten screens of tortuously clumbsy, grossly inefficient and nightmarishly opaque code. Eg. Take a quick peek at this and try and work out what it does? And if you succeed in getting a clue to it's purpose think about how much easier it would be to read if it were written in Perl. Or just about any other language.
The blanket application of any technology is questionable. OO is very powerful, but somethings are just more easily abstracted and manipulated using a functional techniques. Perl 5's sort is the very essence of how powerful procedural techniques can be. One routine that can be used to sort almost anything in almost any way imaginable.
Sure, you could add a sort method to arrays; and a sort method to hashes; and sort method to lists; and all of those could call the underlying single sort routine so as to make things look OO--but it would just be a facade of OO-ness. According to OO-doctrine, it would be necessary to inherit the sort code from some superclass, but what would that superclass be?
The latest invention is variously called mixins, traits or interfaces (though the latter is somewhat different). These can (in some circumstances) be viewed as dataless objects. The reality is that they are just collected groups of subroutines. Ie. Procedural code.
Problems always arise when you try to force fit the universe into a single, coherent model. The debate, and much of the effort gets moved away from 'solving the problem' to that of 'how to solve the problem of solving the problem'. So much time and energy is wasted wrapping up simple, non-conformant solutions into complicated conformant wrappers.