f



What databases have taught me

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.

0
jog (83)
6/23/2006 1:34:48 AM
comp.object 3218 articles. 1 followers. Post Follow

508 Replies
1769 Views

Similar Articles

[PageSpeed] 34

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.
> 

Seems quite a rational recount to me.  Sometimes the flip side is people 
trying to make a dbms look like an OO system too, I've even seen AI 
being tried.  When the tools are crap, it takes guts to implement the 
minimum requirement.

p
0
paul
6/23/2006 1:47:10 AM
JOG wrote:

> - 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)
0
6/23/2006 2:26:55 AM
> OO is hierarchy.

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?

0
neo55592 (356)
6/23/2006 2:51:08 AM
JOG wrote:
>
> - 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

0
6/23/2006 2:59:21 AM
JOG wrote:
[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

0
duggar (292)
6/23/2006 3:01:08 AM
> > OO is hierarchy.
>
> 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
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".

0
neo55592 (356)
6/23/2006 3:34:17 AM
Neo wrote:
> > > 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
> trying to saying ... The statement seems confusing as it
> 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.

-- Keith -- Fraud 6

0
duggar (292)
6/23/2006 4:12:03 AM
> > > OO is hierarchy.
> >
> > 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
> say. 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".

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.

0
neo55592 (356)
6/23/2006 4:17:44 AM
> - 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.

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

0
frebe73 (444)
6/23/2006 6:57:56 AM
frebe73@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.
Then you mix AOP in it ;)

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
0
j_simon (16)
6/23/2006 8:51:59 AM
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 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#) 
------------------------------------------------------------------------
0
6/23/2006 9:54:02 AM
"Keith H Duggar"  wrote:

> 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?

You mean something ultralite like this:
http://www.ianywhere.com/developer/product_manuals/sqlanywhere/0902/en/html/index.html



0
x
6/23/2006 9:56:45 AM
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.
> 
> - 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 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 9:58:33 AM
frebe73@gmail.com wrote:
>>- 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
-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 10:25:33 AM
Bruno Desthuilliers wrote:
> frebe73@gmail.com wrote:
> 
>>>- 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 ?

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.
0
bbadour (434)
6/23/2006 11:32:15 AM
frebe73@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.

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
0
6/23/2006 11:48:27 AM
Marshall wrote:

> JOG wrote:
>>
>> - 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.
> 
> 

Where did this lead you to Marshall?  Can you give your "elevator speech"
about how you develop now in your post-OO mindset?

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
0
6/23/2006 11:51:08 AM
> May I ask 2 questions here ?
> 1/
> 2/
> 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.

0
e.smout (9)
6/23/2006 12:17:21 PM
"Marshall" <marshall.spight@gmail.com> wrote in message
news:1151031561.833094.70320@c74g2000cwc.googlegroups.com...
> JOG wrote:
> >
> > - 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
>

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.





0
dcressey (35)
6/23/2006 12:47:48 PM
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?


>>- 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?
0
bbadour (434)
6/23/2006 1:07:06 PM
Bruno Desthuilliers wrote:

> 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.
0
bbadour (434)
6/23/2006 1:10:27 PM
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.

> > > - 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
0
6/23/2006 1:40:00 PM
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.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 2:02:08 PM
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 ?

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 2:05:01 PM
Bruno Desthuilliers wrote:

> 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.
0
bbadour (434)
6/23/2006 2:25:48 PM
Erwin wrote:
>>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
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 2:31:02 PM
Bob Badour wrote:
> Bruno Desthuilliers wrote:
> 
>> 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.

Only a psychopathological fanatic can be so desperatly unable to have a
reasonable, open-minded, hopefully constructive discussion.

fu2 alt.religion.simpsons

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 2:38:38 PM
Bob Badour wrote:
> Bruno Desthuilliers wrote:
> 
>> 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.

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.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 2:41:01 PM
(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,
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).

		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#) 
------------------------------------------------------------------------
0
6/23/2006 2:46:28 PM
Frans Bouma wrote:

> 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. 

-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
0
6/23/2006 2:51:50 PM
Frans Bouma wrote:
> (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.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 2:54:30 PM
> 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=E8bre 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.

0
e.smout (9)
6/23/2006 2:56:04 PM
JOG wrote:
> [...]
> - 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

0
eric.kaun (62)
6/23/2006 3:00:37 PM
On Fri, 23 Jun 2006 16:31:02 +0200, Bruno Desthuilliers wrote:

>> 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
0
mailbox2 (6357)
6/23/2006 3:01:17 PM
Erwin wrote:
>>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.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 3:10:25 PM
Frans Bouma wrote:

> 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.
0
bbadour (434)
6/23/2006 3:13:02 PM
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 ?

Has any OO proponent ever learned what sophistry is or why such 
fallacious reasoning is unpersuasive to intelligent, educated people?

Bueller? Bueller?
0
bbadour (434)
6/23/2006 3:14:51 PM
"Bruno Desthuilliers" <onurb@xiludom.gro> wrote in message
news:449bc19e$0$1683$626a54ce@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.





0
dcressey (35)
6/23/2006 3:17:20 PM
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? 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

0
eric.kaun (62)
6/23/2006 3:18:55 PM
Bob Badour wrote:
> 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 ?
> 
> 
> Has any OO proponent ever learned what sophistry is or why such
> fallacious reasoning is unpersuasive to intelligent, educated people?

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.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 3:23:07 PM
Erwin wrote:
> 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

0
eric.kaun (62)
6/23/2006 3:25:04 PM
David Cressey wrote:

> "Bruno Desthuilliers" <onurb@xiludom.gro> wrote in message
> news:449bc19e$0$1683$626a54ce@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.

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.
0
bbadour (434)
6/23/2006 3:34:42 PM
[changed followup to comp.database.theory-- I have crosspost fatigue.]

Kenneth Downs wrote:
> Marshall wrote:
>
> > JOG wrote:
> >>
> >> - 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.
> >
>
> Where did this lead you to Marshall?  Can you give your "elevator speech"
> about how you develop now in your post-OO mindset?

Sure.

I was hanging out with a guy at work, during a period where I was
still pretty much a Java bigot. When I would assert this or that
about how great Java was, he'd write a proof on a whiteboard
of some aspect of it being unsound. A proof!

After getting interested in programming languages, I started
reading about as many as I could find. Haskell, SML, O'Caml,
prolog, lisp, J, K, Sather, Eiffel, scheme, ruby, python, erlang,
epigram, etc.

Reading about Haskell, I came across the page that compares
the C version of the quicksort function to the Haskell one. That
blew my mind! I knew about using the RM in a declarative
way, but I had no idea that *code* could be so declarative.

Of the various languages, the family that impressed me the
most was the functional family, specifically Haskell and SML.
These are languages that actually have a formal basis,
rather than just a prose spec. The also emphasize a purely
functional style of coding. That is, functions are real
mathematical functions, in that their return value depends
only on their paramaters. Also, these languages emphasize
the use of higher-order functions, which are functions
that take functions as parameters and/or return functions
as results.

Now, I still program in Java, because it's what I'm most
familiar with, and because it's not too bad, and because
the tools for it are great. But I use a very different style
than I have in the past.

Every possible class that can be a value class, is.
That is, the class is parameterized only in the constructor;
there are no mutators or setters; every field is final.

I make much larger use of tiny objects as if they
were functions. I might have a one-method interface,
and dozens of one-method objects that implement that
interface. Then I use them in a functional style.
(For a while I was using anonymous classes for this,
but the debugging support for anonymous classes
is bad, so I started giving these classes a
semi-gratuitous name.)

I make only a little use of inheritance, mostly as a
way to facilitate polymorphism.

What I *dream* of, though, is a language that will have
built-in, both the functional facilities of a languages like
SML and the relational algebra, together. Since no one
seems to be working on this, I'm toying with it myself.


Marshall

0
Marshall
6/23/2006 3:37:03 PM
erk wrote:
> Erwin wrote:
> 
>>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.

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.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 3:41:40 PM
Bob Badour wrote:
>
> 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.

I never fully understood Bob's favorite "elixer" quote until the recent
crosspost thread with comp.object. Sure, it means that the OOP
stuff is fuzzy, but what else? There's another force at work.

You can think hard thoughts, or you can think easy thoughts.
Easy thoughts are so much easier! One can get in to a state
where one is faced with a choice between formalism, which
is hard, and fuzziness, which is easy. If one picks the easy
path, one is *relieved* of the necessity of doing hard work.
Life appears superficially better. And you have the added
bonus that, if everyone around you lacks any kind of formalism,
no one can prove anything you say wrong.

It really isn't so much an elixer as it is an opiate.


Marshall

0
Marshall
6/23/2006 3:45:18 PM
JOG wrote:
> - 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 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
0
6/23/2006 3:47:21 PM
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. 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-

0
topmind (2124)
6/23/2006 3:53:00 PM
Kenneth Downs wrote:

> Frans Bouma wrote:
> > 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?

	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).

		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#) 
------------------------------------------------------------------------
0
6/23/2006 4:07:59 PM
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.

> 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)

		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#) 
------------------------------------------------------------------------
0
6/23/2006 4:21:24 PM
Bruno Desthuilliers wrote:
> 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?

0
6/23/2006 4:39:59 PM
Frans Bouma wrote:

> 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.
0
bbadour (434)
6/23/2006 4:54:08 PM
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?

0
6/23/2006 5:00:32 PM
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.

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

0
6/23/2006 5:00:51 PM
On Fri, 23 Jun 2006 07:48:27 -0400, Kenneth Downs
<knode.wants.this@see.sigblock> wrote:

>frebe73@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

0
genew2268 (34)
6/23/2006 5:17:53 PM
Erwin wrote:
> 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.

0
6/23/2006 5:22:28 PM
Marshall wrote:
> 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.



-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/23/2006 5:36:46 PM
On 23 Jun 2006 10:00:51 -0700, Marshall wrote:

> 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.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/23/2006 5:52:34 PM
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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/23/2006 5:56:44 PM
Bruno Desthuilliers wrote:
> Marshall wrote:
> >
> > Something that is often a source of misunderstanding in crossposted
> > threads is that comp.databases.theory is a *theory* newsgroup,
>
> <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>

But, but, but ...


> Sorry, nitpicking here - don't waste your time answering to this.

Oh, very well. :-)


Marshall

0
6/23/2006 5:59:44 PM
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

0
alfredono (16)
6/23/2006 6:10:10 PM
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.

0
6/23/2006 6:10:25 PM
> So, is it a problem with OO, or a problem with how OO is used ?

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

0
frebe73 (444)
6/23/2006 6:29:40 PM
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'.

> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in 'onurb@xiludom.gro'.split('@')])"

0
boston103 (240)
6/23/2006 6:46:09 PM
Bob Badour wrote:

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?
0
news261 (167)
6/23/2006 6:54:05 PM
Frans Bouma wrote:
> erk wrote:
> > So technologies and paradigms are the same thing?
> 	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

0
eric.kaun (62)
6/23/2006 7:10:33 PM
Marshall wrote:
> 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

0
eric.kaun (62)
6/23/2006 7:20:06 PM
frebe73@gmail.com wrote:
> 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

0
eric.kaun (62)
6/23/2006 7:28:12 PM
Bruno Desthuilliers wrote:
> 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

0
eric.kaun (62)
6/23/2006 7:31:14 PM
Aloha Kakuikanu wrote:
> 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.

I don't think that was meant seriously...

0
6/23/2006 7:41:06 PM
queisser wrote:
> 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

0
eric.kaun (62)
6/23/2006 7:44:49 PM
> 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.

> 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.

0
neo55592 (356)
6/23/2006 7:53:54 PM
> 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.

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

0
frebe73 (444)
6/23/2006 7:56:19 PM
erk wrote:
> Bruno Desthuilliers wrote:
> > 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.

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.

http://scala.epfl.ch/

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

0
6/23/2006 8:17:25 PM
kvnkrkptrck@gmail.com wrote:
> Aloha Kakuikanu wrote:
> > 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.
>
> I don't think that was meant seriously...

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.

0
6/23/2006 8:28:01 PM
Andrew McDonagh wrote:
> Bob Badour wrote:
> 
> 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?

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.
0
bbadour (434)
6/23/2006 8:35:45 PM
>> "fermeture transitive d'un graphe". <,

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.

0
jcelko212 (1247)
6/23/2006 9:20:30 PM
On 2006-06-22 20:34:48 -0500, "JOG" <jog@cs.nott.ac.uk> said:

> 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: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/23/2006 9:56:01 PM
On 2006-06-23 07:47:48 -0500, "David Cressey" <dcressey@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.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/23/2006 9:59:17 PM
On 2006-06-23 01:57:56 -0500, frebe73@gmail.com said:

> 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.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/23/2006 10:03:09 PM
Alfredo Novoa wrote:

> 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.

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?
0
bbadour (434)
6/23/2006 10:03:21 PM
Marshall wrote:

Alas, i have to mark this as unread and come back to it when i return from
vacation, but thanks for the reply!
-- 
Kenneth Downs
Secure Data Software, Inc.
(Ken)nneth@(Sec)ure(Dat)a(.com)
0
Kenneth
6/23/2006 10:09:31 PM
In article <2006062317030938165-unclebob@objectmentorcom>,
Robert Martin  <unclebob@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
0
cb5180 (38)
6/23/2006 10:14:19 PM
Christian Brunschen wrote:

> In article <2006062317030938165-unclebob@objectmentorcom>,
> Robert Martin  <unclebob@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

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.
0
bbadour (434)
6/23/2006 10:19:46 PM
Marshall wrote:
> erk wrote:
> > Bruno Desthuilliers wrote:
> > > 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.
>
> 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.

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-

0
topmind (2124)
6/23/2006 10:47:49 PM
Bob Badour wrote:
>
> 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.

0
6/23/2006 10:56:35 PM
topmind wrote:
>
> There are a lot of factors affecting popularity, being good is just one
> of them.

Yes; that's what I was saying.


Marshall

0
6/23/2006 10:58:11 PM
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-

0
topmind (2124)
6/23/2006 11:04:21 PM
Marshall wrote:
> What I *dream* of, though, is a language that will have
> built-in, both the functional facilities of a languages
> like SML and the relational algebra, together. Since no
> one seems to be working on this, I'm toying with it
> myself.

Interesting. Since you still use Java have you taken a look
at Rel?

http://dbappbuilder.sourceforge.net/Rel.html

What are you thoughts on it? Also it seems there is some C#
effort/future of incorporating some relational operators
directly into the language:

http://weblogs.java.net/blog/javaben/archive/2005/09/c_30_relational.html

What are your thoughts on this? Have much progress have you
made in your toy language?

Do you know of any good Java or C++ libraries that simply
provide relation classes etc along with a relational
library?

-- Keith -- Fraud 6

0
Keith
6/23/2006 11:28:25 PM
Keith H Duggar wrote:
> http://dbappbuilder.sourceforge.net/Rel.html

Speaking of clumsy syntax, why

R WHERE x = 1 AND y = 2

and not

R AND x = 1 AND y = 2

?

0
Aloha
6/23/2006 11:36:09 PM
Robert Martin wrote:
> On 2006-06-23 07:47:48 -0500, "David Cressey" <dcressey@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?

http://groups.google.com/group/comp.object/browse_frm/thread/24dfa436896b15b9/58fe82352e2b0e9f?lnk=st&q=&rnum=2#58fe82352e2b0e9f

Shouldn't a "mentor" be a little more responsive? The
questions seem fairly simple, can't you answer them?

-- Keith -- Fraud 6

0
duggar (292)
6/23/2006 11:44:26 PM
Keith H Duggar wrote:

> Marshall wrote:
> 
>>What I *dream* of, though, is a language that will have
>>built-in, both the functional facilities of a languages
>>like SML and the relational algebra, together. Since no
>>one seems to be working on this, I'm toying with it
>>myself.
> 
> Interesting. Since you still use Java have you taken a look
> at Rel?
> 
> http://dbappbuilder.sourceforge.net/Rel.html
> 
> What are you thoughts on it? 

I know you asked Marshall and not me. I didn't understand some of the 
changes to the language like, for instance, the requirement for 
BEGIN/END for the WITH statement. A lot of the other additions seemed 
like syntactic candy that don't add functionality -- just complexity and 
language redundancy.
0
Bob
6/24/2006 12:51:30 AM
Aloha Kakuikanu wrote:

> Keith H Duggar wrote:
> 
>>http://dbappbuilder.sourceforge.net/Rel.html
> 
> 
> Speaking of clumsy syntax, why
> 
> R WHERE x = 1 AND y = 2
> 
> and not
> 
> R AND x = 1 AND y = 2
> 
> ?

Would (R AND x = 1 AND y = 2) = (x = 1 AND y = 2 AND R) ?

If so, wouldn't that make name resolution kinda complicated and perhaps 
error-prone?
0
Bob
6/24/2006 12:53:40 AM
topmind wrote:

> 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?
0
bbadour (434)
6/24/2006 12:58:31 AM
Bob Badour wrote:
> Aloha Kakuikanu wrote:
>
> > Keith H Duggar wrote:
> >
> >>http://dbappbuilder.sourceforge.net/Rel.html
> >
> >
> > Speaking of clumsy syntax, why
> >
> > R WHERE x = 1 AND y = 2
> >
> > and not
> >
> > R AND x = 1 AND y = 2
> >
> > ?
>
> Would (R AND x = 1 AND y = 2) = (x = 1 AND y = 2 AND R) ?

Yes

> If so, wouldn't that make name resolution kinda complicated and perhaps
> error-prone?

I'm not clear what do you mean by name resolution. The expression
appeals from sql optimization perspective: it's a join of 3 finite
relations. There are 6 join order permutations possible:

i). x = 1 join y = 2 join R
ii). x = 1 join R join y = 2
iii). x = 2 join R join y = 1
iv). x = 2 join y = 1 join R
v). R join y = 2 join x = 1
vi). R join y = 1 join x = 2

Evaluate cost of each and execute the one with lowest cost!

>From application programer perspective whenever I rewrite SQL by
copying/pasting and rearranging  predicates the "WHERE" keyword is
always a source of bugs (those are admittedly minor problems easily
spotted, but still).

0
Aloha
6/24/2006 1:06:50 AM
Keith H Duggar wrote:
> Marshall wrote:
> > What I *dream* of, though, is a language that will have
> > built-in, both the functional facilities of a languages
> > like SML and the relational algebra, together. Since no
> > one seems to be working on this, I'm toying with it
> > myself.
>
> Interesting. Since you still use Java have you taken a look
> at Rel?
>
> http://dbappbuilder.sourceforge.net/Rel.html

I haven't taken a look at Rel, although I have read TTM several
times through. A while back I was trying to look at Alphora,
but I didn't get too far. It's not clear to me how much success
a for-pay language can get when it's competing with the likes
of python, java, ruby, gcc, etc., all free. I should probably look
at rel. What is the constraint system like? Transactions?


> What are you thoughts on it? Also it seems there is some C#
> effort/future of incorporating some relational operators
> directly into the language:
>
> http://weblogs.java.net/blog/javaben/archive/2005/09/c_30_relational.html

Yes, Linq is *fascinating*. The effort is very ambitious. I'm
quite impressed by the thinking behind it. However, it's as
complicated as an aircraft carrier, and I'm still firmly in
the KISS camp. Makes for great reading, though.


> What are your thoughts on this? Have much progress have you
> made in your toy language?

Well, some. Lots of thinking. A trial syntax. Some ambitious
ideas. There is an interpreter for it, but it's never fully functional,
as I keep changing my mind about important design decisions.
For example, a few months ago I ripped out default arguments
when I realized they broke associativity of natural join. :-(
Sadly, I'm not very good with formal methods yet, so I don't
have an operational semantics. But it's something I want to do.

Its primitive operators are those of the Tropaskho algebra:
natural join and inner union. The language is pretty much
just: those operators, scope and name binding, the type
system, the imperative commands, and a few bits of
miscellany, such as aggregates/group-by. High up on
the wanted-feature list is constraints and updatable views.
But the precise semantics of view updatability remain
elusive.

It might be ready for the light of day in a few years, or
never. I'm an extremely lazy and unproductive person. Also,
I have "daddy daddy" to contend with. As in, I'm straining
my poor brain to figure out how to implement closures,
and "daddy daddy come look at this picture I drew."
Which is cool in its own way, of course, but impedes
forward progress. Plus, you know, the full time job.


> Do you know of any good Java or C++ libraries that simply
> provide relation classes etc along with a relational
> library?

You'd think, wouldn't you, that such would be common, if not
actually part of the standard libraries. But no, I have nothing.


Marshall

0
Marshall
6/24/2006 1:31:22 AM
Bob Badour wrote:
> Keith H Duggar wrote:
> > Interesting. Since you still use Java have you taken a
> > look at Rel?
> >
> > http://dbappbuilder.sourceforge.net/Rel.html
> >
> > What are you thoughts on it?
>
> I know you asked Marshall and not me. I didn't understand
> some of the changes to the language like, for instance,
> the requirement for BEGIN/END for the WITH statement. A
> lot of the other additions seemed like syntactic candy
> that don't add functionality -- just complexity and
> language redundancy.

Oh I'm sorry, I never mean to exclude anyone from answering
any of my questions. Just the writing sometimes seems more
natural to me if directed towards a single person. Thank you
for your input.

I'm less curious about specific language designs and more
curious about I guess architecture and library issues. For
example Rel incorporates a complete DBMS implementation. And
the most recent experience I had with a DBMS (DB2) was using
the usual client/server architecture to submit queries while
most of the analytical computation was actually done in Java.

All that seems a little to heavy for what I want to do; that
is incorporate relational concepts and thinking into my tools
and simulations. I'm looking for a way to develop stand-alone
apps where the relational code operates directly on the data
structures used by the rest of the language. Something like
the C# example linked before or the Tutorial D examples some
have posted in c.d.t before. However, the "compiler" should
ultimately include only the DBMS functionality needed to
correctly implement the code rather than using a complete
black-box DBMS server.

For example, how much relational functionality could one
incorporate into say a C++ library with relation classes, RA
functions, etc without being a front-end for a full-blown
DBMS back-end? Anyone know of any such libraries?

Does it even make sense to talk about a relational language
compiler that does not link to a full-blown DBMS?

I think I'm failing to describe such needs using correct
relational and/or DBMS terminology. Am I making any sense?

-- Keith -- Fraud 6

0
Keith
6/24/2006 1:35:02 AM
Aloha Kakuikanu wrote:

> Bob Badour wrote:
> 
>>Aloha Kakuikanu wrote:
>>
>>
>>>Keith H Duggar wrote:
>>>
>>>
>>>>http://dbappbuilder.sourceforge.net/Rel.html
>>>
>>>
>>>Speaking of clumsy syntax, why
>>>
>>>R WHERE x = 1 AND y = 2
>>>
>>>and not
>>>
>>>R AND x = 1 AND y = 2
>>>
>>>?
>>
>>Would (R AND x = 1 AND y = 2) = (x = 1 AND y = 2 AND R) ?
> 
> 
> Yes
> 
> 
>>If so, wouldn't that make name resolution kinda complicated and perhaps
>>error-prone?
> 
> 
> I'm not clear what do you mean by name resolution. The expression
> appeals from sql optimization perspective: it's a join of 3 finite
> relations. There are 6 join order permutations possible:
> 
> i). x = 1 join y = 2 join R
> ii). x = 1 join R join y = 2
> iii). x = 2 join R join y = 1
> iv). x = 2 join y = 1 join R
> v). R join y = 2 join x = 1
> vi). R join y = 1 join x = 2
> 
> Evaluate cost of each and execute the one with lowest cost!

Consider:

Ra = Rb AND x = 1 AND y = 1

Where Ra and Rb are two relvars. Is that still a join? To what do x and 
y refer?

Consider:

R AND x = 1 AND y = 1

where R has no x attribute. Will that cause a compile-time error? Why or 
why not?
0
Bob
6/24/2006 1:36:07 AM
Bob Badour wrote:
>
> 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

0
6/24/2006 1:39:47 AM
Bob Badour wrote:
>
> Would (R AND x = 1 AND y = 2) = (x = 1 AND y = 2 AND R) ?

I'd think it would have to, wouldn't it? Assuming = binds with
higher precedence than AND in the above syntax, and assuming
AND is associative and commutative, which I would hope it
would be. It is in the Tropashko algebra.


> If so, wouldn't that make name resolution kinda complicated and perhaps
> error-prone?

I don't see any obvious complications to name resolution, but then
I might be mising what you're getting at. As to error-prone,
(assuming we are talking about the progammer writing the
above code) yes, it might be, especially at first. I would
expect to address that issue with coding conventions and
possibly syntactic support. It's hard to say how much of
an issue that will be without field experiece. (Which I don't
have with this question.)


Marshall

0
Marshall
6/24/2006 1:44:38 AM
Bob Badour wrote:
>
> Consider:
>
> Ra = Rb AND x = 1 AND y = 1
>
> Where Ra and Rb are two relvars. Is that still a join? To what do x and
> y refer?
>
> Consider:
>
> R AND x = 1 AND y = 1
>
> where R has no x attribute. Will that cause a compile-time error? Why or
> why not?

I may be short on context here; is this being asked against a
specific language (rel?) Because the answer will depends
on the language, of course.

At least for the second question, I'd expect that it wouldn't
be a compile time error, because AND is natural join, and
natural join has well-defined semantics when the two
relations have no attributes in common. (Cartesian product.)


Marshall

0
Marshall
6/24/2006 1:55:30 AM
Keith H Duggar wrote:
>
> Does it even make sense to talk about a relational language
> compiler that does not link to a full-blown DBMS?

Yes, absolutely! In fact, I would expect an idea language
would include an RDBMS in the library, and also include
ways to connect to various of the big industrial strength
ones. In fact, if you get the physical independence right,
you ought not have to edit your program to switch back
and forth; only startup options would change.


Marshall

0
Marshall
6/24/2006 1:59:27 AM
Bob Badour wrote :
> 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?

-- Keith -- Fraud 6

0
duggar (292)
6/24/2006 2:01:40 AM
Bob Badour wrote:
> Consider:
>
> Ra = Rb AND x = 1 AND y = 1
>
> Where Ra and Rb are two relvars. Is that still a join? To what do x and
> y refer?

There is ambiguity caused by multiple equality signs. Did you mean

(Ra = Rb) AND x = 1 AND y = 1

or

Ra := (Rb AND x = 1 AND y = 1)

The first interpretation is absurd since there is no equality operator
in relational algebra. In the second case there is no longer equality,
but assignment :=   (and I still keep the redundant brackets for
clarity).

> Consider:
>
> R AND x = 1 AND y = 1
>
> where R has no x attribute. Will that cause a compile-time error? Why or
> why not?

No. The cartesian product of

R AND y = 1

with

x = 1

is the EXTEND operator.

I realize that this kind of thinking would steer quite away from exact
Tutorial D semantics. BTW, only now I noticed that Tutorial D is
bastardised version of D&D "A" algebra. Of course, it may be argued
that the connection Tutorial D <--> "A" is better designed than  SQL
<--> RA, but this parallel is kind of ironic.

0
Aloha
6/24/2006 2:01:56 AM
Keith H Duggar wrote:

> Bob Badour wrote:
> 
>>Keith H Duggar wrote:
>>
>>>Interesting. Since you still use Java have you taken a
>>>look at Rel?
>>>
>>>http://dbappbuilder.sourceforge.net/Rel.html
>>>
>>>What are you thoughts on it?
>>
>>I know you asked Marshall and not me. I didn't understand
>>some of the changes to the language like, for instance,
>>the requirement for BEGIN/END for the WITH statement. A
>>lot of the other additions seemed like syntactic candy
>>that don't add functionality -- just complexity and
>>language redundancy.
> 
> 
> Oh I'm sorry, I never mean to exclude anyone from answering
> any of my questions. Just the writing sometimes seems more
> natural to me if directed towards a single person. Thank you
> for your input.
> 
> I'm less curious about specific language designs and more
> curious about I guess architecture and library issues. For
> example Rel incorporates a complete DBMS implementation. And
> the most recent experience I had with a DBMS (DB2) was using
> the usual client/server architecture to submit queries while
> most of the analytical computation was actually done in Java.
> 
> All that seems a little to heavy for what I want to do; that
> is incorporate relational concepts and thinking into my tools
> and simulations. I'm looking for a way to develop stand-alone
> apps where the relational code operates directly on the data
> structures used by the rest of the language. Something like
> the C# example linked before or the Tutorial D examples some
> have posted in c.d.t before. However, the "compiler" should
> ultimately include only the DBMS functionality needed to
> correctly implement the code rather than using a complete
> black-box DBMS server.
> 
> For example, how much relational functionality could one
> incorporate into say a C++ library with relation classes, RA
> functions, etc without being a front-end for a full-blown
> DBMS back-end? Anyone know of any such libraries?

I am not current on the state of the art with C++. When I was, it lacked 
sufficient support for generics to create really effective relational 
operations. Physical independence is somewhat anathema to C++ in any case.


> Does it even make sense to talk about a relational language
> compiler that does not link to a full-blown DBMS?

Yes and no. Static compilation has been around for a very long time; 
however, the focus in those products is still files on disk somewhere.

I get the impression that most people think of database management as 
follows:
=========
I have client computer over here where I run applications and it has no 
dbms.

I have a server or a distributed system of servers over there that have 
a dbms.
=========

I don't look at it that way.

I think the dbms necessarily includes the client computers as part of 
the system. I further think that physical independence requires the 
ability to specify that some of the internal processing for the dbms 
will happen on the client computers.

For a simulation, one can usually reproduce the entire simulation from 
some (possibly large) set of initial boundary conditions. Thus, 
simulations deal with relvars that need never get stored on disk and for 
performance reasons ought to always stay in memory or be minimally 
shared among a cluster of parallel computers as needed to complete the task.


> I think I'm failing to describe such needs using correct
> relational and/or DBMS terminology. Am I making any sense?

Consider a dbms system like the one described above that supports static 
binary compilation and allows one to specify the logic of a simulation 
program that one can test locally on a client computer using fewer 
elements and then put into production on a cluster of networked 
computers just by recompiling with different instructions for the 
physical distribution of the work.

Nothing exists like that now, but that is exactly the sort of thing that 
physical independence means to me. The destination lies somewhere in 
that direction.
0
Bob
6/24/2006 2:04:58 AM
Keith H Duggar wrote:
> Bob Badour wrote :
> 
>>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?

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.
0
bbadour (434)
6/24/2006 2:20:42 AM
Aloha Kakuikanu wrote:

> Bob Badour wrote:
> 
>>Consider:
>>
>>Ra = Rb AND x = 1 AND y = 1
>>
>>Where Ra and Rb are two relvars. Is that still a join? To what do x and
>>y refer?
> 
> 
> There is ambiguity caused by multiple equality signs. Did you mean
> 
> (Ra = Rb) AND x = 1 AND y = 1
> 
> or
> 
> Ra := (Rb AND x = 1 AND y = 1)
> 
> The first interpretation is absurd since there is no equality operator
> in relational algebra.

It exists in mine. It exists in the Date/Darwen one too. I disagree that 
it is ambiguous because obviously equality has a higher precedence than 
AND. Otherwise, R AND x = 1 AND y = 1 would end up as (R AND x) = (1 AND 
y) = 1, which I don't think you intended in any of your previous examples.


  In the second case there is no longer equality,
> but assignment :=   (and I still keep the redundant brackets for
> clarity).

I meant the first case, of course.


>>Consider:
>>
>>R AND x = 1 AND y = 1
>>
>>where R has no x attribute. Will that cause a compile-time error? Why or
>>why not?
> 
> No. The cartesian product of
> 
> R AND y = 1
> 
> with
> 
> x = 1
> 
> is the EXTEND operator.

While that sort of thing might make sense for the internal algebra used 
by the dbms, I prefer something that yells loudly when I type anything 
that is almost certainly an error -- especially when the error would 
likely cause the query to run for orders of magnitude longer duration 
than expected.


> I realize that this kind of thinking would steer quite away from exact
> Tutorial D semantics. BTW, only now I noticed that Tutorial D is
> bastardised version of D&D "A" algebra. Of course, it may be argued
> that the connection Tutorial D <--> "A" is better designed than  SQL
> <--> RA, but this parallel is kind of ironic.

I suggest there is a difference between the best formalism for a machine 
and the best formalism for a human, which is why compilers often start 
by converting programs into some sort of DAG as a first step.
0
Bob
6/24/2006 2:35:08 AM
Dmitry A. Kazakov wrote:
> On Fri, 23 Jun 2006 16:31:02 +0200, Bruno Desthuilliers wrote:
> 
> 
>>>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?
> 

Directed, acyclic graphs.

Date and Darwen say TCLOSE - their operator denoting the
transitive closure operation - on a binary relation having
attributes of the same type yields a superset of that
relation if there exists a sequence of values representing
a path.  [My paraphrase.]  Given an appropriate relation R,
TCLOSE R would contain {x, y} if either {x, y} exists or
there exist some {x, a}, {a, b}, {b, ...}, {..., y}.

There is, as far as I know, nothing for networks.
0
J
6/24/2006 2:36:27 AM
Marshall wrote:

> Bob Badour wrote:
> 
>>Would (R AND x = 1 AND y = 2) = (x = 1 AND y = 2 AND R) ?
> 
> I'd think it would have to, wouldn't it? Assuming = binds with
> higher precedence than AND in the above syntax, and assuming
> AND is associative and commutative, which I would hope it
> would be. It is in the Tropashko algebra.
> 
> 
>>If so, wouldn't that make name resolution kinda complicated and perhaps
>>error-prone?
> 
> I don't see any obvious complications to name resolution, but then
> I might be mising what you're getting at.

How will the dbms know when a name refers to an attribute vs a relation 
variable?

Consider:

R AND x = y

What if the dbms has relvars x and y and R has attributes x and y?


  As to error-prone,
> (assuming we are talking about the progammer writing the
> above code) yes, it might be, especially at first. I would
> expect to address that issue with coding conventions and
> possibly syntactic support. It's hard to say how much of
> an issue that will be without field experiece. (Which I don't
> have with this question.)

Okay, as long as we are not talking about the language the programmer 
works in, one can handle name resolution syntactically in the 
human-readable language and use something unambiguous internally.
0
Bob
6/24/2006 2:41:09 AM
Marshall wrote:

> Bob Badour wrote:
> 
>>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?

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.
0
bbadour (434)
6/24/2006 2:57:37 AM
Robert Martin wrote:
> On 2006-06-22 20:34:48 -0500, "JOG" <jog@cs.nott.ac.uk> said:
> 
>> 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?

I'm familiar with operations defined over more than one type
of operand and with different operations having the same
operator - but I don't know what you mean when you say "dynamic."

And please explain "directed towards the purpose of managing dependencies."
0
J
6/24/2006 2:59:18 AM
J M Davitt wrote:

> Robert Martin wrote:
> 
>> On 2006-06-22 20:34:48 -0500, "JOG" <jog@cs.nott.ac.uk> said:
>>
>>> 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?
> 
> I'm familiar with operations defined over more than one type
> of operand and with different operations having the same
> operator - but I don't know what you mean when you say "dynamic."
> 
> And please explain "directed towards the purpose of managing dependencies."

J M,

Robert Martin is a self-aggrandizing ignorant. He likes to string 
together meaningless sequences of important sounding gibberish. Surely 
you realise this by now.
0
Bob
6/24/2006 3:00:19 AM
Bob Badour wrote:
> Marshall wrote:
>
> > Bob Badour wrote:
> >
> >>Would (R AND x = 1 AND y = 2) = (x = 1 AND y = 2 AND R) ?
> >
> > I'd think it would have to, wouldn't it? Assuming = binds with
> > higher precedence than AND in the above syntax, and assuming
> > AND is associative and commutative, which I would hope it
> > would be. It is in the Tropashko algebra.
> >
> >
> >>If so, wouldn't that make name resolution kinda complicated and perhaps
> >>error-prone?
> >
> > I don't see any obvious complications to name resolution, but then
> > I might be mising what you're getting at.
>
> How will the dbms know when a name refers to an attribute vs a relation
> variable?
>
> Consider:
>
> R AND x = y
>
> What if the dbms has relvars x and y and R has attributes x and y?

