Re: I dislike object-oriented programming in general

[toma]

Don't bother to read my rambling reply unless you are an OO skeptic...

You can eschew OO jargon and consider objects to be user-defined data types, methods to be language extensions or function libraries, and inheritance to be a curiosity.

OO hype can be annoying and counterproductive.

From a user/programmer point of view, it is interesting to notice bugs that occur in applications due to over-fondness for objects. But cataloging this menagerie is unlikely to dampen the current enthusiam for objects.

Even before the first software object, there was a business in selling integrated circuits (ICs) made from semiconductors. These worked wonderfully, and you could design circuits with them without understanding the IC guts. Software developers became jealous, and proposed selling 'software ICs' with no exposed guts. This terminology only appealed to electrical engineers, and to broaden the appeal the name was changed to 'object oriented programming'. Nauseating terminology was introduced, and non-believers were declared incompetent to comment on the subject. New books were written, courses were attended, conferences were established, and money changed hands. Software productivity ground to a halt as developers retooled, and quality suffered for years.

I think the industry has mostly recovered from the OO setback, and now there is possibly some benefit from OO. As Abigail observed, OO enables the creation supportable spaghetti code. If programmers are going to write spaghetti, supportable spaghetti is better.

Last I checked, the overall semiconductor industry revenue is still larger than the overall software industry revenue. The irony is that they semiconductor designers use languages like Verilog, VHDL, and SPICE, which are not particularly OO, to design products that are actually tangible objects.

Electrical engineering is fun, perhaps you should check it out! In that domain, objects tend to be physical objects, the abstractions are less annoying, and there is still a decent living to be made.

[BrowserUk]

... hype can be annoying and counterproductive.

++ The ellipses above can be replaced by almost any magic bullet, holy grail, one true way or dogma and still be true, but it is rarely more so than than in your original formulation.

That said, XML and relational databases come close.

[Gavin]

Being a relative newcomer to both XML and relational databases I too find them annoying.
In my case this is because I do not as yet fully understand their mechanics and as a result I am irritated at not being able to do what I would like to do.
However I doubt that that is the reason for your feelings.
I would be interested to know why you feel XML and relational databases to be "annoying and counterproductive".

[BrowserUk]

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.