Re: Picking the Tools -- Marrying processing models to data model s

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

David, I don't think your message made it to the list.  Perhaps you're
having the same problems I've had posting.

> The reason that I think that O-O is fading is because O-O required software
> developers to make 1 assumption that turned out to be completely incorrect
> for performance reasons.  That assumption is that the consumer of the
> component does not know or care where the data in the component came from.
> It turns out that consumers of components almost always care where the data
> came from, such as an RDBMS.  So the one whole thing that the encapsulation
> hid - where the data really is - turned out to be mostly unusable.

I think you're dead on here.  In Alaric's rejoinder he says you're just
cooking up an impedance mismatch, but I don't see his point.
Encapsulation is an essential part of OO and encapsulation is one of the
most problematic areas I see in OO beyond the packaging of code.

The specific goal of encapsulation was originally to minimize bugs
that come about when a programmer accidentally mutates variables out of
context, quite a common error in languages heavy on expression
side-effects.

I'm not sure how encapsulation grew from this bit of tidy practice into a
general modeling world view, but the result is certainly flawed.


> Again, I tried on at least 5 different projects to build these re-usable
> components but it just never happened.  Eventually I read the einstein quote
> about insane people always trying the same thing and expecting different
> results, and realized where I fit in the quote.

Reusability is one of the biggest lies of OO.  I personally think that
code reusability is the philosopher's stone: it would be a source of
never-ending value, but there is the small problem that it doesn't exist.
There is nothing special about OO that makes code resuse magically easier.
The strange theory that inheritance is the key to object re-use is one of
the reasons I've heard for the insistence of some component models on
making inheritance part of large-granularity interfaces.  This doesn't
lend any magic reusability to components than it does to class libraries.

The important thing is to focus on reusing data rather than code, and this
is a separate issue from whether the code is procedural, functional, OO,
etc.


> The great thing about XML is that it doesn't try to head-fake you into this
> false assumption that some behaviour will auto-magically wrap the real data.
> XML makes you think about coarser grained functionality, while giving you
> really high productivity in creating your data or adapting your data from
> one system to another.

The above belongs in a gallery of quotes somethere.  Rem acu tetugisti:
you hit the nail on the head.


> To me, the biggest benefit of XML is that sooo much
> functionality is pushed into parsers, processors etc.  That means developers
> can make re-use of these coarse grained components in a very high
> productivity environment.
>
> I look at the single most effective way to continue developers productivity
> increase is to raise the standardized component infrastructure as high as
> possible - through things like XSLT, XQuery, and eventually processing
> models and process languages.

One nice thing about this thread is learning that I'm not as alone in my
thinking as I'd assumed.


-- 
Uche Ogbuji                               Principal Consultant
uche.ogbuji@fourthought.com               +1 303 583 9900 x 101
Fourthought, Inc.                         http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python