Ah, I see what you're saying now. Yes, that could well be an issue.
I'm not familiar enough with this syntax to say much.


> >   As to error-prone,
> > (assuming we are talking about the progammer writing the
> > above code) yes, it might be, especially at first. I would
> > expect to address that issue with coding conventions and
> > possibly syntactic support. It's hard to say how much of
> > an issue that will be without field experiece. (Which I don't
> > have with this question.)
>
> Okay, as long as we are not talking about the language the programmer
> works in, one can handle name resolution syntactically in the
> human-readable language and use something unambiguous internally.

Yes. Again, I'm not much familiar with the above syntax, but I could
well imagine some challenges cropping up, given the lack of any
marker characters and the (multiple?) uses of '='.


Marshall

0
Marshall
6/24/2006 3:19:52 AM
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. 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.

-- Keith -- Fraud 6

0
duggar (292)
6/24/2006 3:28:19 AM
> Unstructured *anything* is going to be a bit difficult to use with any kind of automation.

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.

0
neo55592 (356)
6/24/2006 3:35:34 AM
> 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.

(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.

0
neo55592 (356)
6/24/2006 3:56:58 AM
> ... ad hoc queries as simply as even SQL ...

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

0
neo55592 (356)
6/24/2006 4:24:15 AM
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

0
6/24/2006 4:28:03 AM
>
> 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-

0
topmind (2124)
6/24/2006 4:37:24 AM
Neo wrote:
> > 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-

0
topmind (2124)
6/24/2006 4:57:10 AM
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-

0
topmind (2124)
6/24/2006 5:06:01 AM
Aloha Kakuikanu wrote:
> 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.

-- Keith -- Fraud 6

0
duggar (292)
6/24/2006 5:44:37 AM
Neo wrote:

> ... 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)  :-)
0
mAsterdam (155)
6/24/2006 8:47:43 AM
One of the more brilliant troll messages I've seen in a while.  You say 
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" <jog@cs.nott.ac.uk> wrote in message 
news:1151026488.310207.201890@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.
> 


0
nickmalik (325)
6/24/2006 8:56:59 AM
frebe73@gmail.com wrote:
>>So, is it a problem with OO, or a problem with how OO is used ?
> 
> 
> Both.

Could you elaborate ? For the record, here's the full context:
"""
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 ?
"""

> 
>>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.

Indeed - or at least, subclassing is a very inflexible tool with
declarative static typing. But this is not a problem with OO,  it's a
problem with trying to do OO with a somewhat deficient type system.

> 
>>>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.

And ?

> In a recent thread Robert Martin suggested a similar class hierachy:
> Employee
> - Salaried employee
> - Hourly employee
> - Commissioned employee

Hard to tell without the full context, but I would probably go for a
single employee class and a strategy pattern for payment mode instead.

> The Employee interface should have a calculatePayment method and the
> subclasses should have different implementations.
> 
> This might look like a natural thing to do

This hierarchy may makes sens during first analysis steps - but I
certainly would try to get rid of it during design (now here again, we
don't have enough context to make such assertions).

> 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. 

One more reason to switch to a strategy pattern.

> Now you have to repeat this
> logic in all three implementations of calculatePayment. 

Having to repeat something is most often a design smell.

>This is one
> example of problem you will encounter when you start with on dimension
> and later have to handle multiple dimensions.

This is one example of problem you encounter when you try to map the
10000-feets analysis view directly to implementation, totally skipping
the design phase.

> 
>>> 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. 

"logicality" of the rules surely impact design IMHO. It's usually
easiest to come with a sound design for even complex but stable and
non-arbitrary rules than for mostly arbitrary and rapidly changing rules.

Now if you really think you can't handle "multiple dimensions" in OO,
then it's perhaps more a problem with how you design your application
than anything else (well, the language may also makes thing
unnecessarily harder too... As a matter of fact, a good part of the
canonical design patterns are mostly workaround the rigidity of
declarative static typing)

> (But I agree that many business rules are
> unnecessary complex.)

s/unnecessary/arbitrarily/


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 12:51:27 PM
Marshall wrote:
> Bruno Desthuilliers wrote:
> 
>>Marshall wrote:
>>
>>>Something that is often a source of misunderstanding in crossposted
>>>threads is that comp.databases.theory is a *theory* newsgroup,
>>
>><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>
> 
> 
> But, but, but ...
> 

Caught you !-)

> 
>>Sorry, nitpicking here - don't waste your time answering to this.
>  
> Oh, very well. :-)

!-)

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 12:57:10 PM
vc wrote:
> 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.  

Ok, so my teachers where not to blame then...

> 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'.

Well, so there's still some hope we will *one day* have something usable
with a standard syntax, then ?

If I summarize all this, the problem with RM is not RM - it's RDBMS. Too
bad we have to deal with RDBMS then.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:01:18 PM
-CELKO- wrote:
>>>"fermeture transitive d'un graphe". <,
> 
> 
> Transitive closure of a graph.
> 
> There are better eways to model trees in SQL than an adjacency list.
> Look up Nested Sets 

I did some years ago. It's an awful kludge. It that's all you have to
offer, I prefer to handle the case with client code or even P/SQL.

> and get a copy of TREES & HIERATCHIES IN SQL.

Doing commercial ads and self-promotion on usenet, Mr Celko ?

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:04:29 PM
erk wrote:
> Bruno Desthuilliers wrote:
> 
>>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. 

(google, 30 seconds quick look at the front page...)

Hmmm, seems nice, indeed !-)

But at first sight, I don't see what it has to offer I don't actually
have in Python.

(snip)
> Which might be why it'll never take off, 

<troll>
May I suggest that the connection with Java is the worst possible
marketing argument ?-)
</troll>

> but we can dream.

s/can/must/

And then try to refactor reality...

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:10:14 PM
frebe73@gmail.com wrote:
>>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.
> 
> 
> I agree that Python is an excellt language, OO is availible but nothing
> forces you to use it.

Well... When it comes to more advanced tricks, Python's closures and
lambdas are a bit to0 weak, so you need to go for OO constructs instead.
But really, at this level, OO (� la Python/Ruby etc) and closures are
somewhat interchangeable...

> 
>>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.

Well, a little bit more than a map FWIW. But wrt/ object model, there
are great similarities between Javascript and Python (amongst other,
Python objects are mostly maps too - even when they don't directly
expose the map interface -). Now I do find Python somewhat clearer and
less tricky than Javascript (but I may be biased by 7+ years of having
fun with Python).

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:20:21 PM
Aloha Kakuikanu wrote:
> 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.
> 

I guess that Dimtry's answer was to be taken as a joke. But I won't
bother explaining it...

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:22:19 PM
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. 

In which context ?

> What kind of
> methods does it have other than "getName" "setName" and alike?
> 

In which context ?

I could also "challenge the idea that customer is a useful entity." Out
of context, *nothing* is useful.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:25:15 PM
erk wrote:
> queisser wrote:
> 
>>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.

s/objects/classes/

Java insist putting everything in classes for "OOness" sake, but still
have "primitive" (non-object) types and no first-order functions. AFAIC,
Java is a braindead language. Too bad everyone and her little sister
confuses OO with Java - this greatly deserves OO IMHO.

> This criticism obviously doesn't apply to languages with multimethods
> and functions as first-class entities.

+1

> 
> We're creating systems, not trying to emulate reality (in which, by the
> way, it's clear real hierarchies are rare).

Lol. But note that Simula was about, well,  simulation - which may
explain this trend...

> Emulating reality is
> another phantasm conjured by O-O.

Agreed. But see above.

(snip)

>>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;

Is it really so ?

> perhaps
> if industry and academia weren't so faddish, the teaching would
> suffice.

Agreed again. Most of the damage comes IMHO from dummies trying to teach
ununderstood OO to other dummies - with of course dumb examples in dumb
languages.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:45:13 PM
Bob Badour wrote:
(snip)
> I think the focus on structure to the exclusion of manipulation is a
> mistake. 

I'm afraid I have to agree on this.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 1:51:42 PM
Marshall wrote:
> Bob Badour wrote:
> 
>>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. 

But is that *really* the easy part ? Kind of *seems* easy, but... At
least 80% of the complicated code I've ever seen came from a wrong
structure. And it's obvious that if the structure had followed the
processing needs, then the code would have been way much simpler (and
better). As a matter of fact, whenever I find myself writing complicated
code, I *know* there's something wrong.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 2:00:35 PM
Nick Malik [Microsoft] wrote:
> One of the more brilliant troll messages I've seen in a while. 

Given the recent "religious war" threads involving co and cdt, I'd say
it was rather easy and obvious.

Now the funny thing is that the overall tone of this thread seems much
more open-minded (Mr Badour's fanatism set aside - and even he managed
to say at least one sensible thing) than the previous ones.

> You say 
> 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.

I agree that some participation of the OP would be welcome  !-)

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/24/2006 2:11:38 PM
Keith H Duggar wrote:
> Aloha Kakuikanu wrote:
> > 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.

All verbs are trivially dynamic. "Polymorphism", however doesn't look
like a verb.

0
6/24/2006 2:59:34 PM
Bruno Desthuilliers wrote:
> Aloha Kakuikanu wrote:
> > 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.
> >
>
> I guess that Dimtry's answer was to be taken as a joke. But I won't
> bother explaining it...

Oh, phlese.

QueryObject.setExtraWhereClause();
QueryObject.setAdditionalExtraWhereClause();
QueryObject.setOneMoreAdditionalExtraWhereClause();

0
6/24/2006 3:26:15 PM
> >>So, is it a problem with OO, or a problem with how OO is used ?
>> Both.
> Could you elaborate ?

The main problem in OO enterprise applications is the desire to
decouple SQL statements. This causes code bloats. Bloated code are
harder to maintain. Another disadvantage is the fact that the number
SQL statements should be limited and the the same statement should be
reused in different contexts. This does not only creates problem
writing the code, it causes performance problems. The fact that the
result from the SQL query has to be mapped to a "domain object" also
introduces numerous problems.

> >>>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.
> And ?

See the discussion about employee types.

> > In a recent thread Robert Martin suggested a similar class hierachy:
> > Employee
> > - Salaried employee
> > - Hourly employee
> > - Commissioned employee
> Hard to tell without the full context, but I would probably go for a
> single employee class and a strategy pattern for payment mode instead.

Subtyping payment modes instead of employee types has the same
disadvantages. The key is to limit the use of subtyping.

> > 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.
> One more reason to switch to a strategy pattern.

The original solution used a strategy pattern too. The problem with the
strategy pattern (and subtyping) is that you only have one dimension of
strategies. Multiple dimensions (employement type and union
association) might affect how the strategy should be implemented.

> > Now you have to repeat this
> > logic in all three implementations of calculatePayment.
> Having to repeat something is most often a design smell.

That's why a design using subtypes can be very dangerous.

> >This is one
> > example of problem you will encounter when you start with on dimension
> > and later have to handle multiple dimensions.
> This is one example of problem you encounter when you try to map the
> 10000-feets analysis view directly to implementation, totally skipping
> the design phase.

It seem to be very difficult to get i right using OO.... Maybe that is
why we need the mentors...

> Now if you really think you can't handle "multiple dimensions" in OO,

Almost every language (OO or not) can handle multiple dimensions, but a
subtype hiearchy can not. 

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/24/2006 4:08:24 PM
On 24 Jun 2006 08:26:15 -0700, Aloha Kakuikanu wrote:

> Bruno Desthuilliers wrote:
>> Aloha Kakuikanu wrote:
>>> 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.
>>>
>> I guess that Dimtry's answer was to be taken as a joke. But I won't
>> bother explaining it...
> 
> Oh, phlese.
> 
> QueryObject.setExtraWhereClause();
> QueryObject.setAdditionalExtraWhereClause();
> QueryObject.setOneMoreAdditionalExtraWhereClause();

Set_Photo_Of
Get_FFT_Of_His_Photo

(FFT = Fast Fourier transform)

And, guys, what about presenting a query statement for building a dual
graph?

(Or, was it in the "algebra" for decades? (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/24/2006 4:30:14 PM
Dmitry A. Kazakov wrote:
>
> And, guys, what about presenting a query statement for building a dual
> graph?

I'm not at all familiar with graph theory. I couldn't make sense out of
this:

http://mathworld.wolfram.com/DualGraph.html

Can you explain it better?

Is there some known theoretical complexity of this problem? (In other
words, are you just setting me up? :-)


Marshall

0
6/24/2006 5:36:00 PM
Bruno Desthuilliers wrote:
>
> Now the funny thing is that the overall tone of this thread seems much
> more open-minded (Mr Badour's fanatism set aside - and even he managed
> to say at least one sensible thing) than the previous ones.

Do you think so? Or is it merely that this thread is more polite?
Open mindedness and politeness are two desirable qualities,
but it would be a shame not to be able to distinguish them.


Marshall

0
6/24/2006 5:37:44 PM
Nick Malik [Microsoft] wrote:
> One of the more brilliant troll messages I've seen in a while.  You say
> 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.

You're going to feel silly, having written the above, when you are
far enough along to reach the same realization that JOG had.

I speak from experience.


Marshall

0
6/24/2006 5:50:42 PM
Bruno Desthuilliers wrote:
> Marshall wrote:
> > And yet, people make that mistake again and again and
> > again.  The focus is on the easy part: structure.
>
> But is that *really* the easy part ? Kind of *seems* easy,
> but... At least 80% of the complicated code I've ever seen
> came from a wrong structure. And it's obvious that if the
> structure had followed the processing needs, then the code
> would have been way much simpler (and better). As a matter
> of fact, whenever I find myself writing complicated code,
> I *know* there's something wrong.

What happens when different processing needs demand different
structures that "follow their needs"? Then some computations
become easier while others become harder. This is "expression
bias" and for me it has been an annoying problem with network
models. And it drives one inexorably to the relational model.

-- Keith -- Fraud 6

0
duggar (292)
6/24/2006 5:55:10 PM
Marshall <marshall.spight@gmail.com> wrote:
> Dmitry A. Kazakov wrote:
> >
> > And, guys, what about presenting a query statement for building a dual
> > graph?
> 
> I'm not at all familiar with graph theory. I couldn't make sense out of
> this:
> 
> http://mathworld.wolfram.com/DualGraph.html
> 
> Can you explain it better?
> 
> Is there some known theoretical complexity of this problem? (In other
> words, are you just setting me up? :-)

Well, for one thing, a graph is planar if and only if it has a dual, and 
planarity testing is at least an intuitively complex problem.  Bob 
Tarjan showed (in the 70's, I think) that is has a linear time solution 
using depth-first search trees.  However, the algorithm is very non-
obvious and it was assumed for a long time than graph planarity testing 
could not be done in better than O(n^3) time.  This implies that finding 
the dual of a graph is at least as hard, though I really doubt it's 
harder once you have found the layout of nodes that is planar, since you 
may then just find the geometric dual.

I don't know if that counts as "theoretical complexity", or precisely 
what you mean by that anyway.

HTH,

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/24/2006 6:28:31 PM
Keith H Duggar wrote:

> Bruno Desthuilliers wrote:
> 
>>Marshall wrote:
>>
>>>And yet, people make that mistake again and again and
>>>again.  The focus is on the easy part: structure.
>>
>>But is that *really* the easy part ? Kind of *seems* easy,
>>but... At least 80% of the complicated code I've ever seen
>>came from a wrong structure. And it's obvious that if the
>>structure had followed the processing needs, then the code
>>would have been way much simpler (and better). As a matter
>>of fact, whenever I find myself writing complicated code,
>>I *know* there's something wrong.
> 
> What happens when different processing needs demand different
> structures that "follow their needs"? Then some computations
> become easier while others become harder. This is "expression
> bias" and for me it has been an annoying problem with network
> models. And it drives one inexorably to the relational model.

One might add that the 80% of complicated code Bruno saw resulted from 
having a surfeit of structures to choose from and a paucity of available 
manipulations in the first place.
0
bbadour (434)
6/24/2006 6:52:38 PM
On 24 Jun 2006 10:36:00 -0700, Marshall wrote:

> Dmitry A. Kazakov wrote:
>>
>> And, guys, what about presenting a query statement for building a dual
>> graph?
> 
> I'm not at all familiar with graph theory. I couldn't make sense out of
> this:
> 
> http://mathworld.wolfram.com/DualGraph.html
> 
> Can you explain it better?

See:

http://en.wikipedia.org/wiki/Planar_graph
http://en.wikipedia.org/wiki/Dual_graph

It is a quite intuitive thing. I was born in St.Petersburg, but you can
consider Venice for the same purpose. The graph of channels is the dual of
one of the bridges. Regions are the islands + one for mainland.

> Is there some known theoretical complexity of this problem? (In other
> words, are you just setting me up? :-)

It is not hard. The problem specifically for RA lies elsewhere. The dual
graph is not a subgraph or a product of some relational operation on the
graph. You cannot "select" it from something you already have. You need to
construct it from scratch, so to say. It is like power set. The constructed
object, of course, must have the chosen representation of a graph in RA. A
symmetric binary relation is an obvious candidate, plus planarity
constraint. Euler's formula is good for that. You should start with queries
identifying regions, these will give you new nodes. Then for each arc xGy
(two arcs actually, but the relation is symmetric xGy=yGx) of the original
graph you create one in the new graph.

(I can't tell if dual is "algebraic" in RA, but it is in OO (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/24/2006 7:04:49 PM
Dmitry A. Kazakov wrote:
> On 24 Jun 2006 10:36:00 -0700, Marshall wrote:
>
> > Dmitry A. Kazakov wrote:
> >>
> >> And, guys, what about presenting a query statement for building a dual
> >> graph?
> >
> > I'm not at all familiar with graph theory. I couldn't make sense out of
> > this:
> >
> > http://mathworld.wolfram.com/DualGraph.html
> >
> > Can you explain it better?
>
> See:
>
> http://en.wikipedia.org/wiki/Planar_graph
> http://en.wikipedia.org/wiki/Dual_graph

Neither of these provides an unambiguous specification of
the problem.


> It is a quite intuitive thing. I was born in St.Petersburg, but you can
> consider Venice for the same purpose. The graph of channels is the dual of
> one of the bridges. Regions are the islands + one for mainland.

So, if all we are doing is converting bridges in to channels, how
about INSERT INTO Channels (SELECT * FROM Bridges)

But it would probably be better to provide an unambiguous
definition of the problem. Perhaps a minimal example as well?


> > Is there some known theoretical complexity of this problem? (In other
> > words, are you just setting me up? :-)
>
> It is not hard.

Reading about the history of the analysis of the problem, coupled
with the fact that I can't seem to find a decent explanation of it,
woud seem to contradict this. Perhaps it is only not hard after
one has already learned about it.


> The problem specifically for RA lies elsewhere.

Ah, you do have something up your sleeve. How about you just
come clean with it and we talk about it?

You know, the c.d.t. people are well aware of issue like transitive
closure and Turing completeness, and how the traditional and
various modern RAs stack up in comparison. We could discuss
it if you wish.


Marshall

0
6/24/2006 9:39:13 PM
Responding to JOG...

> OO is hierarchy.

LOL.  This pretty much says it all.  I suggest learning something about 
OOA/D; it would make the trolling more credible.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring: 
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



0
h.lahman (3600)
6/24/2006 9:48:47 PM
H. S. Lahman wrote:

> Responding to JOG...
> 
>> OO is hierarchy.
> 
> LOL.  This pretty much says it all.  I suggest learning something about 
> OOA/D; it would make the trolling more credible.

With all due respect, I see no reason to think his education in OOA/D is 
lacking in any way. While his statement is a simplification and a 
generalization, it is accurate at least to a first-order approximation.
0
bbadour (434)
6/24/2006 10:05:30 PM
Bob Badour wrote:
> H. S. Lahman wrote:
> 
>> Responding to JOG...
>>
>>> OO is hierarchy.
>>
>> LOL.  This pretty much says it all.  I suggest learning something 
>> about OOA/D; it would make the trolling more credible.
> 
> With all due respect, I see no reason to think his education in OOA/D is 
> lacking in any way. While his statement is a simplification and a 
> generalization, it is accurate at least to a first-order approximation.

pmsl

with all due respect....re-arrange these words into the well known 
saying:

Calling Black Kettle Pot A
0
news261 (167)
6/24/2006 10:09:36 PM
H. S. Lahman wrote:

> Responding to JOG...
> 
>> OO is hierarchy.
> 
> 
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions  -- Put MDA to Work
> http://www.pathfindermda.com
> blog: http://pathfinderpeople.blogs.com/hslahman
> Pathfinder is hiring: 
> http://www.pathfindermda.com/about_us/careers_pos3.php.
> (888)OOA-PATH

Model Driven Architecture, eh? What a load of horseshit.
0
bbadour (434)
6/24/2006 10:10:04 PM
Marshall wrote:
> Nick Malik [Microsoft] wrote:
>> One of the more brilliant troll messages I've seen in a while.  You say
>> 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.
> 
> You're going to feel silly, having written the above, when you are
> far enough along to reach the same realization that JOG had.
> 
> I speak from experience.

I'm with you, seems a premature, maybe even an immature judgment to me. 
  Didn't read all the offshoots but part of the thread struck me as 
provocative and interesting after keith d made his light compiler 
comment.  Aloha added to it with his relation literals although I'm not 
sure whether he or she intended that.  Maybe it's just because bridging 
the theory and the machine is an interest of mine.  I think it's not so 
much a compiler matter but more to do with what I think of as a minimal 
interpreter.  I think D&D Algebra is quite implementable all by itself 
and that would have value.

In one post, bob b hinted at optimization/user friendliness issues (my 
words, not his) which my point-of-view usually considers to be nothing 
more than a matter of taste (I was more or less in agreement with what 
Dijkstra said about "user-friendly" in one of his interviews - I think 
he was complaining about lowest-common-denominator UI's, which Codd 
opened the door for).  I could be more provocative and say that I think 
other practical matters such as persistence and transactions are 
orthogonal to rt and so would.  Not to criticize D&D as I think they 
have done a public service (even if they've made a few bucks/quid out of 
it).  The parts of TD I've spent time on seem to be me to be aimed above 
all else at preventing ambiguity and I've seen it called verbose but I 
think that is a necessary result of its intention.  Rel has been 
criticized as ponderous (my word) but as teaching tools rather than 
something I'd like to make appl'ns out of, I think both TD and Rel are 
both fine efforts.  Even if they weren't they'd still be worth talking 
about as they are rather unique in trying to bridge theory and machines.

p
0
paul
6/24/2006 10:26:01 PM
paul c wrote:
> Marshall wrote:
>> Nick Malik [Microsoft] wrote:
>>> One of the more brilliant troll messages I've seen in a while.  You say
>>> 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.
>>
>> You're going to feel silly, having written the above, when you are
>> far enough along to reach the same realization that JOG had.
>>
>> I speak from experience.
> 
> I'm with you, seems a premature, maybe even an immature judgment to me. 
>  Didn't read all the offshoots but part of the thread struck me as 
> provocative and interesting after keith d made his light compiler 
> comment.  Aloha added to it with his relation literals although I'm not 
> sure whether he or she intended that.  Maybe it's just because bridging 
> the theory and the machine is an interest of mine.  I think it's not so 
> much a compiler matter but more to do with what I think of as a minimal 
> interpreter.  I think D&D Algebra is quite implementable all by itself 
> and that would have value.
> 
> In one post, bob b hinted at optimization/user friendliness issues (my 
> words, not his) which my point-of-view usually considers to be nothing 
> more than a matter of taste (I was more or less in agreement with what 
> Dijkstra said about "user-friendly" in one of his interviews - I think 
> he was complaining about lowest-common-denominator UI's, which Codd 
> opened the door for).  I could be more provocative and say that I think 
> other practical matters such as persistence and transactions are 
> orthogonal to rt and so would.  ...


Don't know what happened to that cursory thought, think I meant to type 
"and so would be a significant part of a full TTM impl'n".

p
0
paul
6/24/2006 10:30:55 PM
Andrew McDonagh wrote:

> Bob Badour wrote:
> 
>> H. S. Lahman wrote:
>>
>>> Responding to JOG...
>>>
>>>> OO is hierarchy.
>>>
>>>
>>> LOL.  This pretty much says it all.  I suggest learning something 
>>> about OOA/D; it would make the trolling more credible.
>>
>>
>> With all due respect, I see no reason to think his education in OOA/D 
>> is lacking in any way. While his statement is a simplification and a 
>> generalization, it is accurate at least to a first-order approximation.
> 
> 
> pmsl
> 
> with all due respect....re-arrange these words into the well known saying:
> 
> Calling Black Kettle Pot A

Are you suggesting that the self-aggrandizing ignorants coming from c.o 
make statements that are in any way shape or form accurate? They don't. 
What they write is just plain wrong at all levels.
0
bbadour (434)
6/24/2006 11:14:59 PM
Bob Badour wrote:
> Andrew McDonagh wrote:
> 
>> Bob Badour wrote:
>>
>>> H. S. Lahman wrote:
>>>
>>>> Responding to JOG...
>>>>
>>>>> OO is hierarchy.
>>>>
>>>>
>>>> LOL.  This pretty much says it all.  I suggest learning something 
>>>> about OOA/D; it would make the trolling more credible.
>>>
>>>
>>> With all due respect, I see no reason to think his education in OOA/D 
>>> is lacking in any way. While his statement is a simplification and a 
>>> generalization, it is accurate at least to a first-order approximation.
>>
>>
>> pmsl
>>
>> with all due respect....re-arrange these words into the well known 
>> saying:
>>
>> Calling Black Kettle Pot A
> 
> Are you suggesting that the self-aggrandizing ignorants coming from c.o 
> make statements that are in any way shape or form accurate? They don't. 
> What they write is just plain wrong at all levels.

again pmsl


no bob, I'm merely finding it very amusing that when someone else 
(Larmen in this case) makes a remark about someones supposed knowledge 
level, you reply with a remark about them simplifying and generalising.
When there's been plenty of cases in the set of Relational vs OO troll 
threads on these groups.

Keep it up - watching you is better than The Comedy Channel.

(andrew walks off chuckling.....)
0
news261 (167)
6/24/2006 11:24:10 PM
Marshall wrote:
> Dmitry A. Kazakov wrote:
>> Marshall wrote:
>>>Dmitry A. Kazakov wrote:
>>>
>>>>And, guys, what about presenting a query statement for building a dual
>>>>graph?
[snip]
>>>http://mathworld.wolfram.com/DualGraph.html
>>http://en.wikipedia.org/wiki/Planar_graph
>>http://en.wikipedia.org/wiki/Dual_graph
> 
> Neither of these provides an unambiguous specification of
> the problem.
> 
>>It is a quite intuitive thing. I was born in St.Petersburg, but you can
>>consider Venice for the same purpose. The graph of channels is the dual of
>>one of the bridges. Regions are the islands + one for mainland.
> 
> 
> So, if all we are doing is converting bridges in to channels, how
> about INSERT INTO Channels (SELECT * FROM Bridges)
> 
> But it would probably be better to provide an unambiguous
> definition of the problem. Perhaps a minimal example as well?

How about:
Given A planar graph G, compute it's dual graph G'
(this takes out the real hard part, BTW:
given a graph compute if it's planar)

If it is still unclear: just say what is the problem,
I'll do my best. (It's in my 1974 graph syllabus, and very rusty :-)

>>>Is there some known theoretical complexity of this problem? (In other
>>>words, are you just setting me up? :-)
>>
>>It is not hard.
> 
> Reading about the history of the analysis of the problem, coupled
> with the fact that I can't seem to find a decent explanation of it,
> woud seem to contradict this. Perhaps it is only not hard after
> one has already learned about it.
> 
>>The problem specifically for RA lies elsewhere.
> 
> Ah, you do have something up your sleeve. How about you just
> come clean with it and we talk about it?
> 
> You know, the c.d.t. people are well aware of issue like transitive
> closure and Turing completeness, and how the traditional and
> various modern RAs stack up in comparison. We could discuss
> it if you wish.


-- 
"The person who says it cannot be done
should not interrupt the person doing it."
Chinese Proverb.
0
mAsterdam (155)
6/25/2006 12:54:38 AM
mAsterdam wrote:
> Marshall wrote:
> >
> > But it would probably be better to provide an unambiguous
> > definition of the problem. Perhaps a minimal example as well?
>
> How about:
> Given A planar graph G, compute it's dual graph G'
> (this takes out the real hard part, BTW:
> given a graph compute if it's planar)
>
> If it is still unclear: just say what is the problem,
> I'll do my best. (It's in my 1974 graph syllabus, and very rusty :-)

Okay.

First I need to know what a "graph" is. (Don't laugh.)

I think of the term as meaing "nodes and edges" but it
appears for this paticular problem, we need faces as
well. Yes/no? What are these faces? Are they collections
of edges? Do the nodes have a position? If so, what
must be the position of the nodes in the dual? If
it's not specified, then how can we say the dual of
the dual of the graph is the graph? Apparently it's okay
to leave some things out, but it's not clear what.

Then I need to know what "dual" is. Etc.

In essence, I need a specification of the problem.
All I've been given is the *name* of the problem,
according to a nomenclature of a field of mathematics
that I haven't studied, and pointers to vague sketches
of the problem. That's not sufficient.

There are lots of important details to the problem that
none of the references fill in. There are also no examples
presented, which means that as I build an understanding
of the problem, I have nothing to test it against.

The example can be quite primitive: just a triangle maybe.


Marshall

0
6/25/2006 1:16:40 AM
Marshall wrote:
> Well, some. Lots of thinking. A trial syntax. Some ambitious
> ideas. There is an interpreter for it, but it's never fully functional,
> as I keep changing my mind about important design decisions.
> For example, a few months ago I ripped out default arguments
> when I realized they broke associativity of natural join. :-(

I have never been a fan of default arguments, since I first encountered
them in Ada. A function that needs default arguments is a function
that's trying to do too much, it seems to me.

> Sadly, I'm not very good with formal methods yet, so I don't
> have an operational semantics. But it's something I want to do.
>

"Pshaw" says I to operational semantics ;) Check out
http://www.cis.ksu.edu/~schmidt/text/densem.html for free PDF or
Postscript of David Schmidt's most excellent "Denotational Semantics: A
Methodology for Language Development". A very good (and when I wanted
to buy it in 1987, very *expensive*) book on denotational semantics.
Lloyd Allison's introductory book, "A Practical Introduction to
Denotational Semantics" (Cambridge Computer Science Texts No. 23) is a
short, quick and decent introduction which might get you going quicker,
but isn't available on line (it's quite cheap though - =A315 currently).
Lloyd Allison has a website at http://www.csse.monash.edu.au/~lloyd,
and his list of programming languages contains the excellent joke :

"The last good thing written in C was Franz Schubert's Ninth Symphony."
 -  Gregory V. Wilson

> Its primitive operators are those of the Tropaskho algebra:
> natural join and inner union. The language is pretty much
> just: those operators, scope and name binding, the type
> system,

Just ?! Languages are invented just to play with type systems, never
mind anything else :)

> the imperative commands,

Oh, boo ...

> and a few bits of
> miscellany, such as aggregates/group-by. High up on
> the wanted-feature list is constraints and updatable views.
> But the precise semantics of view updatability remain
> elusive.
>

Well, you've got to start *somewhere*. Pick the low-hanging fruit and
make sure you've designed the spec in such a way that adding the fun
stuff is easier later (even if someone else gets to do it). Design the
semantics first - an interpreter will surely follow :)

0
Tony
6/25/2006 1:39:24 AM
Marshall <marshall.spight@gmail.com> wrote:
> First I need to know what a "graph" is. (Don't laugh.)
> 
> I think of the term as meaing "nodes and edges" but it
> appears for this paticular problem, we need faces as
> well. Yes/no? What are these faces? Are they collections
> of edges? Do the nodes have a position? If so, what
> must be the position of the nodes in the dual? If
> it's not specified, then how can we say the dual of
> the dual of the graph is the graph? Apparently it's okay
> to leave some things out, but it's not clear what.
> 
> Then I need to know what "dual" is. Etc.

In case this helps, if you are planning to try this.

- You don't need faces; just a (unordered) nodes and edges.

- These are standard graphs (actually pseudographs... see below); 
position doesn't matter.

- To find a dual geometrically (the easiest to understand) by hand, you 
would do the following:

1. Draw the graph on a sheet of paper, without crossing any edges.  If 
you can't do that, then the graph doesn't have a dual.

2. Identify all of the regions.  Regions are the empty spaces on your 
paper, and are separated by edges from the graph.  The blank space 
outside of where you've drawn the graph DOES count as a region, so there 
is always at least one.  If the graph is a tree, for example, then there 
is only one region, so the dual only has one vertex.

3. On a different sheet of paper for the dual graph, draw a node for 
each of those regions.

4. Now draw the edges of the original graph onto the dual, but draw them 
between the dual vertices that represent the regions on each side of the 
edge.  Note that some edges may actually have the same region on both 
sides, so that the edge becomes a loop (it connects a vertex to itself).  
As an extreme case, the dual of a tree is just a single node with a 
whole bunch of loops on it.

And you're done.  As a simple example, take this graph:

    O ----------- O
    |           / |
    |   A     /   |
    |       /     |
    |     /       |    C
    |   /    B    |
    | /           |
    O ----------- O

There are three regions (two inside, and then the "outside" region) 
which I've labelled A, B, and C.  The dual therefore has three vertices.  
There are two edges that separate A from C (the top and left edges), so 
there are two edges from A to C in the dual.  Following the same 
pattern, the dual has two edges from B to C, and one edge from A to B.  
The dual is:

                  A
                 /|\
                | | |
                 \| |
                  C |
                 /| |
                | | |
                 \|/
                  B

- Here is a definite possible subtlety.  All graphs have duals, but all 
duals are not graphs.  In fact, the dual constructed above is not a 
graph.  Rather, it is a multigraph.  More generally, we also need to 
allow loops as well, so a dual is a pseudo-graph.

Even more generally (though you can probably ignore this detail) duals 
are relationships between planar embeddings of graphs -- which means 
ways to draw the graph in the plane without crossing edges.  So, if you 
did step 1 differently above, you might get a different dual.  In 
practice, it is normal to say something like "a graph may have more than 
one dual", when it would probably be more correct to say "each planar 
embedding of a graph has one and only one dual, which is itself a planar 
embedding of a graph."

- Yes, there is always some way of finding the dual of a dual of a graph 
that can get you back to the original graph.  However, since a graph has 
multiple duals, there may be other paths that don't do so.  
(Technically, the unique dual of the unique dual of a planar embedding 
of a graph does bring you reliably back to the original, but assuming 
you don't plan to store information about the planar embedding, that's 
not really relevant.)

Finally, I'm not convinced that merely guaranteeing that the graph is 
planar is sufficient to find the dual of a graph.  What you need is some 
specific planar embedding of the graph.  Otherwise, you'll need to 
calculate a planar embedding for step #1, and that's just as hard as 
proving that the graph is planar... i.e., knowing in advance that it's 
planar doesn't actually get you anywhere.  I actually don't know off-
hand what a common way is to describe a planar embedding.  Obviously you 
could ask for a list of the regions, which would make your job somewhat 
easier.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/25/2006 4:00:15 AM
> > ... 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:
> T_Links (srcNd_ID, destNd_ID, weight);
> T_Node (node_ID, activationFuncInd, activationWeight);

:) Ddb evolved from similar schemas. The above method, which I refer to
as generic modelling, shifts "schema" modification from being
table-centric to row-centric.

0
neo55592 (356)
6/25/2006 4:09:40 AM
>>>> 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.
>>>
>>> Unstructured *anything* is going to be a bit difficult ...
>>
>> ... the term highly-variable structure may be better.
>
> ... better, but the vocabulary is still in need of much improvement.

how about: The advantages provided by RMDBs are diminished when:
1) the structure of know data is highly-varied (or non-uniform).
2) the structure of new data is unknown.

0
neo55592 (356)
6/25/2006 5:23:12 AM
On 24 Jun 2006 14:39:13 -0700, Marshall wrote:

> Dmitry A. Kazakov wrote:

>> http://en.wikipedia.org/wiki/Planar_graph
>> http://en.wikipedia.org/wiki/Dual_graph
> 
> Neither of these provides an unambiguous specification of
> the problem.

