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

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

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.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."