Re: Lessons

From: <>
Date: 14 Feb 2007 07:27:55 -0800
Message-ID: <>

On Feb 13, 8:17 pm, mAsterdam <> wrote:
> JOG wrote:
> > Bob Badour wrote:
> >>> What lessons have you learned that you might want to relay? (Please
> >>> enumerate.)
> Having been plonked by Bob for "intellectual dishonesty" -
> as usual with his chilling twit filter habits no rebuttal
> chance whatsoever - I don't feel invited to this game of his.
> Yet I see some interesting points here, I hope you do not
> mind me butting in.

Having read the above comment in Paul's excerpt, I decided to read this sub-thread using Google groups. I do so because I steered this sub-thread into the direction of maintaining effectiveness, avoiding frustration and reaching target audiences.

Part of my plan for effectiveness is to avoid wasting time on those who lack the prerequisite intellectual honesty. However, if Jim teaches in a more formal setting, he might not have that luxury. He, then, needs to do as much as he can and accept that he can only do so much.

mAsterdam, if you feel I need to see your posts to make them worth posting, I can only suggest you get real and stay real.

> > Heck, why not. With the all-encompassing caveat that the follwoing is
> > all off the top of my head:
> > 1. Implementation != Theory
> > 2. To produce good IT we should be analysing _Information_ not just
> > Technology.
> > 3. Value based superior to OID's.
> OID only works if either
> - some authority really takes care of it
> (so it becomes a value) or
> - they really are not exposed to users - which requires a lot
> of development team discipline (it /is/ possible though,
> I have seen it in practice).

At that point, I fail to see a difference between OID and a physical pointer address.

> > 4. Values should never be hidden.
> I'd call the "in general" qualifier
> (some stuff really is and should be private).

But not to everyone. The security function is entirely about keeping private things private while making them available to those who need to know.

> > 5. Propositions are simply true or false and do not 'change'.
> > 5. OID's break liebniz equality.
> I plead ignorance. If you'd care to elaborate
> appreciation goes your way.
> > 6. Encapsulation has a negative impact on shared data, leading to
> > query bias.
> Information hiding (which is the purpose of encapsulation, e.g.
> is a very useful criterion when determining the boundaries between
> software/hardware modules.

Hence the important of data independence.

 Data management requires a different
> approach. I have never had a tough practical decision between
> hiding or sharing data, though. I submit/conjecture that
> this is no coincidence.

Information hiding and 'data hiding' as practices by the OO crowd are very different creatures.

> Religious following of any design principle
> will lead to disaster. In casu chasing encapsulation for data
> structuring kills data manageability.

Hear! Hear!

> > 7. Query neutrality is important for good management of shared data.
> Very undervalued insight. Please continue sharing it
> (exception to the "No 'me to's " rule of Usenet dialectics :-).
> > 8. Do not confuse conceptual/physical/logical layers.
> Intuitively, yes. However, defining them is a non-trivial task.

And yet the ISO/IEC standard vocabularies do it on no more than a sheet of paper.

> > 9. Purely Navigational Databases are inferior to Declarative
> > Databases.
> > 10. Nulls are both nonsensical and generate logical errors.
> > 11. There are two types of updates masquerading as one - domain
> > redefinitions/proposition replacement,
> > 12. RM redefines some mathematical concepts - tuple/relation/cross-
> > product.
> > 13. Semi-structured data has no definition.
> Currently, yes. The burden, however, is on the theory.

What theory? That's the heart of the matter.

[snip] Received on Wed Feb 14 2007 - 16:27:55 CET

Original text of this message