See the nice post by Chris Smith.

>> It is a quite intuitive thing. I was born in St.Petersburg, but you can
>> consider Venice for the same purpose. The graph of channels is the dual of
>> one of the bridges. Regions are the islands + one for mainland.
> 
> So, if all we are doing is converting bridges in to channels, how
> about INSERT INTO Channels (SELECT * FROM Bridges)

That could be the final step. The actual problem is the end points of the
arcs. Which depends on the graph representation you choose. If graph were
represented "naturally" as a relation, then each arc would be a pair tuples
(the relation is symmetric).

>> The problem specifically for RA lies elsewhere.
> 
> Ah, you do have something up your sleeve.

Look at me, I wear a T-shirt! (:-))

> How about you just
> come clean with it and we talk about it?
> 
> You know, the c.d.t. people are well aware of issue like transitive
> closure and Turing completeness, and how the traditional and
> various modern RAs stack up in comparison. We could discuss
> it if you wish.

As I said, I don't know if it is "algebraic" in RA. It must definitively be
Turing complete. Ask Chris Smith, he seems to know far more on the topic
than me.

My feeling is that it could turn quite hard for RA. That's why I've
presented it! (:-)) The feeling is based on a trivial observation that the
nodes of the dual graph aren't present in the original graph either as
nodes or as relations. You have to "invent" them (identify the regions).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/25/2006 8:44:48 AM
"Chris Smith" <cdsmith@twu.net> wrote in message
news:MPG.1f07b8374b49cf619896f9@news.altopia.net...

> 2. Identify all of the regions.  Regions are the empty spaces on your
> paper, and are separated by edges from the graph.  The blank space
> outside of where you've drawn the graph DOES count as a region, so there
> is always at least one.  If the graph is a tree, for example, then there
> is only one region, so the dual only has one vertex.

Doesn't region identification depend on the topology of the space?   If your
graph were on the surface of a torus,  wouldn't you come up with possibly
different regions?  (viz.  the seven color map theorem for the surface of a
torus)





0
dcressey (35)
6/25/2006 12:32:16 PM
David Cressey wrote:
> "Chris Smith" <cdsmith@twu.net> wrote in message
> news:MPG.1f07b8374b49cf619896f9@news.altopia.net...
> 
>>2. Identify all of the regions.  Regions are the empty spaces on your
>>paper, and are separated by edges from the graph.  The blank space
>>outside of where you've drawn the graph DOES count as a region, so there
>>is always at least one.  If the graph is a tree, for example, then there
>>is only one region, so the dual only has one vertex.
> 
> Doesn't region identification depend on the topology of the space?   If your
> graph were on the surface of a torus,  wouldn't you come up with possibly
> different regions?  (viz.  the seven color map theorem for the surface of a
> torus)

If it were on a torus, it would not be on a plane.

Damn! Now I have that song going through my head: "I leaving on a jet 
plane. Don't know when I'll be back again..."

Now you all do too! So there!
0
bbadour (434)
6/25/2006 12:56:29 PM
David Cressey wrote:
> Chris Smith wrote:
> 
>>2. Identify all of the regions.  Regions are the empty spaces on your
>>paper, and are separated by edges from the graph.  The blank space
>>outside of where you've drawn the graph DOES count as a region, so there
>>is always at least one.  If the graph is a tree, for example, then there
>>is only one region, so the dual only has one vertex.
> 
> 
> Doesn't region identification depend on the topology of the space?

That complication is thrown out of scope by /planar/
in the problem-statement (which, I think, is accepted):

     Given A planar graph G, compute its dual graph G'

> If your graph were on the surface of a torus,  
> wouldn't you come up with possibly different regions?
> (viz.  the seven color map theorem for the surface of a
> torus)


-- 
"The person who says it cannot be done
should not interrupt the person doing it."
Chinese Proverb.
0
mAsterdam (155)
6/25/2006 2:33:37 PM
Responding to Badour...

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

I can't think of a single statement that would be more antithetical to 
what the OO paradigm is about.  Probably the single most important thing 
the OO paradigm brought to the development table was the elimination of 
the hierarchical dependencies prevalent in structured functional 
decomposition.  Problem space abstraction, peer-to-peer collaboration, 
separation of message and method, encapsulation, flexible logical 
indivisibility, and all the rest of that OO stuff play together for the 
specific purpose of eliminating the spaghetti code resulting from 
hierarchical implementation dependencies.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
Pathfinder is hiring: 
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH



0
h.lahman (3600)
6/25/2006 2:59:50 PM
Neo wrote:
>>>>>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.
> 
>>>>Unstructured *anything* is going to be a bit difficult ...
>>>... the term highly-variable structure may be better.
>>... better, but the vocabulary is still in need of much improvement.
> 
> how about: The advantages provided by RMDBs are diminished when:
> 1) the structure of know data is highly-varied (or non-uniform).
> 2) the structure of new data is unknown.

What I read is an unbalanced, vague impression.
FWIW: it doesn't make me say: "No no no,
this is completely wrong!" - but that's about it
(BTW I'd leave the RM out, in this case. Just DB).

In order to be able to assess or even sensibly talk
about such things, you need a better vocabulary.
You snipped the stuff that might be relevant to that.



Here is a vague impression of mine.
I think this problem area is related
to an earlier conversation we had:

------------
>> It is important to find a good way of stating requirements.
>> Up to now I don't think you have found it.
>
>
> :) You are expecting a static requirement.


No.

> My requirement is how to best meet dynamic 
> requirements (ie like those of an andriod).

Yes. So I'll repeat:
It is important to find a good way of stating requirements.
Up to now I don't think you have found it.
------------






-- 
"The person who says it cannot be done
should not interrupt the person doing it."
Chinese Proverb.
0
mAsterdam (155)
6/25/2006 3:13:28 PM
Dmitry A. Kazakov wrote:
> On 24 Jun 2006 08:26:15 -0700, Aloha Kakuikanu wrote:
> And, guys, what about presenting a query statement for building a dual
> graph?

What about it? It's rather easy.

table Nodes (
   node_id integer
)

table Edges (
   node1 integer,
   node2 integer
   --foreign keys to Nodes
)

table Faces (
   edge_id integer,
   node_id integer,
   --foreign keys to Nodes
)

Faces are needed, because specification consisting of the only Nodes
and Edges defines planar graph ambiguously.

Example:
Nodes: {1,2,3,4,5}
Edges: {(1,2),(1,3),(2,3),(2,4),(3,5),(4,5)}
defines 2 planar graphs -- one where the trianfle is inside the
rectangle, and the other one where it's outside.

Next. Nodes in the dual graph are the faces of the original. Rather
trivial query.

Edges in the dual graph are pairs of faces such that there are 2 common
nodes which also belong to an edge. Rather easy query as well.

0
6/25/2006 5:50:25 PM
H. S. Lahman wrote:
> Responding to Badour...
> 
>>>> OO is hierarchy.
>>>
>>> LOL.  This pretty much says it all.  I suggest learning something 
>>> about OOA/D; it would make the trolling more credible.
>>
>> With all due respect, I see no reason to think his education in OOA/D 
>> is lacking in any way. While his statement is a simplification and a 
>> generalization, it is accurate at least to a first-order approximation.
> 
> I can't think of a single statement that would be more antithetical to 
> what the OO paradigm is about.

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

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


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

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

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

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

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

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


   Problem space abstraction

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


, peer-to-peer collaboration

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

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


> separation of message and method

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

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


, encapsulation

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

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


, flexible logical
> indivisibility

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

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

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

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


, and all the rest of that OO stuff

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


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

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

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


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

http://en.wikipedia.org/wiki/Ravioli_code
0
bbadour (434)
6/25/2006 6:31:13 PM
Bob Badour wrote:
> H. S. Lahman wrote:
>> Responding to Badour...
>>
>>>>> OO is hierarchy.
>>>>
>>>> LOL.  This pretty much says it all.  I suggest learning something 
>>>> about OOA/D; it would make the trolling more credible.
>>>
>>> With all due respect, I see no reason to think his education in OOA/D 
>>> is lacking in any way. While his statement is a simplification and a 
>>> generalization, it is accurate at least to a first-order approximation.
>>
>> I can't think of a single statement that would be more antithetical to 
>> what the OO paradigm is about.
> 
> Thank you for stepping forward to exemplify my recent statement that use 
> of the word 'paradigm' is the surest sign of a self-aggrandizing 
> ignorant. 

I'm losing count now, but I think you have said that around 15 times in 
this thread alone...

After all, 'paradigm' has many meanings where for each meaning
> a better word exists. http://en.wikipedia.org/wiki/Buzzword
> 

Snipped Bob's usual standard of contribution....


<Said in the Jerry Springer style)

"Go-Bob, Go-Bob, Go-Bob"

0
news261 (167)
6/25/2006 6:39:13 PM
> > I can't think of a single statement that would be more antithetical to
> > what the OO paradigm is about.
>
> Thank you for stepping forward to exemplify my recent statement that use
> of the word 'paradigm' is the surest sign of a self-aggrandizing
> ignorant. After all, 'paradigm' has many meanings where for each meaning
> a better word exists. http://en.wikipedia.org/wiki/Buzzword
>
> OO is a computational model and not a paradigm unless by 'paradigm' one
> means an example of a computational model. Idiot. Further, it is a
> computational model comprising a collection of features useful for
> constructing large unpredictable state machines from small predictable
> state machines or otherwise picked arbitrarily in the mid to late 1960's
> for what seemed expedient at the time.
>

Lighten up, guys. "Paradigm" might not be precise, but few words are in
software design.  There are often may ways to say the same thing and
many ways to interpret definitions and many ways to write a program to
return the same answer.

I suggest you try to focus on more practical issues, such as comparing
solutions to realistic scenarios rather than get bogged down in a
definition battle. When software design is turned into a science rather
than an art, then revisit definitions. Until then, stop bickering over
art.

-T-

0
topmind (2124)
6/25/2006 9:14:32 PM
Bob Badour wrote:
> David Cressey wrote:
> > Doesn't region identification depend on the topology of the space?   If you
> > graph were on the surface of a torus, wouldn't you come
> > up with possibly different regions?  (viz.  the seven
> > color map theorem for the surface of a torus)
>
> If it were on a torus, it would not be on a plane.

mAsterdam wrote:
> David Cressey wrote:
> > Chris Smith wrote:
> > > 2. Identify all of the regions.  Regions are the empty
> > > spaces on your paper, and are separated by edges from
> > > the graph.  The blank space outside of where you've
> > > drawn the graph DOES count as a region, so there is
> > > always at least one.  If the graph is a tree, for
> > > example, then there is only one region, so the dual
> > > only has one vertex.
> >
> > Doesn't region identification depend on the topology of
> > the space?
>
> That complication is thrown out of scope by /planar/
> in the problem-statement (which, I think, is accepted):
>
>      Given A planar graph G, compute its dual graph G'

It's clear that Chris Smith was talking about an embedding
in the plane. That said, graph planarity is independent of
whether the graph is or is not embedded. Saying that a graph
is planar is simply a statement that an embedding in the
plane (without crossings) is possible. However, a planar
graph can be embedded in other spaces and yet it is still a
planar /graph/. Consider, what would you call a graph with
no subgraphs homeomorphic to K5 or K3,3 when embedded on a
torus? It would still be called a planar graph I believe.

-- Keith -- Fraud 6

0
duggar (292)
6/25/2006 9:17:43 PM
Neo wrote:
> > > ... 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:
> > T_Links (srcNd_ID, destNd_ID, weight);
> > T_Node (node_ID, activationFuncInd, activationWeight);
>
> :) Ddb evolved from similar schemas. The above method, which I refer to
> as generic modelling, shifts "schema" modification from being
> table-centric to row-centric.

Well, whatever it is called, it shows that RDB's are flexible. If you
want skinny tables with dynamic attributes, you can. (I agree that
existing vendors and query languages don't aways make such easy, but
that is the fault of implementation, not of relational theory.)

-T-

0
topmind (2124)
6/25/2006 9:19:51 PM
> > how about: The advantages provided by RMDBs are diminished when:
> > 1) the structure of know data is highly-varied (or non-uniform).
> > 2) the structure of new data is unknown.
>
> What I read is an unbalanced, vague impression.
> FWIW: it doesn't make me say: "No no no,
> this is completely wrong!" - but that's about it
> (BTW I'd leave the RM out, in this case. Just DB).

Ok, but in general, the above two don't apply to dbd. Dbd's
advantage/disadvantages aren't affected by simplicity or complexity of
data structure. Its method to represent either is the same (albeit more
of the same steps). And the impact on existing schema/queries/code as a
result of adapting to new data requirements is less than other
methodologies that I am aware of.

> It is important to find a good way of stating requirements.
> Up to now I don't think you have found it.

To develop a computing system similar to the human mind. Or less
ambitiously, to develop a flexible system that is minimally impacted in
terms of schema/scripts/queries/code by the need to meet future unknown
requirements at run-time. (see post# 137 on May 8 in "Storing data and
code in a Db with LISP-like interface").

0
neo55592 (356)
6/25/2006 9:27:42 PM
topmind wrote:

>>>I can't think of a single statement that would be more antithetical to
>>>what the OO paradigm is about.
>>
>>Thank you for stepping forward to exemplify my recent statement that use
>>of the word 'paradigm' is the surest sign of a self-aggrandizing
>>ignorant. After all, 'paradigm' has many meanings where for each meaning
>>a better word exists. http://en.wikipedia.org/wiki/Buzzword
>>
>>OO is a computational model and not a paradigm unless by 'paradigm' one
>>means an example of a computational model. Idiot. Further, it is a
>>computational model comprising a collection of features useful for
>>constructing large unpredictable state machines from small predictable
>>state machines or otherwise picked arbitrarily in the mid to late 1960's
>>for what seemed expedient at the time.
> 
> Lighten up, guys. "Paradigm" might not be precise, but few words are in
> software design.

Bullshit. Most of the words used have very precise definitions if one 
bothers to learn them. See ISO/IEC 2382 for instance.

The end product of design is necessarily precise. Can you imagine 
someone designing a building around having "some of those electric plug 
in thingies and some sort of light bulb thingie or other in every room" 
? I can see the estimate from the builder for that design coming back: 
"That'll cost you some money--you know some of those colorful pieces of 
paper they let you exchange for thingies down at the store."


   There are often may ways to say the same thing and
> many ways to interpret definitions and many ways to write a program to
> return the same answer.

And there may be many precise designs that match an analysis and 
requirements with each design making different tradeoffs. Your point?


> I suggest you try to focus on more practical issues, such as comparing
> solutions to realistic scenarios rather than get bogged down in a
> definition battle.

Why? The idiot is a self-aggrandizing ignorant and a snake-oil salesman. 
He has nothing to offer, and I have no intention of wasting much of my 
time on that sort of charlatan.


  When software design is turned into a science rather
> than an art, then revisit definitions. Until then, stop bickering over
> art.

Art or artifice? In any case, we are not discussing art. We are 
comparing formalisms.
0
bbadour (434)
6/25/2006 9:51:14 PM
Bob Badour wrote:
> topmind wrote:
>  Lighten up, 


snipped

> Why? The idiot is a self-aggrandizing ignorant and a snake-oil salesman. 


Bob's on top form tonight folks
0
news261 (167)
6/25/2006 9:55:48 PM
Andrew McDonagh wrote:
> Bob Badour wrote:
> > topmind wrote:
> >  Lighten up,
>
> snipped
>
> > Why? The idiot is a self-aggrandizing ignorant and a
> > snake-oil salesman.
>
> Bob's on top form tonight folks

And what exactly are you contributing, Andrew, with such
vacuous posts? It's clear that you do not enjoy Bob's
posts. How many times do you need to tell us? And who do you
think even cares what your "tally" of Bob is? If you have
formed a club, clique, or whatever, then please establish a
club mailing list. Otherwise, try just ignoring Bob's posts
if you want. Or just learn to filter out the parts you don't
like. Either way stop crying in public about them.

-- Keith -- Fraud 6

0
duggar (292)
6/25/2006 10:06:35 PM
Keith H Duggar wrote:

> Andrew McDonagh wrote:
> 
>>Bob Badour wrote:
>>
>>>topmind wrote:
>>> Lighten up,
>>
>>snipped
>>
>>>Why? The idiot is a self-aggrandizing ignorant and a
>>>snake-oil salesman.
>>
>>Bob's on top form tonight folks
> 
> And what exactly are you contributing, Andrew, with such
> vacuous posts? It's clear that you do not enjoy Bob's
> posts. How many times do you need to tell us? And who do you
> think even cares what your "tally" of Bob is? If you have
> formed a club, clique, or whatever, then please establish a
> club mailing list. Otherwise, try just ignoring Bob's posts
> if you want. Or just learn to filter out the parts you don't
> like. Either way stop crying in public about them.

Looking at my twit filter, I count 33, but I did not separate them by 
self-aggrandizing ignorants, cranks, and the otherwise just 
intellectually dishonest. I lumped them all together as twits.

In any case, I already twit-filtered Andrew so I would never have known 
about his count if you hadn't replied to it.

Or was he counting 16 times when I pointed out that some person in 
particular was posting self-aggrandizing ignorance?
0
bbadour (434)
6/25/2006 10:16:07 PM
Keith H Duggar wrote:
> Andrew McDonagh wrote:
>> Bob Badour wrote:
>>> topmind wrote:
>>>  Lighten up,
>> snipped
>>
>>> Why? The idiot is a self-aggrandizing ignorant and a
>>> snake-oil salesman.
>> Bob's on top form tonight folks
> 
> And what exactly are you contributing, Andrew, with such
> vacuous posts? 

snip


A good question we should have all asked JOG (th OP of this thread)
> 
> -- Keith -- Fraud 6
> 
0
news261 (167)
6/25/2006 10:17:34 PM
Bob Badour wrote:
 > Keith H Duggar wrote:
 >
 >> Andrew McDonag............

 >
 > Looking at my twit filter, I count 33, but I did not separate them by
 > self-aggrandizing ignorants, cranks, and the otherwise just
 > intellectually dishonest. I lumped them all together as twits.
 >
 > In any case, I already twit-filtered Andrew so I would never have known
 > about his count if you hadn't replied to it.

Got to love those who help get past peoples filters eh!

As Mr T says 'Damn fool!'

 >
 > Or was he counting 16 times when I pointed out that some person in
 > particular was posting self-aggrandizing ignorance?

hey, counting has been fun...but not that fun -I mean, there is more to 
life that Bob's grasp on insults.  Now maybe if Bob could extend his 
range....hhmmmmmmm........ doubtful though really eh.


Oh look - wet paint to watch.....
0
news261 (167)
6/25/2006 10:21:43 PM
Keith H Duggar wrote:
> mAsterdam wrote:
>>David Cressey wrote:
[snip]
>>>Doesn't region identification depend on the topology of
>>>the space?
>>
>>That complication is thrown out of scope by /planar/
>>in the problem-statement (which, I think, is accepted):
>>
>>     Given A planar graph G, compute its dual graph G'
> 
> It's clear that Chris Smith was talking about an embedding
> in the plane. That said, graph planarity is independent of
> whether the graph is or is not embedded. Saying that a graph
> is planar is simply a statement that an embedding in the
> plane (without crossings) is possible. However, a planar
> graph can be embedded in other spaces and yet it is still a
> planar /graph/. 

Yes, (after re-reading I can't see how I missed it)
it appears you and David are right, the complication
of the topology of the space is still in scope.
Before I make a fool of myself again:
could you restate the problem in such a way
that it /is/ out?


> Consider, what would you call a graph with
> no subgraphs homeomorphic to K5 or K3,3 when embedded on a
> torus? It would still be called a planar graph I believe.

?

-- 
"The person who says it cannot be done
should not interrupt the person doing it."
Chinese Proverb.
0
mAsterdam (155)
6/25/2006 10:28:25 PM
Bruno Desthuilliers wrote:
> Marshall wrote:
> > Bruno Desthuilliers wrote:
> >
> >>>Yes, but SQL DBMSs are not R DBMSs.
> >>
<snip>

> > 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.

We use them now, in real world life, such as breaking down the bill of
materials for airplanes.

>
> 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.
>

There are quite a few DBMS products that offer the transitive closure
operation.  Teradata has the WITH RECURSIVE statement.  DB2 has a
similar transitive closure syntax, both coming somewhat close to a
standard SQL sytanx.  Oracle still uses the CONNECT BY, which is
unfortunate, but merely implies a translation exercise when trying
"swap out" DBMS support, if that is really a super important reason to
some.

Swapping "persistence engines" might be a big thing for some, but I
would prefer to see the transitive closure operation actually performed
right and consistently, and I certainly haven't seen such implemented
systematically (i.e. consistent) with OO procedural code.

"Persistence engines" already exist in the form of VERSANT, Gemstone,
Poet (now versant), etc. many of which that once claimed themselves
DBMS's, but that now sell themselves as middleware transparent
persistence engines.  These persistence engines are not necessarily
DBMSs, so from a practical standpoint, the market has already made the
distinction between good data management systems and persistent storage
mechanisms.

Moreover, since constraints and data management services provided by
the SQL DBMS offer greater assurances that identity from the business's
domain of discourse will be represented with a degree of fidelity
rather than a general low-level system's level identity artifact that
is navigational in nature and often carries the baggage of identifying
things from an application gui identity approach, one can write
multiple transitive closure operations over the same business domain
from many different access points, and thus can ask and answer
questions using names users use, over both graphs and hierarchies
without getting inconsistent results.

- Dan
> --
> bruno desthuilliers
> python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
> p in 'onurb@xiludom.gro'.split('@')])"

0
6/25/2006 10:29:55 PM
Andrew McDonagh wrote:
> Bob Badour wrote:
> > H. S. Lahman wrote:
> >> Responding to Badour...
<snip>

> I'm losing count now, but I think you have said that around 15 times in
> this thread alone...
>
> After all, 'paradigm' has many meanings where for each meaning
> > a better word exists. http://en.wikipedia.org/wiki/Buzzword
> >
>
> Snipped Bob's usual standard of contribution....

So Andrew, do you have any interesting comments or opinions concerning
the other content of the post, other than counting words?

Where do you think Bob was wrong, or right?

Thanks,

Dan


> 
> 
> <Said in the Jerry Springer style)
> 
> "Go-Bob, Go-Bob, Go-Bob"

0
6/25/2006 11:04:38 PM
Dan wrote:
> Andrew McDonagh wrote:
>> Bob Badour wrote:
>>> H. S. Lahman wrote:
>>>> Responding to Badour...
> <snip>
> 
>> I'm losing count now, but I think you have said that around 15 times in
>> this thread alone...
>>
>> After all, 'paradigm' has many meanings where for each meaning
>>> a better word exists. http://en.wikipedia.org/wiki/Buzzword
>>>
>> Snipped Bob's usual standard of contribution....
> 
> So Andrew, do you have any interesting comments or opinions concerning
> the other content of the post, other than counting words?
> 
> Where do you think Bob was wrong, or right?
> 

Oh God, Dan,  I like others, gave up trying to find wisdom, knowledge or 
anything of use within Bob's post, long ago.

Its just too tiring, they are hidden so well within his insults.

So, given that I nor others can't convince Bob to change his posting 
style so that we may bask in his magnificence, I decided to read Bob's 
posts from a different angle.

Mainly one of 'let's see how many times per thread can Bob can repeat 
his favourite insult: Self-aggrandising idiot'

Got to say - it makes reading his posts SSSsoooooo much more fun and 
less tiring.


> Thanks,

My Pleasure Dan
> 
> Dan


Andrew
0
news261 (167)
6/25/2006 11:30:05 PM
topmind wrote:
> > > I can't think of a single statement that would be more antithetical to
> > > what the OO paradigm is about.
> >
> > Thank you for stepping forward to exemplify my recent statement that use
> > of the word 'paradigm' is the surest sign of a self-aggrandizing
> > ignorant. After all, 'paradigm' has many meanings where for each meaning
> > a better word exists. http://en.wikipedia.org/wiki/Buzzword
> >
> > OO is a computational model and not a paradigm unless by 'paradigm' one
> > means an example of a computational model. Idiot. Further, it is a
> > computational model comprising a collection of features useful for
> > constructing large unpredictable state machines from small predictable
> > state machines or otherwise picked arbitrarily in the mid to late 1960's
> > for what seemed expedient at the time.
> >
>
> Lighten up, guys. "Paradigm" might not be precise, but few words are in
> software design.  There are often may ways to say the same thing and
> many ways to interpret definitions and many ways to write a program to
> return the same answer.

Yeah, uh, I'm going to have to disagree with you there, topmind.
Terminology may be precise or fuzzy. It is important that regularly
practicing either becomes a habit. I suggest that one can, in part,
judge the quality of the company (in a technical context) by the
precision of their terminology.


> I suggest you try to focus on more practical issues, such as comparing
> solutions to realistic scenarios rather than get bogged down in a
> definition battle. When software design is turned into a science rather
> than an art, then revisit definitions. Until then, stop bickering over
> art.

I think the idea of software as art is something of an
anti-intellectual one.


Marshall

0
6/25/2006 11:59:44 PM
Andrew McDonagh wrote:
> Dan wrote:
> >
> > So Andrew, do you have any interesting comments or opinions concerning
> > the other content of the post, other than counting words?
> >
> > Where do you think Bob was wrong, or right?
> >
>
> Oh God, Dan,  I like others, gave up trying to find wisdom, knowledge or
> anything of use within Bob's post, long ago.

Well, gee, Andrew, at least when you say that you're not even
trying to understand Bob, that is more honest than when you
say that Bob isn't actually saying anything. The fact that the
problem lies with you vs. Bob is an important distinction.


> Its just too tiring, they are hidden so well within his insults.

What, you can't tell the insults from the content? Here's an idea:
take some of Bob's posts, pull them in to your favorite text
editor, and edit out the insults *and only* the insults.

Try it:

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

becomes:

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

Not all that hard, really. And you're left with something that is
actually
quite well written, and quite cogent.


Marshall

0
6/26/2006 12:24:18 AM
Chris Smith wrote:
> [...]

Thanks for the very informative writeup.

Upon further (modest) analysis of the problem, it appears that finding
regions from edges is a transitive closure problem, so there is,
I will not say "difficulty" but perhaps "challenge." The rest is
more or less trivial.


> - You don't need faces; just a (unordered) nodes and edges.

Are you sure?

Consider a square, with four points, top-left, top-right, bottom-left,
bottom-right. Now add a fifth edge, from top-right to bottom-left.

If this edge goes through the interior of the square, that is a
different set of regions than if it goes around the outside of
the square.


Marshall

0
6/26/2006 12:34:20 AM
Dmitry A. Kazakov wrote:
>
> My feeling is that it could turn quite hard for RA. That's why I've
> presented it! (:-)) The feeling is based on a trivial observation that the
> nodes of the dual graph aren't present in the original graph either as
> nodes or as relations. You have to "invent" them (identify the regions).

Every query is an "invention" in this sense. Sometimes it is a trivial
one, when all one does it pick out some rows and/or columns. But
you can also write expressions. Simple example: select a+b as c from R.

Where did c come from in the result set? It wasn't there in the
original relation.

Does anyone know if SQL with transitive closure is Turing complete
or not? Alternatively, does anyone know what minimum additional
functionality is necessary to bring SQL to Turing completeness?
What about same question for the RA?

I note that any relational algebra that allows natural join with
recursive functions is Turing complete.


Marshall

0
6/26/2006 12:39:20 AM
> By the way, do any real-estate listings really track fridges?

The andriod-based realtor that I am wiring in my garage, will :)

> Most of your allegedly tough examples are based on physical modeling.

If you mean't any modelling that that requires a table join or
hierarchy, then there is some truth to that. In general, modelling
hierarchies in RM cause some minor adjustments where as in dbd, it
makes little difference if one is modelling a list, tree, table, or
graph; they all require equally verbose scripts :) but the method
remains largely unchanged.

The tough part of dbd examples are the minimal impact to existing
data/scripts/queries/code when meeting new data requirements unknown in
advance (see example below).

