Re^4: I dislike object-oriented programming in general

[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.

[vrk]

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.

Ah, but what about native XML databases? Now there's hype for you, and you don't ever need to store data in files again!

Talking about opaque data, take a look at the mzXML file format. It's a way to store several mass spectrometry runs in a single file, including the parameters of the mass spectrometer, any extra processing done on the data, and other sorts of metadata.

Mass spectrometry data, since it's, in some sense, a sampled analog signal, consists of floating point pairs with the first number being the mass value (or rather the mass to charge ratio, but this is not important here) and the second the intensity for that mass value.

Now, the designers of the format had more clue than simply stuffing this in the following rather straightforward XML:

<peaks>
<peak><mass>100</mass><intensity>1240</intensity></peak>
...
</peaks>

(That would be a nightmare!) Instead, they defined that everything else except peak data is structured metadata in the normal XML style, making a DOM tree, and the peak data itself is stored in a base-64 encoded string in IEEE floating point format in network byte order. So, what you have in the file is, in the case of raw data, a few dozen kilobytes of metadata, and then 130 megabytes of binary junk that is completely opaque to any human being.

While it is generally speaking laudable that people try to make common file formats for storing mass spectra -- as usual, all mass spectrometer manufacturers have their own file formats -- they could have just rolled their own file format without the burden of traversing DOM trees while parsing. I guess there were enough programmers in the bunch who were just thinking of the convenience of using standard XML parsing libraries...

[BrowserUk]

a few dozen kilobytes of metadata, and then 130 megabytes of binary junk that is completely opaque to any human being.

Hmm. Let's see. 130 MB = 17,039,360 values (assuming double precision IEEE). So, if that was formatted as ASCII, assuming that same double precision is required, it would require ~20 bytes per value, ~= 325 MB to render it to the same precision in a human readable format. If we say one pair of values per line and 80 lines per page, that's ~200 reams, or 500 Kg (1/2 tonne) of cheapish printer paper. And that's before you wrap them up in the verbosity of XML.

Now, how long do you think it would take the human being to peruse that lot and pick out the anomolous pairing? And what value is there in having those values in a human readable format if no one is ever going to read them?

The point being, that to do anything meaningful with those volumes of data, it is necessary to use software.

[vrk]

Uh, sorry, I wasn't entirely clear. I didn't mean it makes sense to store some 10 or 20 million pairs of floating point values in human-readable form. There is simply a curious discrepancy between using binary data (albeit encoded in ASCII) in a file format that is supposed to be human-readable -- where readability does not really mean human-usable as such. Of course you need computers and software if you want to analyze millions of peaks.

[Gavin]

Apologies for I missing the "hype" aspect.
The explanation was very enlightening and I have learnt something new.