What databases have taught me
JOG
posts of the OO vs RM thread. Some discouraging stuff indeed. Over the
last few years a study of database technology, helped greatly by
discussions in cdt, has educated my opinions significantly, and perhaps
my albeit slow progress can be illuminative to others.
- I started life as a procedural programmer.
- I adopted OO and soon got the 'aha' click described by R. Martin.
- I spent years coding large OO projects, with beautiful, elegant
architectures.
- I spent further years practically gnawing my arm off attempting to
adapt my perfect OO designs as requirements inevitably shifted and
exceptions arose.
- I finally realised that my 'aha' was utterly illusionary, and that my
code, being OO, was inevitably and irrecovably imprisoned in a
hierarchical strait-jacket
OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
dire and destructive artifice. If one does not recognize this, one is
etiher wholly uneducated (given that the battle between
hierarchy/networks and a relationship based models occurred decades
ago) or has not been involved in enough large scale OO projects. Yet
still this turgid "chinese doll" approach prevails through Java, C++
and the bastard child of them all, XML.
I still code via OO as I currently have no other preferable tools. And
yes, I still absolutely take pride in my crafted generic OO designs.
However I now don't waste precious time trying to perfect them, because
I know they are by definition inflexible, brittle and flawed. So I make
them lightweight and replacable, aware of the limitations of the
neanderthal paradigm that we are currently lumped with.
It really is amazing that IT as a field has so little to do with the
study of 'Information', of its nature and how it ought be structured
for optimal manipulation and integrity provision, and so much on a
'Technology' fetish.
So apologies for the rant, but I find the current status quo very
frustrating. I can only hope that this situation will change as the
field matures and hierarchy-where it does not belong finally dies a
long overdue death.
Kenneth Downs
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that my
> code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket
>
Well said, this is my experience as well.
Then I asked, what does the framework look like if its sole purpose is to
facilitate handling of data? Oddly enough the entire OO aspect
disappeared, wasn't worth the bother. I've got a couple of objects in my
code now, but they are hardly a theoretical basis for anything, just a
handy trick of the language here and there.
--
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
Neo
Some simple questions. What would one have to demonstrate to show that
OO is not hierarchal. Would it be OK to assume that a thing (any thing)
is an object or do you have more specific requirements?
Marshall
>
> - I started life as a procedural programmer.
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that my
> code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket
Nice post!
The progression you describe above is pretty much exactly the
progression I went though as well.
Marshall
Keith H Duggar
[snip all too familiar story]
Same experience for me, though perhaps on smaller scale
projects though with complex algorithms.
> I still code via OO as I currently have no other
> preferable tools.
I'm stuck in the same situation. Please accept my apology
for the questions I'm about to ask. I suspect the answers
are somewhere out there; but, I'm just suffering from search
fatigue (been studying these relational concepts feverishly
for weeks) and would love some easy answers.
The question, how to leverage relational thinking to develop
stand-alone applications? Something where I can write some
code, compile the code, and deliver a tool that a client can
feed a flat-file dataset (database?) to analyze. And where
the "compiler" only incorporates as much DBMS functionality
as is necessary to execute the static procedures defined in
the code. For example the "Rel" project:
http://dbappbuilder.sourceforge.net/Rel.html
incorporates an entire Java implementation of the Berkley DB
engine. Something more lightweight (and preferably not Java)
would be better. Maybe I'm looking for a relational library
rather than a DBMS? JOG what do you do to leverage RM in
your development?
Again forgive me if those questions are confused. Hell, they
may even border on stupid. As said, I'm a bit fatigued. Some
guidance would be most appreciated.
-- Keith -- Fraud 6
Neo
When you say "OO is hierarchy", I can't grasp what you are trying to
saying. For example, things in the real world typically form networks.
In special cases, things in the real world might be structured as
lists, trees, tables, etc. Or a portion of a network might be viewed as
a list, tree, table, etc. The statement seems confusing as it is
similar to saying "Fruit is sugar".
Keith H Duggar
> > > OO is hierarchy.
> >
> > ... What would one have to demonstrate to show that ...
>
> When you say "OO is hierarchy", I can't grasp what you are
> is similar to saying "Fruit is sugar".
Relax Neo, your world is safe. You can continue using OO for
as long as you like :-)
Anyhow, I think what JOG had in mind is that hierarchal
methods are often used to /define implementations/ of
OO. For example inheritance and composition.
Thus the /static/ structures of OO designs are often
hierarchal. The /dynamic/ structure of OO programs can
more generally be a network.
Neo
> >
> > Some simple questions. What would one have to demonstrate to show that
> > OO is not hierarchal. Would it be OK to assume that a thing (any thing)
> > is an object or do you have more specific requirements?
>
> When you say "OO is hierarchy", I can't grasp what you are trying to
> In special cases, things in the real world might be structured as
> lists, trees, tables, etc. Or a portion of a network might be viewed as
> a list, tree, table, etc. The statement seems confusing as it is
> similar to saying "Fruit is sugar".
Never mind. I think I understand what you mean. With current OO tools
such as C++, there is basically only one systematic relationship
(class/instance) between objects and thus they tend to form
hierarchies.
fre...@gmail.com
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that my
> code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket
I share the same experience too. Its a very unpleasant exerience to
finally realize that what you believed in for many years is just an
illusion. But I still think that there are some limited areas, such as
building collection classes (maps, lists, etc), embedded software or
GUI components, in which OO have some benefits.
After all OO started in the telecom industry and I think that OO showed
some significant benefits in that area. But the big problem is then the
gurus tried to apply OO everywhere, specially in business software for
accunting, logistics, HR management etc.
I think that the main disadvantage with OO is that it is not
multi-dimensional. OO textbooks like to use animals as an example. They
like to build a polyphormic hierarchy like this:
Fish
- Shark
- Tunar
Bird
- Eagle
- Condor
Mammal
- Horse
- Dolphin
- Bat
This is the correct zooligical hierachy. But what if there are features
(or behavior) that are common for all animals that can fly or that
lives in water? Many business entities like bank accounts and employee
types, are almost impossible to classify in hierachies.
Fredrik Bertilsson
http://frebe.php0h.com
Joerg Simon
fre...@gmail.com wrote
>
[snip]
> I think that the main disadvantage with OO is that it is not
> multi-dimensional. OO textbooks like to use animals as an example. They
> like to build a polyphormic hierarchy like this:
> Fish
> - Shark
> - Tunar
> Bird
> - Eagle
> - Condor
> Mammal
> - Horse
> - Dolphin
> - Bat
> This is the correct zooligical hierachy. But what if there are features
> (or behavior) that are common for all animals that can fly or that
> lives in water? Many business entities like bank accounts and employee
> types, are almost impossible to classify in hierachies.
Regards,
Jörg Simon
--
Joerg Simon
Student of softwareengineering and Knowledgemanagement at the TU-graz,
Developer at the Know-Center (http://www.know-center.at)
visit the I-KNOW '06 http://www.i-know.at
visit www.kathtreff.at ;)
visit www.joergsimon.at
Frans Bouma
> Well after a brief hiatus I have just ploughed through the whole 800
> posts of the OO vs RM thread. Some discouraging stuff indeed. Over the
> last few years a study of database technology, helped greatly by
> discussions in cdt, has educated my opinions significantly, and
> perhaps my albeit slow progress can be illuminative to others.
Please also realize that in comp.databases*, a lot of people are
die-hard database pundits who preach to implement everything of an
application inside the DB, including BL.
> - I started life as a procedural programmer.
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that
> my code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket
I don't know anything about you nor your projects, so I can't comment
on the experiences you got if they're the result of OO or the result of
applying OO wrong.
What I can say is that if you don't realize that <insert tech /
paradigm here> is just a tool to get to the goal you want to achieve:
an executable solution to the problem you want to solve, that same
tech/paradigm will sooner or later bite you because it will have
limitations and shortcomings.
> OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
> dire and destructive artifice. If one does not recognize this, one is
> etiher wholly uneducated (given that the battle between
> hierarchy/networks and a relationship based models occurred decades
> ago) or has not been involved in enough large scale OO projects. Yet
> still this turgid "chinese doll" approach prevails through Java, C++
> and the bastard child of them all, XML.
True, a good example is a Math library in an OO language runtime
library. It often is implemented as a library with static methods in
one big class or several different classes without state nor specific
type, just a vehicle to hold the static methods together.
That doesn't mean OO sucks, it means for functional problems which can
be appearing in any domain, it might be best to use a functional /
procedural approach instead of an OO.
The same applies to using OO-esk constructs in an procedural language.
I think a lot here have seen or have written C-structs with function
pointers to use some kind of OO-esk approach in their procedural
programs because it would fit the problem better. That's not implying
procedural languages suck, it illustrates there might be better
solutions to that particular problem in that particular domain.
> I still code via OO as I currently have no other preferable tools. And
> yes, I still absolutely take pride in my crafted generic OO designs.
> However I now don't waste precious time trying to perfect them,
> because I know they are by definition inflexible, brittle and flawed.
> So I make them lightweight and replacable, aware of the limitations
> of the neanderthal paradigm that we are currently lumped with.
I think that's, just judged by the sentence above, a flawed vision on
reality, but that could be caused by experiences I or others didn't
experience, so I won't judge you on that.
What I can say is that often people are too blinded by the paradigm
they use. Take for example Object oriented data-access. Entities as
objects in your program, working with object graphs, etc. it all
matches the paradigm used and lets you make progress.
Though what to do when you have to create a simple list of data on the
screen with all the OrderEntity's fields (attributes so you will) and
also the companyname of the related customer. ? that can be a struggle,
as you effectively have to create a new class, project the order data
onto a list of instances of that class and together withthat have to
add the related CustomerEntity's companyname into it as well. It will
likely require you to write extra code if you solely have to work with
the entity classes at hand.
Does it then suck in the core of its being? no, it just doesnt fit
that specific problem. A solution could be to use an untyped container,
the meta-data of orderentity and customer entity and with OO blocks
build a new list of dataelements and use the mechanism at hand to get
that data.
Small example of how OO could get into your way if you're focussed on
a limited part of the whole spectrum: with the same OO constructs you
can for example use factories and meta-objects to build what you need
easily without having to fall back on procedural approaches.
> So apologies for the rant, but I find the current status quo very
> frustrating. I can only hope that this situation will change as the
> field matures and hierarchy-where it does not belong finally dies a
> long overdue death.
"Use the right tool for the job, Luke"
FB
--
------------------------------------------------------------------------
Lead developer of LLBLGen Pro, the productive O/R mapper for .NET
LLBLGen Pro website: http://www.llblgen.com
My .NET blog: http://weblogs.asp.net/fbouma
Microsoft MVP (C#)
------------------------------------------------------------------------
Bruno Desthuilliers
> Well after a brief hiatus I have just ploughed through the whole 800
> posts of the OO vs RM thread. Some discouraging stuff indeed. Over the
> last few years a study of database technology, helped greatly by
> discussions in cdt, has educated my opinions significantly, and perhaps
> my albeit slow progress can be illuminative to others.
>
> - I started life as a procedural programmer.
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that my
> code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket
>
> OO is hierarchy.
May I ask 2 questions here ?
1/ when asserting 'OO is hierarchy', are you talking about type
hierarchy or run-time associations between instances ?
2/ which 'OO' languages did you use ?
3/ have you worked on 'non-business' projects (content management, CAD,
etc) ?
> Enforcing a hierarchy where none exists is an utterly
> dire and destructive artifice. If one does not recognize this, one is
> etiher wholly uneducated (given that the battle between
> hierarchy/networks and a relationship based models occurred decades
> ago) or has not been involved in enough large scale OO projects. Yet
> still this turgid "chinese doll" approach prevails through Java, C++
> and the bastard child of them all, XML.
OO is not restricted to Java and C++. But I can understand that you feel
"imprisoned in a strait-jacket" with these languages. And BTW, I fail to
see how XML relates to OO (Java'ers abuse of it set aside, but this is
more an issue with Java than with OO IMHO).
> I still code via OO as I currently have no other preferable tools. And
> yes, I still absolutely take pride in my crafted generic OO designs.
> However I now don't waste precious time trying to perfect them, because
> I know they are by definition inflexible, brittle and flawed. So I make
> them lightweight and replacable, aware of the limitations of the
> neanderthal paradigm that we are currently lumped with.
I have this pattern too, somehow. Going over the board with genericity
in prevision of changes that are barely previsible is an easy mistake.
The design should first deal with the problem at hand, and only then try
to flexible where it seems (ie : from experience gathered during the
project and previous projects) to makes sens. Now about inflexibility
and brittleness, it's something I faced much more with 'rigid' languages
like Java than with higher-level, more dynamic languages.
> It really is amazing that IT as a field has so little to do with the
> study of 'Information', of its nature and how it ought be structured
> for optimal manipulation and integrity provision, and so much on a
> 'Technology' fetish.
Indeed.
FWIW, it's (IMHO) partly a case of "worst is better", partly a problem
with marketing-addict PHBs, and partly a problem with superstitions
relating to silver bullets and whatnot...
> So apologies for the rant, but I find the current status quo very
> frustrating. I can only hope that this situation will change as the
> field matures and hierarchy-where it does not belong finally dies a
> long overdue death.
Hmmm... The fact is that we *also* have to deal with hierarchical data
structures, and relational algebra does not really shine here.
My 2 cents.
--
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'on...@xiludom.gro'.split('@')])"
Bruno Desthuilliers
>>- I started life as a procedural programmer.
>>- I adopted OO and soon got the 'aha' click described by R. Martin.
>>- I spent years coding large OO projects, with beautiful, elegant
>>architectures.
>>- I spent further years practically gnawing my arm off attempting to
>>adapt my perfect OO designs as requirements inevitably shifted and
>>exceptions arose.
>>- I finally realised that my 'aha' was utterly illusionary, and that my
>>code, being OO, was inevitably and irrecovably imprisoned in a
>>hierarchical strait-jacket
>
>
> I share the same experience too. Its a very unpleasant exerience to
> finally realize that what you believed in for many years is just an
> illusion. But I still think that there are some limited areas, such as
> building collection classes (maps, lists, etc), embedded software or
> GUI components, in which OO have some benefits.
Indeed.
> After all OO started in the telecom industry and I think that OO showed
> some significant benefits in that area. But the big problem is then the
> gurus tried to apply OO everywhere, specially in business software for
> accunting, logistics, HR management etc.
Are OO programs much worse than procedural or functional ones in this
domain ? My own experience is that I write better software and have less
maintenance nightmares with how I use OO today than with some procedural
programs I've had to work on - but then, I've also worked on very badly
designed/written OO apps, and that was by no mean better than the badly
designed/written procedural apps :-/
So, is it a problem with OO, or a problem with how OO is used ?
> I think that the main disadvantage with OO is that it is not
> multi-dimensional. OO textbooks like to use animals as an example.
Alas...
> They
> like to build a polyphormic hierarchy like this:
> Fish
> - Shark
> - Tunar
> Bird
> - Eagle
> - Condor
> Mammal
> - Horse
> - Dolphin
> - Bat
> This is the correct zooligical hierachy.
Yes, and a very bad example of the use of subtyping in OO. Also, it
somehow relies on the assumption that polymorphism is conditionned by
class inheritance - which, while somehow the case with languages like
Java, is not necessarily true for all OOPLs.
> But what if there are features
> (or behavior) that are common for all animals that can fly or that
> lives in water?
What's your problem here exactly ?
class Swimmer(Animal):
def swim(self):
pass
class Shark(Fish, Swimmer):
pass
class Dolphin(Mammal, Swimmer):
pass
FWIW, note that I used a Swimmer class only to factor out common
behavior. I could as well write it like this:
class Shark(object):
def swim(self):
pass
class Dolphin(object):
def swim(self):
pass
And BTW I would certainly start this way unless I already know factoring
out common behaviours will makes sens for the problem at hand.
> Many business entities like bank accounts and employee
> types, are almost impossible to classify in hierachies.
Indeed - business rules are usually much less logical and 'universal'
than scientific taxonomies !-)
Trying to fit entities as revealed by a first analysis of the domain
into a straight, uni-dimensional hierarchy will certainly lead to a very
bad design. Problem-domain entities and solution-space abstractions are
not necessarily mapping 1:1.
My 2 cents
Bob Badour
It is a problem with OO. The benefits you describe come from effective
abstraction and related engineering disciplines that are not unique to
OO. The problems JOG related, on the other hand, are inherent to OO.
>>I think that the main disadvantage with OO is that it is not
>>multi-dimensional. OO textbooks like to use animals as an example.
>
>
> Alas...
>
>
>>They
>>like to build a polyphormic hierarchy like this:
>>Fish
>> - Shark
>> - Tunar
>>Bird
>> - Eagle
>> - Condor
>>Mammal
>> - Horse
>> - Dolphin
>> - Bat
>>This is the correct zooligical hierachy.
>
> Yes, and a very bad example of the use of subtyping in OO. Also, it
> somehow relies on the assumption that polymorphism is conditionned by
> class inheritance - which, while somehow the case with languages like
> Java, is not necessarily true for all OOPLs.
>
>>But what if there are features
>>(or behavior) that are common for all animals that can fly or that
>>lives in water?
>
> What's your problem here exactly ?
Such a silly trivial example doesn't even begin to address the issue JOG
brought up related to application maintenance in a dynamic environment.
Such a stupid example is, in fact, nothing more than a complete waste of
time for everyone.
Kenneth Downs
>
> I share the same experience too. Its a very unpleasant exerience to
> finally realize that what you believed in for many years is just an
> illusion. But I still think that there are some limited areas, such as
> building collection classes (maps, lists, etc), embedded software or
> GUI components, in which OO have some benefits.
>
I've come to the same conclusion: OO is a really nifty GUI tool. In all
other places (within context of biz software) it is disqualified for use by
the KISS principle.
Kenneth Downs
Where did this lead you to Marshall? Can you give your "elevator speech"
about how you develop now in your post-OO mindset?
Erwin
> May I ask 2 questions here ?
> 1/
> 3/
:-))))))
> OO is not restricted to Java and C++.
There's always SmallTalk, of course. Maybe you disagree, but I've
heard more than one self-proclaimed OO-purist declare SmallTalk to be
the only *true* OO language. And that alledgedly "one and only true OO
language" is, to the best of my knowledge, a thousand times more
strictly hierarchical than Java or C-with-any-suffix.
> Going over the board with genericity
> in prevision of changes that are barely previsible is an easy mistake.
Hear hear.
> Hmmm... The fact is that we *also* have to deal with hierarchical data
> structures, and relational algebra does not really shine here.
Hmmmmmm. Is it really the *algebra* you think is crippled ? What kind
of operation do you think is unsupported by the algebra ?
> My 2 cents.
Ditto.
David Cressey
"Marshall" <marshal...@gmail.com> wrote in message
news:1151031561....@c74g2000cwc.googlegroups.com...
My progression was different, mainly because I started earlier, and took a
different turn.
I started as an assembly language programmer, with a little bit of work in
3GLs.
I help build a language of the Lisp family. Some of its more useful
innovations were later subsumed by additions to common Lisp.
Eventually I taught my self structured programming and ALGOL, so I became
what you guys call a "procedural programmer".
Later, I moved to the VAX from earlier DEC computers, and I decided to
learn Pascal, rather than any of the other available languages.
By the time I got exposed to OO, I was in my forties. When the apostles of
OO said, "forget everything you ever learned about programming", I tuned
out. I wasn't about to do that.
My epiphany was in a different direction. It was the move from "process
centered thinking" to "data centered thinking". In my mind, this is a
greater leap than from procedural programing to OOP. YMMV.
I began using Datatrieve (a DEC language) with indexed files, and then
migrated to Rdb, DEC's entry in the relational DBMS derby of the early 80s.
From then on, I've been database oritented. I'vbe written code, but only
for the sake of the data it manages.
Bob Badour
> JOG wrote:
>
>>Well after a brief hiatus I have just ploughed through the whole 800
>>posts of the OO vs RM thread. Some discouraging stuff indeed. Over the
>>last few years a study of database technology, helped greatly by
>>discussions in cdt, has educated my opinions significantly, and
>>perhaps my albeit slow progress can be illuminative to others.
>
> Please also realize that in comp.databases*, a lot of people are
> die-hard database pundits who preach to implement everything of an
> application inside the DB, including BL.
I assume BL=business logic. What, exactly, is your objection to using
predicate logic for dealing with logic? (Other than ignorance.) Exactly
what formalism do you propose that surpasses the predicate calculus for
dealing with logic?
>>- I started life as a procedural programmer.
>>- I adopted OO and soon got the 'aha' click described by R. Martin.
>>- I spent years coding large OO projects, with beautiful, elegant
>>architectures.
>>- I spent further years practically gnawing my arm off attempting to
>>adapt my perfect OO designs as requirements inevitably shifted and
>>exceptions arose.
>>- I finally realised that my 'aha' was utterly illusionary, and that
>>my code, being OO, was inevitably and irrecovably imprisoned in a
>>hierarchical strait-jacket
>
> I don't know anything about you nor your projects, so I can't comment
> on the experiences you got if they're the result of OO or the result of
> applying OO wrong.
From the little bit you write here, I know a lot about you. For
instance, you know little or nothing about higher-level abstractions,
the benefits of symmetric operations, the advantages of declarative
techniques over procedural techniques, robust type systems, separation
of concerns and probably a whole host of other fundamental concepts.
Your speculation over JOG's limitations proves only your own.
I can comment on JOG--his experiences have nothing to do with a
misapplication of OO.
> What I can say is that if you don't realize that <insert tech /
> paradigm here>
The surest sign of a self-aggrandizing ignorant is the wanton use of the
word 'paradigm' which has many meanings where for each meaning a better
word exists.
is just a tool to get to the goal you want to achieve:
> an executable solution to the problem you want to solve
You further reveal your cognitive limitations with your presupposition
that every solution to every problem must execute.
Although, I am sure you are blissfully unaware of it, the specific tools
we are comparing are both formalisms. While I suppose one could argue
that formalisms are "technologies" or "techniques", one would have to
stretch things a little. Formalisms are not 'paradigms' by any of the
myriad meanings of the word.
Formalisms are tools for expressing with rigour and precision amenable
to mechanical manipulation. Mathematicians (and everyone engaged in
programming is practising applied mathematics whether one knows it or
not) have long recognized the importance of good formalisms for
expressing concepts. Formalisms become doubly important in computing
where a machine does the manipulation.
, that same
> tech/paradigm will sooner or later bite you because it will have
> limitations and shortcomings.
While I agree with JOG regarding the hierarchic straightjacket, I find
OO much more damaging for other reasons, and your concluding phrase
above demonstrates the point.
OO proponents in an effort to create some kind of mysticism have
systematically discarded existing precise vocabulary for imprecise
verbiage often using the same word to mean many different things. For
instance, established computing terms like variable, value, type, data,
state machine, etc. are lost in a haze of nebulous terms like object.
This mysticism incapacitates OO proponents. They invariably talk around
issues without ever naming them directly, which leaves one wondering
whether they really understand what each other are saying. Your
inability to identify a formalism as a formalism preferring instead to
call it a 'tech/paradigm' demonstrates my point.
I direct your attention to Dijkstra's comments on elixirs and the
illusion of power. I observe that OO is as damaging to minds as COBOL or
Basic, and I suggest Dijkstra's comments about them should apply equally
to OO.
>>OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
>>dire and destructive artifice. If one does not recognize this, one is
>>etiher wholly uneducated (given that the battle between
>>hierarchy/networks and a relationship based models occurred decades
>>ago) or has not been involved in enough large scale OO projects. Yet
>>still this turgid "chinese doll" approach prevails through Java, C++
>>and the bastard child of them all, XML.
>
> True, a good example is a Math library in an OO language runtime
> library. It often is implemented as a library with static methods in
> one big class or several different classes without state nor specific
> type, just a vehicle to hold the static methods together.
>
> That doesn't mean OO sucks, it means for functional problems which can
> be appearing in any domain, it might be best to use a functional /
> procedural approach instead of an OO.
Here again, you prove yourself ignorant of the meaning of procedural.
All OO languages are procedural rather than declarative. While one or
two functional OO languages exist, almost all are imperative.
Functional languages contrast with imperative languages.
Declarative languages contrast with procedural languages.
OO is just an arbitrary and ad hoc collection of features useful for
constructing large unpredictable state machines from small predictable
state machines.
> The same applies to using OO-esk constructs in an procedural language.
> I think a lot here have seen or have written C-structs with function
> pointers to use some kind of OO-esk approach in their procedural
> programs because it would fit the problem better. That's not implying
> procedural languages suck, it illustrates there might be better
> solutions to that particular problem in that particular domain.
Are you seriously suggesting that C++ is any less procedural than C? Yikes!
>>I still code via OO as I currently have no other preferable tools. And
>>yes, I still absolutely take pride in my crafted generic OO designs.
>>However I now don't waste precious time trying to perfect them,
>>because I know they are by definition inflexible, brittle and flawed.
>>So I make them lightweight and replacable, aware of the limitations
>>of the neanderthal paradigm that we are currently lumped with.
>
> I think that's, just judged by the sentence above, a flawed vision on
> reality, but that could be caused by experiences I or others didn't
> experience, so I won't judge you on that.
If you didn't intend anyone to judge him on 'a flawed vision', why the
hell did you suggest it in the first place?
Frankly, JOG's vision and his cognitive abilities are fine. I cannot say
the same for you, and I do judge you on that.
> What I can say is that often people are too blinded by the paradigm
> they use.
I can understand how one who prefers nebulous terms like paradigm and
object would conclude the danger of blindness. What I don't understand
is the conclusion of the danger of blindness in others who prefer to say
what they mean.
Take for example Object oriented data-access. Entities as
> objects in your program, working with object graphs, etc. it all
> matches the paradigm used and lets you make progress.
You used the word 'object' three times. Define the word. Define 'entity'
while you are at it. What you wrote is meaningless gibberish.
Take the phrase: "Entities as objects in your program"
Let's assume for argument's sake that Entity means "some arbitrary
concept named as a noun and associated with some artifact". When
pluralized, it is not at all clear whether you mean multiple concepts or
multiple artifacts. It is not at all clear whether "objects" means
object classes or object instances. It is clear that you are talking
about mapping some arbitrary concept to something in your program and
that the 'something' is probably either a variable or a data type.
However, since we are discussing an arbitrary concept, it hardly matters
which. Some concepts will map to variables and some will map to data types.
The phrase "working with object graphs" presumably means working with
pointers among variables, and I suggest that is usually just an onerous
task forced on one by a lousy computational model.
The phrase "it all matches the paradigm used" does not in any way
suggest which of the many meanings of 'paradigm' applies. If you mean
the formalism or computation model, which is not really a paradigm in
any sense of the word, the statement is pointless. Obviously, one must
conform to whatever formalism or computational model one uses. One
doesn't really have any other choice. Now does one?
The phrase "lets you make progress" doesn't really offer any useful
information. A couple of days ago, I went fishing for brook trout. I
walked about half a mile along the brook next to my house through dense
alders, chest-high raspberry canes, ostrich ferns as tall as I am and
one particularly thorny patch of wild rose vines. The alders, raspberry
canes, ostrich ferns and rose vines let me make progress too. They
didn't really do anything to facilitate my progress, though.
[straw man snipped]
>>So apologies for the rant, but I find the current status quo very
>>frustrating. I can only hope that this situation will change as the
>>field matures and hierarchy-where it does not belong finally dies a
>>long overdue death.
>
> "Use the right tool for the job, Luke"
>
> FB
What makes you think OO is the right tool for any job?
Bob Badour
> JOG wrote:
>
>>So apologies for the rant, but I find the current status quo very
>>frustrating. I can only hope that this situation will change as the
>>field matures and hierarchy-where it does not belong finally dies a
>>long overdue death.
>
> Hmmm... The fact is that we *also* have to deal with hierarchical data
> structures, and relational algebra does not really shine here.
>
> My 2 cents.
Only a complete ignorant would suggest that relational algebra does not
shine for handling graphs of data. Your focus on structure without
regard to manipulation or integrity is foolish.
Frans Bouma
> Frans Bouma wrote:
> > JOG wrote:
> >
> > > Well after a brief hiatus I have just ploughed through the whole
> > > 800 posts of the OO vs RM thread. Some discouraging stuff indeed.
> > > Over the last few years a study of database technology, helped
> > > greatly by discussions in cdt, has educated my opinions
> > > significantly, and perhaps my albeit slow progress can be
> > > illuminative to others.
> >
> > Please also realize that in comp.databases*, a lot of people are
> > die-hard database pundits who preach to implement everything of an
> > application inside the DB, including BL.
>
> I assume BL=business logic. What, exactly, is your objection to using
> predicate logic for dealing with logic? (Other than ignorance.)
> Exactly what formalism do you propose that surpasses the predicate
> calculus for dealing with logic?
Oh dear, it was crossposted.
I wasn't talking about predicate calculus, I was talking about a
complete middle-tier business logic tier. But let's not go there, I
don't want a discussion about that with people who think everything
except perhaps the bare-bones gui should be inside an RDBMS system.
let's agree to disagree on that, we just share different views on that
topic.
> > > - I started life as a procedural programmer.
> > > - I adopted OO and soon got the 'aha' click described by R.
> > > Martin. - I spent years coding large OO projects, with
> > > beautiful, elegant architectures.
> > > - I spent further years practically gnawing my arm off attempting
> > > to adapt my perfect OO designs as requirements inevitably shifted
> > > and exceptions arose.
> > > - I finally realised that my 'aha' was utterly illusionary, and
> > > that my code, being OO, was inevitably and irrecovably imprisoned
> > > in a hierarchical strait-jacket
> >
> > I don't know anything about you nor your projects, so I can't
> > comment on the experiences you got if they're the result of OO or
> > the result of applying OO wrong.
>
> From the little bit you write here, I know a lot about you. For
> instance, you know little or nothing about higher-level abstractions,
> the benefits of symmetric operations, the advantages of declarative
> techniques over procedural techniques, robust type systems,
> separation of concerns and probably a whole host of other fundamental
> concepts.
Which part of "So I can't comment on..." don't you understand?
> Your speculation over JOG's limitations proves only your own.
that's your interpretation, I just wanted to formulate that what his
experiences were could be the result of wrongly applied OOP, which
could perfectly be caused by his teammembers, or by a skewed project
description or whatever.
> I can comment on JOG--his experiences have nothing to do with a
> misapplication of OO.
That's great to know, it wasn't in the posting. Again, my goal wasn't
to judge the poster's knowledge, just that it's perfectly possible to
have bad experiences with OO like with any technology/method, and thus
that could influence how you think about it.
> > What I can say is that if you don't realize that <insert tech /
> > paradigm here>
>
> The surest sign of a self-aggrandizing ignorant is the wanton use of
> the word 'paradigm' which has many meanings where for each meaning a
> better word exists.
so, all you want is just flame me. Cool, have fun, Bob.
FB
Bruno Desthuilliers
Bob, please save everybody's precious time. We all know that the mere
mention of the term OO is enough to drive you into an almost
pathological rage, so for your own good, it would be better to avoid
posting and even reading posts related to this topic. Take your pills
and go back to your beloved religion.
warning for c.object newcomers: don't waste your time arguing with this
guy, all you'll get will be insults and insults - like with any fanatic
when you don't share their beliefs.
Bruno Desthuilliers
> Bob Badour wrote:
>
(snip)
>>The surest sign of a self-aggrandizing ignorant is the wanton use of
>>the word 'paradigm' which has many meanings where for each meaning a
>>better word exists.
>
>
> so, all you want is just flame me. Cool, have fun, Bob.
Frans, you should know better. Why are you wasting your time reading the
ineptia of religious fanatics ?
Bob Badour
> Bob Badour wrote:
>
> Bob, please save everybody's precious time. We all know that the mere
> mention of the term OO is enough to drive you into an almost
> pathological rage, so for your own good, it would be better to avoid
> posting and even reading posts related to this topic. Take your pills
> and go back to your beloved religion.
>
> warning for c.object newcomers: don't waste your time arguing with this
> guy, all you'll get will be insults and insults - like with any fanatic
> when you don't share their beliefs.
You are a complete embecile who is utterly incapable to distinguish
between religion and mathematics. You deserve severe sanction for
practising applied mathematics with neither an adequate intellect nor an
adequate education. Plonk.
Bruno Desthuilliers
>>May I ask 2 questions here ?
>>1/
>>2/
>>3/
>
>
> :-))))))
>
oops :(
There are 3 kind of people: those who know how to count, and the others.
Seems like I'm in the 3rd part !-)
>>OO is not restricted to Java and C++.
>
>
> There's always SmallTalk, of course.
And Python, Ruby, CLOS, OCaml and objective-C...
> Maybe you disagree, but I've
> heard more than one self-proclaimed OO-purist declare SmallTalk to be
> the only *true* OO language. And that alledgedly "one and only true OO
> language" is, to the best of my knowledge, a thousand times more
> strictly hierarchical than Java or C-with-any-suffix.
oh, really ? Could you please elaborate about what you mean when
asserting that Smalltalk is "a thousand times more strictly
hierarchical" than Java etc ? I fail to understand about which
hierarchies you're talking about here - class hierarchy or runtime
associations between objects ?
>
>>Going over the board with genericity
>>in prevision of changes that are barely previsible is an easy mistake.
>
> Hear hear.
>
>>Hmmm... The fact is that we *also* have to deal with hierarchical data
>>structures, and relational algebra does not really shine here.
>
>
> Hmmmmmm. Is it really the *algebra* you think is crippled ?
AFAICT, yes. At least what I learned as being "algèbre relationnelle".
> What kind
> of operation do you think is unsupported by the algebra ?
I don't know how this translates in english, the french term is
"fermeture transitive d'un graphe". IOW, if I have (minimal example):
('menu1', NULL)
('menu1.1', 'menu1')
('menu1.2', 'menu1')
('menu1.2.1', 'menu1.2')
('menu2', NULL)
('menu2.1', 'menu2')
# etc...
How can I select menu1 and all it's childrens in a single operation ?
How can I select the 'root' for menu1.2.1 (which is 'menu1') in a single
operation ?
AFAIK, when you put this into a RDBMS, you need additional code - either
in "procedural SQL" or in the client app - to deal with this.
And this is only an homegenous hierarchy - what for heterogenous
hierarchies ? and moreover where some entities are not known at design
time (like provided by plugins) ?
NB : please understand this is not intended to demonstrate the
superiority of OO over RM (I just don't give a damn about this kind of
religion wars)- I'd really like to know how to handle this cleanly and
efficiently with a RDBMS without using stored procedures...
Bruno Desthuilliers
Only a psychopathological fanatic can be so desperatly unable to have a
reasonable, open-minded, hopefully constructive discussion.
fu2 alt.religion.simpsons
Bruno Desthuilliers
Ouf. At least we will now be able to continue this discussion without
your ineptias and insults. Glad to be in your killfile, bobby. Really.
Frans Bouma
Bruno Desthuilliers wrote:
> Frans Bouma wrote:
> > Bob Badour wrote:
> >
> (snip)
>
> > > The surest sign of a self-aggrandizing ignorant is the wanton use
> > > of the word 'paradigm' which has many meanings where for each
> > > meaning a better word exists.
> >
> >
> > so, all you want is just flame me. Cool, have fun, Bob.
>
>
> Frans, you should know better. Why are you wasting your time reading
> the ineptia of religious fanatics ?
As I'm relatively new to comp.object, I indeed didn't know this guy,
and when I arrived at that passage, I had my laughs but it was indeed
time to quit reading the post any longer.
I also didn't realize it was cross-posted to cdt, otherwise I wouldn't
evne bothered to reply. I respect database purists, it's a fascinating
field, however some fanatics surrounding it.. no thanks. (goes for all
areas btw: OO fanatics are as horrible to discuss with as well).
Bruno Desthuilliers
> (cross-post to cdt removed)
>
> Bruno Desthuilliers wrote:
>
>
>>Frans Bouma wrote:
>>
>>>Bob Badour wrote:
>>>
>>
>>(snip)
>>
>>
>>>>The surest sign of a self-aggrandizing ignorant is the wanton use
>>>>of the word 'paradigm' which has many meanings where for each
>>>>meaning a better word exists.
>>>
>>>
>>> so, all you want is just flame me. Cool, have fun, Bob.
>>
>>
>>Frans, you should know better. Why are you wasting your time reading
>>the ineptia of religious fanatics ?
>
>
> As I'm relatively new to comp.object, I indeed didn't know this guy,
You would have if you had read some recent flamewar involving c.object
and cdt...
Now as you may have understood, he's not from comp.object but from ctd.
Pity the poor newbies on ctd, they must have hard time dealing with such
a regular !-)
> and when I arrived at that passage, I had my laughs but it was indeed
> time to quit reading the post any longer.
>
> I also didn't realize it was cross-posted to cdt, otherwise I wouldn't
> evne bothered to reply. I respect database purists, it's a fascinating
> field, however some fanatics surrounding it.. no thanks. (goes for all
> areas btw: OO fanatics are as horrible to discuss with as well).
indeed. It's a total waste of time.
Kenneth Downs
> Bob Badour wrote:
>> Frans Bouma wrote:
>> > JOG wrote:
>> >
>> > > Well after a brief hiatus I have just ploughed through the whole
>> > > 800 posts of the OO vs RM thread. Some discouraging stuff indeed.
>> > > Over the last few years a study of database technology, helped
>> > > greatly by discussions in cdt, has educated my opinions
>> > > significantly, and perhaps my albeit slow progress can be
>> > > illuminative to others.
>> >
>> > Please also realize that in comp.databases*, a lot of people are
>> > die-hard database pundits who preach to implement everything of an
>> > application inside the DB, including BL.
>>
>> I assume BL=business logic. What, exactly, is your objection to using
>> predicate logic for dealing with logic? (Other than ignorance.)
>> Exactly what formalism do you propose that surpasses the predicate
>> calculus for dealing with logic?
>
> Oh dear, it was crossposted.
>
> I wasn't talking about predicate calculus, I was talking about a
> complete middle-tier business logic tier. But let's not go there, I
> don't want a discussion about that with people who think everything
> except perhaps the bare-bones gui should be inside an RDBMS system.
> let's agree to disagree on that, we just share different views on that
> topic.
>
Is there a rational basis for deciding where to put the logic?
If there is, then we are doing each other no favors by agreeing to disagree.
In fact if there is a rational basis for making the decision, and a person
refuses to engage the conversation, that person is admitting to a bias.
That's all still fine, we're human and we have biases, but another
admirable human quality is the ability to adjust our bias in the face of
facts.
So for instance I started life as a programmer. The first time I faced the
decision of where to put logic, I chose code for two reasons. First, code
is infinitely flexible so I thought I was preparing for any contigency.
Second, and this is very important, I was ignorant of what databases could
do.
As I learned more about databases I realized one day that they could deliver
what OO could only promise, the two P's of Permanance and Progress. I can
keep permanent that which is Good Enough, and I can progress and add new
things.
You can only get to this understanding if you know what modern DBMS servers
can do and if you thoroughly grasp the role of metadata.
Erwin
> asserting that Smalltalk is "a thousand times more strictly
> hierarchical" than Java etc ? I fail to understand about which
> hierarchies you're talking about here - class hierarchy or runtime
> associations between objects ?
I presume it must be "class hierarchies" because I fail to grasp what
is meant precisely by "runtime associations between objects".
> > Hmmmmmm. Is it really the *algebra* you think is crippled ?
> AFAICT, yes. At least what I learned as being "algèbre relationnelle".
> > What kind
> > of operation do you think is unsupported by the algebra ?
> I don't know how this translates in english, the french term is
> "fermeture transitive d'un graphe". IOW, if I have (minimal example):
That was exactly the answer I was expecting, and indeed you betray your
ignorance. The English term is "transitive closure", and the operator
has, bel et bien, been part of the *algebra* since I don't know when.
> AFAIK, when you put this into a RDBMS, you need additional code - either
> in "procedural SQL" or in the client app - to deal with this.
Yes, but SQL DBMSs are not R DBMSs. The lack of a closure operator *IN
SQL* should not be interpreted as a shortcoming of *the relational
model*, nor as one of the relational algebra. Doing so is, as Chris
Date puts it, criticizing the relational model for never having been
implemented properly.
> I'd really like to know how to handle this cleanly and
> efficiently with a RDBMS without using stored procedures...
Well, as I pointed out, in a *true* RDBMS, just invoke the closure
operator over your binary relation (that records the links between the
nodes). In an SQL DBMS, roll your own operator. So your criticism of
"not being able to handle hierarchies", is really a criticism of SQL,
not one of the relational algebra.
erk
> [...]
> - I started life as a procedural programmer.
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that my
> code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket
A little startling to read such a succinct summary of my own
professional progression! I appear to have finally acquired some sense,
and am actively pursuing further understanding of relational theory,
functional programming, proper type systems (Martin-Lof, Haley-Milner),
and practical formalisms (of which Alloy appears to be the best).
> OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
> dire and destructive artifice.
I've also found that even in places where it appears to exist, there
are better (relational) models of same. Perhaps not in every case, but
in most. Organizational structures and file systems are both examples
of "real" hierarchies for which hierarchical modles are in reality
insufficient for practical use.
> If one does not recognize this, one is
> etiher wholly uneducated (given that the battle between
> hierarchy/networks and a relationship based models occurred decades
> ago) or has not been involved in enough large scale OO projects. Yet
> still this turgid "chinese doll" approach prevails through Java, C++
> and the bastard child of them all, XML.
Bastard in all sense of the word.
> I still code via OO as I currently have no other preferable tools. And
> yes, I still absolutely take pride in my crafted generic OO designs.
> However I now don't waste precious time trying to perfect them, because
> I know they are by definition inflexible, brittle and flawed. So I make
> them lightweight and replacable, aware of the limitations of the
> neanderthal paradigm that we are currently lumped with.
I'd like to hear more about this - any examples of the
lightweight/replaceable? Sounds like you've essentially "encapsulated"
O-O?
> It really is amazing that IT as a field has so little to do with the
> study of 'Information', of its nature and how it ought be structured
> for optimal manipulation and integrity provision, and so much on a
> 'Technology' fetish.
>
> So apologies for the rant, but I find the current status quo very
> frustrating. I can only hope that this situation will change as the
> field matures and hierarchy-where it does not belong finally dies a
> long overdue death.
I echo all of your sentiments.
- erk
Dmitry A. Kazakov
>> What kind
>> of operation do you think is unsupported by the algebra ?
>
> I don't know how this translates in english, the french term is
> "fermeture transitive d'un graphe". IOW, if I have (minimal example):
Transitive closure of?
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
Bruno Desthuilliers
>>oh, really ? Could you please elaborate about what you mean when
>>asserting that Smalltalk is "a thousand times more strictly
>>hierarchical" than Java etc ? I fail to understand about which
>>hierarchies you're talking about here - class hierarchy or runtime
>>associations between objects ?
>
>
> I presume it must be "class hierarchies" because I fail to grasp what
> is meant precisely by "runtime associations between objects".
>
>
>>>Hmmmmmm. Is it really the *algebra* you think is crippled ?
>>
>>AFAICT, yes. At least what I learned as being "algèbre relationnelle".
>>
>>>What kind
>>>of operation do you think is unsupported by the algebra ?
>>
>>I don't know how this translates in english, the french term is
>>"fermeture transitive d'un graphe". IOW, if I have (minimal example):
>
>
> That was exactly the answer I was expecting,
Fine.
> and indeed you betray your
> ignorance.
Then blame my teachers for this. And all the litterature that keep on
saying RA can't do this.
> The English term is "transitive closure", and the operator
> has, bel et bien, been part of the *algebra* since I don't know when.
some link, please ? (not that I doubt your assertion, just want to stop
being ignorant)
>
>>AFAIK, when you put this into a RDBMS, you need additional code - either
>>in "procedural SQL" or in the client app - to deal with this.
>
>
> Yes, but SQL DBMSs are not R DBMSs.
<trolling>
And *this* was exactly the answer I was expecting !-)
</trolling>
> The lack of a closure operator *IN
> SQL* should not be interpreted as a shortcoming of *the relational
> model*, nor as one of the relational algebra. Doing so is, as Chris
> Date puts it, criticizing the relational model for never having been
> implemented properly.
Possibly. But from a very practical POV, I do have to deal with this
improper implementation.
>
>>I'd really like to know how to handle this cleanly and
>>efficiently with a RDBMS without using stored procedures...
>
> Well, as I pointed out, in a *true* RDBMS,
Where do I find one ?-)
> just invoke the closure
> operator over your binary relation (that records the links between the
> nodes). In an SQL DBMS, roll your own operator.
How ? With a stored procedure ? (else, any link welcome - I admit not
having read the *whole* PostgreSQL doc).
> So your criticism of
> "not being able to handle hierarchies", is really a criticism of SQL,
> not one of the relational algebra.
Granted. Now since I don't have any better implementation of the
relational model, I have to deal with the existing ones.
And FWIW, you didn't answer the question about heterogenous hierarchies.
Here again, if you know the solution, please feel free to share.
Bob Badour
> Bob Badour wrote:
>
>>Frans Bouma wrote:
>>
>>>JOG wrote:
>>>
>>>
>>>>Well after a brief hiatus I have just ploughed through the whole
>>>>800 posts of the OO vs RM thread. Some discouraging stuff indeed.
>>>>Over the last few years a study of database technology, helped
>>>>greatly by discussions in cdt, has educated my opinions
>>>>significantly, and perhaps my albeit slow progress can be
>>>>illuminative to others.
>>>
>>> Please also realize that in comp.databases*, a lot of people are
>>>die-hard database pundits who preach to implement everything of an
>>>application inside the DB, including BL.
>>
>>I assume BL=business logic. What, exactly, is your objection to using
>>predicate logic for dealing with logic? (Other than ignorance.)
>>Exactly what formalism do you propose that surpasses the predicate
>>calculus for dealing with logic?
>
> Oh dear, it was crossposted.
>
> I wasn't talking about predicate calculus, I was talking about a
> complete middle-tier business logic tier.
Logic is logic. You appeared to dismiss everyone knowledgeable about
data management as preachers who somehow mistakenly believe they know
something useful for dealing with business logic.
However, the data management world has a firm grasp of exactly how to
leverage the power of predicate logic for both integrity and
manipulation of data. Given an application that has data to manage and
an available data management system, I think one needs a very strong
argument for not using the latter for the former.
Your suggestion for a 'middle-tier business logic tier' says far more
about your own limitations and the limitations of the tools you prefer
than anything else. I suggest you demonstrate a profound lack of
imagination.
But let's not go there, I
> don't want a discussion about that with people who think everything
> except perhaps the bare-bones gui should be inside an RDBMS system.
> let's agree to disagree on that, we just share different views on that
> topic.
With all due respect, you are spreading ignorant misconception that is
likely to harm people. I see no reason to remain silent with my
disagreement while you habitually dismiss better science and better
mathematics with ad hominem. Refuse to learn all you want. But don't
encourage others to join you in your willful ignorance.
>>>>- I started life as a procedural programmer.
>>>>- I adopted OO and soon got the 'aha' click described by R.
>>>>Martin. - I spent years coding large OO projects, with
>>>>beautiful, elegant architectures.
>>>>- I spent further years practically gnawing my arm off attempting
>>>>to adapt my perfect OO designs as requirements inevitably shifted
>>>>and exceptions arose.
>>>>- I finally realised that my 'aha' was utterly illusionary, and
>>>>that my code, being OO, was inevitably and irrecovably imprisoned
>>>>in a hierarchical strait-jacket
>>>
>>> I don't know anything about you nor your projects, so I can't
>>>comment on the experiences you got if they're the result of OO or
>>>the result of applying OO wrong.
>>
>> From the little bit you write here, I know a lot about you. For
>>instance, you know little or nothing about higher-level abstractions,
>>the benefits of symmetric operations, the advantages of declarative
>>techniques over procedural techniques, robust type systems,
>>separation of concerns and probably a whole host of other fundamental
>>concepts.
>
> Which part of "So I can't comment on..." don't you understand?
If you cannot comment on it, why did you mention it in the first place?
Alluding to it the way you did is just an intellectually dishonest and
backhanded way of introducing an ad hominem argument.
"I don't know anything about you nor your parents, so I cannot comment
on the experiences you got if they're the result of random pairing of
recessives or the result of incestuous in-breeding." See what I mean?
>>Your speculation over JOG's limitations proves only your own.
>
> that's your interpretation
It's more than an interpretation. It's clearly evident from what you
wrote. The only thing preventing you from inferring it on your own is
your own ignorance--and by that I don't mean your ignorance of JOG or
his projects.
, I just wanted to formulate that what his
> experiences were could be the result of wrongly applied OOP
In other words, you wanted to dismiss what he said using ad hominem
because it is a lot easier than actually thinking and learning.
, which
> could perfectly be caused by his teammembers
Or could perfectly be caused by exactly what he ascribed it to. After
all, he was there. Do you suppose you have either greater intelligence
or greater experience of JOG's work? Don't you think either
presupposition would be remarkably arrogant?
, or by a skewed project
> description or whatever.
'Whatever' being anything as long as it lets you write sophistry to puff
yourself up while letting you off the hook from doing anything so
difficult as actually thinking.
>>I can comment on JOG--his experiences have nothing to do with a
>>misapplication of OO.
>
> That's great to know, it wasn't in the posting. Again, my goal wasn't
> to judge the poster's knowledge, just that it's perfectly possible to
> have bad experiences with OO like with any technology/method, and thus
> that could influence how you think about it.
I don't see how that lets you off the hook for being completely ignorant
of the fundamentals of your profession. Had you any grasp of those
fundamentals you would have simply taken JOG's post at face value
instead of replying with knee jerk sophistry.
>>> What I can say is that if you don't realize that <insert tech /
>>>paradigm here>
>>
>>The surest sign of a self-aggrandizing ignorant is the wanton use of
>>the word 'paradigm' which has many meanings where for each meaning a
>>better word exists.
>
> so, all you want is just flame me. Cool, have fun, Bob.
> FB
Sure, whatever.
Bob Badour
> Frans Bouma wrote:
>
>>Bob Badour wrote:
>
> (snip)
>
>>>The surest sign of a self-aggrandizing ignorant is the wanton use of
>>>the word 'paradigm' which has many meanings where for each meaning a
>>>better word exists.
>>
>> so, all you want is just flame me. Cool, have fun, Bob.
>
> Frans, you should know better. Why are you wasting your time reading the
> ineptia of religious fanatics ?
Has any OO proponent ever learned what sophistry is or why such
fallacious reasoning is unpersuasive to intelligent, educated people?
Bueller? Bueller?
David Cressey
"Bruno Desthuilliers" <on...@xiludom.gro> wrote in message
news:449bc19e$0$1683$626a...@news.free.fr...
> > multi-dimensional. OO textbooks like to use animals as an example.
>
> Alas...
>
> > They
> > like to build a polyphormic hierarchy like this:
> > Fish
> > - Shark
> > - Tunar
> > Bird
> > - Eagle
> > - Condor
> > Mammal
> > - Horse
> > - Dolphin
> > - Bat
> > This is the correct zooligical hierachy.
>
> Yes, and a very bad example of the use of subtyping in OO. Also, it
> somehow relies on the assumption that polymorphism is conditionned by
> class inheritance - which, while somehow the case with languages like
> Java, is not necessarily true for all OOPLs.
>
> > But what if there are features
> > (or behavior) that are common for all animals that can fly or that
> > lives in water?
There is an even worse problem with the above example. Since most of us are
not zoologists, we accept pretty much without question that a simple
hierarchy is sufficient to classify all animals. However, our superficial
understanding is conditioned on several assumptions that are way below the
surface.
One such assumption is common ancestry. One of the reasons horses, dolphins
and bats belong in the same category is that they have inheritaed some
common characteristics from a presumed common ancestor. That common
ancestor was presumable not the ancestor od all the eagles and condors.
However, zoologists are toying with the hypothesis that DNA from multiple
species can combine to give rise to a new species. If that turns out to be
the case, then the traditional tree of zoological taxonomy may have to be
replaced with some structure that accomodates multiple inheritance. This
makes the example a whole lot messier, t osay the least.
erk
> [snip]
> What I can say is that if you don't realize that <insert tech /
So technologies and paradigms are the same thing? Presumably a
"paradigm" (overloaded++) influences how we think about problems and/or
solutions, and is thus much more than just a "technology," which (I'm
assuming) is a means to an existing end. Paradigms, presumably, alter
the ends by our understanding of the domains involved.
> an executable solution to the problem you want to solve, that same
> tech/paradigm will sooner or later bite you because it will have
> limitations and shortcomings.
I disagree with this entire paragraph, and by way of explanation, will
quote Dijkstra: "A programming language is a tool that has profound
influence on our thinking habits." All languages are not created equal.
Turing equivalence, for such purposes, is essentially meaningless.
Some more, tangentially related:
"If you give someone Fortran, he has Fortran. If you give someone Lisp,
he has any language he pleases." - Guy L. Steele
"Object-oriented programming is an exceptionally bad idea which could
only have originated in California." - Edsger W. Dijkstra
"A programming language is low level when its programs require
attention to the irrelevant." Alan Perlis
"A language that doesn't affect the way you think about programming, is
not worth knowing. - Alan Perlis
"If our basic tool, the language in which we design and code our
programs, is also complicated, the language itself becomes part of the
problem rather than part of its solution. - C.A.R. Hoare [although I
disgree with his use of the word "tool," the rest of the thought is
accurate]
> True, a good example is a Math library in an OO language runtime
> library. It often is implemented as a library with static methods in
> one big class or several different classes without state nor specific
> type, just a vehicle to hold the static methods together.
>
> That doesn't mean OO sucks, it means for functional problems which can
> be appearing in any domain, it might be best to use a functional /
> procedural approach instead of an OO.
And how many programming problems are truly unique to the domain, and
not manifestations of a more general functional pattern? Sadly, I see
this in Java all too often - dozens of static methods thrown into
"Util" "classes", none of which are actually O-O at all, because Java
supports no top-level constructs other than classes. (Clearly other
languages can avoid this issue, but it illustrates the greater utility
of functions - witness CLOS in Lisp, as an example of objects done
right with hooks to meta-object operations.)
> The same applies to using OO-esk constructs in an procedural language.
Don't equate procedural and functional.
> What I can say is that often people are too blinded by the paradigm
> they use. Take for example Object oriented data-access.
What, pray tell, is "object oriented data-access"?
- erk
Bruno Desthuilliers
Oh, my. Just when I thought you had made me the favor of putting me in
your killfile...
But at least you made my day : hearing you talking about education is
somewhat surrealistic.
erk
> There's always SmallTalk, of course. Maybe you disagree, but I've
> heard more than one self-proclaimed OO-purist declare SmallTalk to be
> the only *true* OO language. And that alledgedly "one and only true OO
> language" is, to the best of my knowledge, a thousand times more
> strictly hierarchical than Java or C-with-any-suffix.
I don't know Smalltalk, but from those who do, it offers many
functional features as well - lexical closures, first-class functions,
and some others I can't recall offhand. These programmers told me that
those, as much as the O-O, are key to Smalltalk's power. There's none
of the bizarre and limiting division (class/function/primitive/...) in
languages like Java, and it's the higher-order operations that give
leverage to the O-O. So if Smalltalk is "pure O-O", perhaps it's the
fact that it supports some other "paradigms" (sorry) that gives it such
glowing reviews.
- Eric
Bob Badour
Donkeys, mules, horses and burros already demonstrate that. Retroviruses
incorporated into the germ lines of living organisms of differing
species make things wierd, but even without such incorporation,
cross-over diseases can cause different species to select for similar
genotypes and/or phenotypes.
Bruno Desthuilliers
Quite possible - I use Python instead of Smalltalk, but it does have all
this (ie, the somewhat functional parts) too, and that's a great part of
what make it so usable IMHO. Python is OO almost all the way down (no
'primitive' types, functions and classes are objects too etc), but while
you can't avoid *using* objects when programming in Python, nothing
forces you to actually use the class statement.
And objects are in no way tightly coupled to their classes - it's
perfectly legal to add/delete/replace attributes (including methods) on
a per-object basis,, to dynamically modify a class, to dynamically
create classes at runtime, or even to dynamically change the class of an
object (which can be tricky and happens to be of restricted practical
use, but still can be handy). I really don't feel like being "inevitably
and irrecovably imprisoned in a hierarchical strait-jacket", to quote
the OP.
queisser
> - I started life as a procedural programmer.
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that my
> hierarchical strait-jacket
>
I think a distinction between macro and micro-OO needs to be made. At a
macro level OO may be as good or bad as any other method of structuring
code. At a micro level OO works extremely well. Somewhere in the middle
there's a crossover point and it's not always clear where that point is.
Things like "devices" or "windows" or "customers" can be reasonable
classes in a hierarchy but at the top level things are not as clear.
> OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
> dire and destructive artifice.
Exactly, hierarchy where hierarchy exists.
All this, of course, is well known since the very early days of OO. It
just seems impossible to learn unless you go through the above-mentioned
stages.
Andrew
topmind
hierarchical. However, outside of hierarchies, OO tends to lose its
selling point. It is just a bunch of nodes (objects) with pointers to
link them up, a big graph. Relational offers the chance to bring
discipline to relationships. It may not be perfect, but better than
dealing with raw graphs.
Further, there is still plenty of room for the Big-Iron view of RDBMS
to change, adapt, and branch out. We have jillions of OOP and
procedural languages, but only one production relational language (SQL)
with any decent backing, for example. It is time for a relational
renaissance.
Perhaps it won't fully deliver on its promises either, but billions of
$ chased other fads and overdid them for the heck of it. What is one
more? There may not be any other path to betterment besides
experimentation.
-T-
Frans Bouma
yes.
> If there is, then we are doing each other no favors by agreeing to
> disagree. In fact if there is a rational basis for making the
> decision, and a person refuses to engage the conversation, that
> person is admitting to a bias. That's all still fine, we're human
> and we have biases, but another admirable human quality is the
> ability to adjust our bias in the face of facts.
Of course you can still disagree, because IMHO the rational choice of
where to put BL is based on which programming environment/language
suits the problem better. As SQL is a set-oriented language, it's thus
less suited for procedural tasks and vice versa: a procedural language
is less suited for set-oriented tasks.
So to opt for placing everything related to business logic in a
database system, you IMHO make the choice to pick SQL for tasks it's
not suited for (IMHO). Similar, if you move all set-oriented tasks
outside the BL and for example implement execution of predicates /
filters on in-memory data while SQL is more suitable for that.
However if you decide that's irrelevant, the discussion is moving
towards a different level IMHO and ends up where the previous versions
of this same discussion ended up.
> So for instance I started life as a programmer. The first time I
> faced the decision of where to put logic, I chose code for two
> reasons. First, code is infinitely flexible so I thought I was
> preparing for any contigency. Second, and this is very important, I
> was ignorant of what databases could do.
>
> As I learned more about databases I realized one day that they could
> deliver what OO could only promise, the two P's of Permanance and
> Progress. I can keep permanent that which is Good Enough, and I can
> progress and add new things.
>
> You can only get to this understanding if you know what modern DBMS
> servers can do and if you thoroughly grasp the role of metadata.
Sure, I won't deny the power of databases and what you can accomplish
with them. Though it's not a silver bullet, like nothing is in CS:
there are always situations where it 'could do what it's asked to do'
but it's not ideal (or far from ideal). If people argue there's no
reason NOT to place the BL ALWAYS in the rdbms, by definition they thus
argue that the rdbms IS a silver bullet for all BL problems, and I
don't see that.
But as I said, there are different views possible on the matter,
despite what some people might think (in whatever camp they might live).
Frans Bouma
> Frans Bouma wrote:
> > [snip]
> > What I can say is that if you don't realize that <insert tech /
> > paradigm here> is just a tool to get to the goal you want to
> > achieve:
>
> So technologies and paradigms are the same thing?
Ah, wordgames. You know what I meant.
> Presumably a
> "paradigm" (overloaded++) influences how we think about problems
> and/or solutions, and is thus much more than just a "technology,"
> which (I'm assuming) is a means to an existing end. Paradigms,
> presumably, alter the ends by our understanding of the domains
> involved.
That's great, I was more referring to the difference between OO and
procedural software development. But I'm not a native english speaker,
so I might have chosen the wrong word.
> > True, a good example is a Math library in an OO language runtime
> > library. It often is implemented as a library with static methods in
> > one big class or several different classes without state nor
> > specific type, just a vehicle to hold the static methods together.
> >
> > That doesn't mean OO sucks, it means for functional problems which
> > can be appearing in any domain, it might be best to use a
> > functional / procedural approach instead of an OO.
>
> And how many programming problems are truly unique to the domain, and
> not manifestations of a more general functional pattern? Sadly, I see
> this in Java all too often - dozens of static methods thrown into
> "Util" "classes", none of which are actually O-O at all, because Java
> supports no top-level constructs other than classes. (Clearly other
> languages can avoid this issue, but it illustrates the greater utility
> of functions - witness CLOS in Lisp, as an example of objects done
> right with hooks to meta-object operations.)
True. I also sometimes think that some OO languages should have more
flexible ways to implement things. A bad example perhaps is C++, which
offers you to write plain C and OO together, however OOP fanatics will
now butcher me by saying that C++ isn't a true OO language. ;)
> > The same applies to using OO-esk constructs in an procedural
> > language.
>
> Don't equate procedural and functional.
yeah, though were did I imply they were the same? isn't '/' implying a
choice? Or do you just want to argue because you had nothing better to
do?
> > What I can say is that often people are too blinded by the paradigm
> > they use. Take for example Object oriented data-access.
>
> What, pray tell, is "object oriented data-access"?
Why, on earth, don't you read up about the world outside your _R_DBMS
before replying? Like oh, OODBMS's ? (yes they do exist)
Aloha Kakuikanu
> AFAIK, when you put this into a RDBMS, you need additional code - either
> in "procedural SQL" or in the client app - to deal with this.
Modelling hierarchies in relational is an intersting topic:
http://www.google.com/search?hl=en&q=nested+sets&btnG=Google+Search
> And this is only an homegenous hierarchy - what for heterogenous
> hierarchies ? and moreover where some entities are not known at design
> time (like provided by plugins) ?
What is "heterogenous hierarchy". Another example of throwing fuzzy
terms?
Bob Badour
> erk wrote:
>
>>Frans Bouma wrote:
>>
>>>[snip]
>>> What I can say is that if you don't realize that <insert tech /
>>>paradigm here> is just a tool to get to the goal you want to
>>>achieve:
>>
>>So technologies and paradigms are the same thing?
>
> Ah, wordgames. You know what I meant.
With all due respect, Frans, do you even know what you said? Do you
expect the rest of us to read minds? Isn't it better to say exactly what
one means?
>>Presumably a
>>"paradigm" (overloaded++) influences how we think about problems
>>and/or solutions, and is thus much more than just a "technology,"
>>which (I'm assuming) is a means to an existing end. Paradigms,
>>presumably, alter the ends by our understanding of the domains
>>involved.
>
> That's great, I was more referring to the difference between OO and
> procedural software development.
OO is procedural thus there is no difference whatsoever in that respect.
But I'm not a native english speaker,
> so I might have chosen the wrong word.
Should we ignore the fact that native english speaking OO proponents
very often choose the same ambiguous word? Should we ignore the fact
that some other non-native english speakers seem to have an advantage
over native speakers for using the language precisely? Should we ignore
that even your clarification is meaningless?
If you are uncomfortable with your ability to use the language, why
would you venture so boldly into the realm of sophistry with it?
Are you suggesting you never intended to dismiss your betters as
'die-hard' 'preachers' ? Are you suggesting you never intended to
dismiss JOG's original post as a potential misapplication of something
good if only he had not misapplied it?
>>> What I can say is that often people are too blinded by the paradigm
>>>they use. Take for example Object oriented data-access.
>>
>>What, pray tell, is "object oriented data-access"?
>
> Why, on earth, don't you read up about the world outside your _R_DBMS
> before replying? Like oh, OODBMS's ? (yes they do exist)
Why, on earth, don't you read up on the fundamentals of your profession
so that you can recognize a fundamentally flawed network model dbms when
you see one--even when shrouded in nebulous marketing-speak.
Aloha Kakuikanu
> Things like "devices" or "windows" or "customers" can be reasonable
> classes in a hierarchy but at the top level things are not as clear.
I challenge the idea that customer is a usefull class. What kind of
methods does it have other than "getName" "setName" and alike?
Marshall
> >
> > Yes, but SQL DBMSs are not R DBMSs.
>
> <trolling>
> And *this* was exactly the answer I was expecting !-)
> </trolling>
Something that is often a source of misunderstanding in crossposted
threads is that comp.databases.theory is a *theory* newsgroup,
and we do not limit ourselves, (or sometimes, even concern ourselves)
with what products are out there today. Our concern is for theory,
and for what is possible. This is not to deny the existence of
practical concerns; rather it is to deny the exclusivity of practical
concerns.
In *theory* you just use the transitive closure operation. Does
this help you solve your practical problem today? Sorry, no.
(However, you may wish to check if the database product
you use does support some kind of transitive closure operation,
such as Oracle's CONNECT BY.)
Marshall
Gene Wirchenko
<knode.wa...@see.sigblock> wrote:
>fre...@gmail.com wrote:
>> I share the same experience too. Its a very unpleasant exerience to
>> finally realize that what you believed in for many years is just an
>> illusion. But I still think that there are some limited areas, such as
>> building collection classes (maps, lists, etc), embedded software or
>> GUI components, in which OO have some benefits.
>I've come to the same conclusion: OO is a really nifty GUI tool. In all
>other places (within context of biz software) it is disqualified for use by
>the KISS principle.
I have not found that to be so. My code was definitely moving
towards an OO-structure before I first worked with an OO language. I
like being able to define a framework (class) and selectively override
part. However, I do not go too many levels deep. I use OO to make
things clearer. OO is a useful hammer, but I also use screwdrivers
and wrenches.
Sincerely,
Gene Wirchenko
Aloha Kakuikanu
> Well, as I pointed out, in a *true* RDBMS, just invoke the closure
> operator over your binary relation (that records the links between the
> nodes). In an SQL DBMS, roll your own operator. So your criticism of
> "not being able to handle hierarchies", is really a criticism of SQL,
> not one of the relational algebra.
There is no transitive closure operator in the relational agebra*. This
operator has been added in ad-hock fashion. Furthermore, to say that
the area of hierarchical queies is well understood is a stretch.
Transitive closure is expressed naturally in datalog, but the quesion
is if datalog is really much better than SQL as a query language.
Anyway what are the alternative methods of handling hierarchies? It is
naive to think that pattern matching method of XQuery is in any way
superior to SQL even on its allegedly firm ground of hierarchical
navigation.
*) Which relational algebra? Transitive closure fits naturally into
Tarski algebra of binary relations, but that's another story.
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>
>>>Yes, but SQL DBMSs are not R DBMSs.
>>
>><trolling>
>>And *this* was exactly the answer I was expecting !-)
>></trolling>
>
>
> Something that is often a source of misunderstanding in crossposted
> threads is that comp.databases.theory is a *theory* newsgroup,
I'm aware of this - that's why I added a troll warning and a smiley.
> and we do not limit ourselves, (or sometimes, even concern ourselves)
> with what products are out there today. Our concern is for theory,
> and for what is possible. This is not to deny the existence of
> practical concerns; rather it is to deny the exclusivity of practical
> concerns.
<trolling-again>
but given that most comp.object readers are primarily concerned with
practical stuff, isn't it a bit unfair to argue about the superiority of
the relational model over OO when there's no working, usable
implementation of the relational model ?-)
</trolling-again>
Sorry, nitpicking here - don't waste your time answering to this.
> In *theory* you just use the transitive closure operation. Does
> this help you solve your practical problem today? Sorry, no.
Too bad.
> (However, you may wish to check if the database product
> you use does support some kind of transitive closure operation,
> such as Oracle's CONNECT BY.)
I'd prefer to stick to SQL standard as much as possible. I have a need
for solutions that can run on as many SQL DBMS as possible.
Dmitry A. Kazakov
> Bruno Desthuilliers wrote:
>>>
>>> Yes, but SQL DBMSs are not R DBMSs.
>>
>> <trolling>
>> And *this* was exactly the answer I was expecting !-)
>> </trolling>
>
> Something that is often a source of misunderstanding in crossposted
> threads is that comp.databases.theory is a *theory* newsgroup,
> and we do not limit ourselves, (or sometimes, even concern ourselves)
> with what products are out there today. Our concern is for theory,
> and for what is possible. This is not to deny the existence of
> practical concerns; rather it is to deny the exclusivity of practical
> concerns.
LOL!
> In *theory* you just use the transitive closure operation. Does
> this help you solve your practical problem today? Sorry, no.
> (However, you may wish to check if the database product
> you use does support some kind of transitive closure operation,
> such as Oracle's CONNECT BY.)
If we are done with transitive closure, well, so far theoretically, then
let's take a dual graph.
Dmitry A. Kazakov
Cancel_Project
Marshall
> Marshall wrote:
> >
> > Something that is often a source of misunderstanding in crossposted
> > threads is that comp.databases.theory is a *theory* newsgroup,
>
> but given that most comp.object readers are primarily concerned with
> practical stuff, isn't it a bit unfair to argue about the superiority of
> the relational model over OO when there's no working, usable
> implementation of the relational model ?-)
> </trolling-again>
But, but, but ...
> Sorry, nitpicking here - don't waste your time answering to this.
Oh, very well. :-)
Marshall
Alfredo Novoa
Bob Badour ha escrito:
> The surest sign of a self-aggrandizing ignorant is the wanton use of the
> word 'paradigm' which has many meanings where for each meaning a better
> word exists.
Bob, besides a self-aggrandizing ignorant he is a snake oil salesman.
LLBLGen Pro is crap.
Regards
Alfredo
Aloha Kakuikanu
Dmitry A. Kazakov wrote:
> On 23 Jun 2006 10:00:32 -0700, Aloha Kakuikanu wrote:
>
> > queisser wrote:
> >> Things like "devices" or "windows" or "customers" can be reasonable
> >> classes in a hierarchy but at the top level things are not as clear.
> >
> > I challenge the idea that customer is a usefull class. What kind of
> > methods does it have other than "getName" "setName" and alike?
>
> Cancel_Project
Order.cancel()? This is really about canceling a transaction. You have
to study transaction management in order to implement this
functionality correctly. Inheritance and polymorphish doesn't help
here, sorry.
fre...@gmail.com
Both.
> Yes, and a very bad example of the use of subtyping in OO.
In fact, subtyping have to be used extremly carefully if you don't want
to mess things up. It is a very inflexible tool.
> > But what if there are features
> > (or behavior) that are common for all animals that can fly or that
> > lives in water?
> What's your problem here exactly ?
The implementation might depend on multiple dimensions.
In a recent thread Robert Martin suggested a similar class hierachy:
Employee
- Salaried employee
- Hourly employee
- Commissioned employee
The Employee interface should have a calculatePayment method and the
subclasses should have different implementations.
This might look like a natural thing to do and it probably is while the
problem solution is small and not very complex. But imagine that
depending on what union branch the employee belongs too, the salary is
calculated differently in some aspectes. Now you have to repeat this
logic in all three implementations of calculatePayment. This is one
example of problem you will encounter when you start with on dimension
and later have to handle multiple dimensions.
> > Many business entities like bank accounts and employee
> > types, are almost impossible to classify in hierachies.
> Indeed - business rules are usually much less logical and 'universal'
> than scientific taxonomies !-)
Is it not about being logical or not, it is about being able to handle
multiple dimensions or not. (But I agree that many business rules are
unnecessary complex.)
Fredrik Bertilsson
http://frebe.php0h.com
vc
Bruno Desthuilliers wrote:
[...]
>. And all the litterature that keep on
> saying RA can't do this.
You are quite right that the RA (or the predicate logic of which the RA
is a dialect) cannot express transitive closure. It has to be extended
with some kind of the TC operator.
There is a standard (SQL'99) TC closure operator called 'recursive
query'. Both DB2 and SQL Server 2005 have it. Oracle has had the
proprietary 'connect by' since probably version 7. As far as I
remember, Postgress used to have a patch that implemented the Oracle
'connect by'.
Andrew McDonagh
Once again, Bob jumps in yet more dribble laced with smart-arsed
comments about someone's supposedly limited mind, thereby hiding the
parts of his post that actually are worthwhile reading...
Mind you, I got so bored looking for them, I gave up......
>
> What makes you think OO is the right tool for any job?
What makes you think its not right for any job?
erk
> erk wrote:
> Ah, wordgames. You know what I meant.
No, I don't. The difference is important. I'm not playing word games.
One can't "encapsulate" a "paradigm" behind a generic interface, the
way presumably you mean to imply one can with a "technology." But I'm
not certain what you mean.
> That's great, I was more referring to the difference between OO and
> procedural software development. But I'm not a native english speaker,
> so I might have chosen the wrong word.
No, I think you chose the right words. I've heard similar things from
native English speakers. I just don't think they make sense - at least,
they mix apples and fuel tankers.
> True. I also sometimes think that some OO languages should have more
> flexible ways to implement things. A bad example perhaps is C++, which
> offers you to write plain C and OO together, however OOP fanatics will
> now butcher me by saying that C++ isn't a true OO language. ;)
I like this line:
"C++: an octopus made by nailing extra legs onto a dog." - from
smalltalk.org
> > Don't equate procedural and functional.
> yeah, though were did I imply they were the same? isn't '/' implying a
> choice? Or do you just want to argue because you had nothing better to
> do?
"/" can mean different things - it is also commonly used to give 2
synonyms for the same concept. I wasn't trying to argue.
> > What, pray tell, is "object oriented data-access"?
>
> Why, on earth, don't you read up about the world outside your _R_DBMS
> before replying? Like oh, OODBMS's ? (yes they do exist)
I had no idea what you meant. Here are possible interpretations - you
can possibly understand my confusion:
1. accessing data in an object-oriented way
2. accessing object-oriented data
3. accessing data in an OODBMS
Besides that "data access" is something which begs the question. But
the above are all equally likely, and I was trying to clarify.
- Eric
erk
> Something that is often a source of misunderstanding in crossposted
> threads is that comp.databases.theory is a *theory* newsgroup,
> and we do not limit ourselves, (or sometimes, even concern ourselves)
> with what products are out there today. Our concern is for theory,
> and for what is possible. This is not to deny the existence of
> practical concerns; rather it is to deny the exclusivity of practical
> concerns.
>From an interview with Dijkstra
(http://www.cs.utexas.edu/users/EWD/misc/vanVlissingenInterview.html):
"What is nice from a theoretical point of view is usually eminently
useful, and what is a really good practical idea always has something
deep underlying it. And my fascination with the topic is that there is
a large area where the traditional distinctions between pure and
applied is meaningless. I always refuse to be called a pure computer
scientist if that implies that I am unpractical. I also refuse to be
called a practical computer scientist if that means that what I do is
theoretically shallow, or lousy."
- Eric
erk
> In fact, subtyping have to be used extremly carefully if you don't want
> to mess things up. It is a very inflexible tool.
Agreed - it's badly misunderstood, but is a poisonous pet even for the
wise. Among other things, it's frequently treated as an implementation
tool ("subclassing"), users ignore the need for subtypes to not
restrict the precondition but fully deliver the postcondition (the
former can be relaxed but not the latter)...
Mutation, of course, is a source of endless problems (hence the
Circle/Elipse debate when you "change" the x or y), but is largely
another variable/value debacle.
- erk
erk
> Quite possible - I use Python instead of Smalltalk, [...]
>
> And objects are in no way tightly coupled to their classes - it's
> perfectly legal to add/delete/replace attributes (including methods) on
> a per-object basis,, to dynamically modify a class, to dynamically
> create classes at runtime, or even to dynamically change the class of an
> object (which can be tricky and happens to be of restricted practical
> use, but still can be handy). I really don't feel like being "inevitably
> and irrecovably imprisoned in a hierarchical strait-jacket", to quote
> the OP.
Agreed. If you want to see the language Java should have been, if Sun
had the sense evolution gave a gnat, look at Nice. Of course, Lisp's
generics and CLOS and MOP offer even more, but Nice is... well, nice.
Which might be why it'll never take off, but we can dream.
- erk
kvnkr...@gmail.com
I don't think that was meant seriously...
erk
> I think a distinction between macro and micro-OO needs to be made. At a
> macro level OO may be as good or bad as any other method of structuring
> code.
I've found network of objects to be worse than most. The architectural
"components" you tend to write in decent O-O systems aren't really
objects at all in any normal sense; witness SOA, CORBA, etc. Those
aren't objects, and pretending they are (e.g. in Java where everything
has to be an object) is silly.
This criticism obviously doesn't apply to languages with multimethods
and functions as first-class entities.
> At a micro level OO works extremely well.
It's theoretically fine for implementing user-defined types, but is
notoriously brittle because of the common mistake of viewing them as
functional containers rather than types.
> Somewhere in the middle
> there's a crossover point and it's not always clear where that point is.
> Things like "devices" or "windows" or "customers" can be reasonable
> classes in a hierarchy but at the top level things are not as clear.
> > OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
> > dire and destructive artifice.
>
> Exactly, hierarchy where hierarchy exists.
We're creating systems, not trying to emulate reality (in which, by the
way, it's clear real hierarchies are rare). Emulating reality is
another phantasm conjured by O-O.
> All this, of course, is well known since the very early days of OO.
Perhaps, but those early days aren't taught; only the religion is (or
was - I see encouraging signs that things are changing).
> It just seems impossible to learn unless you go through the above-mentioned
> stages.
Maybe. It's discouraging to think this stuff can't be taught; perhaps
if industry and academia weren't so faddish, the teaching would
suffice.
- Eric
Neo
I agree. In cases where data is highly structured, representing them
with a RMDB provides many advantages. However in cases where data is
highly unstructured, representing them with a RMDB can also become more
difficult and starts to lose some of its advantages.
> There may not be any other path to betterment besides experimentation.
One result of such experimentation is db for dummies. It has a very
general method of representing things. In fact, the same basic method
is used to represent lists, tables, trees, graphs, networks, etc and
yet are navigable via high-level queries. Would someone be interested
in comparing the adv/disadv of RM vs dbd using the example posted at
www.dbfordummies.com/example/ex039.asp which models a food judging
contest. If that one is too simple, we can extend
www.dbfordummies.com/example/ex123.asp which models 10 computer
systems, each with different hardware configuration.
fre...@gmail.com
> this (ie, the somewhat functional parts) too, and that's a great part of
> what make it so usable IMHO. Python is OO almost all the way down (no
> 'primitive' types, functions and classes are objects too etc), but while
> you can't avoid *using* objects when programming in Python, nothing
> forces you to actually use the class statement.
I agree that Python is an excellt language, OO is availible but nothing
forces you to use it.
> And objects are in no way tightly coupled to their classes - it's
> perfectly legal to add/delete/replace attributes (including methods) on
> a per-object basis,, to dynamically modify a class, to dynamically
> create classes at runtime, or even to dynamically change the class of an
> object (which can be tricky and happens to be of restricted practical
> use, but still can be handy).
Or use JavaScript, no classes, only objects. And objects are nothing
else but a map. Perfect.
Fredrik Bertilsson
http://frebe.php0h.com
Marshall
What make a language successful is, I believe, not at all well
understood. It bears mentioning that Java is, by any objective
measure I can think of, just about the most successful progamming
language ever. Does it have significant theoretical shortcomings?
Sure, yes, definitely. What is hard is to understand is whether
Java's success is in spite of those shortcomings or because of
them! Are the lack of genericity (originally), the lack of default
parameters, operator overloading, and multiple inheritance, the
unsound-but-convenient covariant array types, etc., shortcomings
or useful simplification? Again, success is hard to pin down.
As to looking at languages extended from Java, I woud say
Nice is the second best out of hundreds. But the most
interesting one is Scala.
There are a million interesting thing to see in scala, and most
of them have greater or lesser amounts of theory behind them.
Unfortunately I think the bigest lesson I draw from scala is
the importance of simplicity, which it illustrates by not having.
Still: interesting.
Marshall
Aloha Kakuikanu
Which part of the snippet are you challenging? Aside of the fact that
I'm still waiting somebody to provide a nontivial member of the
Customer class. Not Project, and not Order.
Bob Badour
Arguably, it is the right tool for constructing large unpredictable
state machines out of small predictable state machines, which is the
task for which it was originally invented. However, even for expressing
simulations, I have found the relational model and predicate calculus
even more effective than OO.
For instance, I recently posted in c.d.t the bulk of a relational
solution for simulating simple digital circuits. I have previously
created a similar simulation using OO and the relational solution is
smaller, clearer and more elegant.
However, I seem to recall my question was directed at someone who
scoffed at the idea of using a data management system for managing data,
at predicate logic for handling logic, and at knowlegeable data
management professionals for allegedly being "die-hard" "preachers".
I suggest the onus lies on those who opt to forego the use of a data
management system for managing data to justify their decision. It's
certainly not the sort of thing any rational thinking person would
accept on the basis of some idiot's off-hand dismissal.
-CELKO-
Transitive closure of a graph.
There are better eways to model trees in SQL than an adjacency list.
Look up Nested Sets and get a copy of TREES & HIERATCHIES IN SQL.
Robert Martin
> OO is hierarchy.
I disagree. We learned that OO was not hiearchy in the early 90s. OO
is dynamic polymorpism directed towards the purpose of managing
dependencies.
--
Robert C. Martin (Uncle Bob) | email: uncl...@objectmentor.com
Object Mentor Inc. | blog: www.butunclebob.com
The Agile Transition Experts | web: www.objectmentor.com
800-338-6716 |
Robert Martin
> When the apostles of
> OO said, "forget everything you ever learned about programming", I tuned
> out.
It wasn't the apostles who said that; it was the acolytes.
Robert Martin
> After all OO started in the telecom industry
OO started in the NCC, during a study of Norwegian shipping. It went
through adolesence at Xerox Parc in a study of what the computers of
the future might be like. It had a separate, and very different,
adolesence in the telecom industry because of Bjarne Stroustrup. The
two adolescent strains have been trying to merge; but the C++ strain
has been dominating recently. However, the Smalltalk strain is gaining
ground in the guise of Ruby.
Bob Badour
Ooof! I agree. That would explain why the idiot uses sneaky backhanded
ad hominem and other sophistry in place of anything resembling
intelligence. Does he really think people are stupid enough to fall for
that shit? I wonder: Does that reflect something about his customers?
Rhetorical Aside:
Is honesty such a horrible thing to value? Is dishonesty such an
honorable thing to deserve defending? Are common human value systems as
perverse as they so often seem?
Christian Brunschen
Robert Martin <uncl...@objectmentor.com> wrote:
>OO started in the NCC, during a study of Norwegian shipping. It went
>through adolesence at Xerox Parc in a study of what the computers of
>the future might be like. It had a separate, and very different,
>adolesence in the telecom industry because of Bjarne Stroustrup. The
>two adolescent strains have been trying to merge; but the C++ strain
>has been dominating recently. However, the Smalltalk strain is gaining
>ground in the guise of Ruby.
.. and has in fact been quietly going strong in the shape of Objectve-C as
well.
// Christian Brunschen
Bob Badour
One wonders what point the idiot was trying to make by mentioning the
Norwegian Computing Center while not bothering to mention Simula or the
fact that Stroustrup was working on simulation too. Perhaps that was
snipped from the exerpt? Oh well, the question is not sufficiently
interesting to bother removing him from the twit-filter.
topmind
If we judge how good a tech tool is by popularity, then Visual Basic 1
thru 6 would score pretty high, but almost everyone agrees it is a
screwy language carrying a lot of historical baggage. Same with
MS-Windows versus OS/2, Linux, Mac, etc.
There are a lot of factors affecting popularity, being good is just one
of them.
-T-
Marshall
>
> One wonders what point the idiot was trying to make by mentioning the
> Norwegian Computing Center while not bothering to mention Simula or the
> fact that Stroustrup was working on simulation too. Perhaps that was
> snipped from the exerpt?
Norwegian Computing Center?! I thought they were talking about,
you know, NCC-1701 and all:
http://en.wikipedia.org/wiki/NCC_(Star_Trek)
Marshall
PS. Sorry.
Marshall
>
> There are a lot of factors affecting popularity, being good is just one
> of them.
Yes; that's what I was saying.
Marshall
topmind
Neo wrote:
> > As some are pointing out now, OOP designs to not have to be hierarchical. However, outside of hierarchies, OO tends to lose its selling point. It is just a bunch of nodes (objects) with pointers to link them up, a big graph.
>
> I agree. In cases where data is highly structured, representing them
> with a RMDB provides many advantages. However in cases where data is
> highly unstructured, representing them with a RMDB can also become more
> difficult and starts to lose some of its advantages.
I am not sure I agree with that. I will agree that existing RDBMS
brands make dynamism harder than it has to be, but that is only part of
the issue.
Unstructured *anything* is going to be a bit difficult to use with any
kind of automation. If "Name", "L_name", "Last_Name" are attributes all
mixed together, for example, it will be tough to do any kind of
coherant processing because a machine is not going to know that these
are perhaps the same thing or related.
One can dump everything into an "attribute table" if there is no
classification or "slot" for something, for example. Arbitrary graphs
with arbitrary attributes can be created using a couple of many-to-many
tables. If you really want a big blob of sloppy or
inconsistently-labelled stuff, relational can model such. (Many
on-server file systems I encounter are such messes, for example.
Perhaps this is why the likes of Google exist.)
However, I am not saying that relational is best for every structuring
need; just the majority of what I encounter in my domain.
-T-
Keith H Duggar
> On 2006-06-23 07:47:48 -0500, "David Cressey" <dcre...@verizon.net> said:
>
> > When the apostles of OO said, "forget everything you
> > ever learned about programming", I tuned out.
>
> It wasn't the apostles who said that; it was the acolytes.
Which are you Uncle Bob? And why haven't you answered my
questions about your definition of "field" among others?
Shouldn't a "mentor" be a little more responsive? The
questions seem fairly simple, can't you answer them?
-- Keith -- Fraud 6
Bob Badour
> Neo wrote:
>
>>>As some are pointing out now, OOP designs to not have to be hierarchical. However, outside of hierarchies, OO tends to lose its selling point. It is just a bunch of nodes (objects) with pointers to link them up, a big graph.
>>
>>I agree. In cases where data is highly structured, representing them
>>with a RMDB provides many advantages. However in cases where data is
>>highly unstructured, representing them with a RMDB can also become more
>>difficult and starts to lose some of its advantages.
>
> I am not sure I agree with that. I will agree that existing RDBMS
> brands make dynamism harder than it has to be, but that is only part of
> the issue.
>
> Unstructured *anything* is going to be a bit difficult to use with any
> kind of automation. If "Name", "L_name", "Last_Name" are attributes all
> mixed together, for example, it will be tough to do any kind of
> coherant processing because a machine is not going to know that these
> are perhaps the same thing or related.
As Fabian Pascal points out, information devoid of structure is noise.
Without structure, data can have no perceptable meaning.
> One can dump everything into an "attribute table" if there is no
> classification or "slot" for something, for example. Arbitrary graphs
> with arbitrary attributes can be created using a couple of many-to-many
> tables. If you really want a big blob of sloppy or
> inconsistently-labelled stuff, relational can model such. (Many
> on-server file systems I encounter are such messes, for example.
> Perhaps this is why the likes of Google exist.)
>
> However, I am not saying that relational is best for every structuring
> need; just the majority of what I encounter in my domain.
I think the focus on structure to the exclusion of manipulation is a
mistake. Presumably, if you think a different formalism sometimes
surpasses the relational model, the formalism must provide manipulation
as well as structure. What formalisms are you thinking of?
Marshall
>
> I think the focus on structure to the exclusion of manipulation is a
> mistake.
And yet, people make that mistake again and again and again.
The focus is on the easy part: structure. It is just like when
people get in to language design and focus almost entirely on
syntax, to the exclusion of the more important semantic issues.
It's kind of an elixir thing, isn't it? Focusing on the easy part
relieves you of the burden of thinking about the difficult
questions of integrity and manipulation. That must be a good
thing, right? I mean, if you had to come up with a query
mechanism that could handle arbitrary ad hoc queries
as simply as even SQL can, wouldn't that, like, totally
harsh the buzz you got from reintroducing nested
structures?
Marshall
Keith H Duggar
> Arguably, [OO] is the right tool for constructing large
> unpredictable state machines out of small predictable
> state machines, which is the task for which it was
> originally invented.
You know, strangely, the depth and importance of that
statement (and that fact) didn't truly hit me, even though
you have posted it before, until reading it just now.
> However, even for expressing simulations, I have found the
> relational model and predicate calculus even more
> effective than OO.
>
> For instance, I recently posted in c.d.t the bulk of a
> relational solution for simulating simple digital
> circuits. I have previously created a similar simulation
> using OO and the relational solution is smaller, clearer
> and more elegant.
Yes that was an interesting example and thank you again for
it. It was also when you taught me the phrase "expression
bias" which is helpful. I recall your code was essentially
Tutorial D. If one wanted to execute that code or deliver a
stand-alone app that executed it, what options would you
recommend?
Bob Badour
I don't know any of the purported implementations of Tutorial D well
enough to recommend any of them. To implement that example, one would
need a Tutorial D that supports subtypes and/or union types -- unless
one wanted to do anything as 'useless' as simulate a circuit of all NAND
gates or all NOR gates. ;)
Does Alphora still support subtypes? I thought I read somewhere they
abandoned some part of their type system.
Does Rel? I don't know.
Bob Badour
The appeal of OO just occured to me: Humans are good classifiers and
classifying is a skill humans develop very early. Further, it is a skill
that leads to very early positive reinforcers.
The problem is that programming, ie. applied mathematics, requires more
than putting the star shaped block through the star shaped hole.
Some humans never develop sufficient abstract reasoning to master basic
algebra or calculus. Those who do generally develop the skill much later
than the skill of classification.
Yes, I think you hit that nail on the head. People like to focus on
structure because structure is easy for humans, and humans are
conditioned to expect a reward for correct classification from a very
early age. If you get all the blocks inside the plastic ball, Mom gets
all excited and stuff, which I suppose makes humans feel all reassured
and stuff.
Keith H Duggar
> Robert Martin wrote:
> > JOG wrote:
> > > OO is hierarchy.
> >
> > I disagree. We learned that OO was not hiearchy in the
> > early 90s. OO is dynamic polymorpism directed towards
> > the purpose of managing dependencies.
>
Hehe... rather amusing given that morph = change and change
= dynamic. So it's redundant to say the least. It'd be neat
to see the mentor's (who refuses to answer two simple
questions I asked him) example of static polymorphism lol.
Anyhow, it should be obvious to almost anyone who has
implemented OOP that, as I said in a previous post:
... what JOG had in mind is that hierarchal methods are
often used to /define implementations/ of OO. For example
inheritance and composition.
Thus the /static/ structures of OO designs are often
hierarchal. The /dynamic/ structure of OO programs can
more generally be a network.
Neo
The term "highly unstructured" was a poor choice. Everything has a
structure. A neatly stacked deck of cards has structure. All of a
bomb's particles x microseconds after an explosion have a structure. I
think the term high variable structure may be better. In the example
which models 10 computer systems, each has a significantly different
structure. In such a case, RM begins to loses its advantages since the
data doesn't fit neatly in a few tables. Whether the data structure is
a list, tree, table, graph, network makes little difference to dbd as
it uses a very general method to represent/query them. If someone would
like model a few of the computer systems with an RMDB and run a few
basic queries, I think they might see that dbd brings more discipline
to highly variable relationships than RM does.
> However, I am not saying that relational is best for every structuring need; just the majority of what I encounter in my domain.
I agree that a more general method will typically be less efficient
than a less general method that is optimized for a certian
domain/scope. While RM is well suited for many common apps, it is not
as suitable for say AI-type apps where data structures are not only
highly variable but unknown in advance which makes a methodolgy where a
schema has to be updated, less practical.
Neo
I would be interested to see if SQL's queries are simpler for highly
variable data. Could someone post one equivalent to that in
www.dbfordummies.com/Example/Ex117.asp
This example models a real estate listing. It models a $200,000
single-family house with MLS# A2868Z. The house has 3 bedrooms. The
master bedroom is 25x30 and has biege Dupont carpet that was installed
1/1/2000. The second bedroom is 12x15 and has pink and purple carpet.
The third bedroom is 12x15 and has hardwood flooring that was installed
1/2/1990 and needs resurfacing. The house has 3 bathrooms. The master
bathroom has brass finished Moen faucets. The second is a hall bathroom
and the third a half bathroom. The house has a 2-car attached garage.
The house has 2 fireplaces, the first is made of brick and its hearth
is made of stone. The second fireplace is made of stone and its hearth
is made of stone also. The 15x20 kitchen has cork flooring and the
following appliances: a white Maytag dishwasher, an Amana electric
range, and a Sears side-by-side fridge that is brand new.
The example query (shown below) finds single-family listings that have
a bedroom with purple carpet and a kitchen with a Sears fridge.
(and (select single-family instance *)
(select * has (and (select bedroom instance *)
(select * has (and (select carpet instance *)
(select * color purple)))))
(select * has (and (select kitchen instance *)
(select * has (and (select fridge instance *)
(select * mfg sears))))))
If needed, more listing and queries can be added for comparison with
SQL.
Neo
I would be interested to see if SQL is simpler for the following dbd
example which represents a Food Judging Contest. There are three
persons. The first named john (aka johnathan) is a judge. The second
named john (aka johnny) is a contestant. The third whose name is
unknown is a spectator and his age is 28.
There are four food entries. The first is named leftOver1 which is soft
and spicy The second is named apple1 which is crunchy and sweet. The
third is named broccoli1 which is crunchy. The fourth is named tomato1
which is soft, sweet and sour.
Judge john likes leftOver1 and tomato1. Contestant john likes apple1
and tomato1. Spectator likes broccoli1 and tomato1. In addition, judge
john likes contestant john.
The end of the script has a number of queries. Details at
www.dbfordummies.com/Example/Ex039.asp
Aloha Kakuikanu
Keith H Duggar wrote:
> J M Davitt wrote:
> > Robert Martin wrote:
> > > JOG wrote:
> > > > OO is hierarchy.
> > >
> > > I disagree. We learned that OO was not hiearchy in the
> > > early 90s. OO is dynamic polymorpism directed towards
> > > the purpose of managing dependencies.
> >
> > Dynamic polymorphism? What's that?
>
> Hehe... rather amusing given that morph = change and change
> = dynamic.
Morph=form
topmind
> The appeal of OO just occured to me: Humans are good classifiers and
> classifying is a skill humans develop very early. Further, it is a skill
> that leads to very early positive reinforcers.
>
> The problem is that programming, ie. applied mathematics, requires more
> than putting the star shaped block through the star shaped hole.
>
> Some humans never develop sufficient abstract reasoning to master basic
> algebra or calculus. Those who do generally develop the skill much later
> than the skill of classification.
>
> Yes, I think you hit that nail on the head. People like to focus on
> structure because structure is easy for humans, and humans are
> conditioned to expect a reward for correct classification from a very
> early age. If you get all the blocks inside the plastic ball, Mom gets
> all excited and stuff, which I suppose makes humans feel all reassured
> and stuff.
I smell a market for Relational Balls(tm)
-T-
topmind
> > Focusing on the easy part relieves you of the burden of thinking about the difficult questions of integrity and manipulation. That must be a good thing, right? I mean, if you had to come up with a query mechanism that could handle arbitrary ad hoc queries as simply as even SQL can, wouldn't that, like, totally harsh the buzz you got from reintroducing nested structures?
>
> I would be interested to see if SQL's queries are simpler for highly
> variable data. Could someone post one equivalent to that in
> www.dbfordummies.com/Example/Ex117.asp
>
> This example models a real estate listing. It models a $200,000
> single-family house with MLS# A2868Z. The house has 3 bedrooms. The
> master bedroom is 25x30 and has biege Dupont carpet that was installed
> 1/1/2000. The second bedroom is 12x15 and has pink and purple carpet.
> The third bedroom is 12x15 and has hardwood flooring that was installed
> 1/2/1990 and needs resurfacing. The house has 3 bathrooms. The master
> bathroom has brass finished Moen faucets. The second is a hall bathroom
> and the third a half bathroom. The house has a 2-car attached garage.
> The house has 2 fireplaces, the first is made of brick and its hearth
> is made of stone. The second fireplace is made of stone and its hearth
> is made of stone also. The 15x20 kitchen has cork flooring and the
> following appliances: a white Maytag dishwasher, an Amana electric
> range, and a Sears side-by-side fridge that is brand new.
>
> The example query (shown below) finds single-family listings that have
> a bedroom with purple carpet and a kitchen with a Sears fridge.
SELECT * FROM houses
WHERE houseType="single family"
AND houseID in
(SELECT houseID FROM rooms WHERE carpetColor="purple")
AND houseID in (SELECT houseID FROM furniture
WHERE furnitureType="fridge" AND brand="Sears")
There may be a better way to do it with joins instead of IN. Note that
I am assuming that the fridge can be anywhere in the house. People
often put a 2nd fridge in their garage. In practice I would double
check with the customer/requestor. Adding kitchen-only would add
another clause or join to the query. Actually, I wonder how your query
would look if the fridge could be in any room.
By the way, do any real-estate listings really track fridges?
>
> (and (select single-family instance *)
> (select * has (and (select bedroom instance *)
> (select * has (and (select carpet instance *)
> (select * color purple)))))
> (select * has (and (select kitchen instance *)
> (select * has (and (select fridge instance *)
> (select * mfg sears))))))
>
> If needed, more listing and queries can be added for comparison with
> SQL.
Most of your allegedly tough examples are based on physical modeling.
Whether SQL stinks at physical modeling I won't really venture due to
lack of experience in that domain. Some CAD experts once claimed
relational does have performance problems in CAD.
-t-
topmind
Neo wrote:
> > However, I am not saying that relational is best for every structuring need; just the majority of what I encounter in my domain.
>
> I agree that a more general method will typically be less efficient
> than a less general method that is optimized for a certian
> domain/scope. While RM is well suited for many common apps, it is not
> as suitable for say AI-type apps where data structures are not only
> highly variable but unknown in advance which makes a methodolgy where a
> schema has to be updated, less practical.
AI?
Our very *brain* can be modelled more or less with a "static schema", I
would note:
table: Links
=================
sourceNode_ID
destinationNode_ID
weight // weighting factor, can be negative in some models
table: Node
===============
node_ID
activationFuncIndicator // see note
activationWeight // the "volume" given to activation function
There are about 5 activation functions in common use: unit_step,
sigmoid, piecewise_linear, gaussian, and identity. (I haven't reviewed
my schema model closely, so buyer beware. This model allows "Y splits",
which real neurons don't directly allow IIRC, but can be modeled with
explicit neurons such that they are still interchangable.)
-T-
Keith H Duggar
> Keith H Duggar wrote:
> > Hehe... rather amusing given that morph = change and change
> > = dynamic.
>
> Morph=form
http://dictionary.reference.com/browse/morph
Be sure to read the definition of the verb form. And stop
quibbling with a jest (ie "Hehe... rather amusing ..."). At
least not with such a minimal and obvious post :-)
It was meant to be ironic since the double meaning of morph
parallels the multiple meanings of polymorphism. IOW, it is
polymorphism period not "dynamic polymorphism" that "OO is".
All of static, dynamic, and dynamic implementation of static
polymorphism are key concepts in OO. Uncle Bob the /mentor/
decided to declare only "dynamic polymorphism" "OO is" and
that I found amusing.
mAsterdam
> ... Everything has a structure.
> A neatly stacked deck of cards has structure. All of a bomb's
> particles x microseconds after an explosion have a structure.
> I think the term high variable structure may be better.
The purpose of structure is to support substance.
In varying the structure care must be taken to
either
have the substance temporarily supported
by another structure while the original structure
undergoes change
or
limit the changes to the structure to those
which do not break the support.
So yes, better, but the vocabulary is still in need
of much improvement. No, I have no reference.
If someone would provide one I'd be as
happy as you (should be) :-)
Nick Malik [Microsoft]
nothing that contributes to anything. You blast someone's pet idea without
offering anything in return. Then you sit back and watch the flames fly.
Cudos.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"JOG" <j...@cs.nott.ac.uk> wrote in message
news:1151026488.3...@m73g2000cwd.googlegroups.com...
> Well after a brief hiatus I have just ploughed through the whole 800
> posts of the OO vs RM thread. Some discouraging stuff indeed. Over the
> last few years a study of database technology, helped greatly by
> discussions in cdt, has educated my opinions significantly, and perhaps
> my albeit slow progress can be illuminative to others.
>
> - I started life as a procedural programmer.
> - I adopted OO and soon got the 'aha' click described by R. Martin.
> - I spent years coding large OO projects, with beautiful, elegant
> architectures.
> - I spent further years practically gnawing my arm off attempting to
> adapt my perfect OO designs as requirements inevitably shifted and
> exceptions arose.
> - I finally realised that my 'aha' was utterly illusionary, and that my
> code, being OO, was inevitably and irrecovably imprisoned in a
> hierarchical strait-jacket
>
> OO is hierarchy. Enforcing a hierarchy where none exists is an utterly
> dire and destructive artifice. If one does not recognize this, one is
> etiher wholly uneducated (given that the battle between
> hierarchy/networks and a relationship based models occurred decades
> ago) or has not been involved in enough large scale OO projects. Yet
> still this turgid "chinese doll" approach prevails through Java, C++
> and the bastard child of them all, XML.
>
> I still code via OO as I currently have no other preferable tools. And
> yes, I still absolutely take pride in my crafted generic OO designs.
> However I now don't waste precious time trying to perfect them, because
> I know they are by definition inflexible, brittle and flawed. So I make
> them lightweight and replacable, aware of the limitations of the
> neanderthal paradigm that we are currently lumped with.
>
> It really is amazing that IT as a field has so little to do with the
> study of 'Information', of its nature and how it ought be structured
> for optimal manipulation and integrity provision, and so much on a
> 'Technology' fetish.
>
> So apologies for the rant, but I find the current status quo very
> frustrating. I can only hope that this situation will change as the
> field matures and hierarchy-where it does not belong finally dies a
> long overdue death.
>