> > [Sample query to find first real-estate listing in dbd example 117]:
> >
> > (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))))))
>
> [RMDB's query]:
> 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")
>
> Note that I am assuming that the fridge can be anywhere in the house.
> Adding kitchen-only would add another clause or join to the query.

The above two queries are roughly equivalent (although the underlying
data is structure is different, may need to add T_hasHierarchy). The
most significant difference that is determinable from the queries is
that in dbd's example, the fridge is located in the kitchen, where as
in the RMDB example, the fridge is located in the house (which makes
the RMDB query slightly simpler). Another signficant different that the
fridge is a thing that could be move from one room to another or even
one house to another without worrying about what
attributes/subParts/contents belong to it.

> People often put a 2nd fridge in their garage...  I wonder how your query would look if the fridge could be in any room.

Below is dbd's script to create a second fridge and locate it in the
garage. The new fridge is also classified as an appliance. It's serial#
is FRZ001. It's manufacturer is Panasonic whose phone# is 333-4444..
It's style is low-profile. It needs freon. Both serial# and phone# are
attributes that are created on-the-fly.

(create (and (select garage instance *)
             (select (select * MLS# A2868Z) has *))
        has
        (block (new)
               (create appliance instance (it))
               (create fridge instance (it))
               (block (new 'FRZ001 'serial#))
               (create (it) (. 'serial#) (. 'FRZ001))
               (create (it) mfg (block (new)
                                       (create mfg instance (it))
                                       (create (it) name (word+
'panasonic))
                                       (block (new '333-4444 'phone#))
                                       (create (it) (. 'phone#) (.
'333-4444))
                                       (return (it))))
               (create (it) style (val+ 'low-profile))
               (create (it) note (val+ 'needs_freon))
               (return (it))))

The significant thing that I wanted you (and mAsterdam) to notice is
that adding the second fridge, which was unknown when the data was
original modelled, doesn't affect the original script/schema/queries.
Below is a new query (old one still works) to find house using the
added fridge. Also note that this query includes a second color (pink)
for carpet. The carpet in that room always had 2 colors previously but
the first query only utilized one of its colors. The carpet is a thing
that has its own attributes, etc and could be move to attic, if
desired.

(and (select single-family instance *)
     (select * has (and (select bedroom instance *)
                        (select * has (and (select carpet instance *)
                                           (select * color pink)
                                           (select * color purple)))))
     (select * has (and (select kitchen instance *)
                        (select * has (and (select fridge instance *)
                                           (select * mfg sears)))))
     (select * has (and (select garage instance *)
                        (select * has (and (select fridge instance *)
                                           (select * mfg
panasonic))))))

Note: I will be updating the web page to include the above additions.

0
neo55592 (356)
6/26/2006 12:45:13 AM
Marshall wrote:
> What, you can't tell the insults from the content? Here's
> an idea: take some of Bob's posts, pull them in to your
> favorite text editor, and edit out the insults *and only*
> the insults.
>
> Try it:

[snip example]

> Not all that hard, really. And you're left with something
> that is actually quite well written, and quite cogent.

Fascinating. I actually found it more clear /with/ the
insult. Go figure. Maybe it helps to highlight points of
disagreement?

Andrew McDonagh wrote:
> Bob Badour wrote :
> > In any case, I already twit-filtered Andrew so I would
> > never have known about his count if you hadn't replied
> > to it.
>
> Got to love those who help get past peoples filters eh!
>
> As Mr T says 'Damn fool!'

I'm not sure who you are calling a fool. If it is "those
people" you directed it to, let me inform you that other
people's twit filters do not concern me in the slightest.

> So, given that I nor others can't convince Bob to change
> his posting style so that we may bask in his magnificence,
> I decided to read Bob's posts from a different angle.
>
> Mainly one of 'let's see how many times per thread can Bob
> can repeat his favourite insult: Self-aggrandising idiot'
>
> Got to say - it makes reading his posts SSSsoooooo much
> more fun and less tiring.

So you are having fun at the expense of others who read the
group? How mature and considerate of you. Vaguely seems like
nascent C'mode behavior. Perhaps you should nip the bud.

-- Keith -- Fraud 6

0
duggar (292)
6/26/2006 12:47:44 AM
Andrew McDonagh wrote:
> Dan wrote:
> > Andrew McDonagh wrote:
> >> Bob Badour wrote:
> >>> H. S. Lahman wrote:
> >>>> Responding to Badour...
> > <snip>
> >
> >> I'm losing count now, but I think you have said that around 15 times in
> >> this thread alone...
> >>
> >> After all, 'paradigm' has many meanings where for each meaning
> >>> a better word exists. http://en.wikipedia.org/wiki/Buzzword
> >>>
> >> Snipped Bob's usual standard of contribution....
> >
> > So Andrew, do you have any interesting comments or opinions concerning
> > the other content of the post, other than counting words?
> >
> > Where do you think Bob was wrong, or right?
> >
>
> Oh God, Dan,  I like others, gave up trying to find wisdom, knowledge or
> anything of use within Bob's post, long ago.
>
> Its just too tiring, they are hidden so well within his insults.
>
While I certainly agree that colorful use of the language can either be
1) a turn-off or 2) entertaining, but distracting, I am trying to learn
new things and reconcile different perspectives, all of which might be
valid, but within different contexts.

Now on the usenet, anybody can assert anything or claim themselves an
expert.  So, it has been useful for me to synthesize and isolate 1)
logical argument form aside from the use of language which can be
fettered for a variety of reasons, aside from just insults; and 2)
reconcile assertions of fact within that argument form.

So I'm more of a substance guy than one that gives credence to
appearance and politically correct use of rhetoric.  When I read your
post, I read 'no substance', but when I read Bob's post, I read
'insulting, ascerbic, but full of substance and validity in the absence
of counterexamples'.

> So, given that I nor others can't convince Bob to change his posting
> style so that we may bask in his magnificence, I decided to read Bob's
> posts from a different angle.
>
Ok.

> Mainly one of 'let's see how many times per thread can Bob can repeat
> his favourite insult: Self-aggrandising idiot'
>
Ok.  But that doesn't do much for me, the guy trying to glean insight
from your expertise.

> Got to say - it makes reading his posts SSSsoooooo much more fun and
> less tiring.
>
> 
> > Thanks,
> 
> My Pleasure Dan
> > 
> > Dan
> 
> 
> Andrew

Cheers!

0
6/26/2006 12:51:29 AM
Keith H Duggar wrote:
> Marshall wrote:
> > What, you can't tell the insults from the content? Here's
> > an idea: take some of Bob's posts, pull them in to your
> > favorite text editor, and edit out the insults *and only*
> > the insults.
> >
> > Try it:
>
> [snip example]
>
> > Not all that hard, really. And you're left with something
> > that is actually quite well written, and quite cogent.
>
> Fascinating. I actually found it more clear /with/ the
> insult. Go figure. Maybe it helps to highlight points of
> disagreement?

Let me be clear: I thought it was cogent before the edit as well.

I remain deeply ambivalent about Bob's use of insults. Sometimes,
I think that all they do is distract and inflame. Other times, I think
that in fact Bob is the only one rude enough to cut through
the bullshit and point out the ridiculousness of what people are
saying. Sometimes I think he's too quick on the trigger, other
times it seems as if he's the first one to figure out when we're
being snowed. Maybe all those are true, I dunno.

What I have never done, however, is mistake the presence
of insults for the absence of content. Bob always has content.
And I might add, a laserlike command of terminology, which
frankly impresses the hell out of me.


Marshall

0
6/26/2006 1:16:39 AM
mAsterdam wrote:
> Yes, (after re-reading I can't see how I missed it) it
> appears you and David are right, the complication of the
> topology of the space is still in scope. Before I make a
> fool of myself again: could you restate the problem in
> such a way that it /is/ out?

Graph theory is definitely /not/ something I have a deep
understanding of. I think Chris was just trying to help give
Marshall a more intuitive feel for the problem. Hence the
description of a graph embedded in a plane etc. I was just
pointing out that a graph is or is not planar regardless of
what space you embed it in.

> > Consider, what would you call a graph with no subgraphs
> > homeomorphic to K5 or K3,3 when embedded on a torus? It
> > would still be called a planar graph I believe.

A graph is planar if and only if it contains no subgraphs
"equivalent" (for a particular notion of equivalence in this
case homeomorphism) to either K5 or K3,3. K5 is the graph of
5 completely connected nodes. In other words an edge from
each node to every other node. And K3,3 is a graph with two
groups of three nodes where each node is connected to every
node in the other group.

So you see the planarity of a graph can be stated without
any reliance on embedding.

-- Keith -- Fraud 6

0
duggar (292)
6/26/2006 1:22:59 AM
Marshall <marshall.spight@gmail.com> wrote:
> > - You don't need faces; just a (unordered) nodes and edges.
> 
> Are you sure?
> 
> Consider a square, with four points, top-left, top-right, bottom-left,
> bottom-right. Now add a fifth edge, from top-right to bottom-left.
> 
> If this edge goes through the interior of the square, that is a
> different set of regions than if it goes around the outside of
> the square.

Yes, those are different planar embeddings, so they have different 
duals.  (The duals happen to be isomorphic to each other in this case, 
but that's just a coincidence; not necessarily guaranteed to always be 
true.)  This gets back to the fact that duals are really an operation on 
planar embeddings[*] of graphs rather than on graphs.  The phrase "dual 
of a graph" means "a dual of some planar embedding of that graph".  So 
using either embedding would give you a correct answer.  However, yes 
you would need to pick an embedding of the graph at some point to use 
the geometric algorithm.  (The combinatorial dual, which is equivalent 
to a geometric dual but is defined in a completely different way, may be 
more amenable to computation via the relational model than a planar 
embedding of the graph.  However, you'll have to find someone who knows 
about it to explain combinatorial duals to you.)

I didn't think of that as needing faces... mainly because the word 
"faces" was used in a different sense by the MathWorld article that 
someone posted a link to earlier (it was talking about the three-
dimensional analog of a dual for a polyhedral graph), and I just assumed 
that you saw the word "faces" there.

[*] Since someone brought up topology, I suppose this would be an 
opportune time to point out that duals are formally described in terms 
of embeddings on a sphere, rather than a plane.  That turns out to be 
equivalent, because the embedding can't possibly depend on every single 
point of the sphere, so it's always possible to remove a point of the 
sphere and thus turn it into the topological equivalent of a plane.  The 
use of a sphere turns out to be different from use of a plane, except 
that it removes that messiness about having to specify that "outside" 
counts as a region.  I am not familiar with embeddings on torii (sp?) 
and thus can't comment on that aspect of the conversation.  It certainly 
seems reasonable that there could be graphs that could be embedded on 
torii but which are not planar, in which case there may be something 
like a torus-embedding that's analogous to a dual; but if so, that is 
not what is normally meant by the word "dual".

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/26/2006 1:25:39 AM
Marshall wrote:
> Chris Smith wrote:
> 
>>[...]
> 
> Thanks for the very informative writeup.
> 
> Upon further (modest) analysis of the problem, it appears that finding
> regions from edges is a transitive closure problem, so there is,
> I will not say "difficulty" but perhaps "challenge." The rest is
> more or less trivial.
> 
>>- You don't need faces; just a (unordered) nodes and edges.
> 
> 
> Are you sure?
> 
> Consider a square, with four points, top-left, top-right, bottom-left,
> bottom-right. Now add a fifth edge, from top-right to bottom-left.
> 
> If this edge goes through the interior of the square, that is a
> different set of regions than if it goes around the outside of
> the square.

Marshall, I direct your attention to _Written in Anger_ EDW 696.

Suppose one labelled each of the above nodes A, B, C, D respectively. 
One has the following edges: AB, AC, BD, CD and finally BC.

There is a region that is adjacent to AB, AC, BD and CD that is not 
adjacent to BC regardless whether one draws BC through the middle of the 
square or around the square. Lets call that region ABCD.

Likewise, there is a region that is adjacent to AB, AC and BC that is 
not adjacent to BD or CD. Let's call that region ABC. Similarly, there 
is a region adjacent to BD, CD and BC that is not adjacent to AB or AC. 
Let's call that region BCD.

If you draw BC through the square, then ABCD is the outer region with 
ABC and BCD on either side of BC inside the square.

If you draw BC below the square, then ABC is the outer region, BCD lies 
between BC and the square, while ABCD is the interior of the square.

If you draw BC above the square, then BCD is the outer region, ABC lies 
between BC and the square, while again ABCD is the interior of the square.

However, in all the above cases, we have the same regions: ABCD, ABC and 
BCD. Of course, what I called a square above could be drawn as any 
arbitrary quadrilateral without changing anything.

Interestingly, the above suggests to me an excellent justification for 
relation-valued attributes as candidate keys for an edge relation and a 
region relation except that it would not necessarily work for the dual 
due to the multiplicity of edges between nodes. Hmmmm.

But then again, the logical identity for what we draw as an edge in a 
dual is really two regions and an edge, and one could make all three 
attributes relation-valued attributes.

Interesting.
0
bbadour (434)
6/26/2006 1:30:37 AM
Andrew McDonagh wrote:
> Dan wrote:
> 
>> Andrew McDonagh wrote:
>>
>>> Bob Badour wrote:
>>>
>>>> H. S. Lahman wrote:
>>>>
>>>>> Responding to Badour...
>>
>> <snip>
>>
>>> I'm losing count now, but I think you have said that around 15 times in
>>> this thread alone...
>>>
>>> After all, 'paradigm' has many meanings where for each meaning
>>>
>>>> a better word exists. http://en.wikipedia.org/wiki/Buzzword
>>>>
>>> Snipped Bob's usual standard of contribution....
>>
>> So Andrew, do you have any interesting comments or opinions concerning
>> the other content of the post, other than counting words?
>>
>> Where do you think Bob was wrong, or right?
>>
> 
> Oh God, Dan,  I like others, gave up trying to find wisdom, knowledge or 
> anything of use within Bob's post, long ago.

Too bad,  Bob's taken me to the woodshed a couple times for sloppy
writing - and I learned from it.  And he's accepted criticism for
exactly the same thing.  After all, this is a newsgroup and our
missives aren't regularly publication quality work; there are
plenty of opportunities to clarify our thoughts and straighten-
out our thinking.

If a contributor doesn't show signs of learning from mistakes,
Bob lays it on.

[snip]
0
J
6/26/2006 1:44:56 AM
Marshall wrote:

> Dmitry A. Kazakov wrote:
> 
>>My feeling is that it could turn quite hard for RA. That's why I've
>>presented it! (:-)) The feeling is based on a trivial observation that the
>>nodes of the dual graph aren't present in the original graph either as
>>nodes or as relations. You have to "invent" them (identify the regions).
> 
> Every query is an "invention" in this sense. Sometimes it is a trivial
> one, when all one does it pick out some rows and/or columns. But
> you can also write expressions. Simple example: select a+b as c from R.
> 
> Where did c come from in the result set? It wasn't there in the
> original relation.
> 
> Does anyone know if SQL with transitive closure is Turing complete
> or not? Alternatively, does anyone know what minimum additional
> functionality is necessary to bring SQL to Turing completeness?
> What about same question for the RA?
> 
> I note that any relational algebra that allows natural join with
> recursive functions is Turing complete.

Dmitry is wrong about identifying regions. (See my reply where I 
directed you to EWD 696.) An edge is a non-empty set of at most two 
nodes. A region is a non-empty set of nodes. This suggests to me the 
domains in question are relation valued.

The 'nodes' of a dual are regions. The 'edges' of a dual are a tuple of 
a non-empty set of at most two regions plus the edge in the original 
graph which acts as the separator between the region(s).
0
bbadour (434)
6/26/2006 1:45:37 AM
Marshall <marshall.spight@gmail.com> wrote:
> Dmitry A. Kazakov wrote:
> >
> > My feeling is that it could turn quite hard for RA. That's why I've
> > presented it! (:-)) The feeling is based on a trivial observation that the
> > nodes of the dual graph aren't present in the original graph either as
> > nodes or as relations. You have to "invent" them (identify the regions).
> 
> Every query is an "invention" in this sense. Sometimes it is a trivial
> one, when all one does it pick out some rows and/or columns. But
> you can also write expressions. Simple example: select a+b as c from R.

I don't know anything about the theoretical limits of relational algebra 
or SQL.  However, my intuition is that Dmitry might be right about 
finding a planar embedding.  I believe I mentioned earlier that it's 
neither an obvious nor a trivial problem.  Aside from that, though, the 
reason I doubt the ability to express it in SQL is, roughly speaking, 
that there are several right answers, each of which is going to be some 
arbitrary number of tuples, and there is no obvious way to distinguish 
between the answers.  My feeling (and I say feeling in the sense of "I 
don't really know") about SQL is that there's no obvious way to ask for 
just the first answer that becomes apparent, nor for it to assign some 
arbitrary "solution number" for each solution.  So I wouldn't even know 
what results in relational form, much less how to write the query!

If I'm wrong about the above, then you can ignore my conclusion.  I 
don't claim to have knowledge in this area.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/26/2006 2:03:47 AM
Chris Smith wrote:
> Marshall <marshall.spight@gmail.com> wrote:
> > Dmitry A. Kazakov wrote:
> > >
> > > My feeling is that it could turn quite hard for RA. That's why I've
> > > presented it! (:-)) The feeling is based on a trivial observation that the
> > > nodes of the dual graph aren't present in the original graph either as
> > > nodes or as relations. You have to "invent" them (identify the regions).
> >
> > Every query is an "invention" in this sense. Sometimes it is a trivial
> > one, when all one does it pick out some rows and/or columns. But
> > you can also write expressions. Simple example: select a+b as c from R.
>
> I don't know anything about the theoretical limits of relational algebra
> or SQL.  However, my intuition is that Dmitry might be right about
> finding a planar embedding.  I believe I mentioned earlier that it's
> neither an obvious nor a trivial problem.

Excuse me, but the "planar embedding" idea was never in the original
challenge. He stated "find the dual of a graph" and that turned out to
be trivial if faces of the planar graph are known. Yes, "face" is a
legitimate concept -- p.13 of Algebraic Graph Theory byGodsil&Royle. If
they are not known, then please provide a formal way to define planar
embedding. Without planar embedding the problem is ambiguous. The
answer for ambiguous problem would be a set of dual graphs, and when
answer becomes a set of structures it is usually much harder query.
However, his query was "find the dual of a graph" where the "dual" is
singular. Therefore, just accept the defeat.

0
6/26/2006 3:04:07 AM
Aloha Kakuikanu <aloha.kakuikanu@yahoo.com> wrote:
> However, his query was "find the dual of a graph" where the "dual" is
> singular. Therefore, just accept the defeat.

Umm, alrighty then.  Someone got up on the wrong side of the bed.

I was just providing information.  That information is that finding the 
dual graph is trivial given some useful description of a plane 
embedding; and also that finding a plan embedding, while it is possible 
in linear time, is decidedly not a trivial problem.  It's at least 
sufficiently non-trivial that even though I understand the general idea 
of Bob Tarjan's algorithm, I don't think I could actually do it in any 
language, SQL included, without a good bit of research.  More research 
than I'd do just because of a newsgroup post.  And I seem to know as 
much about the problem as most people here.

As it turns out, I don't much care whether SQL is a suitable language 
for finding a dual of a graph.  I've never needed to find a dual of a 
graph.  I just happened to have information that was being asked about.

I do find your word games interesting, though.  I could easily conclude 
that the problem as originally stated is unsolvable (i.e., there is no 
"the" dual of a graph).  However, it's going a bit far to start 
confusing graphs with their planar embeddings.  Graphs still don't have 
faces, regardless of any mistakes that Dmitry may have made in phrasing 
the problem.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/26/2006 4:09:11 AM
Neo wrote:
> > By the way, do any real-estate listings really track fridges?
>
> The andriod-based realtor that I am wiring in my garage, will :)
>
> > Most of your allegedly tough examples are based on physical modeling.
>
> If you mean't any modelling that that requires a table join or
> hierarchy, then there is some truth to that. In general, modelling
> hierarchies in RM cause some minor adjustments where as in dbd, it
> makes little difference if one is modelling a list, tree, table, or
> graph; they all require equally verbose scripts :) but the method
> remains largely unchanged.
>
> The tough part of dbd examples are the minimal impact to existing
> data/scripts/queries/code when meeting new data requirements unknown in
> advance (see example below).
>
> > > [Sample query to find first real-estate listing in dbd example 117]:
> > >
> > > (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))))))
> >
> > [RMDB's query]:
> > 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")
> >
> > Note that I am assuming that the fridge can be anywhere in the house.
> > Adding kitchen-only would add another clause or join to the query.
>
> The above two queries are roughly equivalent (although the underlying
> data is structure is different, may need to add T_hasHierarchy). The
> most significant difference that is determinable from the queries is
> that in dbd's example, the fridge is located in the kitchen, where as
> in the RMDB example, the fridge is located in the house (which makes
> the RMDB query slightly simpler). Another signficant different that the
> fridge is a thing that could be move from one room to another or even
> one house to another without worrying about what
> attributes/subParts/contents belong to it.
>
> > People often put a 2nd fridge in their garage...  I wonder how your query would look if the fridge could be in any room.
>

For the need it looks like you have in mind, perhaps it may make more
sense to create a "meta" table(s) with dynamic attributes rather than a
table for each kind of thing (furniture, rooms, etc). If a dynamic
RDBMS existed in practice, such may not be necessary. But with the
existing Oracle-copy-cat static-style RDBMS out there, skinny tables
may be in order for your needs.

-T-

0
topmind (2124)
6/26/2006 5:49:08 AM
Chris Smith wrote:
> Aloha Kakuikanu <aloha.kakuikanu@yahoo.com> wrote:
> > However, his query was "find the dual of a graph" where
> > the "dual" is singular. Therefore, just accept the
> > defeat.
>
> Umm, alrighty then.  Someone got up on the wrong side of
> the bed.

Does he sleep? :-)

> I was just providing information ... that finding a plan
> embedding, while it is possible in linear time, is
> decidedly not a trivial problem. It's at least
> sufficiently non-trivial that even though I understand the
> general idea of Bob Tarjan's algorithm, I don't think I
> could actually do it in any language, SQL included,
> without a good bit of research. More research than I'd do
> just because of a newsgroup post. And I seem to know as
> much about the problem as most people here.

I couldn't agree with you more on all points. I can't even
think of a naive (even exponential) algorithm that is what I
would call "simple". You know of any super-naive slow as
hell but simple algorithms? How about a randomized one?

We never covered this problem in any of the algorithms or
computation courses I took. If one wanted to compare network
and relational implementations I can think of /many/ more
commonly useful algorithms: minimum spanning tree, shortest
path, all-pairs shortest path, isomorphism etc.

Hehe ... it all goes back to Dimitry's seemingly innocent
little challenge: "And, guys, what about presenting a query
statement for building a dual graph?" In hindsight it seems
to be a sneak attack. Or maybe DAK had a deeper purpose and
it trying to point out something fundamental. However, I'm
more inclined to agree with you that finding the dual would
be a pain in any language.

-- Keith -- Fraud 6

0
duggar (292)
6/26/2006 5:59:36 AM
On 25 Jun 2006 20:04:07 -0700, Aloha Kakuikanu wrote:

> Chris Smith wrote:
>> Marshall <marshall.spight@gmail.com> wrote:
>>> Dmitry A. Kazakov wrote:
>>> >
>>> > My feeling is that it could turn quite hard for RA. That's why I've
>>> > presented it! (:-)) The feeling is based on a trivial observation that the
>>> > nodes of the dual graph aren't present in the original graph either as
>>> > nodes or as relations. You have to "invent" them (identify the regions).
>>>
>>> Every query is an "invention" in this sense. Sometimes it is a trivial
>>> one, when all one does it pick out some rows and/or columns. But
>>> you can also write expressions. Simple example: select a+b as c from R.
>>
>> I don't know anything about the theoretical limits of relational algebra
>> or SQL.  However, my intuition is that Dmitry might be right about
>> finding a planar embedding.  I believe I mentioned earlier that it's
>> neither an obvious nor a trivial problem.
> 
> Excuse me, but the "planar embedding" idea was never in the original
> challenge. He stated "find the dual of a graph" and that turned out to
> be trivial if faces of the planar graph are known.

An analogy might probably help.

Problem:

Write a compiler

Compiler designer:
 
Hmm, there seem to be many possible representations of a program in machine
code. Please, annotate the source code with a machine code of...

> Yes, "face" is a
> legitimate concept -- p.13 of Algebraic Graph Theory byGodsil&Royle. If
> they are not known, then please provide a formal way to define planar
> embedding. Without planar embedding the problem is ambiguous. The
> answer for ambiguous problem would be a set of dual graphs, and when
> answer becomes a set of structures it is usually much harder query.
> However, his query was "find the dual of a graph" where the "dual" is
> singular. Therefore, just accept the defeat.

It would be sufficient to produce a dual for an arbitrarily chosen
embedding. "Arbitrarily" means that your solution is free to take any.

[ As for embedding, as I remotely remember, it has linear algorithms. Not
that hard. ]

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/26/2006 7:53:11 AM
On 25 Jun 2006 16:59:44 -0700, Marshall wrote:

> topmind wrote:

>> I suggest you try to focus on more practical issues, such as comparing
>> solutions to realistic scenarios rather than get bogged down in a
>> definition battle. When software design is turned into a science rather
>> than an art, then revisit definitions. Until then, stop bickering over
>> art.
> 
> I think the idea of software as art is something of an
> anti-intellectual one.

"Irrational" would be a better word. There exist quite intelligent artists,
you can't deny it.

To understand software design rationally is an intellectual challenge for
CS. Calls to give up, to remain artisans, "reflexive developing" indeed
smell anti-intellectual.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/26/2006 8:08:25 AM
Bob Badour wrote:
> topmind wrote:
> 
> > > > I can't think of a single statement that would be more
> > > > antithetical to what the OO paradigm is about.
> > > 
> > > Thank you for stepping forward to exemplify my recent statement
> > > that use of the word 'paradigm' is the surest sign of a
> > > self-aggrandizing ignorant. After all, 'paradigm' has many
> > > meanings where for each meaning a better word exists.
> > > http://en.wikipedia.org/wiki/Buzzword
> > > 
> > > OO is a computational model and not a paradigm unless by
> > > 'paradigm' one means an example of a computational model. Idiot.
> > > Further, it is a computational model comprising a collection of
> > > features useful for constructing large unpredictable state
> > > machines from small predictable state machines or otherwise
> > > picked arbitrarily in the mid to late 1960's for what seemed
> > > expedient at the time.
> > 
> > Lighten up, guys. "Paradigm" might not be precise, but few words
> > are in software design.
> 
> Bullshit. Most of the words used have very precise definitions if one
> bothers to learn them. See ISO/IEC 2382 for instance.
> 
> The end product of design is necessarily precise. Can you imagine
> someone designing a building around having "some of those electric
> plug in thingies and some sort of light bulb thingie or other in
> every room" ? I can see the estimate from the builder for that design
> coming back: "That'll cost you some money--you know some of those
> colorful pieces of paper they let you exchange for thingies down at
> the store."

	Though it's also a language thing. In my native language, Dutch, we
have the same word for Relation and Relationship. This is common in a
lot of the european languages. This gives problems when you discuss
elements of a relational model: one would use the same word for two
fundamental different elements in the relational model. If a person
who's native language contains one word for Relation and Relationship
has to write an english text, like a newsposting, it can be that the
person uses the wrong word, as the person just knows one word for both:
to do it correctly, you have to know that in English there are two
words, not one.

	This just as an example how a person could end up choosing the wrong
word for a term where a person would have picked a different word if
the person would have been a native speaker of the target language. I
agree that definitions, if set in stone, should be followed, but I also
find that if both parties in a discussion know from eachother what the
other means by a given word W, bickering over definitions is IMHO
making the discussion impossible.

> > I suggest you try to focus on more practical issues, such as
> > comparing solutions to realistic scenarios rather than get bogged
> > down in a definition battle.
> 
> Why? The idiot is a self-aggrandizing ignorant and a snake-oil
> salesman. He has nothing to offer, and I have no intention of wasting
> much of my time on that sort of charlatan.

	What saddens me a bit is that instead of having an open discussion
about the core topic, you find it necessary to insult people which IMHO
only kill off the discussion. I'm not sure if that's your intention,
though it looks like it.

	The thing is that in every day life, thousands of developers have to
face the problem of the mismatch between the language they (have to)
work with and the nature of the persistent storage they (have to) work
with. Making a discussion about said problem impossible by insulting
people without any reason, is not helping these developers. But maybe
you're not interested in solving these developer's problem.

		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#) 
------------------------------------------------------------------------
0
6/26/2006 8:33:38 AM
Marshall wrote:
> Bruno Desthuilliers wrote:
> 
>>Now the funny thing is that the overall tone of this thread seems much
>>more open-minded (Mr Badour's fanatism set aside - and even he managed
>>to say at least one sensible thing) than the previous ones.
> 
> 
> Do you think so?

Well, maybe I am just too na�ve ? But at least I had this feeling when I
posted this.


-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/26/2006 9:15:06 AM
Aloha Kakuikanu wrote:
> Bruno Desthuilliers wrote:
> 
>>Aloha Kakuikanu wrote:
>>
>>>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.
>>>
>>
>>I guess that Dimtry's answer was to be taken as a joke. But I won't
>>bother explaining it...
> 
> 
> Oh, phlese.

You're aware that a customer can cancel a project, aren't you ?-)

> QueryObject.setExtraWhereClause();
> QueryObject.setAdditionalExtraWhereClause();
> QueryObject.setOneMoreAdditionalExtraWhereClause();

Yuck. What's that Javaish horror doing here ?

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/26/2006 9:52:44 AM
"Keith H Duggar" <duggar@alum.mit.edu> wrote in message
news:1151284979.344198.152780@m73g2000cwd.googlegroups.com...
> mAsterdam wrote:
> > Yes, (after re-reading I can't see how I missed it) it
> > appears you and David are right, the complication of the
> > topology of the space is still in scope. Before I make a
> > fool of myself again: could you restate the problem in
> > such a way that it /is/ out?
>
> Graph theory is definitely /not/ something I have a deep
> understanding of. I think Chris was just trying to help give
> Marshall a more intuitive feel for the problem. Hence the
> description of a graph embedded in a plane etc. I was just
> pointing out that a graph is or is not planar regardless of
> what space you embed it in.
>
> > > Consider, what would you call a graph with no subgraphs
> > > homeomorphic to K5 or K3,3 when embedded on a torus? It
> > > would still be called a planar graph I believe.
>
> A graph is planar if and only if it contains no subgraphs
> "equivalent" (for a particular notion of equivalence in this
> case homeomorphism) to either K5 or K3,3. K5 is the graph of
> 5 completely connected nodes. In other words an edge from
> each node to every other node. And K3,3 is a graph with two
> groups of three nodes where each node is connected to every
> node in the other group.
>
> So you see the planarity of a graph can be stated without
> any reliance on embedding.
>
> -- Keith -- Fraud 6
>

Thanks to everybody for clearing up the matter of "planar".

Now, I'm interested in a a subset of the planar graphs.

It's the graphs that don't divide the space into more than one region.

It seems to me  that it's appropriate to call such graphs "hierarchical
graphs",  or simply "hierarchies".  But I'm not sure.  Can anyone clear this
up?

(And please skip over  the comment that you can call it anything you want.
We all know that.)






0
dcressey (35)
6/26/2006 11:34:59 AM
On Mon, 26 Jun 2006 11:34:59 GMT, David Cressey wrote:

> Now, I'm interested in a a subset of the planar graphs.
> 
> It's the graphs that don't divide the space into more than one region.
> 
> It seems to me  that it's appropriate to call such graphs "hierarchical
> graphs",  or simply "hierarchies".  But I'm not sure.  Can anyone clear this
> up?

'Ordered graph' is the technical term, IMO.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/26/2006 12:04:28 PM
Frans Bouma wrote:
> Bob Badour wrote:
> 
>>topmind wrote:
>>
>>>>>I can't think of a single statement that would be more
>>>>>antithetical to what the OO paradigm is about.
>>>>
>>>>Thank you for stepping forward to exemplify my recent statement
>>>>that use of the word 'paradigm' is the surest sign of a
>>>>self-aggrandizing ignorant. After all, 'paradigm' has many
>>>>meanings where for each meaning a better word exists.
>>>>http://en.wikipedia.org/wiki/Buzzword
>>>>
>>>>OO is a computational model and not a paradigm unless by
>>>>'paradigm' one means an example of a computational model. Idiot.
>>>>Further, it is a computational model comprising a collection of
>>>>features useful for constructing large unpredictable state
>>>>machines from small predictable state machines or otherwise
>>>>picked arbitrarily in the mid to late 1960's for what seemed
>>>>expedient at the time.
>>>
>>>Lighten up, guys. "Paradigm" might not be precise, but few words
>>>are in software design.
>>
>>Bullshit. Most of the words used have very precise definitions if one
>>bothers to learn them. See ISO/IEC 2382 for instance.
>>
>>The end product of design is necessarily precise. Can you imagine
>>someone designing a building around having "some of those electric
>>plug in thingies and some sort of light bulb thingie or other in
>>every room" ? I can see the estimate from the builder for that design
>>coming back: "That'll cost you some money--you know some of those
>>colorful pieces of paper they let you exchange for thingies down at
>>the store."
> 
> 	Though it's also a language thing. In my native language, Dutch, we
> have the same word for Relation and Relationship. This is common in a
> lot of the european languages. This gives problems when you discuss
> elements of a relational model: one would use the same word for two
> fundamental different elements in the relational model.

Relationship has no particular meaning in the relational model--other 
than perhaps as an artificial distinction in one or another of Codd's 
early papers and now of interest only as an historical footnote.

My Wolter's is packed up somewhere. Is 'association' the same word too? 
Is 'reference' the same word too?


  If a person
> who's native language contains one word for Relation and Relationship
> has to write an english text, like a newsposting, it can be that the
> person uses the wrong word, as the person just knows one word for both:
> to do it correctly, you have to know that in English there are two
> words, not one.

With all due respect, Dijkstra shared your mother tongue and he noted 
exactly the opposite:

 From _My Hopes of Computing Science_ EWD 709

"One more remark about language that seems relevant. With English being 
computing science's Esperanto, colleagues with English as their native 
tongue often feel somewhat guilty about what they regard as their 
undeserved advantage over most foreigners. Their feeling of guilt is 
misplaced, because the advantage is ours. It is very helpful to have to 
do your work in what always remains a foreign language, as it forces you 
to express yourself more consciously. (About the most excellent prose 
written in our field that I can think of, is to be found in 
aforementioned ALGOL 60 Report: its editor had the great advantage of 
being, besides brilliant, a Dane. I have always felt that much of the 
stability and well-deserved fame of ALGOL 60 could be traced down 
directly to the inexorable accuracy of Peter Naur's English.)"

April 1979

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD07xx/EWD709.html


> 	This just as an example how a person could end up choosing the wrong
> word for a term where a person would have picked a different word if
> the person would have been a native speaker of the target language.

That's not the case here. Besides, someone who learns a technical term 
from a foreign perspective is far more likely to learn its precise 
meaning than a native speaker who grew their understanding of the term 
organically when still a toddler.



  I
> agree that definitions, if set in stone, should be followed, but I also
> find that if both parties in a discussion know from eachother what the
> other means by a given word W, bickering over definitions is IMHO
> making the discussion impossible.

That's my whole point, though. I don't know what the hell the ignorant 
was trying to say. You don't either. Not really. The fuzzy imprecise 
bullshit has a specific meaning to you, and you project that meaning 
onto those words. However, there is no evidence to suggest that any two 
people will project the same meaning.

Because you project the meaning, whatever meaning you project will seem 
self-evident and true to you. This works out great for the 
self-aggrandizing ignorants because they don't have to think or deliver 
anything of value. They need only spout important-sounding gibberish to 
leave an impression of profound insight and near infallibility. They are 
almost guaranteed a response of "Yeah! That's right!" because the 
meaning actually comes from the listener himself.

What the self-aggrandizing ignorants write is nonsense: on its face, it 
is nonsense.


>>>I suggest you try to focus on more practical issues, such as
>>>comparing solutions to realistic scenarios rather than get bogged
>>>down in a definition battle.
>>
>>Why? The idiot is a self-aggrandizing ignorant and a snake-oil
>>salesman. He has nothing to offer, and I have no intention of wasting
>>much of my time on that sort of charlatan.
> 
> 	What saddens me a bit is that instead of having an open discussion
> about the core topic, you find it necessary to insult people which IMHO
> only kill off the discussion. I'm not sure if that's your intention,
> though it looks like it.

Killing off discussions with charlatans and snake-oil salesmen, like 
yoursel, is a public good. The only useful discussion with such a crook 
is the discussion that reveals them for what they are.


> 	The thing is that in every day life, thousands of developers have to
> face the problem of the mismatch between the language they (have to)
> work with and the nature of the persistent storage they (have to) work
> with.

Bullshit. The thing is that in every day life, tens of thousands of 
developers are practising their craft without the requisite knowledge, 
education and skill. They choose to work with shitty tools mostly on the 
basis of fashion or fads.


  Making a discussion about said problem impossible by insulting
> people without any reason, is not helping these developers. But maybe
> you're not interested in solving these developer's problem.

You are making a fallacious ad hominem argument. I insult you because 
you are an ignorant crook with snake-oil to sell. Your posts reveal you 
for what you are. Your argument is that, because I insult you, I have no 
interest in helping your victims. That's completely non sequitur and absurd.
0
bbadour (434)
6/26/2006 1:56:53 PM
Bob Badour wrote:
> Model Driven Architecture, eh? What a load of horseshit.

Bob, you do have an amazing knack for entertainingly concise
declarations of contempt for nonsense. MDA is indeed snake oil, to
invent a "new" market (more $ that way) to hide with as much expense as
possible the obvious need for logically sound, non-imperative
languages.

In a rational world, we'd simply say we needed higher-level languages.
Instead, we get a shiny MDA troika hitched to a blind, reeking mule
[hence sterile, as no good can come of it] named UML and the tick on
its hide, OCL (Object Constraint Language). All crap, amply argued
elsewhere, but especially constructively here:
http://people.csail.mit.edu/dnj/publications/omg.pdf.

- erk

0
eric.kaun (62)
6/26/2006 2:36:01 PM
David Cressey <dcressey@verizon.net> wrote:
> Thanks to everybody for clearing up the matter of "planar".
> 
> Now, I'm interested in a a subset of the planar graphs.
> 
> It's the graphs that don't divide the space into more than one region.
> 
> It seems to me  that it's appropriate to call such graphs "hierarchical
> graphs",  or simply "hierarchies".  But I'm not sure.  Can anyone clear this
> up?

Well, such a graph has no cycles, so it is a forest.  If it's connected, 
then it's a tree.  I don't know where Dmitry got "ordered".  Any graph 
(planar or not, cycles or not, doesn't matter) may be made into an 
ordered graph simply by defining an order for its nodes.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/26/2006 2:55:02 PM
erk wrote:

> Bob Badour wrote:
> 
>>Model Driven Architecture, eh? What a load of horseshit.
> 
> Bob, you do have an amazing knack for entertainingly concise
> declarations of contempt for nonsense. MDA is indeed snake oil, to
> invent a "new" market (more $ that way) to hide with as much expense as
> possible the obvious need for logically sound, non-imperative
> languages.
> 
> In a rational world, we'd simply say we needed higher-level languages.
> Instead, we get a shiny MDA troika hitched to a blind, reeking mule
> [hence sterile, as no good can come of it] named UML and the tick on
> its hide, OCL (Object Constraint Language). All crap, amply argued
> elsewhere, but especially constructively here:
> http://people.csail.mit.edu/dnj/publications/omg.pdf.

What's not clear to me is whether Alloy is an improvement over other 
conceptual modelling languages and methods. It seems not.
0
bbadour (434)
6/26/2006 3:12:52 PM
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> [ As for embedding, as I remotely remember, it has linear algorithms. Not
> that hard. ]

I would warn you against confusing time bounds with difficulty.  It is 
most decidedly hard, unless you wish to assume that fifty years of 
algorithms researchers were all idiots.

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/26/2006 3:17:32 PM
Bob Badour wrote:

> Frans Bouma wrote:
> 
>> Bob Badour wrote:
>>
>>> topmind wrote:
>>>
>>>>>> I can't think of a single statement that would be more
>>>>>> antithetical to what the OO paradigm is about.
>>>>>
>>>>>
>>>>> Thank you for stepping forward to exemplify my recent statement
>>>>> that use of the word 'paradigm' is the surest sign of a
>>>>> self-aggrandizing ignorant. After all, 'paradigm' has many
>>>>> meanings where for each meaning a better word exists.
>>>>> http://en.wikipedia.org/wiki/Buzzword
>>>>>
>>>>> OO is a computational model and not a paradigm unless by
>>>>> 'paradigm' one means an example of a computational model. Idiot.
>>>>> Further, it is a computational model comprising a collection of
>>>>> features useful for constructing large unpredictable state
>>>>> machines from small predictable state machines or otherwise
>>>>> picked arbitrarily in the mid to late 1960's for what seemed
>>>>> expedient at the time.
>>>>
>>>>
>>>> Lighten up, guys. "Paradigm" might not be precise, but few words
>>>> are in software design.
>>>
>>>
>>> Bullshit. Most of the words used have very precise definitions if one
>>> bothers to learn them. See ISO/IEC 2382 for instance.
>>>
>>> The end product of design is necessarily precise. Can you imagine
>>> someone designing a building around having "some of those electric
>>> plug in thingies and some sort of light bulb thingie or other in
>>> every room" ? I can see the estimate from the builder for that design
>>> coming back: "That'll cost you some money--you know some of those
>>> colorful pieces of paper they let you exchange for thingies down at
>>> the store."
>>
>>
>>     Though it's also a language thing. In my native language, Dutch, we
>> have the same word for Relation and Relationship. This is common in a
>> lot of the european languages. This gives problems when you discuss
>> elements of a relational model: one would use the same word for two
>> fundamental different elements in the relational model.
> 
> 
> Relationship has no particular meaning in the relational model--other 
> than perhaps as an artificial distinction in one or another of Codd's 
> early papers and now of interest only as an historical footnote.
> 
> My Wolter's is packed up somewhere. Is 'association' the same word too? 
> Is 'reference' the same word too?
> 
> 
>  If a person
> 
>> who's native language contains one word for Relation and Relationship
>> has to write an english text, like a newsposting, it can be that the
>> person uses the wrong word, as the person just knows one word for both:
>> to do it correctly, you have to know that in English there are two
>> words, not one.
> 
> 
> With all due respect, Dijkstra shared your mother tongue and he noted 
> exactly the opposite:
> 
>  From _My Hopes of Computing Science_ EWD 709
> 
> "One more remark about language that seems relevant. With English being 
> computing science's Esperanto, colleagues with English as their native 
> tongue often feel somewhat guilty about what they regard as their 
> undeserved advantage over most foreigners. Their feeling of guilt is 
> misplaced, because the advantage is ours. It is very helpful to have to 
> do your work in what always remains a foreign language, as it forces you 
> to express yourself more consciously. (About the most excellent prose 
> written in our field that I can think of, is to be found in 
> aforementioned ALGOL 60 Report: its editor had the great advantage of 
> being, besides brilliant, a Dane. I have always felt that much of the 
> stability and well-deserved fame of ALGOL 60 could be traced down 
> directly to the inexorable accuracy of Peter Naur's English.)"
> 
> April 1979
> 
> http://www.cs.utexas.edu/users/EWD/transcriptions/EWD07xx/EWD709.html
> 
> 
>>     This just as an example how a person could end up choosing the wrong
>> word for a term where a person would have picked a different word if
>> the person would have been a native speaker of the target language.
> 
> 
> That's not the case here. Besides, someone who learns a technical term 
> from a foreign perspective is far more likely to learn its precise 
> meaning than a native speaker who grew their understanding of the term 
> organically when still a toddler.
> 
> 
> 
>  I
> 
>> agree that definitions, if set in stone, should be followed, but I also
>> find that if both parties in a discussion know from eachother what the
>> other means by a given word W, bickering over definitions is IMHO
>> making the discussion impossible.
> 
> 
> That's my whole point, though. I don't know what the hell the ignorant 
> was trying to say. You don't either. Not really. The fuzzy imprecise 
> bullshit has a specific meaning to you, and you project that meaning 
> onto those words. However, there is no evidence to suggest that any two 
> people will project the same meaning.
> 
> Because you project the meaning, whatever meaning you project will seem 
> self-evident and true to you. This works out great for the 
> self-aggrandizing ignorants because they don't have to think or deliver 
> anything of value. They need only spout important-sounding gibberish to 
> leave an impression of profound insight and near infallibility. They are 
> almost guaranteed a response of "Yeah! That's right!" because the 
> meaning actually comes from the listener himself.
> 
> What the self-aggrandizing ignorants write is nonsense: on its face, it 
> is nonsense.

I found another (and much earlier) EWD relevant to the last point:

 From _Some Comments on the Aims of MIRFAC_ EWD 68

"Of course he can check it, but the crucial point is whether he will 
find the errors! And of course he will not find them: for in human 
communication one is constantly trained to try to understand the others 
intentions and not to notice the nonsense."

Probably from 1963 or 1964 -- before I was born!
0
bbadour (434)
6/26/2006 3:31:46 PM
Bob Badour wrote:
>
> Probably from 1963 or 1964 -- before I was born!

Ack! You're younger than me. That is *so* unfair.


Marshall

0
6/26/2006 4:33:06 PM
On Mon, 26 Jun 2006 08:55:02 -0600, Chris Smith wrote:

> David Cressey <dcressey@verizon.net> wrote:
>> Thanks to everybody for clearing up the matter of "planar".
>> 
>> Now, I'm interested in a a subset of the planar graphs.
>> 
>> It's the graphs that don't divide the space into more than one region.
>> 
>> It seems to me  that it's appropriate to call such graphs "hierarchical
>> graphs",  or simply "hierarchies".  But I'm not sure.  Can anyone clear this
>> up?
> 
> Well, such a graph has no cycles, so it is a forest.  If it's connected, 
> then it's a tree.  I don't know where Dmitry got "ordered".

G is ordered if DAG. Its transitive closure G* is a strict order [on
nodes].

[ OK, planarity is lost, but it is not required for hierarchies either. ]

> Any graph 
> (planar or not, cycles or not, doesn't matter) may be made into an 
> ordered graph simply by defining an order for its nodes.

If you can order the set of nodes. But that order is not necessary G*.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/26/2006 6:09:30 PM
frebe73@gmail.com wrote:
>>>>So, is it a problem with OO, or a problem with how OO is used ?
>>>
>>>Both.
>>
>>Could you elaborate ?
> 
> 
> The main problem in OO enterprise applications

If you mean 'enterprise' � la Java-PHB-buzzword, then the main problem
is with believing in bullshit that silver-bullet dealers want to sell you.

> is the desire to
> decouple SQL statements.

To decouple them from what ? From the view code ? I wouldn't call this a
problem.

> This causes code bloats. Bloated code are
> harder to maintain.

The problem with putting SQL statements everywhere in the code is that
it causes duplications. And everyone should know why duplication is
bad... Or do you advocate redundancy in the schema too ?-)

> Another disadvantage is the fact that the number
> SQL statements should be limited

???

> and the the same statement should be
> reused in different contexts.  This does not only creates problem
> writing the code,

????

> it causes performance problems. 

?????

> The fact that the
> result from the SQL query has to
> be mapped to a "domain object" also
> introduces numerous problems.

Does it "have to" ? I've seen a lot of ways to use OO in SQLDBMS-based
applications, not all using "domain objects". So this can't count as a
problem with OO itself, only with how OO is/can be used.

Also, and FWIW, using a dumb data-holder (dynamically created class,
hashtable, tuple, whatever) or a more elaborate object is a design
choice. Like all design choices, it has pros and cons. Like all design
choices, it should IMHO be based on the contex. There's nothing like a
'one-size-fits-all' golden rule here. If using a more elaborate object
solves more problems than it creates, and if the later are easy to
solve, then it may be the right thing to do. Let's be pragmatic, will you ?

>>>>>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.
>>
>>And ?
> 
> 
> See the discussion about employee types.

I still fail to see where's the problem.

> 
>>>In a recent thread Robert Martin suggested a similar class hierachy:
>>>Employee
>>>- Salaried employee
>>>- Hourly employee
>>>- Commissioned employee
>>
>>Hard to tell without the full context, but I would probably go for a
>>single employee class and a strategy pattern for payment mode instead. 
> 
> Subtyping payment modes
> instead of employee types has the same
> disadvantages. The key is to limit the use of subtyping.

Who talked about subtyping ? Is your reference OOPL so deficient that
you cannot attach/replace methods on a per-object basis ? If so, bad
OOPL, change OOPL.

>>>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.
>>
>>One more reason to switch to a strategy pattern.
> 
> The original solution used a strategy pattern too. The problem with the
> strategy pattern (and subtyping)

Strategy pattern doesn't imply subtyping, cf above.

> is that you only have one dimension of
> strategies. 

really ?

> Multiple dimensions (employement type and union
> association) might affect how the strategy should be implemented.

Then use multimethods and method combination. Or simply a template
method FWIW...

>>>Now you have to repeat this
>>>logic in all three implementations of calculatePayment.

cf above - and below too !-)

>>Having to repeat something is most often a design smell.
>  
> That's why a design using subtypes can be very dangerous.

That's why a *bad* design using subclassing can be very dangerous. But a
bad design is a bad design is a bad design...

(not to pretend I never do bad design...)

>>>This is one
>>>example of problem you will encounter when you start with on dimension
>>>and later have to handle multiple dimensions.
>>
>>This is one example of problem you encounter when you try to map the
>>10000-feets analysis view directly to implementation, totally skipping
>>the design phase.
>  
> It seem to be very difficult to get i right using OO....

Who said design was easy ? And would it be easier with a strictly
procedural approach ? Or with a strictly functional approach ? And in
both cases, would it be easier because of the approach used, or because
of the adequation between the problem, the way the designer thinks, and
the approach used ?

FWIW, I've never been able to come up with a sensible procedural
solution to any non-trivial problem. And yet I've seen some pretty good
procedural solutions to non-trivial problems.

I'm afraid that the problem is more with silver-bullet dealers than with
OO itself. If you (ie : a 'generic' you - not necessarily th person
named Fredrik Bertilsson) believe that just using a braindead so-called
"OO" language and following the braindead "OO 101" tutorials is enough
to get any advantage from OO, then you're in deep deep trouble... And
you can s/OO/whatever/g IMHO.

OO is just a way to organize code. If it don't fit your mental map
and/or the problem to solve, use another way. There's no need sticking
to the same approach for each and any part of a program (but using a
language that let you mix approaches without too much inconsistency is
of great help).

> Maybe that is
> why we need the mentors...

Hmm... I've always been suspicious of self proclaimed 'mentors'. My best
'mentors' so far have been newbies questionning some complex or
complicated parts of my solutions !-)

>>Now if you really think you can't handle "multiple dimensions" in OO,
>  
> Almost every language (OO or not) can handle multiple dimensions, but a
> subtype hiearchy can not. 

Ever heard of duck typing, multiple inheritance and multimethods ? OO is
not necessarily about inheritance and "subtype hierarchies" - that's
something I unlearned when I switched away from PHB-oriented languages
and crappy 00 tutorials.

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/26/2006 6:18:12 PM
Bruno Desthuilliers wrote:
> frebe73@gmail.com wrote:
>>>>> So, is it a problem with OO, or a problem with how OO is used ?
>>>> Both.
>>> Could you elaborate ?
>>
>> The main problem in OO enterprise applications
> 
snipped.

> 
> Who talked about subtyping ? Is your reference OOPL so deficient that
> you cannot attach/replace methods on a per-object basis ? If so, bad
> OOPL, change OOPL.
> 

holy cow  - snipped - nothign here folks...  move along...  move along now


Bruno PLEASE...dont start a dynamic vs static typing sub-thread, I'd 
fear for the ng servers if you did!
0
news261 (167)
6/26/2006 6:41:08 PM
Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> G is ordered if DAG.

Eh?  That's not a grammatically correct sentence, and I can't figure out 
what you mean by it.  If it was supposed to mean "G is ordered if G is a 
DAG", then that's not true.  Here are some possible true statements 
involving ordered graphs and DAGs.  Did you mean one or more of these?

1. A DAG (like any other graph) can be given an order.

2. If an order is assigned to a DAG such that for all directed edges
   (P, Q), P <= Q, then the order is called a topological order, and
   topological orders have certain interesting properties on DAGs.

3. Given an order for an arbitrary (undirected) graph, the graph can be
   oriented in such a way that the order is the topological order of the
   resulting DAG.

(Incidentally, it's not true that a DAG has a unique topological order.  
There can be any number of orderings that are topological.  That's 
probably worth mentioning, since it is something your sentence above may 
have have been supposed to mean.)

In fact, though, the possibility of ordering is not really related to 
DAGs at all.  All graphs, whether they are directed or not, have cycles 
or not, are planar or not, *whatever*, may ge given an order.  In fact, 
they may be given p! different possible orders, where p is the number of 
nodes.

> Its transitive closure G* is a strict order [on
> nodes].

No.  The transitive closure of a directed acyclic graph does define an 
order on the set of nodes.  An order on the graph itself, though, has 
nothing to do with the edges of that graph (though, of course, it could 
be expressed as a /different/ graph... but that's not really very 
relevant, is it?)

> 
> [ OK, planarity is lost, but it is not required for hierarchies either. ]

You've really lost me now.  The question was what to call a graph whose 
dual has only one node (i.e., the edges don't divide the plane).  The 
correct answer is "forest" (or "tree", if we assume connectedness).  
"Ordered" is decidedly not a correct answer.

> > Any graph 
> > (planar or not, cycles or not, doesn't matter) may be made into an 
> > ordered graph simply by defining an order for its nodes.
> 
> If you can order the set of nodes. But that order is not necessary G*.

Of course I can order the set of nodes.  I just start somewhere, and 
start counting, like so... 1, 2, 3, 4, and so on.  Who cares if the 
order I come up with is equivalent to the transitive closure of a 
directed graph?

-- 
Chris Smith - Lead Software Developer / Technical Trainer
MindIQ Corporation
0
cdsmith (3862)
6/26/2006 7:33:51 PM
> > The main problem in OO enterprise applications
> If you mean 'enterprise' =E0 la Java-PHB-buzzword, then the main problem
> is with believing in bullshit that silver-bullet dealers want to sell you.

I use the word "enterprise" just because I don't want anyone to get the
impression that I am talking about FTP-clients, MP3-players etc here.

> > is the desire to
> > decouple SQL statements.
> To decouple them from what ? From the view code ? I wouldn't call this a
> problem.

Decoupling from the rest of the application. You can find many
successful applications like osCommerce that put SQL code in the view
code (PHP) with great success.

> > This causes code bloats. Bloated code are
> > harder to maintain.
> The problem with putting SQL statements everywhere in the code is that
> it causes duplications. And everyone should know why duplication is
> bad... Or do you advocate redundancy in the schema too ?-)

If you have two identical SQL statements it is a good idea to put it
into a function, unless it is more trivial than actually calling the
function (like update customer set lastname=3D? where customerid=3D?). But
if you put non-identical trivial SQL statements everywhere, you don't
cause any duplication, only less bloated code.

> > Another disadvantage is the fact that the number
> > SQL statements should be limited
> ???

For example, a common practice is to only have one update method which
updates all columns, regardless if they need to be updated or not. The
same practice can be seen with select statments, all columns are
selected regardless if you actually need the value or not. You have
similar problems with joining.

> > and the the same statement should be
> > reused in different contexts.  This does not only creates problem
> > writing the code,
> ????

Se above.

> > it causes performance problems.

The N+1 problem is well-known in EJB for example.

> > The fact that the
> > result from the SQL query has to
> > be mapped to a "domain object" also
> > introduces numerous problems.
>
> Does it "have to" ? I've seen a lot of ways to use OO in SQLDBMS-based
> applications, not all using "domain objects". So this can't count as a
> problem with OO itself, only with how OO is/can be used.

Another problem with OO. Nobody actually knows that OO is. Many OO
evangelists would fight until they die before they drop the use of
"domain objects". Maybe you can provide links to the definition of OO?

> Let's be pragmatic, will you ?

That is why I don't use OOAD.

> >>>In a recent thread Robert Martin suggested a similar class hierachy:
> >>>Employee
> >>>- Salaried employee
> >>>- Hourly employee
> >>>- Commissioned employee
> >>Hard to tell without the full context, but I would probably go for a
> >>single employee class and a strategy pattern for payment mode instead.
> > Subtyping payment modes
> > instead of employee types has the same
> > disadvantages. The key is to limit the use of subtyping.
> Who talked about subtyping ? Is your reference OOPL so deficient that
> you cannot attach/replace methods on a per-object basis ? If so, bad
> OOPL, change OOPL.

In this case Robert Martin. If you use a typeless language, subtyping
is of course impossible. But some people seem to prefer typed
languages.

> Strategy pattern doesn't imply subtyping, cf above.

http://en.wikipedia.org/wiki/Strategy_pattern
http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPattern=
..htm

It seem to me that subtyping is used. Maybe this is an issue about
typeless vs types languages.

> Who said design was easy ?

I do.

> And would it be easier with a strictly
> procedural approach ?

I don't know your definition of "strictly procedureal" but designing a
relational data model is pretty easy anyway.

> I'm afraid that the problem is more with silver-bullet dealers than with
> OO itself. If you (ie : a 'generic' you - not necessarily th person
> named Fredrik Bertilsson) believe that just using a braindead so-called
> "OO" language and following the braindead "OO 101" tutorials is enough
> to get any advantage from OO, then you're in deep deep trouble... And
> you can s/OO/whatever/g IMHO.

The reason that OO is misused is that nobody really knows what OO is.
OO also seem to change by time.

> OO is just a way to organize code.

Do you think everybody at comp.object agree?

> If it don't fit your mental map
> and/or the problem to solve, use another way.

That is what I am doing.

> Ever heard of duck typing, multiple inheritance and multimethods ?

So far I know, multiple inheritance was skipped in Java because all the
disadvantages.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/26/2006 8:01:49 PM
H. S. Lahman wrote:
> Responding to Badour...
>
> >>> OO is hierarchy.
> >>
> >>
> >> LOL.  This pretty much says it all.  I suggest learning something
> >> about OOA/D; it would make the trolling more credible.
> >
> >
> > With all due respect, I see no reason to think his education in OOA/D is
> > lacking in any way. While his statement is a simplification and a
> > generalization, it is accurate at least to a first-order approximation.
>
> I can't think of a single statement that would be more antithetical to
> what the OO paradigm is about.  Probably the single most important thing
> the OO paradigm brought to the development table was the elimination of
> the hierarchical dependencies prevalent in structured functional
> decomposition.  Problem space abstraction, peer-to-peer collaboration,
> separation of message and method, encapsulation, flexible logical
> indivisibility, and all the rest of that OO stuff play together for the
> specific purpose of eliminating the spaghetti code resulting from
> hierarchical implementation dependencies.

Heavy procedural hierarchies were tried in the 70's and didn't work out
so well. Today's procedural does not need to do that. Use of databases
and event-driven programming greatly reduces the need for such. (Some
argue that OO is better for event-driven programming, but i've yet to
see a good demo of this claim. Perhaps some mean it is better for
implimenting event frameworks, not using them.)

> 
> 
> *************
> H. S. Lahman

-T-

0
topmind (2124)
6/26/2006 8:11:17 PM
Bruno Desthuilliers wrote:

> Ok; given the latest developpemnts, I actually was totally wrong.
> Desperatly turned into one more fanatic flame war. I give up any hope of a
> sound and open-minded exchange here.

Another satisfied customer!

-- 
  Phlip
0
phlip20052 (146)
6/26/2006 10:09:02 PM
Bruno Desthuilliers wrote:
> Marshall a �crit :
>> Bruno Desthuilliers wrote:
>>
>>> Now the funny thing is that the overall tone of this thread seems much
>>> more open-minded (Mr Badour's fanatism set aside - and even he managed
>>> to say at least one sensible thing) than the previous ones.
>>
>>
>> Do you think so? Or is it merely that this thread is more polite?
>> Open mindedness and politeness are two desirable qualities,
>> but it would be a shame not to be able to distinguish them.
> 
> Ok; given the latest developpemnts, I actually was totally wrong. 
> Desperatly turned into one more fanatic flame war. I give up any hope of 
> a sound and open-minded exchange here.

me too - hence the bob counting
0
news261 (167)
6/26/2006 10:25:32 PM
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.
>
> - 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.

JOG you've written nothing about "what databases have taught you", the
title is wrong, how 'bout:

Ladies and gentlemen, tonight's top 10 titles, (drrrr, drrrr,
drum-roll....bara-bing):-

10. "If I'm a bad programmer mommy, will OOP make me good?"
9."Hey, what's wrong with too much code, the more the merrier, right"?
(bloat)
8. "Design by buzzward compliance, what's wrong with that"?
7."Databases can be used to solve every problem in computer science".
6. "Ok it's not even use-able but I'm makin' my code "super-re-usable"
- right?
5. "Nevermind the customer's project, here comes my framework"
4."Yes, I tried to think but it hurts".
3. *All* those OO guys are self-agrandizing ignorants but all those db
guys know where it's at.
2. I use Java, Java is a well designed OOL, therefore all my code is
well designed OOP.
1. What, I thought you're suppose to use inheritence, all-the-time.

I hope that helps a bad workman who blames his tools.

0
6/26/2006 11:09:10 PM
Keith H Duggar a �crit :
> Bruno Desthuilliers wrote:
> 
>>Marshall wrote:
>>
>>>And yet, people make that mistake again and again and
>>>again.  The focus is on the easy part: structure.
>>
>>But is that *really* the easy part ? Kind of *seems* easy,
>>but... At least 80% of the complicated code I've ever seen
>>came from a wrong structure. And it's obvious that if the
>>structure had followed the processing needs, then the code
>>would have been way much simpler (and better). As a matter
>>of fact, whenever I find myself writing complicated code,
>>I *know* there's something wrong.
> 
> 
> What happens when different processing needs demand different
> structures that "follow their needs"? 

I assume you mean different 'views' of the same data ?-)

> Then some computations
> become easier while others become harder. 

Depends... If the 'base' structure allows to easily 'map' to different 
views, then everything's fine. Else, we're back to the "wrong structure, 
complicated code" problem.

> This is "expression
> bias" 

Ok. To be honest, re-reading my post, the "if the structure had followed 
the processing needs" part is really wrongly expressed. What I had in 
mind was mostly about having a sound schema that can easily be 
"translated" back and forth to the processing-specific needed structure.

> and for me it has been an annoying problem with network
> models. And it drives one inexorably to the relational model.

While I do agree that RM is one of the best possible solutions I know as 
soon as there are non-trivial relationships between 'entities' and one 
want to ensure consistency and integrity, I would certainly not use the 
term "inexorably" (even if I fail to see anything more suited for most 
business apps).

Also, just "using 'the' relational model" is not enough - it has to be 
done right. As a matter of fact, a significant part of the "wrong 
structure, complicated code" I've seen was in RDBMS-based apps. Note 
that I don't jump to the conclusion that RM is bad - just that analysis 
and design can be hard, whatever 
approach/technology/"paradigm"/model/whatever one uses. No silver 
bullet, as usual...

0
6/27/2006 1:03:41 AM
Bob Badour a �crit :
(snip)
> 
> One might add that the 80% of complicated code Bruno saw resulted from 
> having a surfeit of structures to choose from and a paucity of available 
> manipulations in the first place.

One might better not assert anything in the wild. A significant part of 
this code was in RDBMS-based, procedural apps. RM is not more of a 
silver bullet than anything else - if done wrong, then the result wrong, 
period.
0
6/27/2006 1:07:58 AM
Marshall wrote:
> Keith H Duggar wrote:
> 
> I remain deeply ambivalent about Bob's use of insults. Sometimes,
> I think that all they do is distract and inflame. Other times, I think
> that in fact Bob is the only one rude enough to cut through
> the bullshit and point out the ridiculousness of what people are
> saying. Sometimes I think he's too quick on the trigger, other
> times it seems as if he's the first one to figure out when we're
> being snowed. Maybe all those are true, I dunno.
> 
> What I have never done, however, is mistake the presence
> of insults for the absence of content. Bob always has content.
> And I might add, a laserlike command of terminology, which
> frankly impresses the hell out of me.

Irrespective of content he is still a bully which is unbecoming in 
practically every culture I have encountered.

For the benefit of non CDT'ers when his claim that a certain outcome 
could not be achieved using SQL was shown to be trivially possible his 
best response was "I shouldn't have to do that".

So impressed I am not - he is just loud _and_ gutless.  Therefore FWIW 
be careful of being tarred as a sycophant!

Cheers, Frank.
0
6/27/2006 1:12:11 AM
Marshall a �crit :
> Bruno Desthuilliers wrote:
> 
>>Now the funny thing is that the overall tone of this thread seems much
>>more open-minded (Mr Badour's fanatism set aside - and even he managed
>>to say at least one sensible thing) than the previous ones.
> 
> 
> Do you think so? Or is it merely that this thread is more polite?
> Open mindedness and politeness are two desirable qualities,
> but it would be a shame not to be able to distinguish them.

Ok; given the latest developpemnts, I actually was totally wrong. 
Desperatly turned into one more fanatic flame war. I give up any hope of 
a sound and open-minded exchange here.
0
6/27/2006 1:17:59 AM
Keith H Duggar wrote:
> Marshall wrote:
> > What, you can't tell the insults from the content? Here's
> > an idea: take some of Bob's posts, pull them in to your
> > favorite text editor, and edit out the insults *and only*
> > the insults.
> >
> > Try it:
>
> [snip example]
>
> > Not all that hard, really. And you're left with something
> > that is actually quite well written, and quite cogent.
>
> Fascinating. I actually found it more clear /with/ the
> insult. Go figure. Maybe it helps to highlight points of
> disagreement?
>
> Andrew McDonagh wrote:
> > Bob Badour wrote :
> > > In any case, I already twit-filtered Andrew so I would
> > > never have known about his count if you hadn't replied
> > > to it.
> >
> > Got to love those who help get past peoples filters eh!
> >
> > As Mr T says 'Damn fool!'
>
> I'm not sure who you are calling a fool. If it is "those
> people" you directed it to, let me inform you that other
> people's twit filters do not concern me in the slightest.
>
> > So, given that I nor others can't convince Bob to change
> > his posting style so that we may bask in his magnificence,
> > I decided to read Bob's posts from a different angle.
> >
> > Mainly one of 'let's see how many times per thread can Bob
> > can repeat his favourite insult: Self-aggrandising idiot'
> >
> > Got to say - it makes reading his posts SSSsoooooo much
> > more fun and less tiring.
>
> So you are having fun at the expense of others who read the
> group? How mature and considerate of you. Vaguely seems like
> nascent C'mode behavior. Perhaps you should nip the bud.
>
> -- Keith -- Fraud 6

Keith, I can't believe you're talking about "mature and considerate",
Bob has insulted more people in these forums than just about everyone
else put together, then you and that other great suck-up Marshall
constantly praise him for it. You go out of your way to say so, yet if
anyone has a mild rib at him you come running to the brute's defense!
Wow, what kind of a brainless moron are you? Are you sane? Is Bob your
cult leader or something? Or are you guys the only ones with a license
to insult?

0
6/27/2006 2:30:58 AM
Marshall wrote:
> Andrew McDonagh wrote:
> > Dan wrote:
> > >
> > > So Andrew, do you have any interesting comments or opinions concerning
> > > the other content of the post, other than counting words?
> > >
> > > Where do you think Bob was wrong, or right?
> > >
> >
> > Oh God, Dan,  I like others, gave up trying to find wisdom, knowledge or
> > anything of use within Bob's post, long ago.
>
> Well, gee, Andrew, at least when you say that you're not even
> trying to understand Bob, that is more honest than when you
> say that Bob isn't actually saying anything. The fact that the
> problem lies with you vs. Bob is an important distinction.
>

Marshall, why are you sucking up to Bob? Why is he allowed to post
whatever trash he wants, yet you come running to his rescue?

Look at Andrew's effort as a tongue in cheek or even polite way of
saying "Bob stop posting trash".

And I'm sure Andrew isn't the only one wanting to express that
sentiment.

>
> > Its just too tiring, they are hidden so well within his insults.
>
> What, you can't tell the insults from the content? Here's an idea:
> take some of Bob's posts, pull them in to your favorite text
> editor, and edit out the insults *and only* the insults.
>

What content? The only useful things he says are directly plagiarized
from Chris Date.

> Try it:
>
> Bob Badour wrote:
> >
> > OO is a computational model and not a paradigm unless by 'paradigm' one
> > means an example of a computational model. Idiot. Further, it is a
> > computational model comprising a collection of features useful for
> > constructing large unpredictable state machines from small predictable
> > state machines or otherwise picked arbitrarily in the mid to late 1960's
> > for what seemed expedient at the time.
>
> becomes:
>
> > OO is a computational model and not a paradigm unless by 'paradigm' one
> > means an example of a computational model. Further, it is a
> > computational model comprising a collection of features useful for
> > constructing large unpredictable state machines from small predictable
> > state machines or otherwise picked arbitrarily in the mid to late 1960's
> > for what seemed expedient at the time.
>
> Not all that hard, really. And you're left with something that is
> actually
> quite well written, and quite cogent.

And this you provide as a good example of quality content. That's the
worst definition of OOP I've ever seen "Large unpredictable state
machines", yeah right.

These newsgroups were way more polite and informative before you guys
showed up so don't gloat about any "well written, cogent" content. It's
just filthy trash!

0
6/27/2006 3:11:36 AM
Bruno Desthuilliers wrote:
> Bob Badour a =E9crit :
> (snip)
> >
> > One might add that the 80% of complicated code Bruno saw resulted from
> > having a surfeit of structures to choose from and a paucity of available
> > manipulations in the first place.
>
> One might better not assert anything in the wild. A significant part of
> this code was in RDBMS-based, procedural apps. RM is not more of a
> silver bullet than anything else - if done wrong, then the result wrong,
> period.

Absolutely true!  Relational or object-oriented, it doesn't matter,
it's the thought process and ability to apply critical analysis to
problems that makes or breaks the project or solves the problem in the
most elegant way possible.  Unfortuntely, it doesn't matter if it is RM
or OO or structured programming, skills and the general level of formal
training in computer science have declined, and therefore knowledgeable
and truly exceptional systems and programming people seem to be
becoming extinct, at least to me.

It's funny...the RM camp comes off using the exact same arguments as
the formal specification movement camp; yet no one makes the
connection.  Formal methods and formal specifications versus other
flexible frameworks and programming approaches could have just as
easily been supplanted as the two warring factions.  And there have
been some successes with formal methods!    Or better yet, whether
software development is engineering, science, or art.  Software
engineering would have us believe its entirely about process, and not
necessarily entirely about qualified people, which it refers often to
in literature as cowboys or the purveyors of art. .

There is no black and white.  And there is no silver bullet.  That is
for sure. =20

- Dan

0
6/27/2006 3:59:15 AM
Frank Hamersley wrote:
> Marshall wrote:
> >
> > I remain deeply ambivalent about Bob's use of insults.
>
> So impressed I am not - he is just loud _and_ gutless.  Therefore FWIW
> be careful of being tarred as a sycophant!

So now you're implying I'm a sycophant? Do you know what "deeply
ambivalent" means?

This is bizarre, the recent spate of people insulting me as a
Bob-puppet.
I wonder who, over the years, has been the most vocal and
persistant critic of Bob's style of diction. Because I rather think
it's me.


Marshall

0
6/27/2006 4:08:36 AM
george99may@gmail.com wrote:
> Keith H Duggar wrote:
> > Marshall wrote:
> > > What, you can't tell the insults from the content? Here's
> > > an idea: take some of Bob's posts, pull them in to your
> > > favorite text editor, and edit out the insults *and only*
> > > the insults.
> >
> > Fascinating. I actually found it more clear /with/ the
> > insult. Go figure. Maybe it helps to highlight points of
> > disagreement?
>
> Keith, I can't believe you're talking about "mature and considerate",
> Bob has insulted more people in these forums than just about everyone
> else put together, then you and that other great suck-up Marshall
> constantly praise him for it. You go out of your way to say so, yet if
> anyone has a mild rib at him you come running to the brute's defense!
> Wow, what kind of a brainless moron are you? Are you sane? Is Bob your
> cult leader or something? Or are you guys the only ones with a license
> to insult?

George,

If you're trying to convince people that insults are bad, doing so in
a style that involves spewing diverse insults at a variety of people
is not going to be effective. If insulting is bad, why are you doing
it so much?


Marshall

0
6/27/2006 4:15:34 AM
Dan wrote:
> Bruno Desthuilliers wrote:
> > Bob Badour a =E9crit :
> > (snip)
> > >
> > > One might add that the 80% of complicated code Bruno saw resulted from
> > > having a surfeit of structures to choose from and a paucity of availa=
ble
> > > manipulations in the first place.
> >
> > One might better not assert anything in the wild. A significant part of
> > this code was in RDBMS-based, procedural apps. RM is not more of a
> > silver bullet than anything else - if done wrong, then the result wrong,
> > period.
>
> Absolutely true!  Relational or object-oriented, it doesn't matter,
> it's the thought process and ability to apply critical analysis to
> problems that makes or breaks the project or solves the problem in the
> most elegant way possible.

It's one thing to say that quality individuals are an important
part of project success; it's quite another to say that the
choice of tools or computational models or "paradigms"
doesn't matter at all. If that were true, then front panel
switches would be just as good as SQL for data
management, and OO itself, with an IDE,  would have
been an unnecessary change from Pascal and Fortran
and punch cards.


> [...]
> It's funny...the RM camp comes off using the exact same arguments as
> the formal specification movement camp; yet no one makes the
> connection.

I've made the connection, and lots of other people have made
the connection.=20


Marshall

0
6/27/2006 4:24:19 AM
Marshall wrote:
> Dan wrote:
> > Bruno Desthuilliers wrote:
> > > Bob Badour a =E9crit :
> > > (snip)
> > > >
> > > > One might add that the 80% of complicated code Bruno saw resulted f=
rom
> > > > having a surfeit of structures to choose from and a paucity of avai=
lable
> > > > manipulations in the first place.
> > >
> > > One might better not assert anything in the wild. A significant part =
of
> > > this code was in RDBMS-based, procedural apps. RM is not more of a
> > > silver bullet than anything else - if done wrong, then the result wro=
ng,
> > > period.
> >
> > Absolutely true!  Relational or object-oriented, it doesn't matter,
> > it's the thought process and ability to apply critical analysis to
> > problems that makes or breaks the project or solves the problem in the
> > most elegant way possible.
>
> It's one thing to say that quality individuals are an important
> part of project success; it's quite another to say that the
> choice of tools or computational models or "paradigms"
> doesn't matter at all. If that were true, then front panel
> switches would be just as good as SQL for data
> management, and OO itself, with an IDE,  would have
> been an unnecessary change from Pascal and Fortran
> and punch cards.
>
I'm not sure I'm understanding.  Babbage, Turing, Shannon, and many
others did just fine.  I now see the problems they solved, resolved in
the worst possible ways with the state of the art tools and
computational models.  The ideal soluton would be both of course, but
that just goes to support my assertion that it isn't black and white.

>
> > [...]
> > It's funny...the RM camp comes off using the exact same arguments as
> > the formal specification movement camp; yet no one makes the
> > connection.
>
> I've made the connection, and lots of other people have made
> the connection.

Oh my.  I missed it then.  Apologies.

If the arguments in favor of mathematics and logic as a specification
for programming and systems architecture had been couched in terms of
Alloy, NP, Catalysis, Fusion, UML, the Object Constraint Language
(OCL), or Z, perhaps it wouldn't be an RM versus OO thing as much.

>=20
>=20
> Marshall

- Dan

0
6/27/2006 4:40:07 AM
george99may@gmail.com wrote:
> Keith, I can't believe you're talking about "mature and
> considerate"

What you believe about me is entirely irrelevant and surely
uninteresting to everyone reading this. Furthermore, that
phrase is trivial and contains almost no substance.

> Bob has insulted more people in these forums than just
> about everyone else put together

*sigh* Ye old two wrongs crap. Bob and Andrew are different
people. If Andrew views Bob as behaving badly and decides to
retaliate by behaving badly himself, that is immature. In
addition, even when Bob does insult people his posts /still/
contain cogent content even if you or others are unable to
maintain enough mental focus to comprehend it. In contrast,
the Andrew posts I was responding to were entirely vacuous.

> then you and that other great suck-up Marshall constantly
> praise him for it. You go out of your way to say so,

I do not recall ever /praising/ Bob for insulting people. I
think it's even more unlikely that Marshall ever /praised/
him for insulting someone. I have at times discussed the
possible motivations for and the effects (both beneficial
and detrimental) of insulting someone. But /praise/? Why
are you libeling me this way?

> yet if anyone has a mild rib at him you come running to
> the brute's defense!

What the hell are you talking about? I wasn't defending Bob.
I was pointing out to Andrew that his posts were worthless
and vacuous. And I don't give a shit who insults who as long
as they do so while providing /substantive content/.

> Wow, what kind of a brainless moron are you? Are you sane?
> Is Bob your cult leader or something? Or are you guys the
> only ones with a license to insult?

Obviously you feel you have license to insult me. That makes
your final question rather stupid don't you think? But, yes;
We are the only ones with license to insult and we are the
only licensing authority. You insulted me without license,
so consider your license to insult revoked for life!

-- Keith -- Fraud 6

0
duggar (292)
6/27/2006 4:41:32 AM
George wrote:
> Marshall wrote:
> > Andrew McDonagh wrote:
> > >
> > > Oh God, Dan,  I like others, gave up trying to find wisdom, knowledge or
> > > anything of use within Bob's post, long ago.
> >
> > Well, gee, Andrew, at least when you say that you're not even
> > trying to understand Bob, that is more honest than when you
> > say that Bob isn't actually saying anything. The fact that the
> > problem lies with you vs. Bob is an important distinction.
> >
>
> Marshall, why are you sucking up to Bob?

That wasn't sucking up to Bob; it was criticising Andrew.


> Why is he allowed to post
> whatever trash he wants, yet you come running to his rescue?
> Look at Andrew's effort as a tongue in cheek or even polite way of
> saying "Bob stop posting trash".
>
> And I'm sure Andrew isn't the only one wanting to express that
> sentiment.

Where did you get the idea that "allowed" has anything to do
with usenet? People post whatever they want. There are
no crossing guards. If you don't like that fact, you might
want to seek out a moderated forum.

And consider:

George, why are you sucking up to Andrew? Why is he
allowed to post whatever trash he wants, yet you come
running to his rescue? Look at Bob's efforts as an educated
or even rude way of saying "Andrew stop posting trash."
And I'm sure Bob isn't the only one wanting to express
that sentiment.

See how it works?


> > Try it:
> >
> > Bob Badour wrote:
> > >
> > > OO is a computational model and not a paradigm unless by 'paradigm' one
> > > means an example of a computational model. Idiot. Further, it is a
> > > computational model comprising a collection of features useful for
> > > constructing large unpredictable state machines from small predictable
> > > state machines or otherwise picked arbitrarily in the mid to late 1960's
> > > for what seemed expedient at the time.
> >
> > becomes:
> >
> > > OO is a computational model and not a paradigm unless by 'paradigm' one
> > > means an example of a computational model. Further, it is a
> > > computational model comprising a collection of features useful for
> > > constructing large unpredictable state machines from small predictable
> > > state machines or otherwise picked arbitrarily in the mid to late 1960's
> > > for what seemed expedient at the time.
> >
> > Not all that hard, really. And you're left with something that is
> > actually quite well written, and quite cogent.
>
> And this you provide as a good example of quality content.

Love Bob or hate him, "OO is a computational model and not
a paradigm unless by 'paradigm' one means an example of
a computational model" is an awesome sentence.


> That's the
> worst definition of OOP I've ever seen "Large unpredictable state
> machines", yeah right.

Okay, so is "yeah right" supposed to be an example of a
substantive refutation? Why don't you look of the definition
of "state machine" and tell me what aspect of is not met
by an object.


> These newsgroups were way more polite and informative before you guys
> showed up so don't gloat about any "well written, cogent" content. It's
> just filthy trash!

You're right; I could never aspire to the degree of politeness and
informativeness that you embody.


Marshall

0
6/27/2006 4:45:06 AM
Keith H Duggar wrote:
> george99may@gmail.com wrote:
> > Keith, I can't believe you're talking about "mature and
> > considerate"
>
> What you believe about me is entirely irrelevant and surely
> uninteresting to everyone reading this. Furthermore, that
> phrase is trivial and contains almost no substance.
>

But it was your phrase not mine.

> > Bob has insulted more people in these forums than just
> > about everyone else put together
>
> *sigh* Ye old two wrongs crap. Bob and Andrew are different
> people. If Andrew views Bob as behaving badly and decides to
> retaliate by behaving badly himself, that is immature. In
> addition, even when Bob does insult people his posts /still/
> contain cogent content even if you or others are unable to
> maintain enough mental focus to comprehend it. In contrast,
> the Andrew posts I was responding to were entirely vacuous.
>

Bob's posts contain substance, yep, and pigs fly too.

> > then you and that other great suck-up Marshall constantly
> > praise him for it. You go out of your way to say so,
>
> I do not recall ever /praising/ Bob for insulting people. I
> think it's even more unlikely that Marshall ever /praised/
> him for insulting someone. I have at times discussed the
> possible motivations for and the effects (both beneficial
> and detrimental) of insulting someone. But /praise/? Why
> are you libeling me this way?
>

Why don't you re-read the following post of yours, I thought the most
apt description of it and others like it was "praise" (for Bob) but hey
if you prefer another word please let it be known.

http://groups.google.com/group/comp.databases.theory/browse_frm/thread/7e3e1931a8454d40/f9a60f38fa93bf51?lnk=st&q=&rnum=97#f9a60f38fa93bf51

> > yet if anyone has a mild rib at him you come running to
> > the brute's defense!
>
> What the hell are you talking about? I wasn't defending Bob.
> I was pointing out to Andrew that his posts were worthless
> and vacuous. And I don't give a shit who insults who as long
> as they do so while providing /substantive content/.
>

Yeah, ok and consider my sample link as provision of substance.

> > Wow, what kind of a brainless moron are you? Are you sane?
> > Is Bob your cult leader or something? Or are you guys the
> > only ones with a license to insult?
>
> Obviously you feel you have license to insult me. That makes
> your final question rather stupid don't you think? But, yes;
> We are the only ones with license to insult and we are the
> only licensing authority. You insulted me without license,
> so consider your license to insult revoked for life!
>

Hey that's almost amusing. But if it's good enough for you, Bob,
Marshall, Alfredo ... it's good enough for me.

> -- Keith -- Fraud 6

Keith next time you give whole hearted support to a brute don't be so
surprised if people paint you with the same brush.

0
6/27/2006 5:26:25 AM
On Mon, 26 Jun 2006 13:33:51 -0600, Chris Smith wrote:

> You've really lost me now.  The question was what to call a graph whose 
> dual has only one node (i.e., the edges don't divide the plane).  The 
> correct answer is "forest" (or "tree", if we assume connectedness).  
> "Ordered" is decidedly not a correct answer.

OK, I thought the question was about hierarchies. My mistake.

>>> Any graph 
>>> (planar or not, cycles or not, doesn't matter) may be made into an 
>>> ordered graph simply by defining an order for its nodes.
>> 
>> If you can order the set of nodes. But that order is not necessary G*.
> 
> Of course I can order the set of nodes.  I just start somewhere, and 
> start counting, like so... 1, 2, 3, 4, and so on.
> Who cares if the 
> order I come up with is equivalent to the transitive closure of a 
> directed graph?

The hierarchy does.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
6/27/2006 7:16:14 AM
frebe73@gmail.com wrote:

> > > Another disadvantage is the fact that the number
> > > SQL statements should be limited
> > ???
> 
> For example, a common practice is to only have one update method which
> updates all columns, regardless if they need to be updated or not. The
> same practice can be seen with select statments, all columns are
> selected regardless if you actually need the value or not. You have
> similar problems with joining.

	What if you have an Employee table which contains a BLOB with the
employee's mugshot^H^H^H^Hpicture? Updating a set of employees then
requires you to pass the blob as well even if it's not changed.

> > Does it "have to" ? I've seen a lot of ways to use OO in
> > SQLDBMS-based applications, not all using "domain objects". So this
> > can't count as a problem with OO itself, only with how OO is/can be
> > used.
> 
> Another problem with OO. Nobody actually knows that OO is. Many OO
> evangelists would fight until they die before they drop the use of
> "domain objects". Maybe you can provide links to the definition of OO?

	I fail to see why a lack of agreement over what an acronym stands for
as in: the exact definition, stops you from applying mechanisms (or
whatever the f... some people want to call them) in your software
writing? After all, 'SQL' is also an acronym, and it even had several
standard versions, yet none of the major RDBMS vendors implements these
standard in full. So what is 'SQL' anyway? Well, a nice definition and
standard on paper, however in practise you better get your <insert
dialect acronym here>-SQL manual ready if you want to get things done.

> > Strategy pattern doesn't imply subtyping, cf above.
> 
> http://en.wikipedia.org/wiki/Strategy_pattern
> http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPa
> ttern.htm
> 
> It seem to me that subtyping is used. Maybe this is an issue about
> typeless vs types languages.

	No, the strategy pattern can also be used with plug-in style object
usage at runtime. Code calls a generic method, that method checks the
active object which has to handle the call and if it's present it calls
into that object. You then can swap out algorithms by swapping out the
object and replace it with another one. Very common in a lot of
software, like oh, operating systems.

> > I'm afraid that the problem is more with silver-bullet dealers than
> > with OO itself. If you (ie : a 'generic' you - not necessarily th
> > person named Fredrik Bertilsson) believe that just using a
> > braindead so-called "OO" language and following the braindead "OO
> > 101" tutorials is enough to get any advantage from OO, then you're
> > in deep deep trouble... And you can s/OO/whatever/g IMHO.
> 
> The reason that OO is misused is that nobody really knows what OO is.
> OO also seem to change by time.

	if you apply a given algorithm A, and in 1980 it was called X and
today it's called Y, did A change because of that name change? No. Only
definition-fetisjists think it's the upmost important issue. Of course
there's no true definition of OO because the _term_ is used in so many
different ways that to get a unified definition is IMHO impossible.
However, if you talk to a C++ programmer, a smalltalk programmer and a
java programmer and you ask them what OO is, it's likely they declare
their language' way of applying OO _the_ way to apply OO. Discussions
about that are stone-age old and keep the definition-fetijists off the
streets but for the rest it's irrelevant, simply because the theory
behind a given pattern P doesn't change which definition of a very
generic term like OO you use.

	Funny thing is that if you give 3 randomly chosen database architects
(or whatever the f... some people want to call these people) the task
to develop the RDM for a big hospital (so you end up with at least 700
or so tables), you will definitely get 3 completely different models.
Which one is right? Which one is wrong? A matter of argumentation and
discussion, not something you can test with a hardened testsuit you
pull off the shelve. Is RM then an ambiguous technique?

> > OO is just a way to organize code.
> 
> Do you think everybody at comp.object agree?

	I'm certain not everyone agrees, also because it's irrelevant. This
isn't comp.OO

> > Ever heard of duck typing, multiple inheritance and multimethods ?
> 
> So far I know, multiple inheritance was skipped in Java because all
> the disadvantages.

	That's Sun propaganda. They just couldn't solve the MI problem in an
elegant way, while there is a solution for the problem, see Eiffel.

		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#) 
------------------------------------------------------------------------
0
6/27/2006 8:35:31 AM
George wrote:
> Keith H Duggar wrote:
> > george99may@gmail.com wrote:

Well, sadly, since your reply was terribly stupid, did not
respond to any of the main points, and offered no apology
for insulting without cause, it's time to move on to the next
phase of dealing with you, moron. The insult laden phase;
since clearly you can only focus on and comprehend insults.

> > > Keith, I can't believe you're talking about "mature
> > > and considerate"
> >
> > What you believe about me is entirely irrelevant and
> > surely uninteresting to everyone reading
> > this. Furthermore, that phrase is trivial and contains
> > almost no substance.
>
> But it was your phrase not mine.

No, idiot, the phrase "Keith, I can't believe you're talking
about 'mature and considerate'" which was yours.

> Bob's posts contain substance, yep, and pigs fly too.

LMAO. Ignorant moron.

> > > then you and that other great suck-up Marshall
> > > constantly praise him for it. You go out of your way
> > > to say so,
> >
> > I do not recall ever /praising/ Bob for insulting people.
> >
>
> Why don't you re-read the following post of yours, I thought the most
> apt description of it and others like it was "praise" (for Bob) but hey
> if you prefer another word please let it be known.

Bahahahaa. This moron can't even tell the difference between
"praise for Bob" and "praising Bob for insulting people".
Try again, idiot.

> > > yet if anyone has a mild rib at him you come running
> > > to the brute's defense!
> >
> > What the hell are you talking about? I wasn't defending
> > Bob.  I was pointing out to Andrew that his posts were
> > worthless and vacuous. And I don't give a shit who
> > insults who as long as they do so while providing
> > /substantive content/.
>
> Yeah, ok and consider my sample link as provision of
> substance.

Providing a link is your idea of substance? LMAO. Damn man,
grow a brain and try some original thought for a change. And
in this case your link was 1) irrelevant (see the inability
to distinguish the meaning of different phrases above) and
2) even irrelevant to both the statements I actually made
above. The idiot can't even tell the difference between
defending person B and chiding person A.

> > > Wow, what kind of a brainless moron are you? Are you
> > > sane?  Is Bob your cult leader or something? Or are
> > > you guys the only ones with a license to insult?
> >
> > Obviously you feel you have license to insult me. That
> > makes your final question rather stupid don't you think?
> > But, yes; We are the only ones with license to insult
> > and we are the only licensing authority. You insulted me
> > without license, so consider your license to insult
> > revoked for life!
>
> Hey that's almost amusing. But if it's good enough for
> you, Bob, Marshall, Alfredo ... it's good enough for me.

Pity that you don't also find reason and brainpower good
for you. Well, perhaps you have no choice. How sad.

> Keith next time you give whole hearted support to a brute
> don't be so surprised if people paint you with the same
> brush.

The only thing that (does not) surprises me is your moronic
inability to understand simple language.

-- Keith -- Fraud 6

0
duggar (292)
6/27/2006 8:36:15 AM
Here's what databases have taught me.

Data, like knowledge, is power.
Databases are for sharing data.
When data gets shared, power gets shared.
When power gets shared, politics happens.




0
dcressey (35)
6/27/2006 10:36:10 AM
> > > > Another disadvantage is the fact that the number
> > > > SQL statements should be limited
> > > ???
> >
> > For example, a common practice is to only have one update method which
> > updates all columns, regardless if they need to be updated or not. The
> > same practice can be seen with select statments, all columns are
> > selected regardless if you actually need the value or not. You have
> > similar problems with joining.
>
> 	What if you have an Employee table which contains a BLOB with the
> employee's mugshot^H^H^H^Hpicture? Updating a set of employees then
> requires you to pass the blob as well even if it's not changed.

I just tell you a common practice in the OO world. I don't agree for
the same argument as you provided. If you need to manipulate data, make
a update statement that sets the columns you want to change, nothing
else.

> > > Does it "have to" ? I've seen a lot of ways to use OO in
> > > SQLDBMS-based applications, not all using "domain objects". So this
> > > can't count as a problem with OO itself, only with how OO is/can be
> > > used.
> >
> > Another problem with OO. Nobody actually knows that OO is. Many OO
> > evangelists would fight until they die before they drop the use of
> > "domain objects". Maybe you can provide links to the definition of OO?
>
> 	I fail to see why a lack of agreement over what an acronym stands for
> as in: the exact definition, stops you from applying mechanisms (or
> whatever the f... some people want to call them) in your software
> writing?

But it is a little bit hard to debate benefits and disadvantages with
OO if we don't know what we are talking about. The use of "domain
objects" are extremly common in "OO applications".

> After all, 'SQL' is also an acronym, and it even had several
> standard versions,

As far as I know there are one standard, ANSI. However the standard is
still developing (-92, -99) but I assume that the new versions are
backward compatible.

> yet none of the major RDBMS vendors implements these
> standard in full.

This is indeed a problem, but the level of standardization is pretty
high.

> So what is 'SQL' anyway?

ANSI SQL.

> Well, a nice definition and
> standard on paper, however in practise you better get your <insert
> dialect acronym here>-SQL manual ready if you want to get things done.

A few years ago I was a member of a team converting a large enterprise
application (<500 tables) to support three major database vendors. 99%
of the SQL statements are used for all three vendors. We had to drop
some vendor specific features, but that is not a big problem.

> > > Strategy pattern doesn't imply subtyping, cf above.
> >
> > http://en.wikipedia.org/wiki/Strategy_pattern
> > http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPa
> > ttern.htm
> >
> > It seem to me that subtyping is used. Maybe this is an issue about
> > typeless vs types languages.
>
> 	No, the strategy pattern can also be used with plug-in style object
> usage at runtime. Code calls a generic method, that method checks the
> active object which has to handle the call and if it's present it calls
> into that object. You then can swap out algorithms by swapping out the
> object and replace it with another one. Very common in a lot of
> software, like oh, operating systems.

It sounds like function pointers. What extra benefits does OO bring to
us?

> > The reason that OO is misused is that nobody really knows what OO is.
> > OO also seem to change by time.
>
> Of course
> there's no true definition of OO because the _term_ is used in so many
> different ways that to get a unified definition is IMHO impossible.

Isn't that a problem? No formal definition?

> 	Funny thing is that if you give 3 randomly chosen database architects
> (or whatever the f... some people want to call these people) the task
> to develop the RDM for a big hospital (so you end up with at least 700
> or so tables), you will definitely get 3 completely different models.
> Which one is right? Which one is wrong?

The relational model has a formal definition in opposite to OO. You can
also use normalization to validate a model. But it will of course be
possible to create different solutions given the same requirements.

Fredrik Bertilsson
http://frebe.php0h.com

0
frebe73 (444)
6/27/2006 11:45:41 AM
David Cressey wrote:
> Here's what databases have taught me.
> 
> Data, like knowledge, is power.
> Databases are for sharing data.
> When data gets shared, power gets shared.
> When power gets shared, politics happens.

Insightful.  Succinct.  One of those "big
picture" perspectives that explains why so
many are so fond of the high priests and
wizards roles that various technologies
engender.
0
J
6/27/2006 2:28:29 PM
Marshall wrote:
(snip)
> 
> Love Bob or hate him, "OO is a computational model and not
> a paradigm unless by 'paradigm' one means an example of
> a computational model" is an awesome sentence.

May I play too ?
"A is a B and not a C unless by 'C' one means an example of B"

Waoo ! Awesome, isn't it ?

Now let's do the same with some other profound cogitations of Mr Badour,
 randomly replace placeholders (here A, B and C) by any funny CS jargon,
spice the whole with the usuals insults, and we'll have a great BBBot.

but wait... A terrible idea crosses my mind... Yes, could it be possible
that they've *already* done it ???

-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/27/2006 4:15:47 PM
George wrote:
> JOG wrote:
> 
(snip)
> 
> JOG you've written nothing about "what databases have taught you", the
> title is wrong, how 'bout:
> 
(snip)
> 

Lol.

But indeed, if the OP learned OO with Java and C++ and all the
Java/Enterprise/PHB-directed-buzzwords crap that is usually associated
with, he surely is in position to blame the tool.

The only problems here with him are 1/ needing years and years to
realize their was something wrong with the tool, 2/ then thinking that
OO is restricted to this kind of crap, and 3/ then buying another
silver-bullet and trolling about the previous.



-- 
bruno desthuilliers
python -c "print '@'.join(['.'.join([w[::-1] for w in p.split('.')]) for
p in 'onurb@xiludom.gro'.split('@')])"
0
onurb (1416)
6/27/2006 4:38:18 PM
Frans Bouma wrote:
> frebe73@gmail.com wrote:
> 
>>>Strategy pattern doesn't imply subtyping, cf above.
>>
>>http://en.wikipedia.org/wiki/Strategy_pattern
>>http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/StrategyPa
>>ttern.htm
>>
>>It seem to me that subtyping is used. Maybe this is an issue about
>>typeless vs types languages.
> 
> 	No, the strategy pattern can also be used with plug-in style object
> usage at runtime. Code calls a generic method, that method checks the
> active object which has to handle the call and if it's present it calls
> into that object. You then can swap out algorithms by swapping out the
> object and replace it with another one. Very common in a lot of
> software, like oh, operating systems.

With all due respect, the generic method makes all these types subtypes 
regardless whether one declares them that way or even uses a language 
that allows one to. They are all subtypes of the union of types defining 
the method.


>>>I'm afraid that the problem is more with silver-bullet dealers than
>>>with OO itself. If you (ie : a 'generic' you - not necessarily th
>>>person named Fredrik Bertilsson) believe that just using a
>>>braindead so-called "OO" language and following the braindead "OO
>>>101" tutorials is enough to get any advantage from OO, then you're
>>>in deep deep trouble... And you can s/OO/whatever/g IMHO.
>>
>>The reason that OO is misused is that nobody really knows what OO is.
>>OO also seem to change by time.
> 
> 	if you apply a given algorithm A, and in 1980 it was called X and
> today it's called Y, did A change because of that name change? No.

That wasn't his argument though. If you call one algorithm X in 1980 and 
  today another algorithm is called X, are they the same algorithm? No.

Thus, speaking sensibly about X becomes extremely difficult. See Date's 
_Principle of Incoherence_.


[irrelevant tirade against alleged fetishists snipped]


> 	Funny thing is that if you give 3 randomly chosen database architects
> (or whatever the f... some people want to call these people) the task
> to develop the RDM for a big hospital (so you end up with at least 700
> or so tables), you will definitely get 3 completely different models.

I will assume that by 'models' above you mean logical designs. The 
differences should come as no surprise because they start from 
requirements and not from a conceptual analysis, which creates the 
starting point for logical design. Conceptual analysis is 'anything 
goes' and is well outside the scope of the relational model.

If all three designers started from the same conceptual analysis, the 
logical designs would be very similar; although, the theory related to 
higher normal forms proves that in at least some cases there are 
multiple equivalent non-loss decompositions using project/join. Making 
those minor differences meaningless.

While a graph of the relations and references among them might look 
different when drawn by the three designers, they would be pretty-much 
the same graph.


> Which one is right? Which one is wrong? A matter of argumentation and
> discussion, not something you can test with a hardened testsuit you
> pull off the shelve. Is RM then an ambiguous technique?

No. The conceptual analysis is the ambiguous part of the example, which 
is totally irrelevant to the RM.


>>>OO is just a way to organize code.
>>
>>Do you think everybody at comp.object agree?
> 
> 	I'm certain not everyone agrees, also because it's irrelevant. This
> isn't comp.OO

When all the OO proponents at c.o agree on what object means, your 
response might begin to approach something valid. As it is, your reply 
was just meaningless handwaving.

[more evasive handwaving snipped]
0
bbadour (434)
6/27/2006 5:22:10 PM
Bruno Desthuilliers wrote:
> Marshall wrote:
> (snip)
> >
> > Love Bob or hate him, "OO is a computational model and not
> > a paradigm unless by 'paradigm' one means an example of
> > a computational model" is an awesome sentence.
>
> May I play too ?
> "A is a B and not a C unless by 'C' one means an example of B"
>
> Waoo ! Awesome, isn't it ?

If you think the sentence remains as clever when you leave
out the nouns, you're mistaken.


> but wait... A terrible idea crosses my mind... Yes, could it be possible
> that they've *already* done it ???

All this demonstrates is that you didn't understand the orginal
sentence.


Marshall

0
6/27/2006 5:34:40 PM
Marshall wrote:

> Bruno Desthuilliers wrote:
> 
>>Marshall wrote:
>>(snip)
>>
>>>Love Bob or hate him, "OO is a computational model and not
>>>a paradigm unless by 'paradigm' one means an example of
>>>a computational model" is an awesome sentence.
>>
>>May I play too ?
>>"A is a B and not a C unless by 'C' one means an example of B"
>>
>>Waoo ! Awesome, isn't it ?
> 
> If you think the sentence remains as clever when you leave
> out the nouns, you're mistaken.
> 
>>but wait... A terrible idea crosses my mind... Yes, could it be possible
>>that they've *already* done it ???
> 
> All this demonstrates is that you didn't understand the orginal
> sentence.

I hope you don't find that at all surprising. Did you think even for a 
minute that any of the self-aggrandizing ignorants ever bothered to open 
a dictionary to learn the meaning of the buzzwords they use?

They use buzzwords because the words are buzzwords and not because the 
buzzwords mean anything. For an excellent treatise on the subject, see 
any of Scott Adams' various compilations.
0
bbadour (434)
6/27/2006 5:51:36 PM
Marshall wrote>
>
> Love Bob or hate him, "OO is a computational model and not
> a paradigm unless by 'paradigm' one means an example of
> a computational model" is an awesome sentence.
>

>
> > That's the
> > worst definition of OOP I've ever seen "Large unpredictable state
> > machines", yeah right.
>
> Okay, so is "yeah right" supposed to be an example of a
> substantive refutation? Why don't you look of the definition
> of "state machine" and tell me what aspect of is not met
> by an object.
>

The definition was:

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

You can represent a state machine with VB version 1, a UNIX shell
script, DOS batch job or rows and tables in a relational db - are these
examples of OOP?

"Large" is a relative term what does it mean 3 or 3million? Sloppy but
I won't pursue it.

"Unpredictable"? Every object I've instantiated behaves in a completely
predictable fashion, specifically as defined by its class, there is no
mystery, no unpredictability. Actually I'm not sure how you'd implement
unpredictability, perhaps you can use reflection then you can invoke
methods at random?

Yet in this great definition the original recipient is suppose to be
the idiot? That's just truly amazing isn't it.

0
6/27/2006 6:04:56 PM
Keith H Duggar wrote:
> george99may@gmail.com wrote:
>> Keith, I can't believe you're talking about "mature and
>> considerate"
> 
> What you believe about me is entirely irrelevant and surely
> uninteresting to everyone reading this. Furthermore, that
> phrase is trivial and contains almost no substance.
> 
>> Bob has insulted more people in these forums than just
>> about everyone else put together
> 
> *sigh* Ye old two wrongs crap. Bob and Andrew are different
> people. If Andrew views Bob as behaving badly and decides to
> retaliate by behaving badly himself, that is immature. 

All true except I'm not retaliating against Bob - he hasn't insulted me 
(or if he has, I've not taken it to heart as insults as boring and 
childish).


> In addition, even when Bob does insult people his posts /still/
> contain cogent content even if you or others are unable to
> maintain enough mental focus to comprehend it. 

What I am doing, is pointing out (in my own mildly-sarcastic-comedy 
way) that for me and others, its getting too tiresome to filter Bob's 
insults from his content.  Its actually easier to simply count the 
'self-aggrandizing idiot' phrase that appear in each of his posts.

 > In contrast,
> the Andrew posts I was responding to were entirely vacuous.

I completely agree.  They aren't meant to contain anything of value or 
worth.

;-)  thats why I changed the subject line  - I was hoping it would be 
enough of a hint to those that dont care to read them...

