in reply to (OT) Terminology Oriented Programming

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.

  • Comment on Re: (OT) Terminology Oriented Programming

Replies are listed 'Best First'.
Re: Re: (OT) Terminology Oriented Programming
by Anonymous Monk on Dec 11, 2003 at 04:27 UTC

    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.

[reply]

      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.

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

[reply]
[d/l]
[reply]

In Section Meditations