Re: What databases have taught me

H. S. Lahman wrote:
> Responding to Badour...
>

>>>> OO is hierarchy.
>>>
>>> LOL.  This pretty much says it all.  I suggest learning something 
>>> about OOA/D; it would make the trolling more credible.
>>
>> With all due respect, I see no reason to think his education in OOA/D 
>> is lacking in any way. While his statement is a simplification and a 
>> generalization, it is accurate at least to a first-order approximation.

Thank you for stepping forward to exemplify my recent statement that use of the word 'paradigm' is the surest sign of a self-aggrandizing ignorant. After all, 'paradigm' has many meanings where for each meaning a better word exists. http://en.wikipedia.org/wiki/Buzzword

OO is a computational model and not a paradigm unless by 'paradigm' one means an example of a computational model. Idiot. Further, it is a computational model comprising a collection of features useful for constructing large unpredictable state machines from small predictable state machines or otherwise picked arbitrarily in the mid to late 1960's for what seemed expedient at the time.

   Probably the single most important thing
> the OO paradigm brought to the development table was the elimination of
> the hierarchical dependencies prevalent in structured functional
> decomposition.

Your use of 'functional decomposition' is ambiguous. It could mean the computer science use of the word related to parallel computation. Or it could mean the general engineering method. Regardless, neither meaning makes any sense in what you wrote above.

http://en.wikipedia.org/wiki/Functional_decomposition

OO interferes with parallel computation and the first meaning of 'functional decomposition' more than it helps. The engineering method called 'functional decomposition' does not imply any hierarchical dependencies. The strike head, peen and handle of a hammer do not form a hierarchy; neither do the components of a home entertainment system.

You did qualify your use of the term with 'structured'. While it is not entirely clear to me what you mean by that, I will assume for argument's sake that you used the qualifier to imply the buzzwords/fashion "structured analysis and design" promoted by Ed Yourdon in the 1970's and early 1980's, which really has little to do with databases or the relational model, per se. It has everything to do with the limitations of imperative, procedural programming languages like Pascal, C, Algol, COBOL, Simula and Fortran. "Structured analysis and design" quite frankly forms the basis for buzzwords/fashion "object-oriented analysis and design" also promoted by Ed Yourdon in the late 1980's and 1990's.

http://en.wikipedia.org/wiki/Ed_Yourdon

   Problem space abstraction

Another nebulous bullshit marketing term. Are you suggesting that some ad hoc collection of features useful for creating large unpredictable state machines has any advantage over mathematics as a medium for abstraction? Predicate logic and set theory are mathematics, after all.

, peer-to-peer collaboration

It's not clear to me what you are trying to suggest here. Neither the meaning of 'peer-to-peer' as relates to computer networks nor the meaning as relates to social theory have anything to do with object-orientation, per se.

http://en.wikipedia.org/wiki/Peer-to-peer_%28disambiguation%29

> separation of message and method

Method, when used in conjunction with message, is a term that applies only to the OO computational model. If one rejects the computational model, why the hell should one care whether 'method' is separated from anything?

http://en.wikipedia.org/wiki/Method

, encapsulation

Again, it's not entirely clear what various OO proponents mean when they use this nebulous term. Each proponent often seem to use it to refer to an implementation feature of the proponent's favourite OOPL. In terms of general design principles, it generally seems to equate to the principle of information hiding. Physical and logical independence in the relational model achieve the same goals far better and far more automatically.

http://en.wikipedia.org/wiki/Encapsulation

, flexible logical
> indivisibility

Meaningless gibberish. In fact, doing the research trying to figure out what the hell you might have meant by it, I discovered that you seemingly made up the term as part of the absolute horseshit you peddle.

Further, I found your ignorant 'definitions' (misconceptions) of some of the other bullshit buzzword terms you used here and are apparently trying to build a career around. Information hiding is a general software engineering principle of restricting the effect of arbitrary design decisions to a (minimally) constrained locus. 'Encapsulation' and 'implementation hiding' are basically synonyms for information hiding that are bandied about with arbitrary and ever-shifting demarcations among them. If it were not for the arbitrary and useless added complexity introduced by the OO computational model, there would never be an opportunity for any arbitrary differences in the demarcations in the first place.

http://pathfinderpeople.blogs.com/hslahman/2004/07/defining_charac.html

 From what I can tell, the definitions you give to the terms you use are arbitrary and ignorantly contradict the well-established meanings the terms already have. Shame on you. Snake oil salesmen deserve tarring, feathering and running out on rails--ruby or no ruby.

, and all the rest of that OO stuff

OO stuff--now that's precise and meaningful... NOT!

play together for the
> specific purpose of eliminating the spaghetti code resulting from
> hierarchical implementation dependencies.

That's odd. I could have sworn that spaghetti code resulted from 'goto' and not hierarchies or dependencies.

http://en.wikipedia.org/wiki/Spaghetti_code

Perhaps you meant to say 'ravioli code' ? But then, OO would be the cause of the problem. Wouldn't it?

http://en.wikipedia.org/wiki/Ravioli_code Received on Sun Jun 25 2006 - 20:31:13 CEST