> 
>> then you and that other great suck-up Marshall constantly
>> praise him for it. You go out of your way to say so,
> 
> I do not recall ever /praising/ Bob for insulting people. I
> think it's even more unlikely that Marshall ever /praised/
> him for insulting someone. I have at times discussed the
> possible motivations for and the effects (both beneficial
> and detrimental) of insulting someone. 

and that might just be the whole problem right there.  A lot of us here 
don't see that insults or bullying is ever appropriate or beneficial.

YMMV

>But /praise/? Why
> are you libeling me this way?
> 
>> yet if anyone has a mild rib at him you come running to
>> the brute's defense!
> 
> What the hell are you talking about? I wasn't defending Bob.
> I was pointing out to Andrew that his posts were worthless
> and vacuous. And I don't give a shit who insults who as long
> as they do so while providing /substantive content/.
> 
>> Wow, what kind of a brainless moron are you? Are you sane?
>> Is Bob your cult leader or something? Or are you guys the
>> only ones with a license to insult?
> 
> Obviously you feel you have license to insult me. That makes
> your final question rather stupid don't you think? But, yes;
> We are the only ones with license to insult and we are the
> only licensing authority. You insulted me without license,
> so consider your license to insult revoked for life!

:)

> 
> -- Keith -- Fraud 6
> 
0
news261 (167)
6/27/2006 6:23:07 PM
David Cressey wrote:
> Here's what databases have taught me.
> 
> Data, like knowledge, is power.
> Databases are for sharing data.
> When data gets shared, power gets shared.
> When power gets shared, politics happens.
> 
> 
> 
> 

