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 realised after posting that I had omitted two of your categories.

• Cryptography
• Natural language processing

I'll bite.

- Ouch!

OS kernels 
Device drivers 
Image processing 
Genetics applications 
Natural language processing 
Cryptography
[download]

All of these can be, and I believe have been, successfully analysed and designed using OOD techniques. Examples:

• The Mach Kernel

  Mach provides a small set of abstractions that have been designed to be both simple and powerful.

• Devices as Objects

  Devices make good objects. Programmers seem to understand and respond well to this technique. As an example, a uCR library includes classes for communicating with a host through a PCI bus.

• GD

  1. To create a new, empty image, send a new() message to GD::Image, passing it the width and height of the image you want to create. An image object will be returned.

• bioperl;

  Bioperl Bio::Root::Root Object
  All objects in Bioperl (but for interfaces) inherit from the Bio::Root::Root.

That leaves

Quickie sys-admin scripts

Good design takes time. Quickies are rarely well designed, they simply get the job done, but if the quickie need to be frequently re-used with small changes...

Would you care to state examples that are intractable to non-OO solutions?

Math.

When you invoke the 'add' method (often overloaded to the symbol '+') on a variable (object) that happens to be an integer, the cpu processes that operation as an integer. If the object that is the subject of that method happens to be a IEEE representation of a floating point value, then the cpu hands that method off to a math co-processor. Try 'add' on a string and you'll get an exception. This is true, regardless of the processor or the language used.

Some languages happen to overload the symbol '+' to perform a concatenation operation on a string, and that too is a OO concept (overloading). However, as was pointed out in these halls not too long ago, that is a pretty bad idea. The semantics of concatenation and those of numeric addition are completely different. 1 + 3 and 3 + 1 are commutative, but "foo" concat "bar" and "bar" concat "foo" are not.

This battle of wits you propose would be a two way street.

As I tried to indicate in my post, I was simply looking for good, well-defined examples of problems that are, or seem to be intractable to OOD, purely for research purposes.

Too many OOD books and courses concentrate on design problems, often concocted or artificially simplified, that naturally lend themselves to OOD. If your going to explore the real benefits (or otherwise) of a subject, it is better to start with difficult examples. If you can solve the difficult ones and show benefits, then the easy natural ones speak for themselves. This was the purpose of my request.

I would say most business/databasebase applications are not well modelled by OOD. That does not say such apps are intractable or even difficult to do in OO, just that contrary to popular wisdom and some large investment in OO languages for business applications, people are still left groping for a better way to model such applications.