In the end, they all come down to switching bits on and off in particular sequences. The problem is that getting the right bits to change in the right sequence is hard.

As with all hard tasks, it helps to have mental overview of what you are attempting to do. A set of guidelines to follow. All the O's you mention (except the ones you made up:) are just that, sets of guidelines. None are the holy grail. They can all coexists and serve particular purposes, or particular people.

The only time their existance becomes a problem, is when people decide, whether thru blind conviction, or commercial greed, that there is Only One True Way.

In programming, as in every other aspect of life, once exclusivity and zealotry take over from inclusivity and tolorence, the result is that the few set themselves and their needs above those of others with the inevitable results.

All the O's you mention (except the ones you made up:)

But none were made up ... honest!

There is no technical concept so fine that it cannot be brought down by conversion to a buzzword.

  Step right up! In this booth we have the never seen before,
  the outrageous, the unbelievable, the "Object Oriented"! You
  will be amazed, my friends. You won't be satisfied with
  anything else...
[download]

Software vendors are the food strip. Microsoft is like an elephant ear vendor -- the stuff they sell is big, sweet, attracts kids, lacks any real substance, and leaves you hungry after a short while.

Perl modules, then, must be the port-a-potty. They have a bad reputation, they're free to use, necessary, and you always feel better afterwards.

Is it just me or has the programming of models taken a backseat to the modelling of programming?

No, I don't think so myself :-) For an industry that's only been around for the last fifty or sixty years, and has changed so radically in scope during that time, it seems quite a small list to me.

Pretty much every new fad that has managed to escape from the labs into my awareness (including a fair few off your list) has helped improve my life as a developer. To pick one from recent history I find patterns have helped in many places. At the least it means I rarely have to explain what terms like "singleton" mean ;-) To pick a couple of non-"oriented" ones Extreme Programming and Test Driven Development have also improved project development a huge amount for me over the last couple of years.

More methods. Bring 'em on!

For example, Extreme Programming is based on experiences with "heavy-weight" methodologies, picking the good things from them, and dropping (or replacing) the bad things.

Arjen

I think it was in one of the Agile-Oriented books that the author used the acronym BDUF (Big Design Up Front). I thought to myself, well there's a useless acronym and one that no one is expected to memorize long term. But dang, as a short-term thing, it worked well in that the book chapter was easy to read and summarizing one approach with that acronym allowed the author to talk about a whole group of issues with one word. (and dang, I seem to have memorized the sucker). So I kind of judge these new words and acronyms and -based/-oriented things by the usefulness of their summarizing ability. (A feature that is easily converted into a bug).

Ok, gotta share this one: my wife's in the health care profession and noticed that a certain hospital used the acronym FDGB on some patient charts. On inquiry, she found out it stands for the well known medical syndrome "Fall Down Go Boom". :-)

I say keep a wide array of weapons, and choose the right one for any job. Sadly, this is unpopular in a world of OOP-only design-patterns-forever java-is-the-holy-grail IT folks. They can't see the light and call unbelievers ignorant. They show up with a knife at a gun fight. If only HR and management would understand TMTOWTDI.

Notice that all of those terms have something in common: programming. They are all just different perspectives of the same thing. For some reason, everybody feels the need to name their perspective, but slight differences in orientation and the resulting differences in description rarely lead to significant practical differences. The ones that do, however, are worth knowing about.

The reason that there seems to be "a paucity of real *information*" is that most of the information simply overlaps and there truly is a paucity of new information. That doesn't mean it isn't worth looking for new information, it just means you have to cultivate the skill of finding it.

-sauoq
"My two cents aren't worth a dime.";

My humble (and I hope not too heretical) opinion is that the glut of methodologies and orientations today are more indicative of failure than success. In fact, many seem to be quite directly about "fixing" OO in one way or another, generally by extending OO with additional concepts. But, I think that instead of succeeding in adding new and better modelling techniques, they mostly succeed in hiding existing failures in different ways.

Simply put, OO has a very limited area of truly successful application, that being the area it was originally designed for: Simula(tions). Take a look at the application examples in Booch's original "Object Oriented Design with Applications" (1991). Four of the five case studies presented are simulations at heart (and it is no mere accident or coincidence that this is so): Home Heating System, Optics Construction Kit, Cryptanalysis, and Traffic Management System. The one that most closely resembles a business application, the Problem Reporting System, is the one that has the most semantic difficulties between the application space and the OO modelling space and requires significant bridge work.

OO as a modelling technique just doesn't map very well onto many common application domains. Enter Role Oriented design, Aspect Oriented design, Ontology Oriented design, etc., and the additional syntactical and semantical constructs they bring to OO programming. If you read research papers in these areas you are struck by the fact that the authors seem both excited at the prospects of further research in the area, but less than satisfied with any of the current results in terms of practical application.

To me it seems as if OO is the Ptolemaic programming model and the current flurry of design and programming techniques is a struggle to add new and different forms of epicycles to try to fix the model, or at least bring better coincidence with reality. What amounts to the Copernican model has probably lain quietly unrecognized for quite some time (much like a real heliocentric model was put forward by Aristarchus in 250 B.C., some four centuries prior to Claudius Ptolemy's 'The Almagest' effectively laid down "The Model" for over a millenia). It is impossible to predict when, where, and who will bring forth the Copernican revolution, but my bet is it will happen within the decade.

Would you care to offer a common application probem that you know to be difficult or intractable to OOD? As the basis of further exploration of the idea.

It would need sufficient flesh to be a reasonably complete and clear definition of the problem space. Whatever came of my exploration would be purely for my own purposes, but could be posted back.

It might be interesting to see a collective attack on such a problem, and the evolution that might result, a bit like the occasional golf games here, though not so easy, as there isn't really an obvious common notation that could be used.

Would you care to offer a common application probem that you know to be difficult or intractable to OOD?

I'll bite.

• OS kernels
• Device drivers
• Image processing
• Genetics applications
• Natural language processing
• Cryptography
• Quickie sys-admin scripts

Would you care to state examples that are intractable to non-OO solutions? This battle of wits you propose would be a two way street. I'd say nearly all solutions that appear to be best served by OO can be served equally well with strong data structures and relational databases. Folks have gotten by a long time on these, and they'll survive many buzzword-compliant trends. I like to use objects here and there, but sporadically, never enough to call my programs object oriented. Basically structures are good enough for me in most cases.

I was educated to love pure OO. It took me years to unlearn that. And I'm a much better (and more open minded) programmer because of it.

I have found that development teams get so wrapped up trying to follow methodologies that they begin to serve two masters. One master is the customers requirements, the other master is the methodology. The methods are supposed to work for us but instead we actually work for the methodology.

For example in OO, it becomes a requirement that data and all methods that operate on the data shall be in a class.

In order to be effective tools, methodologies need to be well known and understood. Organizations would be well advised to seek out experienced help.

For organizations beginning their first x-Oriented project - my heart goes out to you as you begin this death march.

Those who survive the grueling road ahead will have learned the important, real-world techniques used to make the methodologies work.