lol
0
news261 (167)
6/27/2006 6:27:37 PM
Bob Badour wrote:

snipped

> 
> I hope you don't find that at all surprising. Did you think even for a 
> minute that any of the self-aggrandizing ignorants ever bothered to open 
> a dictionary to learn the meaning of the buzzwords they use?
> 
> They use buzzwords because the words are buzzwords and not because the 
> buzzwords mean anything. For an excellent treatise on the subject, see 
> any of Scott Adams' various compilations.


Keep it up Bob - at this rate we'll have usenet record by the end of the 
month!

0
news261 (167)
6/27/2006 6:33:02 PM
George wrote:
> Bob Badour wrote:
> > OO is a computational model and not a paradigm unless by
> > 'paradigm' one means an example of a computational
> > model. Idiot. Further, it is a computational model
> > comprising a collection of features useful for
> > constructing large unpredictable state machines from
> > small predictable state machines or otherwise picked
> > arbitrarily in the mid to late 1960's
>
> You can represent a state machine with VB version 1, a
> UNIX shell script, DOS batch job or rows and tables in a
> relational db - are these examples of OOP?

As I pointed out in another response, this moron cannot
comprehend basic language. George ignores important words
choosing only to see a subset that offends him. For example,
in his response above the idiot failed to comprehend the
phrases "it is a" and "useful for" by ignoring the words
"a" and "useful".

> "Unpredictable"? Every object I've instantiated behaves in
> a completely predictable fashion, specifically as defined
> by its class, there is no mystery, no unpredictability.

Here the idiot failed to comprehend the phrase "constructing
large unpredictable state machines from small predictable
state machines". He failed to equate "small predictable
state machine" with /object/ and countered by /agreeing/
saying "every object ... behaves in a ... completely
predictable fashion". He failed to understand that "large
unpredictable state machines" means /programs/.

> Actually I'm not sure how you'd implement unpredictability,
> perhaps you can use reflection then you can invoke methods
> at random?

Here the idiot seems to think you need a buzzword
"reflection" to invoke methods at random. LOL.

-- Keith -- Fraud 6

0
duggar (292)
6/27/2006 6:33:59 PM
Keith H Duggar wrote:
> George wrote:
>> Bob Badour wrote:

snipped

> 
>> Actually I'm not sure how you'd implement unpredictability,
>> perhaps you can use reflection then you can invoke methods
>> at random?
> 
> Here the idiot seems to think you need a buzzword
> "reflection" to invoke methods at random. LOL.
> 
> -- Keith -- Fraud 6
> 

Maybe in the language(s) he uses, it is the only way to call random 
methods....  ?

Certainly dont need it in lanuages llike C++, but in ones like Java, 
you'd have very little (if any) alternative.
0
news261 (167)
6/27/2006 6:40:15 PM
George wrote:
> Marshall wrote>
> >
> > Love Bob or hate him, "OO is a computational model and not
> > a paradigm unless by 'paradigm' one means an example of
> > a computational model" is an awesome sentence.
> >
>
> >
> > > That's the
> > > worst definition of OOP I've ever seen "Large unpredictable state
> > > machines", yeah right.
> >
> > Okay, so is "yeah right" supposed to be an example of a
> > substantive refutation? Why don't you look of the definition
> > of "state machine" and tell me what aspect of is not met
> > by an object.
> >
>
> The definition was:
>
> > > Bob Badour wrote:
> > > > OO is a computational model and not a paradigm unless by 'paradigm' one
> > > > means an example of a computational model. Idiot. Further, it is a
> > > > computational model comprising a collection of features useful for
> > > > constructing large unpredictable state machines from small predictable
> > > > state machines or otherwise picked arbitrarily in the mid to late 1960's
> > > > for what seemed expedient at the time.
>
> You can represent a state machine with VB version 1, [...]

Etc. etc. etc., all of which does not answer my question.

Look of the definition of "state machine" and tell me what aspect of
is not met by an object.


> "Unpredictable"? Every object I've instantiated behaves in a completely
> predictable fashion, specifically as defined by its class, there is no
> mystery, no unpredictability.

I take it you've never written a multithreaded program then?


Marshall

0
6/27/2006 6:50:58 PM
Frans Bouma wrote:
[snip]

> 	Funny thing is that if you give 3 randomly chosen database architects
> (or whatever the f... some people want to call these people) the task
> to develop the RDM for a big hospital (so you end up with at least 700
> or so tables), you will definitely get 3 completely different models.

Is this from experience - did you see 3 actual models for
a big hospital? Did you try to find out what was same,
similar and different? I speculate that it is speculation.

It does not match my experience. I did some admittedly
shallow comparisons of different data models in operation
for different organizations in the same businesses
(not hospitals). The similarities were striking,
noted differences were accounted for.
I think this is because when you are in the same
business, you have to deal with the same
facts. If you don't you are in a niche.

> Which one is right? Which one is wrong? A matter of argumentation and
> discussion, not something you can test with a hardened testsuit you
> pull off the shelve. Is RM then an ambiguous technique?

Yes, I suspect it is - in theory more so than in practice.
This is something that can actually be researched beyond the
anekdotal level. Is anybody aware of such research?



-- 
"The person who says it cannot be done
should not interrupt the person doing it."
Chinese Proverb.
0
mAsterdam (155)
6/27/2006 6:58:02 PM
George wrote:

> Marshall wrote>
> 
>>Love Bob or hate him, "OO is a computational model and not
>>a paradigm unless by 'paradigm' one means an example of
>>a computational model" is an awesome sentence.
> 
>>>That's the
>>>worst definition of OOP I've ever seen "Large unpredictable state
>>>machines", yeah right.
>>
>>Okay, so is "yeah right" supposed to be an example of a
>>substantive refutation? Why don't you look of the definition
>>of "state machine" and tell me what aspect of is not met
>>by an object.
> 
> The definition was:
> 
>>>Bob Badour wrote:
>>>
>>>>OO is a computational model and not a paradigm unless by 'paradigm' one
>>>>means an example of a computational model. Idiot. Further, it is a
>>>>computational model comprising a collection of features useful for
>>>>constructing large unpredictable state machines from small predictable
>>>>state machines or otherwise picked arbitrarily in the mid to late 1960's
>>>>for what seemed expedient at the time.
> 
> You can represent a state machine with VB version 1, a UNIX shell
> script, DOS batch job or rows and tables in a relational db - are these
> examples of OOP?

Are you trying to make a point? I don't recall redefining OOP as "any 
device or technology useful for constructing state machines." One can 
construct state machines with nothing more than inverting amplifiers. 
Computers, themselves, are nothing more or less than huge state machines.

I will respond to your argument above by analogy: That "a lever is a 
simple machine useful for amplifying force" in no way diminishes or 
contradicts the statement that "a ramp is a simple machine useful for 
amplifying force."


> "Large" is a relative term what does it mean 3 or 3million? Sloppy but
> I won't pursue it.

It has been argued that there are only three useful numbers in 
computing: zero, one and some arbitrarily large power of two. Others 
have stated essentially the same point as: zero, one and infinity.

Whatever "large" is, it is larger than zero or one. Given that the 
purpose of relative terms is to compare things and given that the 
original statement compared the sizes of two state machines, I find your 
inability to understand a relative term relating sizes quite remarkable.

Do you have anything to offer resembling a substantive or relevant 
rebuttal to my description of the inclusion criteria for features of the 
OO computational model?


> "Unpredictable"? Every object I've instantiated behaves in a completely
> predictable fashion, specifically as defined by its class, there is no
> mystery, no unpredictability. Actually I'm not sure how you'd implement
> unpredictability, perhaps you can use reflection then you can invoke
> methods at random?

Given your inability to parse my statement in any accurate or useful 
manner, I have to conclude you are either totally ignorant of the 
origins of the OO computational model or you lack the intellect to 
comprehend written english or both. I am not sure exactly how the source 
of your inability breaks down, though.

OO was invented for simulation and was first expressed in a language 
called Simula. Stroustrop later invented C++ as a variant of C for 
exactly the same purpose: simulation. Stroustrop used the same inclusion 
criteria when transforming the C computational model into OO and in fact 
borrowed the features from Simula.

The whole purpose of a simulation is to create a large unpredictable 
state machine to discover what would happen in various conditions. If 
the simulations were predictable, there would be no need for them in the 
first place.

That an individual object class defines a template for a relatively 
simple predictable state machine agrees entirely with my description of 
the inclusion criterion for features of the OO computational model. The 
computational model is, after all, useful for piecing together large 
unpredictable state machines from small predictable state machines.

Oh the irony, when people using the computational model to piece 
together predictable state machines with the intent to create larger 
predictable state machines discover the result is unpredictable after all.


> Yet in this great definition the original recipient is suppose to be
> the idiot? That's just truly amazing isn't it.

I am not sure what part you find amazing. The part where I can identify 
idiots by their apparent ignorance and profound inability to accurately 
describe what they vociferously advocate? The part where I can identify 
idiots by their habit of substituting meaningless buzzwords where one 
would ordinarily expect to find intelligence and reason? The part where 
I have a demonstrably better grasp of both OO and written english than 
the OO proponents I encounter? The part where I am unafraid to give 
voice to these observations?
0
bbadour (434)
6/27/2006 7:04:05 PM
Marshall wrote:

> Bob Badour wrote:
> 
>>Probably from 1963 or 1964 -- before I was born!
> 
> Ack! You're younger than me. That is *so* unfair.

Then, you have retained your enthusiasm for pure mathematics much longer 
than me, and that is at least equally unfair.
0
bbadour (434)
6/27/2006 7:23:50 PM
Dan wrote:
> Absolutely true!  Relational or object-oriented, it doesn't matter,
> it's the thought process and ability to apply critical analysis to
> problems that makes or breaks the project or solves the problem in the
> most elegant way possible.

This seems to imply that the languages and other formalisms are all the
same, though, and I don't think that's true at all. Yes, you can write
horrid code using Lisp, Haskell, Java, assembler, XML, SQL tables,
relations, etc., and you can write good systems in them as well, but
that doesn't mean that some languages and constructs aren't better all
around than some others. To assert otherwise is to assert that
languages and systems have no impact on the way we think, and I think
that's silly.

- Eric

0
eric.kaun (62)
6/27/2006 7:49:18 PM
Marshall wrote:
> George wrote:
> > Marshall wrote>
> > >
> > > Love Bob or hate him, "OO is a computational model and not
> > > a paradigm unless by 'paradigm' one means an example of
> > > a computational model" is an awesome sentence.
> > >
> >
> > >
> > > > That's the
> > > > worst definition of OOP I've ever seen "Large unpredictable state
> > > > machines", yeah right.
> > >
> > > Okay, so is "yeah right" supposed to be an example of a
> > > substantive refutation? Why don't you look of the definition
> > > of "state machine" and tell me what aspect of is not met
> > > by an object.
> > >
> >
> > The definition was:
> >
> > > > Bob Badour wrote:
> > > > > OO is a computational model and not a paradigm unless by 'paradigm' one
> > > > > means an example of a computational model. Idiot. Further, it is a
> > > > > computational model comprising a collection of features useful for
> > > > > constructing large unpredictable state machines from small predictable
> > > > > state machines or otherwise picked arbitrarily in the mid to late 1960's
> > > > > for what seemed expedient at the time.
> >
> > You can represent a state machine with VB version 1, [...]
>
> Etc. etc. etc., all of which does not answer my question.
>

I have answered issues you raised in previous posts, you issued a
challange to find what was wrong with Bob's "awesome definition",
remember you provided a recipe for how to read such cogent posts.

> Look of the definition of "state machine" and tell me what aspect of
> is not met by an object.
>

Object's may be state machines but state machines are not necessarily
(OOP) objects, there are many other kinds of state machines and the
terms are far from synonymous.

>
> > "Unpredictable"? Every object I've instantiated behaves in a completely
> > predictable fashion, specifically as defined by its class, there is no
> > mystery, no unpredictability.
>
> I take it you've never written a multithreaded program then?
>

Actually I have, and funny enough it was all predictable. I think they
call it programming.

>
> Marshall

Marshall do you concede the definition in question is totally
rediculous or do you wish to defend it further?  And if you guys
critique OOP shouldn't you at least first understand it  (in terms of a
reasonable definition)?

0
6/27/2006 8:01:50 PM
Dan wrote:
><SNIP>   ... Babbage, Turing, Shannon, and many
> others did just fine.  I now see the problems they solved, resolved in
> the worst possible ways with the state of the art tools and
> computational models.  <SNIP>

OK, I'll bite.  What exactly can I learn (or re-learn) from Babbage?
What exactly does "doing just fine" mean with regard to Babbage when he
signally failed to build either one of his machines?

Or is this just a variation of the lament for the lost *Truely*
Relational DBMS?

0
6/27/2006 9:06:00 PM
George wrote:

> Marshall wrote:
> 
>>George wrote:
>>
>>>Marshall wrote>
>>>
>>>>Love Bob or hate him, "OO is a computational model and not
>>>>a paradigm unless by 'paradigm' one means an example of
>>>>a computational model" is an awesome sentence.
>>>>
>>>
>>>>>That's the
>>>>>worst definition of OOP I've ever seen "Large unpredictable state
>>>>>machines", yeah right.
>>>>
>>>>Okay, so is "yeah right" supposed to be an example of a
>>>>substantive refutation? Why don't you look of the definition
>>>>of "state machine" and tell me what aspect of is not met
>>>>by an object.
>>>
>>>The definition was:
>>>
>>>>>Bob Badour wrote:
>>>>>
>>>>>>OO is a computational model and not a paradigm unless by 'paradigm' one
>>>>>>means an example of a computational model. Idiot. Further, it is a
>>>>>>computational model comprising a collection of features useful for
>>>>>>constructing large unpredictable state machines from small predictable
>>>>>>state machines or otherwise picked arbitrarily in the mid to late 1960's
>>>>>>for what seemed expedient at the time.
>>>
>>>You can represent a state machine with VB version 1, [...]
>>
>>Etc. etc. etc., all of which does not answer my question.
> 
> I have answered issues you raised in previous posts, you issued a
> challange to find what was wrong with Bob's "awesome definition",
> remember you provided a recipe for how to read such cogent posts.

And you proceeded to prove yourself incapable of comprehending written 
english.


>>Look of the definition of "state machine" and tell me what aspect of
>>is not met by an object.
> 
> Object's may be state machines but state machines are not necessarily
> (OOP) objects

Your statement was already implied by my description of OO. After all, 
if all state machines were object instances, one could not construct 
larger unpredictable state machines from smaller predictable ones.


, there are many other kinds of state machines and the
> terms are far from synonymous.

That, however, does nothing to contradict my description of the 
inclusion criteria for the computational model.

[multithreaded irrelevancies snipped]


> Marshall do you concede the definition in question is totally
> rediculous or do you wish to defend it further?

Why on earth would he concede that something accurate, true and 
informative is ridiculous? Do you expect him to lie?

Or are you suggesting it is accurate, true, informative and nevertheless 
ridiculous? Like a mother's admonition to always wear clean underwear in 
case one gets incapacitated in a horrible accident and hauled off to the 
hospital?

Do you concede that my statement accurately describes the foundation and 
formation of the OO computational model? After all, it was merely a 
succinct restatement of verifiable historic facts.


   And if you guys
> critique OOP shouldn't you at least first understand it  (in terms of a
> reasonable definition)?

I do understand it. I have demonstrated 1) that I understand the 
computational model, 2) that I understand the origin of the 
computational model, 3) that I understand the weaknesses of the 
computational model, and 4) that I understand that it is a computational 
model in the first place, which is a lot more than you can legitimately 
claim for yourself. I not only understand it--I can articulate my 
understanding with precision and brevity.
0
bbadour (434)
6/27/2006 9:45:43 PM
Bruno Desthuilliers wrote:
> Bob Badour a �crit :
> (snip)
>> I hope you don't find that at all surprising. Did you think even for a 
>> minute that any of the self-aggrandizing ignorants 
> 
> Youpie ! I finally got my self-aggrandizing ignorant degree !-)

A few more posts and it'll be a doctorate!
0
news261 (167)
6/27/2006 10:06:12 PM
Bruno Desthuilliers wrote:

> erk a �crit :
> 
>> Dan wrote:
>>
>>> Absolutely true!  Relational or object-oriented, it doesn't matter,
>>> it's the thought process and ability to apply critical analysis to
>>> problems that makes or breaks the project or solves the problem in the
>>> most elegant way possible.
>>
>> This seems to imply that the languages and other formalisms are all the
>> same, though, and I don't think that's true at all.
> 
> It does not imply that RM and OO are "the same", but that the real 
> problem is elsewhere.

You have yet to establish that my description of the source of the 
problem was in any way inaccurate:

"One might add that the 80% of complicated code Bruno saw resulted from 
having a surfeit of structures to choose from and a paucity of available 
manipulations in the first place."

Precise languages encourage precise thinking. Imprecise languages 
encourage imprecise thinking. For tasks where precision of thought is 
important, precise languages are superior to imprecise languages. 
Computer programming requires precise thought.

I suggest that you sometime read some of these EWD's I frequently 
reference. They reflect the beauty of a much more powerful and 
well-trained mind than mine or probably any contributing in either of 
these newsgroups. I suggest you start with EWD709 and EWD68:

http://www.cs.utexas.edu/users/EWD/transcriptions/EWD07xx/EWD709.html
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD00xx/EWD68.html


>> Yes, you can write
>> horrid code using Lisp, Haskell, Java, assembler, XML, SQL tables,
>> relations, etc., and you can write good systems in them as well, but
>> that doesn't mean that some languages and constructs aren't better all
>> around than some others. To assert otherwise is to assert that
>> languages and systems have no impact on the way we think, and I think
>> that's silly.
> 
> Flawed logic here. The fact that languages[/systems/tools/whatever] have 
> an impact on the way we think does not imply that some languages[etc] 
> are better "all around" than other.

Your logic is the flawed logic. He did not say 'this language is 
necessarily better than that language because...'. He merely pointed out 
that your argument failed to prove the impossibility of such a language. 
Your argument also fails to contradict the idea that a language can be 
worse all around too.


  It only implies that some
> languages[etc] *can* be better (ie: more appropriate) for certain 
> persons for a certain class of tasks.

No, his argument implies that you have failed to prove the conjecture 
that no universally superior or inferior languages can exist within some 
universe of languages.


  So, since it's a person that is
> doing the job, the purely technical aspect may not be the most important 
> factor in success or failure.

That in no way affects your failure to prove the impossibility of 
superior or inferior languages. In fact, the introduction of psychology 
only introduces another method by which a language can be universally 
good or universally bad.


> The truth is that anyone trying to sell you a silver bullet is liar.

Hear! Hear! That's the first sensible thing you have written here.
0
bbadour (434)
6/27/2006 10:27:48 PM
Bruno Desthuilliers wrote:
> Bob Badour a �crit :
> (snip)
> 
>> I hope you don't find that at all surprising. Did you think even for a 
>> minute that any of the self-aggrandizing ignorants 
> 
> Youpie ! I finally got my self-aggrandizing ignorant degree !-)

Tu l'avais depuis longtemps. Plonque!
0
bbadour (434)
6/27/2006 10:27:52 PM
Pickie wrote:
> Dan wrote:
> ><SNIP>   ... Babbage, Turing, Shannon, and many
> > others did just fine.  I now see the problems they solved, resolved in
> > the worst possible ways with the state of the art tools and
> > computational models.  <SNIP>
>
> OK, I'll bite.  What exactly can I learn (or re-learn) from Babbage?
> What exactly does "doing just fine" mean with regard to Babbage when he
> signally failed to build either one of his machines?
>
> Or is this just a variation of the lament for the lost *Truely*
> Relational DBMS?

Hey pickie,

To your question, "what can I learn from..?", perhaps my statement was
overly general, but I was trying to convey my appreciation for those
that could describe a problem and solution using english and formalisms
to solve problems, even without the benefit of tools and technology.  I
don't want to go on a rant here though.  It is merely my own opinion
and therefore subjective.

In regards to Babbage's failures, I was under the impression his plans
and specifications resulted in a perfectly functioning difference
engine in the late 1900's, but that funding and such proved the barrier
to him succeeding in his time.  He still visualized a mechanical
computer for solving problems without the benefit of having a computer
or programming language and it had remarkable similarity of
architecture to computers of our time.

In regards to your last point.  No.  I am not one of those that does
such lamenting.

- Dan

0
6/28/2006 12:44:55 AM
erk wrote:
> Dan wrote:
> > Absolutely true!  Relational or object-oriented, it doesn't matter,
> > it's the thought process and ability to apply critical analysis to
> > problems that makes or breaks the project or solves the problem in the
> > most elegant way possible.
>
> This seems to imply that the languages and other formalisms are all the
> same, though,

How so?  Is this your logic?

1.  If the RM designer is unskilled then the implemented solution
sucks.
2.  If the OO programmer is unskilled then the implemented solution
sucks.
3.  For any language x, if the programmer/architect/designer is
unskilled and ignorant, the implemented solution y sucks.

Therefore all languages and formalisms are the same.  ????

I think I know what you meant, but I don't buy it.  I have an
appreciation for clear, declarative statements, but others don't share
my appreciation and are much more adept at linear procedural type
thinking.  Believe it or not, my 6-8 page declarative queries do
confuse some, no matter how logical and self-evident I belive they are.

and I don't think that's true at all. Yes, you can write
> horrid code using Lisp, Haskell, Java, assembler, XML, SQL tables,
> relations, etc., and you can write good systems in them as well, but
> that doesn't mean that some languages and constructs aren't better all
> around than some others.

Did it appear as though I made such a claim?  If so, I take it back.

To assert otherwise is to assert that
> languages and systems have no impact on the way we think, and I think
> that's silly.

Again, I fail to see the validity of the logic.  How does the assertion
or claim that some languages or constructs are not better than others
necessarily lead to the conclusion that languages and systems have no
impact on the way we think?  We are missing a lot of logical
connectives and premises here in order to make this connection.  I'm
talking about form here.

Regardless, what is the objective function for determining "better"?
and does your statements then mean that users of some languages and
constructs are "better" thinkers?  Was Dijkstra an RM user?  Wirth?
Aristotle?

> 
> - Eric

- Dan

0
6/28/2006 1:05:24 AM
erk a �crit :
> Dan wrote:
> 
>>Absolutely true!  Relational or object-oriented, it doesn't matter,
>>it's the thought process and ability to apply critical analysis to
>>problems that makes or breaks the project or solves the problem in the
>>most elegant way possible.
> 
> 
> This seems to imply that the languages and other formalisms are all the
> same, though, and I don't think that's true at all.

It does not imply that RM and OO are "the same", but that the real 
problem is elsewhere.

> Yes, you can write
> horrid code using Lisp, Haskell, Java, assembler, XML, SQL tables,
> relations, etc., and you can write good systems in them as well, but
> that doesn't mean that some languages and constructs aren't better all
> around than some others. To assert otherwise is to assert that
> languages and systems have no impact on the way we think, and I think
> that's silly.

Flawed logic here. The fact that languages[/systems/tools/whatever] have 
an impact on the way we think does not imply that some languages[etc] 
are better "all around" than other. It only implies that some 
languages[etc] *can* be better (ie: more appropriate) for certain 
persons for a certain class of tasks. So, since it's a person that is 
doing the job, the purely technical aspect may not be the most important 
factor in success or failure.

The truth is that anyone trying to sell you a silver bullet is liar.
0
6/28/2006 1:08:11 AM
Bob Badour a �crit :
(snip)
> I hope you don't find that at all surprising. Did you think even for a 
> minute that any of the self-aggrandizing ignorants 

Youpie ! I finally got my self-aggrandizing ignorant degree !-)
0
6/28/2006 1:10:47 AM
Marshall a �crit :
> Bruno Desthuilliers wrote:
> 
>>Marshall wrote:
>>(snip)
>>
>>>Love Bob or hate him, "OO is a computational model and not
>>>a paradigm unless by 'paradigm' one means an example of
>>>a computational model" is an awesome sentence.
>>
>>May I play too ?
>>"A is a B and not a C unless by 'C' one means an example of B"
>>
>>Waoo ! Awesome, isn't it ?
> 
> 
> If you think the sentence remains as clever when you leave
> out the nouns, you're mistaken.

If you think this was supposed to be clever, you're mistaken.

> 
> 
>>but wait... A terrible idea crosses my mind... Yes, could it be possible
>>that they've *already* done it ???
> 
> 
> All this demonstrates is that you didn't understand the orginal
> sentence.

All this demonstrate that you don't understand the difference between an 
obvious joke (probaly bad, that's not the point) and a serious argument.
0
6/28/2006 1:16:47 AM
Dan wrote:

> erk wrote:
> 
>>Dan wrote:
>>
> To assert otherwise is to assert that
> 
>>languages and systems have no impact on the way we think, and I think
>>that's silly.
> 
> Again, I fail to see the validity of the logic.  How does the assertion
> or claim that some languages or constructs are not better than others
> necessarily lead to the conclusion that languages and systems have no
> impact on the way we think?  We are missing a lot of logical
> connectives and premises here in order to make this connection.  I'm
> talking about form here.
> 
> Regardless, what is the objective function for determining "better"?
> and does your statements then mean that users of some languages and
> constructs are "better" thinkers?  Was Dijkstra an RM user?  Wirth?
> Aristotle?

Dijkstra and Wirth used predicate calculus. Dijkstra credits Hoare with 
introducing him to it. (I am extrapolating to Wirth given that his work 
so often touched on Hoare's and Dijkstra's.)

Aristotle did not use predicate calculus. However, he broke ground on a 
little think called symbolic logic. It took a couple millenia and a lot 
of nurturing but the darn thing grew up into predicate calculus.

I agree they are all examples of exceptional minds, and I note they all 
saw the value of a good formalism.
0
bbadour (434)
6/28/2006 1:31:14 AM
Bob Badour a �crit :
(snip)

> OO was invented for simulation and was first expressed in a language 
> called Simula. Stroustrop later invented C++ 

Simula : 1962/1967.
C++ : 1979/1985.

Strange enough, you forgot this one:

Smalltalk  : 1971/1980.

First language labelled as "object-oriented", and to have all the 
canonical features of OO.

> as a variant of C for 
> exactly the same purpose: simulation.

"The specific tasks that caused me to start designing and implementing 
C++ (initially called "C with Classes") had to do with distributing 
operating system facilities across a network."

http://www.research.att.com/~bs/bs_faq.html#why

> Stroustrop used the same inclusion 
> criteria when transforming the C computational model into OO 

"C++ is a multi-paradigm programming language that supports 
Object-Oriented and other useful styles of programming"

http://www.research.att.com/~bs/bs_faq.html#Object-Oriented-language

> and in fact 
> borrowed the features from Simula.

"Standard C++ and the design and programming styles it supports owe a 
debt to the functional languages, especially to ML"

http://www.research.att.com/~bs/bs_faq.html#advanced

NB : to be honest : 
http://www.research.att.com/~bs/bs_faq.html#from-Smalltalk

> The whole purpose of a simulation is to create a large unpredictable 
> state machine 

Possibly. But simulation was not the purpose of Smalltalk (first 
language labelled as "object-oriented") nor AFAICT of C++

"When I first developed C++, AT&T built systems of greater complexity 
and with greater reliability requirements than most organizations. 
Consequently, we had to influence the market and help set standards that 
meet our needs - or else we wouldn't have the tools to build our systems. "

http://www.research.att.com/~bs/bs_faq.html#why-ATT

Now waiting for the usual insults...
0
6/28/2006 2:54:03 AM
Bob Badour a �crit :
> Bruno Desthuilliers wrote:
> 
(snip)
> Your logic is the flawed logic. He did not say 'this language is 
> necessarily better than that language because...'. He merely pointed out 
> that your argument

Not mine. Should read before you reply...

(snip)


>> So, since it's a person that is
>> doing the job, the purely technical aspect may not be the most 
>> important factor in success or failure. 
> 
> That in no way affects your failure to prove the impossibility of 
> superior or inferior languages.

You fail to prove that I meant to prove such a thing.

> In fact, the introduction of psychology 
> only introduces another method by which a language can be universally 
> good or universally bad.

Care to explain, or is this just random words ?

>> The truth is that anyone trying to sell you a silver bullet is liar.
>  
> Hear! Hear! That's the first sensible thing you have written here.

No, but you're way too fanatical to notice the rest (would require a 
much more opened mindset). Now I'm glad you find this sensible, since it 
also apply to the "SQL DBMS �ber alles" side...
0
6/28/2006 3:17:52 AM
Bob Badour a �crit :
> Bruno Desthuilliers wrote:
> 
>> Bob Badour a �crit :
>> (snip)
>>
>>> I hope you don't find that at all surprising. Did you think even for 
>>> a minute that any of the self-aggrandizing ignorants 
>>
>>
>> Youpie ! I finally got my self-aggrandizing ignorant degree !-)
> 
> 
> Tu l'avais depuis longtemps. Plonque!

Bobby, mon chou, �a fait deux fois que tu me plonque, mais je constate 
que tu persistes � lire ma prose...
0
6/28/2006 3:19:55 AM
Andrew McDonagh a �crit :
> Bruno Desthuilliers wrote:
> 
>> Bob Badour a �crit :
>> (snip)
>>
>>> I hope you don't find that at all surprising. Did you think even for 
>>> a minute that any of the self-aggrandizing ignorants 
>>
>>
>> Youpie ! I finally got my self-aggrandizing ignorant degree !-)
> 
> 
> A few more posts and it'll be a doctorate!

Do you think we should mention that on our resumes ?-)
0
6/28/2006 3:20:49 AM
Bob Badour wrote:

> George wrote:
>
> > Marshall wrote>
> >
> >>Love Bob or hate him, "OO is a computational model and not
> >>a paradigm unless by 'paradigm' one means an example of
> >>a computational model" is an awesome sentence.
> >
> >>>That's the
> >>>worst definition of OOP I've ever seen "Large unpredictable state
> >>>machines", yeah right.
> >>
> >>Okay, so is "yeah right" supposed to be an example of a
> >>substantive refutation? Why don't you look of the definition
> >>of "state machine" and tell me what aspect of is not met
> >>by an object.
> >
> > The definition was:
> >
> >>>Bob Badour wrote:
> >>>
> >>>>OO is a computational model and not a paradigm unless by 'paradigm' one
> >>>>means an example of a computational model. Idiot. Further, it is a
> >>>>computational model comprising a collection of features useful for
> >>>>constructing large unpredictable state machines from small predictable
> >>>>state machines or otherwise picked arbitrarily in the mid to late 1960's
> >>>>for what seemed expedient at the time.
> >
> > You can represent a state machine with VB version 1, a UNIX shell
> > script, DOS batch job or rows and tables in a relational db - are these
> > examples of OOP?
>
> Are you trying to make a point? I don't recall redefining OOP as "any
> device or technology useful for constructing state machines." One can
> construct state machines with nothing more than inverting amplifiers.
> Computers, themselves, are nothing more or less than huge state machines.
>

I gave you the benefit of doubt and stuck to programming but nothing in
your definition actually defines the type of programming. You mainly
talk about state machines, which of course can be implemented using
"OOP" and many other ways. Your definition is devoid of any useful
differentiation yet you call the other guy an idiot, so what does that
make you?

> I will respond to your argument above by analogy: That "a lever is a
> simple machine useful for amplifying force" in no way diminishes or
> contradicts the statement that "a ramp is a simple machine useful for
> amplifying force."
>

Can we just stick to "large unpredictable state machines comprised of
smaller predictable ones".

>
> > "Large" is a relative term what does it mean 3 or 3million? Sloppy but
> > I won't pursue it.
>
> It has been argued that there are only three useful numbers in
> computing: zero, one and some arbitrarily large power of two. Others
> have stated essentially the same point as: zero, one and infinity.
>
> Whatever "large" is, it is larger than zero or one. Given that the
> purpose of relative terms is to compare things and given that the
> original statement compared the sizes of two state machines, I find your
> inability to understand a relative term relating sizes quite remarkable.
>

What part of "I won't pursue it" is confusing you?

> Do you have anything to offer resembling a substantive or relevant
> rebuttal to my description of the inclusion criteria for features of the
> OO computational model?
>

I have argued using reductio ad absurdum (proof by contradiction), I
just started with your definition and applied allowed for and
reasonable absurdities, from there the conclusions are obvious?

Implementing "large unpredictable state machines" using DOS batch jobs
may not be what you indended but nothing in your definition disallows
it, can't you see that? And OO programs do not have to be
unpredictable, can't you see that?

Man I cannot think for you.

>
> > "Unpredictable"? Every object I've instantiated behaves in a completely
> > predictable fashion, specifically as defined by its class, there is no
> > mystery, no unpredictability. Actually I'm not sure how you'd implement
> > unpredictability, perhaps you can use reflection then you can invoke
> > methods at random?
>
> Given your inability to parse my statement in any accurate or useful
> manner, I have to conclude you are either totally ignorant of the
> origins of the OO computational model or you lack the intellect to
> comprehend written english or both. I am not sure exactly how the source
> of your inability breaks down, though.
>

Or you could conclude your definition is stupid.

> OO was invented for simulation and was first expressed in a language
> called Simula. Stroustrop later invented C++ as a variant of C for
> exactly the same purpose: simulation. Stroustrop used the same inclusion
> criteria when transforming the C computational model into OO and in fact
> borrowed the features from Simula.
>

Yes but things have moved on and there are other big influences like
Smalltalk and Minsky's frames and what has any of that to do with your
definition?

> The whole purpose of a simulation is to create a large unpredictable
> state machine to discover what would happen in various conditions. If
> the simulations were predictable, there would be no need for them in the
> first place.
>

That may be valid for simulations but not all simulations need to be
written using OOP. Furthermore not all OO programs are simulations, so
the terms are not synonymous. Equating the two is one of your gross
errors.

> That an individual object class defines a template for a relatively
> simple predictable state machine agrees entirely with my description of
> the inclusion criterion for features of the OO computational model. The
> computational model is, after all, useful for piecing together large
> unpredictable state machines from small predictable state machines.
>

You haven't used "class" or "template" until now and you haven't
defined them so I don't know what you mean by them.

> Oh the irony, when people using the computational model to piece
> together predictable state machines with the intent to create larger
> predictable state machines discover the result is unpredictable after all.
>
>

Oh the even greater irony of sloppy operators calling other people
idiots. I'm not even sure you can see how useless your definition is,
that doesn't make you so bright does it? And why are you still
defending it?

> > Yet in this great definition the original recipient is suppose to be
> > the idiot? That's just truly amazing isn't it.
>
> I am not sure what part you find amazing. The part where I can identify
> idiots by their apparent ignorance and profound inability to accurately
> describe what they vociferously advocate? The part where I can identify
> idiots by their habit of substituting meaningless buzzwords where one
> would ordinarily expect to find intelligence and reason? The part where
> I have a demonstrably better grasp of both OO and written english than
> the OO proponents I encounter? The part where I am unafraid to give
> voice to these observations?

The part where you fail to identify yourself as the chief idiot is the
most amazing part.

You have wrongly equated OOP with "simulations" making the terms
virtually synonymous, they are not. And you have wrongly equated "state
machine" and "object" again the terms are not synonymous. If you fail
to grasp this I can't help you.

Until you demonstrate a mildly valid understanding of OOP your
critiques of it are worthless. And your insults seem to best apply to
yourself.

0
6/28/2006 3:25:01 AM
Dan wrote:
> Pickie wrote:
> > Dan wrote:
> > ><SNIP>   ... Babbage, Turing, Shannon, and many
> > > others did just fine.  I now see the problems they solved, resolved in
> > > the worst possible ways with the state of the art tools and
> > > computational models.  <SNIP>
> >
> > OK, I'll bite.  What exactly can I learn (or re-learn) from Babbage?
> > What exactly does "doing just fine" mean with regard to Babbage when he
> > signally failed to build either one of his machines?
> >
> > Or is this just a variation of the lament for the lost *Truely*
> > Relational DBMS?
>
> Hey pickie,
>
> To your question, "what can I learn from..?", perhaps my statement was
> overly general, but I was trying to convey my appreciation for those
> that could describe a problem and solution using english and formalisms
> to solve problems, even without the benefit of tools and technology.  I
> don't want to go on a rant here though.  It is merely my own opinion
> and therefore subjective.
>
> In regards to Babbage's failures, I was under the impression his plans
> and specifications resulted in a perfectly functioning difference
> engine in the late 1900's, but that funding and such proved the barrier
> to him succeeding in his time.  He still visualized a mechanical
> computer for solving problems without the benefit of having a computer
> or programming language and it had remarkable similarity of
> architecture to computers of our time.
>
> In regards to your last point.  No.  I am not one of those that does
> such lamenting.
>
> - Dan

You picked bad examples.  The contributions of Turing and Shannon have
not been lost at all - they underpin the way computers work.  I don't
think anyone is resolving their (Babbage, Turing and Shannon's)
problems using state of the art tools and computational models "in the
worst possible ways".

The accepted story is that Babbage did not have the technology
available to him to build parts to the accuracy he required.  However,
the Science Museum in London built a working "Difference Engine No. 2"
in 1989-1991 to accuracy achievable in Babbage's time, and using
materials as similar to those he could use as possible.  Babbage had
made no attempt to build a No 2 machine.

http://www.sciencemuseum.org.uk/on-line/babbage/index.asp

The difference engine was to carry out a specific task - much like the
earliest electronic computers.  The analytical engine was to have been
a general purpose machine.  A similar inspiration worked in those who
built the first general purpose electronic computers.  In that sense we
may be said to have solved Babbage's problem over again, but we didn't
lose all that much by it.

0
6/28/2006 4:15:24 AM
Bob Badour wrote:

> George wrote:
>
> > Marshall wrote:
> >
> >>George wrote:
> >>
> >>>Marshall wrote>
> >>>
> >>>>Love Bob or hate him, "OO is a computational model and not
> >>>>a paradigm unless by 'paradigm' one means an example of
> >>>>a computational model" is an awesome sentence.
> >>>>
> >>>
> >>>>>That's the
> >>>>>worst definition of OOP I've ever seen "Large unpredictable state
> >>>>>machines", yeah right.
> >>>>
> >>>>Okay, so is "yeah right" supposed to be an example of a
> >>>>substantive refutation? Why don't you look of the definition
> >>>>of "state machine" and tell me what aspect of is not met
> >>>>by an object.
> >>>
> >>>The definition was:
> >>>
> >>>>>Bob Badour wrote:
> >>>>>
> >>>>>>OO is a computational model and not a paradigm unless by 'paradigm' one
> >>>>>>means an example of a computational model. Idiot. Further, it is a
> >>>>>>computational model comprising a collection of features useful for
> >>>>>>constructing large unpredictable state machines from small predictable
> >>>>>>state machines or otherwise picked arbitrarily in the mid to late 1960's
> >>>>>>for what seemed expedient at the time.
> >>>
> >>>You can represent a state machine with VB version 1, [...]
> >>
> >>Etc. etc. etc., all of which does not answer my question.
> >
> > I have answered issues you raised in previous posts, you issued a
> > challange to find what was wrong with Bob's "awesome definition",
> > remember you provided a recipe for how to read such cogent posts.
>
> And you proceeded to prove yourself incapable of comprehending written
> english.
>

Your logic is garbaled, as is your understanding of computer science
which is making it difficult but good news I'm ok with your English.

>
> >>Look of the definition of "state machine" and tell me what aspect of
> >>is not met by an object.
> >
> > Object's may be state machines but state machines are not necessarily
> > (OOP) objects
>
> Your statement was already implied by my description of OO. After all,
> if all state machines were object instances, one could not construct
> larger unpredictable state machines from smaller predictable ones.
>

Bob you haven't defined object oriented or any other kind of
programming, What makes OOP different from "structured", "unstructured"
or "declarative" programming? They can all represent state machines.

>
> , there are many other kinds of state machines and the
> > terms are far from synonymous.
>
> That, however, does nothing to contradict my description of the
> inclusion criteria for the computational model.
>
> [multithreaded irrelevancies snipped]
>
>
> > Marshall do you concede the definition in question is totally
> > rediculous or do you wish to defend it further?
>
> Why on earth would he concede that something accurate, true and
> informative is ridiculous? Do you expect him to lie?
>

Accurate, true and informative? Maybe you should stop taking those
pills.

> Or are you suggesting it is accurate, true, informative and nevertheless
> ridiculous? Like a mother's admonition to always wear clean underwear in
> case one gets incapacitated in a horrible accident and hauled off to the
> hospital?
>

What?

> Do you concede that my statement accurately describes the foundation and
> formation of the OO computational model? After all, it was merely a
> succinct restatement of verifiable historic facts.
>

You talked about Simula and simulations so what?

Can you now realize not all object oriented programs are simulations?
And not all simulations need be implemented using OOP? Or is that
stretching your abilities too far?

Can you also realize your definition allows for implementations using
just about any kind of programming, like DOS batch jobs, all you need
is a way to achieve unpredictability (no wait ...blue screen of
death...) - again are you having trouble here?

>
>    And if you guys
> > critique OOP shouldn't you at least first understand it  (in terms of a
> > reasonable definition)?
>
> I do understand it. I have demonstrated 1) that I understand the
> computational model, 2) that I understand the origin of the
> computational model, 3) that I understand the weaknesses of the
> computational model, and 4) that I understand that it is a computational
> model in the first place, which is a lot more than you can legitimately
> claim for yourself. I not only understand it--I can articulate my
> understanding with precision and brevity.

That's just self-agrandizement.

Your definitions do not concur with any current or historic computer
science. Granted OOP is not defined upon one formal definition or
formalism but there is concensus on its general meaning. OOP doesn't
lack definition, the problem is there are too many definitions. There
exist, however, precise definitions and specifications for most OO
languages. For example Sun's Java specifications therefore you cannot
bemoan any lack of clear specification at least at the language level.
At any rate there is much to draw from.

"Large unpredictable state machines comprised of smaller ones" -
fantastic.

No wonder you resort to insulting but when will you realize insults are
a poor substitute for logic and honest science?

0
6/28/2006 4:27:35 AM
On 2006-06-23 01:51:59 -0700, Joerg Simon <j_simon@gmx.at> said:

> 
> frebe73@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.

It is unfortunately true that there are books that describe OO this 
way.  However, it has been known for quite some time (probably since 
the beginning of OO) that this was an inappropriate way to look at OO.  
While classification structures do exist, they aren't typically deep, 
and they aren't typically common.  What's more, they are based on 
behavior rather than on state.

It is not hiearchy that drives OO, it is dependency management.  It is 
the decoupling of callers from callees through the mechanisms of 
dynamic polymorhism that is the driving force behind OO design.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 5:39:06 AM
On 2006-06-23 11:29:40 -0700, frebe73@gmail.com said:

> 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.

You use the Bridge pattern.

    |PaymentMethod|<-------|Employee|------>|UnionMembership|
           A                                        A
           |                                        |
    +------+------+                       +---------+--------+
    |             |                       |                  |
|HourlyMethod| |SalariedMethod|    |NonMember|         |Local705Member|

So, in fact, you don't have to repeat the implementation.  Instead you 
create a different hierarchy that represents the union branch and pass 
the calculated pay to it.

To see this in action in much more detail I refer you to the Payroll 
solution in my book "Agile Software Development: Principles, Patterns, 
and Practices"


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 5:48:42 AM
On 2006-06-23 04:48:27 -0700, Kenneth Downs 
<knode.wants.this@see.sigblock> said:

> frebe73@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 find this conclusion fascinating.  I cannot imagine a system in which 
I would not want the ability to use dynamic polymorphism to decouple 
modules from each other.  OO has little to do with GUIs, and everything 
to do with dependency management.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 5:50:21 AM
On 2006-06-23 07:51:50 -0700, Kenneth Downs 
<knode.wants.this@see.sigblock> said:

> Is there a rational basis for deciding where to put the logic?

Yes.  It's called "The Single Resonsibility Principle" (SRP).  This 
principle says that a software module should have one, and only one 
reason to change.  For example, a module that contains business rules 
should not also contain report formatting.  Business rules and report 
formatting change for completely different reasons, and should 
therefore be isolated in completely different modules.

Then there's "The Dependency Inversion Principle" (DIP) which says that 
the target of a dependency should be an abstraction.  So, instead of 
this:

     |A|------>|B|

Where module A depends on module B, we want this:

     |A|------->|I|
                 A
                 |
                |B|

Where A depends on an abstract interface, and B implements that 
abstract interface.

If you follow these two principle you will focus change into modules, 
and prevent those changes from leaking out into other modules.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 5:57:26 AM
On 2006-06-23 12:10:33 -0700, "erk" <eric.kaun@gmail.com> said:

> "C++: an octopus made by nailing extra legs onto a dog." - from
> smalltalk.org

C++ is a fine language for many kinds of applications.  I think it's 
getting a little long in the tooth nowadays; but it will be around for 
a long time to come.  Though I used to be a C++ programmer and 
evangelist, my interests lie elsewhere these days.  I now do most of my 
programming in Java, and am about to start investing heavily into Ruby.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 6:01:31 AM
On 2006-06-23 05:17:21 -0700, "Erwin" <e.smout@myonline.be> said:

> 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.

Quite to the contrary, while you can build hierarchies in Smalltalk, 
they are nowhere near as important as they are in C++, Java, or C#.  
Smalltalk, (and derivative languages like Ruby and Python) are 
dynamically typed, and therefore don't rely on inheritance to give them 
dynamic polymorphism.  Therefore building inheritance hierarchies is of 
much less importance in these languages.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 6:04:30 AM
Robert Martin <unclebob@objectmentor.com> writes:
>     |A|------->|I|
>                 A
>                 |
>                |B|

  There's a trade-off ...

  I never understood what this �dependency inversion� is,
  until I re-invented it myself. It happend this way:
 
  I wanted to refactor this Java code:

token.extend( this.cursor.source, text, this.cursor.offset );

  OK, one should not access fields of another class directly, so:

token.extend( this.cursor.getSource(), text, this.cursor.getOffset() );

  Next, �getters are evil� and �tell, don't ask�, so:

cursor.extend( text, token );

  This assumes a new method �extend� will be added to the class
  of �cursor�, which then will call �token.extend� with private
  fields of cursor; so no getter will be needed.

  I was satisfied for a moment ... but then I became aware that
  I have introduced a new dependency! Now the object �cursor�
  needs to know about the class of �token�.

  So, I could add an interface

interface Extensible
{ java.lang.String getSource();
  int getOffset(); }

  implemented by �token�, so that �cursor� only needs to know
  about this interface.

  (I assume, this is �dependency inversion�.)

  But still, I was not satisfied:

  Assume, I continue to do this for every place in the
  code, where getters are used. I would replace them by
  calls such as �cursor.extend�, bloating the class of �cursor�
  and possibly introducing additional interfaces. This would
  also increment code complexity.

  So maybe the solution with getters is not that evil, after all? 

0
ram (2986)
6/28/2006 6:16:09 AM
Pickie wrote:
> Dan wrote:
> > Pickie wrote:
> > > Dan wrote:
> > > ><SNIP>   ... Babbage, Turing, Shannon, and many
> > > > others did just fine.  I now see the problems they solved, resolved in
> > > > the worst possible ways with the state of the art tools and
> > > > computational models.  <SNIP>
> > >
> > > OK, I'll bite.  What exactly can I learn (or re-learn) from Babbage?
> > > What exactly does "doing just fine" mean with regard to Babbage when he
> > > signally failed to build either one of his machines?
> > >
> > > Or is this just a variation of the lament for the lost *Truely*
> > > Relational DBMS?
> >
> > Hey pickie,
> >
> > To your question, "what can I learn from..?", perhaps my statement was
> > overly general, but I was trying to convey my appreciation for those
> > that could describe a problem and solution using english and formalisms
> > to solve problems, even without the benefit of tools and technology.  I
> > don't want to go on a rant here though.  It is merely my own opinion
> > and therefore subjective.
> >
> > In regards to Babbage's failures, I was under the impression his plans
> > and specifications resulted in a perfectly functioning difference
> > engine in the late 1900's, but that funding and such proved the barrier
> > to him succeeding in his time.  He still visualized a mechanical
> > computer for solving problems without the benefit of having a computer
> > or programming language and it had remarkable similarity of
> > architecture to computers of our time.
> >
> > In regards to your last point.  No.  I am not one of those that does
> > such lamenting.
> >
> > - Dan
>
> You picked bad examples.  The contributions of Turing and Shannon have
> not been lost at all - they underpin the way computers work.  I don't
> think anyone is resolving their (Babbage, Turing and Shannon's)
> problems using state of the art tools and computational models "in the
> worst possible ways".

I didn't say the contributions had been lost.  I also didn't limit my
examples to just Babbage, Turing, and Shannon, though I didn't
explicitly list others explicitly.  I admit I formulated my point
rather poorly and concede you raise valid points.

>
> The accepted story is that Babbage did not have the technology
> available to him to build parts to the accuracy he required.  However,
> the Science Museum in London built a working "Difference Engine No. 2"
> in 1989-1991 to accuracy achievable in Babbage's time, and using
> materials as similar to those he could use as possible.  Babbage had
> made no attempt to build a No 2 machine.
>
> http://www.sciencemuseum.org.uk/on-line/babbage/index.asp
>
> The difference engine was to carry out a specific task - much like the
> earliest electronic computers.  The analytical engine was to have been
> a general purpose machine.  A similar inspiration worked in those who
> built the first general purpose electronic computers.  In that sense we
> may be said to have solved Babbage's problem over again, but we didn't
> lose all that much by it.

Thanks for the added information and clarification.

- Dan

0
6/28/2006 7:26:41 AM
Bob Badour wrote:

> Frans Bouma wrote:
> > frebe73@gmail.com wrote:
> > 
> > > > Strategy pattern doesn't imply subtyping, cf above.
> > > 
> > > http://en.wikipedia.org/wiki/Strategy_pattern
> > > http://www.exciton.cs.rice.edu/JavaResources/DesignPatterns/Strate
> > > gyPa ttern.htm
> > > 
> > > It seem to me that subtyping is used. Maybe this is an issue about
> > > typeless vs types languages.
> > 
> > 	No, the strategy pattern can also be used with plug-in style object
> > usage at runtime. Code calls a generic method, that method checks
> > the active object which has to handle the call and if it's present
> > it calls into that object. You then can swap out algorithms by
> > swapping out the object and replace it with another one. Very
> > common in a lot of software, like oh, operating systems.
> 
> With all due respect, the generic method makes all these types
> subtypes regardless whether one declares them that way or even uses a
> language that allows one to. They are all subtypes of the union of
> types defining the method.

 	you mean 'part of the code the generic method is in' ? strictly
speaking, in memory, THAT's correct. For example if you use function
pointers in C to mimic this behavior, you effectively inject code in
your total code. But that's not the same as being part of the type, as
that's not true. The code in generic method can be completed by
programming against an interface. Which code implements that interface
at runtime is of no concern of the generic method.

> > > > I'm afraid that the problem is more with silver-bullet dealers
> > > > than with OO itself. If you (ie : a 'generic' you - not
> > > > necessarily th person named Fredrik Bertilsson) believe that
> > > > just using a braindead so-called "OO" language and following
> > > > the braindead "OO 101" tutorials is enough to get any advantage
> > > > from OO, then you're in deep deep trouble... And you can
> > > > s/OO/whatever/g IMHO.
> > > 
> > > The reason that OO is misused is that nobody really knows what OO
> > > is.  OO also seem to change by time.
> > 
> > 	if you apply a given algorithm A, and in 1980 it was called X and
> > today it's called Y, did A change because of that name change? No.
> 
> That wasn't his argument though. If you call one algorithm X in 1980
> and   today another algorithm is called X, are they the same
> algorithm? No.
> 
> Thus, speaking sensibly about X becomes extremely difficult. See
> Date's _Principle of Incoherence_.

	of course if the same name means 2 things, speaking about any of these
two things by using that ambiguous name is difficult. However 'OO'
means 'object oriented', i.e.: it's a snipped acronym, it's incomplete.
So actually it doesn't mean anything. Now, if you look at when 'OO' is
used stand along as an acronym, it's so diverse, it's irrelevant what
meaning the standalone acronym 'OO' stands for

> > 	Funny thing is that if you give 3 randomly chosen database
> > architects (or whatever the f... some people want to call these
> > people) the task to develop the RDM for a big hospital (so you end
> > up with at least 700 or so tables), you will definitely get 3
> > completely different models.
> 
> I will assume that by 'models' above you mean logical designs. The
> differences should come as no surprise because they start from
> requirements and not from a conceptual analysis, which creates the
> starting point for logical design. Conceptual analysis is 'anything
> goes' and is well outside the scope of the relational model.

	true, but that's the same with OOAD.

> If all three designers started from the same conceptual analysis, the
> logical designs would be very similar; although, the theory related
> to higher normal forms proves that in at least some cases there are
> multiple equivalent non-loss decompositions using project/join.
> Making those minor differences meaningless.
> 
> While a graph of the relations and references among them might look
> different when drawn by the three designers, they would be
> pretty-much the same graph.

	exactly. though the WHOLE process makes it that there can be 3
different graphs which all could be completely correct in their RDM
form.

	If you solely use the term 'OO', which is fuzzy at best, and you pick
3 random system architects, everyone using a different target
platform/language and therefore are bound to the technical aspects of
their target platform/language (platform == java/C++/Smalltalk etc. +
RTL) you get 3 completely different class models which might be correct
for their target platform/language. If you pick a dedicated platform
and language, and do the same thing, and start from the conceptual
analysis, you also end up with pretty much the same class models. So OO
as a standalone term is ambiguous, hardly effectively usable, though if
you're talking about real platforms/languages, and see that as an
analogy of the RM in this, it's not ambigous anymore.

> > Which one is right? Which one is wrong? A matter of argumentation
> > and discussion, not something you can test with a hardened testsuit
> > you pull off the shelve. Is RM then an ambiguous technique?
> 
> No. The conceptual analysis is the ambiguous part of the example,
> which is totally irrelevant to the RM.

	exactly. With OOAD, if you don't know the target platform/language and
thus also not the technical details of these, it's IMHO impossible to
design a class model which you can use to write your software, so 'OO'
is too vague to be useful in this context. You too would agree on the
fact that you can't design an RDM if you don't know what 'RM' is all
about.

> > > > OO is just a way to organize code.
> > > 
> > > Do you think everybody at comp.object agree?
> > 
> > 	I'm certain not everyone agrees, also because it's irrelevant. This
> > isn't comp.OO
> 
> When all the OO proponents at c.o agree on what object means, your
> response might begin to approach something valid. As it is, your
> reply was just meaningless handwaving.

	I don't see it that B/W. Dr. Chen defined 'Entity' years ago, still
the term is also used in various contexts of which I think it has
nothing to do with what Chen meant in the context in which he meant it.
'Object' is such a broad term, it more or less follows the same path as
'Entity' has followed and will follow.

	The thing is that even though for example C# and C++ have one
fundamental element of OOP NOT in common, namely multiple
implementation inheritance, you can still discuss object oriented
development ideas and algorithms/patterns with eachother, as most of
them arent tied to a 'language' but to the ideas behind OOAD.

	IMHO it's similar to that I can defined derived tables in postgresql
but can't do that in sqlserver 2000. It  has nothing to do with RM, but
it has everything to do with the implementation of the constructed RM
in a RDBMS.

		FB

	ps: I'm happy you avoided the insults so we could discuss things. 

-- 
------------------------------------------------------------------------
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#) 
------------------------------------------------------------------------
0
6/28/2006 9:26:44 AM
mAsterdam wrote:

> Frans Bouma wrote:
> [snip]
> 
> > 	Funny thing is that if you give 3 randomly chosen database
> > architects (or whatever the f... some people want to call these
> > people) the task to develop the RDM for a big hospital (so you end
> > up with at least 700 or so tables), you will definitely get 3
> > completely different models.
> 
> Is this from experience - did you see 3 actual models for
> a big hospital? Did you try to find out what was same,
> similar and different? I speculate that it is speculation.

	I have, actually. All 3 had over 1000 tables. Not for the same
hospital, but all were databases for the information systems for big
hospitals. It struck me that they were so different. Of course they all
define 'patient' but it was kind of odd that they ended up with such
different models. And yet, when you looked at them they all made sense.

> It does not match my experience. I did some admittedly
> shallow comparisons of different data models in operation
> for different organizations in the same businesses
> (not hospitals). The similarities were striking,
> noted differences were accounted for.
> I think this is because when you are in the same
> business, you have to deal with the same
> facts. If you don't you are in a niche.

	Then our experiences differ indeed. :)

	My example was more to illustrate that if you talk about something
like 'RM' the end result of the analysis phases might be a RDM, and it
also might be following all the rules defined for RM, but semantically,
does it make sense, is it 'correct' when you project it on reality?
That's something that's unclear, which is the same with OOAD and which
was IMHO the reason why it was more or less classified as not useful by
some, while RM and OOAD are actually in the same boat: the end result
can be tested technically if they obey the rules of RM resp. OOAD, but
if they are 'correct' with respect to reality is not clear in both
situations as in: not for 100% certain. (otherwise no software project
would ever fail ;))

		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#) 
------------------------------------------------------------------------
0
6/28/2006 9:41:26 AM
Bruno Desthuilliers wrote:
> Bob Badour a =E9crit :

Google is not a substitute for thinking. There is more to
learning than the Internet. Wikipedia is an not education.
Information is not knowledge.

> > as a variant of C for exactly the same purpose:
> > simulation.
>
> "The specific tasks that caused me to start designing and
> implementing C++ (initially called "C with Classes") had
> to do with distributing operating system facilities across
> a network."

Do you understand Stroustrup's background was /simulating/
distributed operating systems not /implementing/ them? And
hence "had to do with" there almost surely refers to said
research /simulations/. Find a copy of "The Design and
Evolution of C++" and start reading. It is a great book
anyhow. Here is a relevant quote:

"What is relevant, though, was the focus on composing
software out of well-delimited modules and that the main
experimental tool was a relatively large and detailed
SIMULATOR I wrote for SIMULATING software running on a
distributed system."

> > and in fact borrowed the features from Simula.
>
> "Standard C++ and the design and programming styles it
> supports owe a debt to the functional languages,
> especially to ML"

D&E is replete with references regarding the influence of
Simula. Examples:

(The first sentence of the first chapter.)

"The prehistory of C++ - the couple of years before the idea
of adding Simula-like features to C occurred to me ..."

"It was a pleasure to write that SIMULATOR. The features of
Simula were almost ideal for the purpose ..."

"During the writing and initial debugging, I acquired a great
respect for the expressiveness of Simula's type system ... In
contrast, I had found Pascal's type system to be worse than
useless ... The contrast I perceived between the rigidity of
Pascal and the flexibility of Simula was ESSENTIAL for the
development of C++. Simula's class concept was seen as the
key difference ..."

And it goes on and on and on.

> > The whole purpose of a simulation is to create a large
> > unpredictable state machine
>
> Possibly. But simulation was not the purpose of Smalltalk
> (first language labelled as "object-oriented") nor AFAICT
> of C++

Well it was certainly /an/ original purpose. Though the
design goals seem to have /evolved/ to encompass more
general purposes. However, given that, as Stroustrup said,
his experience with /simulation/ was core it can be argued
that regardless of his goals, he created a language that is
designed around simulation (at least the class portion). And
certainly Bob's original and weaker claim that such features
are /useful/ for simulation is well supported. (Note George
is unable to comprehend words like /an/ and /useful/. He
ignores them and sees /the/ and /defines/ instead.
Hopefully you do not have the same problem.)

-- Keith -- Fraud 6

0
duggar (292)
6/28/2006 11:03:16 AM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2006062722390616807-unclebob@objectmentorcom...


> It is not hiearchy that drives OO, it is dependency management.  It is
> the decoupling of callers from callees through the mechanisms of
> dynamic polymorhism that is the driving force behind OO design.

This is a significant point.  It's worth civil discussion.

From the point of view of databases,  the relational model, and its
commercial implementations (however imperfect),  were also about dependency
management.  What we are talking about here is decoupling the writers of
data from the readers of the same data.  Typically, the writers and the
readers are separated in time,  and therefore decoupled in at least one way.

But the mechanisms (if I can call them that) of physical data independence
and logical data independence allow the decoupling to proceed further than
it would without those mechanisms.  And data independence has been the
driving force behind data modeling for about 36 years.

The value of data independence tends to be lost on those who use a single
application,  or a suite of applications that share a common object class
library to write and read data in a database.  But all you have to do is try
to use Crystal Reports on data that was written by a PowerBuilder
application,  and you begin to truly appreciate the value of data
independence.

I realize the above hasn't said much of anything about dynamic polymorphism,
but I wanted to lay the foundations for a rational discussion of RM  (or
RDM, as I prefer to call it).  A rational discussion of OO and of RM might
yield insights that the present discussion has not yet yielded.



0
dcressey (35)
6/28/2006 12:11:38 PM
Robert Martin wrote:
>
> It is not hiearchy that drives OO, it is dependency management.  It is
> the decoupling of callers from callees through the mechanisms of
> dynamic polymorhism that is the driving force behind OO design.
>
It's a matter of perspective.  From the perspective of web services
people, for example, all of your examples of decoupling are in fact
examples of tight coupling, through dependencies on language bindings
and platform.  From the web services perspective, decoupling is
achieved through the standardization of the format of documents.

Regards,
Daniel Parker

0
6/28/2006 12:41:05 PM
George wrote:

> Bob Badour wrote:
> 
> 
>>George wrote:
>>
>>
>>>Marshall wrote:
>>>
>>>
>>>>George wrote:
>>>>
>>>>
>>>>>Marshall wrote>
>>>>>
>>>>>>Love Bob or hate him, "OO is a computational model and not
>>>>>>a paradigm unless by 'paradigm' one means an example of
>>>>>>a computational model" is an awesome sentence.
>>>>>>
>>>>>
>>>>>>>That's the
>>>>>>>worst definition of OOP I've ever seen "Large unpredictable state
>>>>>>>machines", yeah right.
>>>>>>
>>>>>>Okay, so is "yeah right" supposed to be an example of a
>>>>>>substantive refutation? Why don't you look of the definition
>>>>>>of "state machine" and tell me what aspect of is not met
>>>>>>by an object.
>>>>>
>>>>>The definition was:
>>>>>
>>>>>
>>>>>>>Bob Badour wrote:
>>>>>>>
>>>>>>>
>>>>>>>>OO is a computational model and not a paradigm unless by 'paradigm' one
>>>>>>>>means an example of a computational model. Idiot. Further, it is a
>>>>>>>>computational model comprising a collection of features useful for
>>>>>>>>constructing large unpredictable state machines from small predictable
>>>>>>>>state machines or otherwise picked arbitrarily in the mid to late 1960's
>>>>>>>>for what seemed expedient at the time.
>>>>>
>>>>>You can represent a state machine with VB version 1, [...]
>>>>
>>>>Etc. etc. etc., all of which does not answer my question.
>>>
>>>I have answered issues you raised in previous posts, you issued a
>>>challange to find what was wrong with Bob's "awesome definition",
>>>remember you provided a recipe for how to read such cogent posts.
>>
>>And you proceeded to prove yourself incapable of comprehending written
>>english.
> 
> Your logic is garbaled, as is your understanding of computer science
> which is making it difficult but good news I'm ok with your English.

With all due respect, I can believe you actually believe the above 
statement. You are too stupid and too ignorant to know otherwise. I will 
leave it to the reader to discriminate.


>>>>Look of the definition of "state machine" and tell me what aspect of
>>>>is not met by an object.
>>>
>>>Object's may be state machines but state machines are not necessarily
>>>(OOP) objects
>>
>>Your statement was already implied by my description of OO. After all,
>>if all state machines were object instances, one could not construct
>>larger unpredictable state machines from smaller predictable ones.
> 
> Bob you haven't defined object oriented or any other kind of
> programming, What makes OOP different from "structured", "unstructured"
> or "declarative" programming? They can all represent state machines.

I don't recall claiming to have defined it. I described it's origin and 
construction. Do you see what I mean by your stupidity preventing you 
from comprehending relatively simple english? You are not smart enough 
to understand what is actually written so you respond to something 
entirely different instead.

You then proceed to compare apples and broomhandles. 'Declarative' is 
not a computational model but a classification of computational models. 
"Unstructured" and "structured" have become meaningless nonsense for 
most. Dijkstra himself noted that others had perverted his "austere 
intellectual discipline" called 'structured programming' into a 
meaningless buzzword. See below.

If you want to put forward a legitimate and substantive refutal you must 
do one of the following:

1) Refute that OO is a computational model
2) Refute that the computational model was created ad hoc
3) Demonstrate an inclusion criterion for the features of OO other than 
to facilitate simulation or for expediency at the time.

Regarding the origin of 'structured' and its evolution:

http://www.cs.utexas.edu/users/EWD/ewd02xx/EWD249.PDF
http://www.cs.utexas.edu/users/EWD/transcriptions/EWD02xx/EWD268.html

(Read EWD249 and the much shorter EWD268 in their entirety to learn what 
the term originally meant.) If one has any skill whatsoever using any 
computational model, one will recognize that the intellectual discipline 
of structured programming is orthogonal to the computational model.


http://www.cs.utexas.edu/users/EWD/transcriptions/EWD07xx/EWD709.html

"Write a paper promising salvation, make it a 'structured' something or 
a 'virtual' something, or 'abstract', 'distributed' or 'higher-order' or 
'applicative' and you can almost be certain of having started a new cult."


http://www.cs.utexas.edu/users/EWD/transcriptions/EWD11xx/EWD1175.html

"The second reason is that what society overwhelmingly asks for is snake 
oil. Of course, the snake oil has the most impressive names �otherwise 
you would be selling nothing� like "Structured Analysis and Design", 
"Software Engineering", "Maturity Models", "Management Information 
Systems", "Integrated Project Support Environments" "Object Orientation" 
and "Business Process Re-engineering" (the latter three being known as 
IPSE, OO and BPR, respectively)."

(Martin, pay particularly close attention to the above. As distasteful 
as you find the hypothesis, better minds than mine have put forward the 
same hypothesis.)


http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1305.html

"The required techniques of effective reasoning are pretty formal, but 
as long as programming is done by people that don't master them, the 
software crisis will remain with us and will be considered an incurable 
disease. And you know what incurable diseases do: they invite the quacks 
and charlatans in, who in this case take the form of Software 
Engineering gurus."

"Some of you doubt that aforementioned "techniques of effective 
reasoning", nice as they are for small programs, will scale up, I quote 
"given the daunting size and sheer complexity of most programs". Well, 
they will be powerless if you try to use them to disentangle the 
horrendous mess produced by a group of incompetent, unorganized 
programmers. Their power manifests itself in the construction phase 
where (i) they tend to lead to much shorter texts than would be produced 
otherwise and (ii) lengths of program derivations tend to grow not much 
more than linearly with the lengths of the programs derived. Finally the 
programs thus produced are infinitely better than the usual junk."


http://www.cs.utexas.edu/users/EWD/transcriptions/EWD13xx/EWD1308.html

"Apparently, IBM did not like the popularity of my text; it stole the 
term "Structured Programming" and under its auspices Harlan D. Mills 
trivialized the original concept to the abolishment of the goto statement."

(EWD1308 also has the interesting anecdote giving N. Wirth credit for 
inventing on of Dijkstra's most famous quotes.)


>>>Marshall do you concede the definition in question is totally
>>>rediculous or do you wish to defend it further?
>>
>>Why on earth would he concede that something accurate, true and
>>informative is ridiculous? Do you expect him to lie?
> 
> Accurate, true and informative? Maybe you should stop taking those
> pills.

I don't take pills, and you have failed to demonstrate that the 
description was inaccurate, untrue or uninformative. I am concluding you 
are too stupid to.


>>Or are you suggesting it is accurate, true, informative and nevertheless
>>ridiculous? Like a mother's admonition to always wear clean underwear in
>>case one gets incapacitated in a horrible accident and hauled off to the
>>hospital?
> 
> What?

Apparently, you were not, then.


>>Do you concede that my statement accurately describes the foundation and
>>formation of the OO computational model? After all, it was merely a
>>succinct restatement of verifiable historic facts.
> 
> You talked about Simula and simulations so what?
> 
> Can you now realize not all object oriented programs are simulations?

I never made any such claim so I find your loaded question absurd. 
Nevertheless, OO 1) is a computational model, 2) was created in ad hoc 
fasion, 3) is a collection of features chosen primarily to facilitate 
the task of creating large unpredictable state machines (simulations) 
out of small predictable state machines or otherwise for expediency at 
the time in the late 1960's.


> And not all simulations need be implemented using OOP? Or is that
> stretching your abilities too far?

Again, I never made any such claim so I find your loaded question 
absurd. (Please note that loaded questions are fallacious on their face.)


> Can you also realize your definition allows for implementations using
> just about any kind of programming, like DOS batch jobs, all you need
> is a way to achieve unpredictability (no wait ...blue screen of
> death...) - again are you having trouble here?

I reiterate that you are too stupid to understand relatively simple 
english sentences. Somehow you hallucinate definitions where none exist.


>>   And if you guys
>>
>>>critique OOP shouldn't you at least first understand it  (in terms of a
>>>reasonable definition)?
>>
>>I do understand it. I have demonstrated 1) that I understand the
>>computational model, 2) that I understand the origin of the
>>computational model, 3) that I understand the weaknesses of the
>>computational model, and 4) that I understand that it is a computational
>>model in the first place, which is a lot more than you can legitimately
>>claim for yourself. I not only understand it--I can articulate my
>>understanding with precision and brevity.
> 
> That's just self-agrandizement.

Perhaps. However, that was not my motive, and it is nevertheless 
entirely accurate and true.


> Your definitions do not concur with any current or historic computer
> science.

Again, I note that you are too stupid to understand relatively simple 
english sentences. You hallucinate definitions where none exist.

[consequent irrelevancies snipped]


> "Large unpredictable state machines comprised of smaller ones" -
> fantastic.
> 
> No wonder you resort to insulting but when will you realize insults are
> a poor substitute for logic and honest science?

The insults are direct consequents of logic and of honest science thus 
they in no way substitute for them.

Plonk.
0
bbadour (434)
6/28/2006 1:49:17 PM
George wrote:

> Bob Badour wrote:
> 
>>George wrote:
>>
>>>Marshall wrote>
>>>
>>>>Love Bob or hate him, "OO is a computational model and not
>>>>a paradigm unless by 'paradigm' one means an example of
>>>>a computational model" is an awesome sentence.
>>>
>>>>>That's the
>>>>>worst definition of OOP I've ever seen "Large unpredictable state
>>>>>machines", yeah right.
>>>>
>>>>Okay, so is "yeah right" supposed to be an example of a
>>>>substantive refutation? Why don't you look of the definition
>>>>of "state machine" and tell me what aspect of is not met
>>>>by an object.
>>>
>>>The definition was:
>>>
>>>>>Bob Badour wrote:
>>>>>
>>>>>>OO is a computational model and not a paradigm unless by 'paradigm' one
>>>>>>means an example of a computational model. Idiot. Further, it is a
>>>>>>computational model comprising a collection of features useful for
>>>>>>constructing large unpredictable state machines from small predictable
>>>>>>state machines or otherwise picked arbitrarily in the mid to late 1960's
>>>>>>for what seemed expedient at the time.
>>>
>>>You can represent a state machine with VB version 1, a UNIX shell
>>>script, DOS batch job or rows and tables in a relational db - are these
>>>examples of OOP?
>>
>>Are you trying to make a point? I don't recall redefining OOP as "any
>>device or technology useful for constructing state machines." One can
>>construct state machines with nothing more than inverting amplifiers.
>>Computers, themselves, are nothing more or less than huge state machines.
> 
> I gave you the benefit of doubt and stuck to programming but nothing in
> your definition actually defines the type of programming.

I marvel at your stupidity and your ability to hallucinate definitions 
where none exist.



  You mainly
> talk about state machines, which of course can be implemented using
> "OOP" and many other ways.

The people who invented OO did so as I described. Do you have anything 
substantive to offer that refutes my observations of well-documented 
historic facts?


  Your definition is devoid of any useful
> differentiation yet you call the other guy an idiot, so what does that
> make you?

That makes me able to correctly discern meaning from meaningful english 
sentences. Very much unlike you.


>>I will respond to your argument above by analogy: That "a lever is a
>>simple machine useful for amplifying force" in no way diminishes or
>>contradicts the statement that "a ramp is a simple machine useful for
>>amplifying force."
> 
> Can we just stick to "large unpredictable state machines comprised of
> smaller predictable ones".

Sadly, you are too stupid to understand analogy as well. I conclude you 
are too stupid to understand the historic record even if you bothered to 
read it. Thus, you are a complete and utter waste of time.


>>>"Large" is a relative term what does it mean 3 or 3million? Sloppy but
>>>I won't pursue it.
>>
>>It has been argued that there are only three useful numbers in
>>computing: zero, one and some arbitrarily large power of two. Others
>>have stated essentially the same point as: zero, one and infinity.
>>
>>Whatever "large" is, it is larger than zero or one. Given that the
>>purpose of relative terms is to compare things and given that the
>>original statement compared the sizes of two state machines, I find your
>>inability to understand a relative term relating sizes quite remarkable.
> 
> What part of "I won't pursue it" is confusing you?

I am not confused. What part of the distinction between "I" and "you" 
confuses you?

Afterward, perhaps, you could explain how using a relative term for the 
exact purpose of a relative term is in any way "sloppy".


>>Do you have anything to offer resembling a substantive or relevant
>>rebuttal to my description of the inclusion criteria for features of the
>>OO computational model?
> 
> I have argued using reductio ad absurdum (proof by contradiction), I
> just started with your definition and applied allowed for and
> reasonable absurdities, from there the conclusions are obvious?

Sorry, but no. What you offered as a reply was absurd but that is not 
the same thing.


> Implementing "large unpredictable state machines" using DOS batch jobs
> may not be what you indended but nothing in your definition disallows
> it, can't you see that?

Whether DOS batch jobs can create state machines is irrelevant to my 
description of OO and in no way diminishes the accuracy, truth or import 
of what I wrote.


  And OO programs do not have to be
> unpredictable, can't you see that?

A penguin doesn't have to swim, but that is what it's best at.


> Man I cannot think for you.

I find that statement singularly unsurprising in that you have 
demonstrated no ability to think for yourself--or at all for that matter.


>>>"Unpredictable"? Every object I've instantiated behaves in a completely
>>>predictable fashion, specifically as defined by its class, there is no
>>>mystery, no unpredictability. Actually I'm not sure how you'd implement
>>>unpredictability, perhaps you can use reflection then you can invoke
>>>methods at random?
>>
>>Given your inability to parse my statement in any accurate or useful
>>manner, I have to conclude you are either totally ignorant of the
>>origins of the OO computational model or you lack the intellect to
>>comprehend written english or both. I am not sure exactly how the source
>>of your inability breaks down, though.
> 
> Or you could conclude your definition is stupid.

Having offered no definition, I find your suggestion absurd. Your 
hallucination of a definition causes me to conclude your inability 
relates more to stupidity (or perhaps psychosis?) than to ignorance.


>>OO was invented for simulation and was first expressed in a language
>>called Simula. Stroustrop later invented C++ as a variant of C for
>>exactly the same purpose: simulation. Stroustrop used the same inclusion
>>criteria when transforming the C computational model into OO and in fact
>>borrowed the features from Simula.
> 
> Yes but things have moved on and there are other big influences like
> Smalltalk and Minsky's frames and what has any of that to do with your
> definition?

By equating a description with a definition, you prove only your own 
stupidity. I have conversed with Minsky online--or at least with someone 
claiming to be Minsky. I thought him a lightweight whose reputation 
exceeds his contribution, and I note that his contribution has little or 
nothing to do with the computational model we are discussing.

The Smalltalk computational model is largely the same computational 
model as Simula's. When people speak of OO, they speak of the features 
shared among these models more than the differences among them.


>>The whole purpose of a simulation is to create a large unpredictable
>>state machine to discover what would happen in various conditions. If
>>the simulations were predictable, there would be no need for them in the
>>first place.
> 
> That may be valid for simulations but not all simulations need to be
> written using OOP.

Given the absolute absense of any such claim, I find your statement 
absurd. You clearly lack the intellect necessary to extract meaning from 
relatively simple english sentences.


  Furthermore not all OO programs are simulations, so
> the terms are not synonymous.

Having never stated the words are synonyms and having never used the 
words synonymously, I find your statement absurd. In any case, your 
observation in no way refutes that OO is a computational model or the 
historic facts of the computational model's construction.


  Equating the two is one of your gross
> errors.

Again, having never equated the two, I find your statement absurd.


>>That an individual object class defines a template for a relatively
>>simple predictable state machine agrees entirely with my description of
>>the inclusion criterion for features of the OO computational model. The
>>computational model is, after all, useful for piecing together large
>>unpredictable state machines from small predictable state machines.
> 
> You haven't used "class" or "template" until now and you haven't
> defined them so I don't know what you mean by them.

That's okay. You have proved yourself unable to extract meaning from 
reasonably simple english sentences regardless. Any reasonable 
definition of the terms encompassing the full scope of comp.object would 
suffice for anyone not quite so stupid as yourself.


>>Oh the irony, when people using the computational model to piece
>>together predictable state machines with the intent to create larger
>>predictable state machines discover the result is unpredictable after all.
> 
> Oh the even greater irony of sloppy operators calling other people
> idiots.

Given that you consider "sloppy" the use of a relative term for the 
exact purpose of a relative term, I am not sure exactly what point you 
are trying to make.


  I'm not even sure you can see how useless your definition is,
> that doesn't make you so bright does it?

Again, having never stated a definition, I find your hallucination of 
one quite remarkable. Given that Marshall Spight, someone who is clearly 
quite intelligent, found my description informative satisfies me that I 
stated something useful.


  And why are you still
> defending it?

A much better question is: Why are you still attacking it? (Quite 
ineffectually, I might add.) It was nothing more than a verifiable 
statement of fact.


>>>Yet in this great definition the original recipient is suppose to be
>>>the idiot? That's just truly amazing isn't it.
>>
>>I am not sure what part you find amazing. The part where I can identify
>>idiots by their apparent ignorance and profound inability to accurately
>>describe what they vociferously advocate? The part where I can identify
>>idiots by their habit of substituting meaningless buzzwords where one
>>would ordinarily expect to find intelligence and reason? The part where
>>I have a demonstrably better grasp of both OO and written english than
>>the OO proponents I encounter? The part where I am unafraid to give
>>voice to these observations?
> 
> The part where you fail to identify yourself as the chief idiot is the
> most amazing part.

I suppose everything amazes an idiot.


> You have wrongly equated OOP with "simulations" making the terms
> virtually synonymous, they are not.

Again, I find your hallucinations remarkable, and I note that they 
account for your stupidity. If you read an english sentence and 
hallucinate a meaning that simply is not there, you render yourself 
incapable of learning from english sentences.


  And you have wrongly equated "state
> machine" and "object" again the terms are not synonymous. If you fail
> to grasp this I can't help you.

Once again, having never equated them and having never used the terms 
synonymously, I find your statements absurd. However, object instances 
are, in fact, a subset of state machines.

Given your clear demonstration that you are too stupid to help yourself, 
your inability to help others is quite unremarkable.


> Until you demonstrate a mildly valid understanding of OOP your
> critiques of it are worthless. And your insults seem to best apply to
> yourself.

Given your readily apparent stupidity, I remain unaffected by your 
assessments of 1) my demonstrations, 2) my understanding, 3) my 
critiques and 4) the application of my insults. Plonk.
0
bbadour (434)
6/28/2006 2:41:50 PM
Robert Martin wrote:
> C++ is a fine language for many kinds of applications.

For systems that need tight O/S integration and high performance, it's
better than C. I'd say "many" is overstating it, and I think the number
is dwindling.

> I think it's
> getting a little long in the tooth nowadays; but it will be around for
> a long time to come.

Agreed, but so are COBOL and Fortran.

> Though I used to be a C++ programmer and
> evangelist, my interests lie elsewhere these days.  I now do most of my
> programming in Java, and am about to start investing heavily into Ruby.

Lisp has all the niceties Ruby does, and many more. I think Ruby shows
O-O aficionados just a glimpse of the power that other languages
already have (closures - sort of, DSLs, other hooks into the runtime /
metaobject system).

On the other side of the coin, I'm learning Ocaml and Haskell. I think
the attention on the dynamically-typed languages is due primarily to
the problems with the major statically-typed languages; that doesn't
mean there aren't better statically-typed languages with good type
inferencing, and I think many strides are still being made on the
strongly-typed front.

- Eric

0
eric.kaun (62)
6/28/2006 2:45:38 PM
On 2006-06-23 08:47:21 -0700, queisser <andrew.queisser@hp.com> said:

> 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 a tool to help decouple modules.  It's not a tool for large scale 
organization.  You can think of OO as the girders of a building, 
providing the small-scale structural material.  The building itself 
doesn't look like a girder.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 3:16:14 PM
On 2006-06-23 10:00:32 -0700, "Aloha Kakuikanu" 
<aloha.kakuikanu@yahoo.com> said:

> 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?

That depends upon the application.  In some applications there might be 
business rules deeply associated with the customer.  In others, a 
customer is nothing but a data carrier that has no rules associated 
with it.


-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 3:17:24 PM
On 2006-06-23 11:10:25 -0700, "Aloha Kakuikanu" 
<aloha.kakuikanu@yahoo.com> said:

> 
> 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.

Again, this depends.  If there are several different types of customer  
(e.g. GovernmentContractor, privateContractor, foreignContractor) you 
might find that each of these different types must follow a different 
procedure in order to cancel an order.
-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 3:19:01 PM
On 2006-06-23 12:44:49 -0700, "erk" <eric.kaun@gmail.com> said:

> Emulating reality is
> another phantasm conjured by
> O-O.

Or rather, Emulating reality is another phantasm conjured by a few 
people who wanted to sell OO.

Frankly I think it was an innocent statement that got out of control.  
I suppose that it's possible to get to "emulate reality" from Dah's 
original statement about accepting the extra complexity because it 
makes so many concepts easier to express; but it's a stretch.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 3:22:01 PM
On 2006-06-23 08:53:00 -0700, "topmind" <topmind@technologist.com> said:

> 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.

No, that's just silly.  Hierarchies might appeal to non-technical 
people who don't know much about software.  Decoupling appeals to very 
technical people who understand the cost of errant dependencies.

-- 
Robert C. Martin (Uncle Bob)��| email: unclebob@objectmentor.com
Object Mentor Inc.� � � � � ��| blog:��www.butunclebob.com
The Agile Transition Experts��| web:���www.objectmentor.com
800-338-6716� � � � � � � � ��|



0
unclebob2 (2724)
6/28/2006 3:23:07 PM
On 2006-06-23 08:53:00 -0700, "topmind" <topmind@technologist.com> said:

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

OO is not just a bunch of nodes with pointers.  You can do that in raw 
C without OO.  OO *adds* dynamic polymorhism to the mix, which means 
that the runtime graph, can be very different from the source code 
graph.  OO allows dependencies within the graph to be inverted from the 
source code viewpoint.  This means that from the source code view you 
don't have a graph at all; rather you have a suite of many tiny 
graphlets all se