f



Object-relational impedence

On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> All attempts by applications to access a DB's tables and columns
> directly violates design principles that guard against close-coupling.
> This is a basic design tenet for OO.  Violating it when jumping from OO
> to RDB is, I think, the source of problem that are collectively and
> popularly referred to as the object-relational impedance mismatch.

I wondered if we might be able to come up with some agreement on what
object-relational impedence mismatch actually means. I always thought
the mismatch was centred on the issue that a single object != single
tuple, but it appears there may be more to it than that.

I was hoping perhaps people might be able to offer perspectives on the
issues that they have encountered.  One thing I would like to avoid
(outside of almost flames of course), is the notion that database
technology is merely a persistence layer (do people still actually
think that?) - I wonder if the 'mismatch' stems from such a
perspective.
0
jog (83)
3/3/2008 4:52:10 PM
comp.object 3218 articles. 1 followers. Post Follow

432 Replies
1566 Views

Similar Articles

[PageSpeed] 49

JOG wrote:
> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means. I always thought
> the mismatch was centred on the issue that a single object != single
> tuple, but it appears there may be more to it than that.
>   
The issue as I've discovered it has to do with the fact OO systems are
composed of graphs of data and RDBs are two-dimensional.

What defines an account in an RDB may be composed of multiple tables. 
An RDB might express multiple account types through multiple tables
where OO may reflect it as multiple classes.  Attempts to make RDBs
function as graphs through mapping tools results in disappointing
performance and, in my experience, too much mapping, too much
infrastructure, and too much language/paradigm-specific layers.  In
short, way more code, way more maintenance, and way more job-security
for consultants, pundits, and tool providers.


-- 
Visit <http://blogs.instreamco.com/anything.php> to read 
my rants on technology and the finance industry.  Visit
<http://tggagne.blogspot.com/> for politics, society and culture.
0
tgagne (596)
3/3/2008 5:07:35 PM
"Thomas Gagne" <tgagne@wide-open-west.com> wrote in message 
news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d@wideopenwest.com...
> JOG wrote:
>> I wondered if we might be able to come up with some agreement on what
>> object-relational impedence mismatch actually means. I always thought
>> the mismatch was centred on the issue that a single object != single
>> tuple, but it appears there may be more to it than that.
>>
> The issue as I've discovered it has to do with the fact OO systems are
> composed of graphs of data and RDBs are two-dimensional.

RDBs are not two-dimensional, they are n-dimensional.  You are confusing the 
picture of the thing with the thing.  I have a three dimensional kitchen 
table.  I have an RDB table with three columns (dimensions) called length, 
width and height that describes it.

> What defines an account in an RDB may be composed of multiple tables.
> An RDB might express multiple account types through multiple tables
> where OO may reflect it as multiple classes.  Attempts to make RDBs
> function as graphs through mapping tools results in disappointing
> performance and, in my experience, too much mapping, too much
> infrastructure, and too much language/paradigm-specific layers.  In
> short, way more code, way more maintenance, and way more job-security
> for consultants, pundits, and tool providers.

I completely, 100% agree with that.  Code is evil.

Roy 


0
specially (35)
3/3/2008 5:24:20 PM
"JOG" <jog@cs.nott.ac.uk> wrote in message 
news:0cd61579-0f26-422c-9aec-908ffdea59ff@i7g2000prf.googlegroups.com...
> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> One thing I would like to avoid
> (outside of almost flames of course), is the notion that database
> technology is merely a persistence layer (do people still actually
> think that?)

Are you kidding?!!  You will grow old and die before you find someone not on 
c.d.t. who DOESN'T think that.  In the real world you will be thought some 
kind of simpleton/troll/nutcase if you suggest it isn't just a persistence 
layer.

Roy 


0
specially (35)
3/3/2008 5:27:46 PM
"Roy Hann" <specially@processed.almost.meat> wrote in message
news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...
> "Thomas Gagne" <tgagne@wide-open-west.com> wrote in message
> news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d@wideopenwest.com...
> > JOG wrote:
> >> I wondered if we might be able to come up with some agreement on what
> >> object-relational impedence mismatch actually means. I always thought
> >> the mismatch was centred on the issue that a single object != single
> >> tuple, but it appears there may be more to it than that.
> >>
> > The issue as I've discovered it has to do with the fact OO systems are
> > composed of graphs of data and RDBs are two-dimensional.
>
> RDBs are not two-dimensional, they are n-dimensional.  You are confusing
the
> picture of the thing with the thing.  I have a three dimensional kitchen
> table.  I have an RDB table with three columns (dimensions) called length,
> width and height that describes it.

Stop!  You're both right!

There is a certain level of abstraction where and RDB is definitely
n-dimensional.  This is the level of abstraction where I spend most of my
time thinking.  So I tend to agree with you, Roy.

There is, however, a different level of abstraction where an RDB is
two-dimensional.  So Tom is not "wrong" all the way.  And it may be at that
level of abstraction where the OO RM impedance match comes about.

> I completely, 100% agree with that.  Code is evil.
>
It appears,  from reading c.o., that OO people regard data structures as
evil.

It sounds like Stalinists versus Trotskyites to me!





0
cressey73 (124)
3/3/2008 5:36:50 PM
JOG wrote:
> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> 
>>All attempts by applications to access a DB's tables and columns
>>directly violates design principles that guard against close-coupling.
>>This is a basic design tenet for OO.  Violating it when jumping from OO
>>to RDB is, I think, the source of problem that are collectively and
>>popularly referred to as the object-relational impedance mismatch.
> 
> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means. I always thought
> the mismatch was centred on the issue that a single object != single
> tuple, but it appears there may be more to it than that.
> 
> I was hoping perhaps people might be able to offer perspectives on the
> issues that they have encountered.  One thing I would like to avoid
> (outside of almost flames of course), is the notion that database
> technology is merely a persistence layer (do people still actually
> think that?) - I wonder if the 'mismatch' stems from such a
> perspective.

It's pretty obvious to me: object-relational mismatch is to relations as 
assembler-object mismatch is to objects.
0
bbadour (434)
3/3/2008 5:41:15 PM
JOG wrote:

> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:

>>All attempts by applications to access a DB's tables and columns
>>directly violates design principles that guard against close-coupling.
>>This is a basic design tenet for OO.  Violating it when jumping from OO
>>to RDB is, I think, the source of problem that are collectively and
>>popularly referred to as the object-relational impedance mismatch.

> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means.I always thought
> the mismatch was centred on the issue that a single object != single
> tuple, but it appears there may be more to it than that.

Apart from issues such as "joins" etc, there actually isn't a mismatch
between OO and Relational at the fundamental level IMHO.


> I was hoping perhaps people might be able to offer perspectives on the
> issues that they have encountered.

Given some entity E = (p1,p2, ... pn) , where p1 etc are the properties of
E, OO allows the following :

1. the properties of E could be realised as data values or a computational
    process

2. in any system, there may be multiple existing implementations for E
    (each instance of E created using any one of those implementations)


An RDB that requires all properties are data values will not satisfy 1.
An RDB that allows 1, but forces one universal implementation for E will
not satisfy 2.


For OO, the big problem is the prog langs themselves.
Syntax, semantics, implementation.

Assuming there is an RDB that can do 1 and 2 above, how can a specific
OO prog lang 'align' its representation of objects to the 'tuple' form that
will allow an underlying Relational engine to work its wonders (execution,
optimisation etc) ??


Regards,
Steven Perryman
0
S
3/3/2008 5:58:47 PM
"David Cressey" <cressey73@verizon.net> wrote in message 
news:SGWyj.2671$4D2.1906@trndny06...

> There is, however, a different level of abstraction where an RDB is
> two-dimensional.

There is?  Are you thinking of report writers and GUI painters?

> So Tom is not "wrong" all the way.  And it may be at that
> level of abstraction where the OO RM impedance match comes about.

>> I completely, 100% agree with that.  Code is evil.
>>
> It appears,  from reading c.o., that OO people regard data structures as
> evil.
>
> It sounds like Stalinists versus Trotskyites to me!

Until I know their reasons for their views on data structures I couldn't 
say.  However I notice that I am surrounded by programmers who consume most 
the development budget writing code, and when a change request comes along I 
can accommodate it in the database in minutes and they spend months spewing 
out more code (sometimes after doing an extensive and expensive impact 
assessment).  Code may not be evil, but it sure has a case to answer.

Roy 


0
specially (35)
3/3/2008 6:08:39 PM
Roy Hann wrote:
>
>
> Until I know their reasons for their views on data structures I couldn't 
> say.  However I notice that I am surrounded by programmers who consume most 
> the development budget writing code, and when a change request comes along I 
> can accommodate it in the database in minutes and they spend months spewing 
> out more code (sometimes after doing an extensive and expensive impact 
> assessment).  Code may not be evil, but it sure has a case to answer.
>   
Roy, that's a great example of why I advocate for a separation
(loosely-coupled) between applications and databases.

-- 
Visit <http://blogs.instreamco.com/anything.php> to read 
my rants on technology and the finance industry.  Visit
<http://tggagne.blogspot.com/> for politics, society and culture.
0
tgagne (596)
3/3/2008 6:15:24 PM
On Mar 3, 10:41=A0am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> JOG wrote:
> > On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
> >>All attempts by applications to access a DB's tables and columns
> >>directly violates design principles that guard against close-coupling.
> >>This is a basic design tenet for OO. =A0Violating it when jumping from O=
O
> >>to RDB is, I think, the source of problem that are collectively and
> >>popularly referred to as the object-relational impedance mismatch.
>
> > I wondered if we might be able to come up with some agreement on what
> > object-relational impedence mismatch actually means. I always thought
> > the mismatch was centred on the issue that a single object !=3D single
> > tuple, but it appears there may be more to it than that.
>
> > I was hoping perhaps people might be able to offer perspectives on the
> > issues that they have encountered. =A0One thing I would like to avoid
> > (outside of almost flames of course), is the notion that database
> > technology is merely a persistence layer (do people still actually
> > think that?) - I wonder if the 'mismatch' stems from such a
> > perspective.
>
> It's pretty obvious to me: object-relational mismatch is to relations as
> assembler-object mismatch is to objects.- Hide quoted text -
>
> - Show quoted text -

Very well put. I'm filing this away in my brain for future reference.
0
cs_troyk (11)
3/3/2008 6:26:33 PM
On Mar 3, 11:08=A0am, "Roy Hann" <specia...@processed.almost.meat>
wrote:
> "David Cressey" <cresse...@verizon.net> wrote in message
>
> news:SGWyj.2671$4D2.1906@trndny06...
>
> > There is, however, a different level of abstraction where an RDB is
> > two-dimensional.
>
> There is? =A0Are you thinking of report writers and GUI painters?
>
> > So Tom is not "wrong" all the way. =A0And it may be at that
> > level of abstraction where the OO RM impedance match comes about.
> >> I completely, 100% agree with that. =A0Code is evil.
>
> > It appears, =A0from reading c.o., that OO people regard data structures =
as
> > evil.
>
> > It sounds like Stalinists versus Trotskyites to me!
>
> Until I know their reasons for their views on data structures I couldn't
> say. =A0However I notice that I am surrounded by programmers who consume m=
ost
> the development budget writing code, and when a change request comes along=
 I
> can accommodate it in the database in minutes and they spend months spewin=
g
> out more code (sometimes after doing an extensive and expensive impact
> assessment). =A0Code may not be evil, but it sure has a case to answer.
>
> Roy

My experience is somewhere between 2 and 3 orders of magnitude
difference between implementing a business rules change in the db vs.
the programming team doing it in OO code.
0
cs_troyk (11)
3/3/2008 6:29:02 PM

JOG wrote:
> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> > All attempts by applications to access a DB's tables and columns
> > directly violates design principles that guard against close-coupling.
> > This is a basic design tenet for OO.  Violating it when jumping from OO
> > to RDB is, I think, the source of problem that are collectively and
> > popularly referred to as the object-relational impedance mismatch.
>
> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means. I always thought
> the mismatch was centred on the issue that a single object != single
> tuple, but it appears there may be more to it than that.
>
> I was hoping perhaps people might be able to offer perspectives on the
> issues that they have encountered.  One thing I would like to avoid
> (outside of almost flames of course), is the notion that database
> technology is merely a persistence layer (do people still actually
> think that?) - I wonder if the 'mismatch' stems from such a
> perspective.

This came up in a nearby message. I borrowed the following text from
wikipedia:

Key philosophical differences between the OO and relational models can
be summarized as follows:

Declarative vs. imperative interfaces -- Relational thinking tends to
use data as interfaces, not behavior as interfaces. It thus has a
declarative tilt in design philosophy in contrast to OO's behavioral
tilt. (Some relational proponents propose using triggers, etc. to
provide complex behavior, but this is not a common viewpoint.)

Schema bound -- Objects do not have to follow a "parent schema" for
which attributes or accessors an object has, while table rows must
follow the entity's schema. A given row must belong to one and only
one entity. The closest thing in OO is inheritance, but it is
generally tree-shaped and optional. A dynamic reformulation of
relational theory may solve this, but it is not practical yet.

Access rules -- In relational databases, attributes are accessed and
altered through predefined relational operators, while OO allows each
class to create its own state alteration interface and practices. The
"self-handling noun" viewpoint of OO gives independence to each object
that the relational model does not permit. This is a "standards versus
local freedom" debate. OO tends to argue that relational standards
limit expressiveness, while relational proponents suggest the rule
adherence allows more abstract math-like reasoning, integrity, and
design consistency.

Relationship between nouns and actions -- OO encourages a tight
association between operations (actions) and the nouns (entities) that
the operations operate on. The resulting tightly-bound entity
containing both nouns and the operations is usually called a class, or
in OO analysis, a concept. Relational designs generally do not assume
there is anything natural or logical about such tight associations
(outside of relational operators).

Uniqueness observation -- Row identities (keys) generally have a text-
representable form, but objects do not require an externally-viewable
unique identifier.

Object identity -- Objects (other than immutable ones) are generally
considered to have a unique identity; two objects which happen to have
the same state at a given point in time are not considered to be
identical. Relations, on the other hand has no inherent concept of
this kind of identity. That said, it is a common practice to fabricate
"identity" for records in a database through use of globally-unique
candidate keys; though many consider this a poor practice for any
database record which does not have a one-to-one correspondence with a
real world entity. (Relational, like objects, can use domain keys if
they exist in the external world for identification purposes).
Relational systems strive for "permanent" and inspect-able
identification techniques, where-as object identification techniques
tend to be transient or situational.

Normalization -- Relational normalization practices are often ignored
by OO designs. However, this may just be a bad habit instead of a
native feature of OO. An alternate view is that a collection of
objects, interlinked via pointers of some sort, is equivalent to a
network database; which in turn can be viewed as an extremely-
denormalized relational database.

Schema inheritance -- Most relational databases do not support schema
inheritance. Although such a feature could be added in theory to
reduce the conflict with OOP, relational proponents are less likely to
believe in the utility of hierarchical taxonomies and sub-typing
because they tend to view set-based taxonomies or classification
systems as more powerful and flexible than trees. OO advocates point
out that inheritance/subtyping models need not be limited to trees
(though this is a limitation in many popular OO languages such as
Java), but non-tree OO solutions are seen as more difficult to
formulate than set-based variation-on-a-theme management techniques
preferred by relational. At the least, they differ from techniques
commonly used in relational algebra.

Structure vs. behaviour -- OO primarily focuses on ensuring that the
structure of the program is reasonable (maintainable, understandable,
extensible, reusable, safe), whereas relational systems focus on what
kind of behaviour the resulting run-time system has (efficiency,
adaptability, fault-tolerance, liveness, logical integrity, etc.).
Object-oriented methods generally assume that the primary user of the
object-oriented code and its interfaces are the application
developers. In relational systems, the end-users' view of the
behaviour of the system is sometimes considered to be more important.
However, relational queries and "views" are common techniques to re-
represent information in application- or task-specific configurations.
Further, relational does not prohibit local or application-specific
structures or tables from being created, although many common
development tools do not directly provide such a feature, assuming
objects will be used instead. This makes it difficult to know whether
the stated non-developer perspective of relational is inherent to
relational, or merely a product of current practice and tool
implementation assumptions.

As a result of the object-relational impedance mismatch, it is often
argued by partisans on both sides of the debate that the other
technology ought to be abandoned or reduced in scope. Some database
advocates view traditional "procedural" languages as more compatible
with a RDBMS than many OO languages; and/or suggest that a less OO-
style ought to be used. (In particular, it is argued that long-lived
domain objects in application code ought not to exist; any such
objects that do exist should be created when a query is made and
disposed of when a transaction or task is complete). On the other
hand, many OO advocates argue that more OO-friendly persistence
mechanisms, such as OODBMS, ought to be developed and used, and that
relational technology ought to be phased out. Of course, it should be
pointed out that many (if not most) programmers and DBAs do not hold
either of these viewpoints; and view the object-relational impedance
mismatch as a mere fact of life that Information Technology has to
deal with.

(end quote)

-T-
0
topmind (2124)
3/3/2008 6:31:12 PM
David Cressey wrote:
> "Roy Hann" <specially@processed.almost.meat> wrote in message
> news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...
> 
>>"Thomas Gagne" <tgagne@wide-open-west.com> wrote in message
>>news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d@wideopenwest.com...
>>
>>>JOG wrote:
>>>
>>>>I wondered if we might be able to come up with some agreement on what
>>>>object-relational impedence mismatch actually means. I always thought
>>>>the mismatch was centred on the issue that a single object != single
>>>>tuple, but it appears there may be more to it than that.
>>>>
>>>
>>>The issue as I've discovered it has to do with the fact OO systems are
>>>composed of graphs of data and RDBs are two-dimensional.
>>
>>RDBs are not two-dimensional, they are n-dimensional.  You are confusing
> 
> the
> 
>>picture of the thing with the thing.  I have a three dimensional kitchen
>>table.  I have an RDB table with three columns (dimensions) called length,
>>width and height that describes it.
> 
> Stop!  You're both right!
> 
> There is a certain level of abstraction where and RDB is definitely
> n-dimensional.  This is the level of abstraction where I spend most of my
> time thinking.  So I tend to agree with you, Roy.
> 
> There is, however, a different level of abstraction where an RDB is
> two-dimensional.  So Tom is not "wrong" all the way.  And it may be at that
> level of abstraction where the OO RM impedance match comes about.

David, the flaw in your logic is: At the level of abstraction where an 
RDB is two-dimensional, OO is uni-dimensional.


>>I completely, 100% agree with that.  Code is evil.
> 
> It appears,  from reading c.o., that OO people regard data structures as
> evil.
> 
> It sounds like Stalinists versus Trotskyites to me!
0
bbadour (434)
3/3/2008 6:45:54 PM
On Mar 3, 9:27 am, "Roy Hann" <specia...@processed.almost.meat> wrote:
> "JOG" <j...@cs.nott.ac.uk> wrote in message
>
> news:0cd61579-0f26-422c-9aec-908ffdea59ff@i7g2000prf.googlegroups.com...
>
> > On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> > One thing I would like to avoid
> > (outside of almost flames of course), is the notion that database
> > technology is merely a persistence layer (do people still actually
> > think that?)
>
> Are you kidding?!!  You will grow old and die before you find someone not on
> c.d.t. who DOESN'T think that.  In the real world you will be thought some
> kind of simpleton/troll/nutcase if you suggest it isn't just a persistence
> layer.
>
> Roy

As the girls say, "It depends on how you use it".

It depends on how you use the DB. In Robert Martin's version of the
payroll application, the DB is almost reduced to a dumb filing system
("persistence layer") because the app code does all the work. However,
in my version:

http://www.geocities.com/tablizer/payroll2.htm

I *leveraged* the DB so that much if not most of the work is done by
the database and queries *instead* of the app code.  There's more
attribute setup work, but noticeably less app code than Martin's. One
"programs" largely by putting attributes in tables instead of writing
app code.

One can choose to use the features available from RDBMS, or they can
choose to manually program it in app code. Your perspective on what
DB's are "for" largely depends on which route you take.

-T-
0
topmind (2124)
3/3/2008 6:46:09 PM
On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:

> "Roy Hann" <specially@processed.almost.meat> wrote in message
> news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...

>> I completely, 100% agree with that.  Code is evil.
>
> It appears,  from reading c.o., that OO people regard data structures as
> evil.

Right, the structure of data would be too low-level to be able to capture
behavior. As in mathematics, in OO the internal structure of objects is
irrelevant and when considered, then only as an implementation detail to be
abstracted away. OO deals with the structures of sets of objects exposing
same behavior and relations between such sets.

> It sounds like Stalinists versus Trotskyites to me!

Huh, both regarded themselves as true Leninists. No, by this analogy c.d.t.
wanted to impose Leninism on us, others who consider Leninism just a silly
amateur philosophy, though very wicked when tried in practice. You know the
examples, the Gulag, SQL... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/3/2008 6:47:59 PM
topmind wrote:

> JOG wrote:
> 
>>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>>
>>>All attempts by applications to access a DB's tables and columns
>>>directly violates design principles that guard against close-coupling.
>>>This is a basic design tenet for OO.  Violating it when jumping from OO
>>>to RDB is, I think, the source of problem that are collectively and
>>>popularly referred to as the object-relational impedance mismatch.
>>
>>I wondered if we might be able to come up with some agreement on what
>>object-relational impedence mismatch actually means. I always thought
>>the mismatch was centred on the issue that a single object != single
>>tuple, but it appears there may be more to it than that.
>>
>>I was hoping perhaps people might be able to offer perspectives on the
>>issues that they have encountered.  One thing I would like to avoid
>>(outside of almost flames of course), is the notion that database
>>technology is merely a persistence layer (do people still actually
>>think that?) - I wonder if the 'mismatch' stems from such a
>>perspective.
> 
> This came up in a nearby message. I borrowed the following text from
> wikipedia:

The text had too many blatant errors to start enumerating them all. The 
problem with wikipedia is any ignorant fool can just start typing 
nonsense. Even when one follows the requirements for references to 
primary sources, the quality of the end product can vary over many 
orders of magnitude.
0
bbadour (434)
3/3/2008 6:54:00 PM
On Mar 3, 6:47 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
> > "Roy Hann" <specia...@processed.almost.meat> wrote in message
> >news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...
> >> I completely, 100% agree with that.  Code is evil.
>
> > It appears,  from reading c.o., that OO people regard data structures as
> > evil.
>
> Right, the structure of data would be too low-level to be able to capture
> behavior. As in mathematics, in OO the internal structure of objects is
> irrelevant and when considered, then only as an implementation detail to be
> abstracted away. OO deals with the structures of sets of objects exposing
> same behavior and relations between such sets.
>
> > It sounds like Stalinists versus Trotskyites to me!
>
> Huh, both regarded themselves as true Leninists. No, by this analogy c.d.t.
> wanted to impose Leninism on us, others who consider Leninism just a silly
> amateur philosophy, though very wicked when tried in practice. You know the
> examples, the Gulag, SQL... (:-))

If you'd please, I was hoping for reasonable discussion, not
flamebait.

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

0
jog (83)
3/3/2008 7:16:34 PM
On Mar 3, 6:54 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> topmind wrote:
> > JOG wrote:
>
> >>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
> >>>All attempts by applications to access a DB's tables and columns
> >>>directly violates design principles that guard against close-coupling.
> >>>This is a basic design tenet for OO.  Violating it when jumping from OO
> >>>to RDB is, I think, the source of problem that are collectively and
> >>>popularly referred to as the object-relational impedance mismatch.
>
> >>I wondered if we might be able to come up with some agreement on what
> >>object-relational impedence mismatch actually means. I always thought
> >>the mismatch was centred on the issue that a single object != single
> >>tuple, but it appears there may be more to it than that.
>
> >>I was hoping perhaps people might be able to offer perspectives on the
> >>issues that they have encountered.  One thing I would like to avoid
> >>(outside of almost flames of course), is the notion that database
> >>technology is merely a persistence layer (do people still actually
> >>think that?) - I wonder if the 'mismatch' stems from such a
> >>perspective.
>
> > This came up in a nearby message. I borrowed the following text from
> > wikipedia:
>
> The text had too many blatant errors to start enumerating them all. The
> problem with wikipedia is any ignorant fool can just start typing
> nonsense. Even when one follows the requirements for references to
> primary sources, the quality of the end product can vary over many
> orders of magnitude.

And yet wikipedia entries are often remarkably half-decent. However
not in this case - the entry is a convloluted mess, and actually
instigated my question.(I often wonder if it would not be better if
opposing views on wikipedia could be treated as separate articles
rather than the standard mish mash).
0
jog (83)
3/3/2008 7:21:37 PM
On Mon, 03 Mar 2008 12:07:35 -0500, Thomas Gagne wrote:

> JOG wrote:
>> I wondered if we might be able to come up with some agreement on what
>> object-relational impedence mismatch actually means. I always thought
>> the mismatch was centred on the issue that a single object != single
>> tuple, but it appears there may be more to it than that.
>>   
> The issue as I've discovered it has to do with the fact OO systems are
> composed of graphs of data and RDBs are two-dimensional.

> What defines an account in an RDB may be composed of multiple tables. 
> An RDB might express multiple account types through multiple tables
> where OO may reflect it as multiple classes.  Attempts to make RDBs
> function as graphs through mapping tools results in disappointing
> performance and, in my experience, too much mapping, too much
> infrastructure, and too much language/paradigm-specific layers.  In
> short, way more code, way more maintenance, and way more job-security
> for consultants, pundits, and tool providers.

Certainly RDBs are n-dimensional.

The difference is not there. If you wanted to consider the space [of
objects], then the difference would be in its the structure and the
distance defined there.

RA assumes existence of such space and tries to *abstract* any distance
away. Clearly any implementation would introduce a distance and that will
have a huge impact on the performance of the DB. This includes also the
mental pictures of the DB "performing" in the heads of people programming
it. Negative/positive impacts do not necessarily correlate, which does not
make things any better.

OO clusters the space into isolated multidimensional planes and *publishes*
the distances and orders there. This allows a far better modeling of the
problems which space differ from one described by RA. This also includes
larger problems which can be described by RA but cannot be modeled by it
due to hardware limitations (finiteness etc).

Disclaimer: "a real FORTRAN program" can be written in any language under
any paradigm etc.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/3/2008 7:26:51 PM

Dmitry A. Kazakov wrote:
> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
>
> > "Roy Hann" <specially@processed.almost.meat> wrote in message
> > news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...
>
> >> I completely, 100% agree with that.  Code is evil.
> >
> > It appears,  from reading c.o., that OO people regard data structures as
> > evil.
>
> Right, the structure of data would be too low-level to be able to capture
> behavior. As in mathematics, in OO the internal structure of objects is
> irrelevant and when considered, then only as an implementation detail to be
> abstracted away. OO deals with the structures of sets of objects exposing
> same behavior and relations between such sets.

This is misleading. An association between object A and object B does
NOT go away just because it is managed via accessors. OOP not only
doesn't get one away from dealing with things as "structures", but
uses structures that were discredited in late 60's.

Hiding behind accessors is merely a shell game. setMess and getMess is
*still* a mess.

> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

-T-
0
topmind (2124)
3/3/2008 7:44:07 PM
Responding to the subject line:

It's an "impedance mismatch".

And it's not. OO and declarative, relational, etc. are just "orthogonal". That's 
a Good Thing.
0
phlip2005 (2215)
3/3/2008 8:22:23 PM
On Mon, 3 Mar 2008 11:44:07 -0800 (PST), topmind wrote:

> Dmitry A. Kazakov wrote:
>> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
>>
>>> "Roy Hann" <specially@processed.almost.meat> wrote in message
>>> news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...
>>
>>>> I completely, 100% agree with that.  Code is evil.
>>>
>>> It appears,  from reading c.o., that OO people regard data structures as
>>> evil.
>>
>> Right, the structure of data would be too low-level to be able to capture
>> behavior. As in mathematics, in OO the internal structure of objects is
>> irrelevant and when considered, then only as an implementation detail to be
>> abstracted away. OO deals with the structures of sets of objects exposing
>> same behavior and relations between such sets.
> 
> This is misleading. An association between object A and object B does
> NOT go away just because it is managed via accessors.

Associations are not managed via links. There are no strings tying the
numbers 1 (object A) and 2 (object B).

But I guess you probably meant a data structure called "linked list".
Please note: _data structure_. Watch out, you fall into heresy, dear
topmind!

> OOP not only
> doesn't get one away from dealing with things as "structures", but
> uses structures that were discredited in late 60's.

How can anybody discredit a data structure? Recently I was taught by our
c.d.t. colleges that data are recorded facts. You didn't object them. So,
may I humble ask you, who and how could discredit facts? (outside Usenet
discussion forums, I mean... (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/3/2008 9:11:19 PM
On 2008-03-03 10:52:10 -0600, JOG <jog@cs.nott.ac.uk> said:

> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>> All attempts by applications to access a DB's tables and columns
>> directly violates design principles that guard against close-coupling.
>> This is a basic design tenet for OO.  Violating it when jumping from OO
>> to RDB is, I think, the source of problem that are collectively and
>> popularly referred to as the object-relational impedance mismatch.
> 
> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means. I always thought
> the mismatch was centred on the issue that a single object != single
> tuple, but it appears there may be more to it than that.

There is indeed more to it than that.  OO and RDB are both strategies 
for partitioning data.  However, the motivation behind the partitioning 
is completely different.  OO partitions data based on the way a 
particular application will process that data.  RDBs partition data 
based on how many different applications will need to access that data.

This really isn't an impedance mismatch.  It's a mismatch of intent.  
When designers use each strategy for what it's good at, there is no 
mismatch at all.

> One thing I would like to avoid
> (outside of almost flames of course), is the notion that database
> technology is merely a persistence layer (do people still actually
> think that?) - I wonder if the 'mismatch' stems from such a
> perspective.

Take out the word "merely", and recognize that "persistence" is more 
than just storage.

-- 
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)
3/3/2008 9:50:17 PM
On Mar 3, 1:11 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Mon, 3 Mar 2008 11:44:07 -0800 (PST), topmind wrote:
> > Dmitry A. Kazakov wrote:
> >> On Mon, 03 Mar 2008 17:36:50 GMT, David Cressey wrote:
>
> >>> "Roy Hann" <specia...@processed.almost.meat> wrote in message
> >>>news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...
>
> >>>> I completely, 100% agree with that.  Code is evil.
>
> >>> It appears,  from reading c.o., that OO people regard data structures as
> >>> evil.
>
> >> Right, the structure of data would be too low-level to be able to capture
> >> behavior. As in mathematics, in OO the internal structure of objects is
> >> irrelevant and when considered, then only as an implementation detail to be
> >> abstracted away. OO deals with the structures of sets of objects exposing
> >> same behavior and relations between such sets.
>
> > This is misleading. An association between object A and object B does
> > NOT go away just because it is managed via accessors.
>
> Associations are not managed via links. There are no strings tying the
> numbers 1 (object A) and 2 (object B).
>
> But I guess you probably meant a data structure called "linked list".
> Please note: _data structure_. Watch out, you fall into heresy, dear
> topmind!

I did not say that *all* objects have associations between them. In
practice, there are a lot of associations between objects. In memory
these become a graph of object pointers.  Even in UML, relationship
diagrams are common. If all that could be magically encapsulated under
the carpet so that nobody had to worry about them, then why have
relationship diagrams? If one doesn't focus on such, then duplication
(among other problems) slips in.

>
> > OOP not only
> > doesn't get one away from dealing with things as "structures", but
> > uses structures that were discredited in late 60's.
>
> How can anybody discredit a data structure? Recently I was taught by our
> c.d.t. colleges that data are recorded facts. You didn't object them. So,
> may I humble ask you, who and how could discredit facts? (outside Usenet
> discussion forums, I mean... (:-))

Navigational structures are unwieldy on a larger scale for most
mortals. Dr. Codd introduced relational to reign in the chaos of the
pasta machines that were growing around that time. OOP didn't fix the
problems with navigational structures. Putting accessors around them
was not a fix. A developer/designer must still know and manage
relationships between objects.

>
> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

-T-
0
topmind (2124)
3/3/2008 9:51:41 PM
On 2008-03-03 11:24:20 -0600, "Roy Hann" 
<specially@processed.almost.meat> said:

> Code is evil.

SQL is code.

-- 
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)
3/3/2008 9:53:15 PM
On 2008-03-03 11:36:50 -0600, "David Cressey" <cressey73@verizon.net> said:

> There is, however, a different level of abstraction where an RDB is
> two-dimensional.  So Tom is not "wrong" all the way.  And it may be at that
> level of abstraction where the OO RM impedance match comes about.

I don't know.  Computer memory is one-dimensional.
-- 
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)
3/3/2008 9:54:16 PM
On 2008-03-03 12:08:39 -0600, "Roy Hann" 
<specially@processed.almost.meat> said:

> However I notice that I am surrounded by programmers who consume most
> the development budget writing code, and when a change request comes along I
> can accommodate it in the database in minutes and they spend months spewing
> out more code (sometimes after doing an extensive and expensive impact
> assessment).  Code may not be evil, but it sure has a case to answer.

Silly developers and DBAs always have a case to answer.  Their tools 
are innocent.

BTW, "minutes"?  "weeks"?  Why didn't you make the change in "minutes" 
and demonstrate it while everybody else was still working on the impact 
analysis?


-- 
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)
3/3/2008 9:57:36 PM
On Mar 3, 10:54 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> topmind wrote:
> > JOG wrote:
>
> >>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
> >>>All attempts by applications to access a DB's tables and columns
> >>>directly violates design principles that guard against close-coupling.
> >>>This is a basic design tenet for OO.  Violating it when jumping from OO
> >>>to RDB is, I think, the source of problem that are collectively and
> >>>popularly referred to as the object-relational impedance mismatch.
>
> >>I wondered if we might be able to come up with some agreement on what
> >>object-relational impedence mismatch actually means. I always thought
> >>the mismatch was centred on the issue that a single object != single
> >>tuple, but it appears there may be more to it than that.
>
> >>I was hoping perhaps people might be able to offer perspectives on the
> >>issues that they have encountered.  One thing I would like to avoid
> >>(outside of almost flames of course), is the notion that database
> >>technology is merely a persistence layer (do people still actually
> >>think that?) - I wonder if the 'mismatch' stems from such a
> >>perspective.
>
> > This came up in a nearby message. I borrowed the following text from
> > wikipedia:
>
> The text had too many blatant errors to start enumerating them all.

Most of them are statements about philosophy or practice rather than
absolutes; thus its hard for them to be objectively or "blatantly"
wrong. Whether that's a good thing or not is another issue. I see the
list as a starting point for discussion even if it does not settle
everything.

It brings up interesting questions, such as why not have schema
inheritance? If inheritance is good or OO, why is it not good for
relational schema's? The answer is that OO and relational approach
things differently.

> The
> problem with wikipedia is any ignorant fool can just start typing
> nonsense. Even when one follows the requirements for references to
> primary sources, the quality of the end product can vary over many
> orders of magnitude.

-T-
0
topmind (2124)
3/3/2008 9:57:42 PM
On 2008-03-03 12:29:02 -0600, TroyK <cs_troyk@juno.com> said:

> My experience is somewhere between 2 and 3 orders of magnitude
> difference between implementing a business rules change in the db vs.
> the programming team doing it in OO code.

Then you should be able to fly rings around the programmers and get 
them all fired.  Why haven't you?

Ladies and gentlemen, there are certainly tasks that are better suited 
to SQL and stored procedures.  There are other tasks that are better 
suited to general purpose languages.  True wisdom comes from knowing 
the strengths and weaknesses of both.  Good architects build systems 
that combine the tools synergistically.

-- 
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)
3/3/2008 10:11:25 PM
On 2008-03-03 11:36:50 -0600, "David Cressey" <cressey73@verizon.net> said:

> It appears,  from reading c.o., that OO people regard data structures as
> evil.

Not at all.  Data structures are not evil, they just aren't objects.

Objects expose behaviors and hide their data.  Data structures expose 
their data and have no behavior.  So the two are in almost diametric 
opposition.

Moreover, software that uses data structures is easy to add new 
functions to, but hard to add new data to.  On the other hand, software 
that uses objects is easy to add new objects to but hard to add new 
functions to.

These two different affordances are the tools that a good architect 
will use to construct systems that are easy to change.  The architect 
will use data structures in those areas where new functions are likely 
to be added, and will use objects in those areas where new data is 
likely to be added.

-- 
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)
3/3/2008 10:15:33 PM
On 2008-03-03 13:44:07 -0600, topmind <topmind@technologist.com> said:

>> Right, the structure of data would be too low-level to be able to capture
>> behavior. As in mathematics, in OO the internal structure of objects is
>> irrelevant and when considered, then only as an implementation detail to be
>> abstracted away. OO deals with the structures of sets of objects exposing
>> same behavior and relations between such sets.
> 
> This is misleading. An association between object A and object B does
> NOT go away just because it is managed via accessors. OOP not only
> doesn't get one away from dealing with things as "structures", but
> uses structures that were discredited in late 60's.
> 
> Hiding behind accessors is merely a shell game. setMess and getMess is
> *still* a mess.

Bryce, he wasn't talking about setters and getters.


-- 
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)
3/3/2008 10:18:12 PM
On Mar 3, 9:50 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-03 10:52:10 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> > On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
> >> All attempts by applications to access a DB's tables and columns
> >> directly violates design principles that guard against close-coupling.
> >> This is a basic design tenet for OO.  Violating it when jumping from OO
> >> to RDB is, I think, the source of problem that are collectively and
> >> popularly referred to as the object-relational impedance mismatch.
>
> > I wondered if we might be able to come up with some agreement on what
> > object-relational impedence mismatch actually means. I always thought
> > the mismatch was centred on the issue that a single object != single
> > tuple, but it appears there may be more to it than that.
>
> There is indeed more to it than that.  OO and RDB are both strategies
> for partitioning data.  However, the motivation behind the partitioning
> is completely different.  OO partitions data based on the way a
> particular application will process that data.

Is it really as clean cut as that? A single application may be
required to process data in several ways - and some may be initially
unforseen, as requirements (inevitably) may change?

> RDBs partition data
> based on how many different applications will need to access that data.

....or based on the different ways a single application will need to
process the data, no?

>
> This really isn't an impedance mismatch.  It's a mismatch of intent.
> When designers use each strategy for what it's good at, there is no
> mismatch at all.
>
> > One thing I would like to avoid
> > (outside of almost flames of course), is the notion that database
> > technology is merely a persistence layer (do people still actually
> > think that?) - I wonder if the 'mismatch' stems from such a
> > perspective.
>
> Take out the word "merely", and recognize that "persistence" is more
> than just storage.

Perhaps you could expand? I was referring to the fact that databases
do more than 'persist' objects.

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

0
jog (83)
3/3/2008 10:18:19 PM
On 2008-03-03 15:11:19 -0600, "Dmitry A. Kazakov" 
<mailbox@dmitry-kazakov.de> said:

> On Mon, 3 Mar 2008 11:44:07 -0800 (PST), topmind wrote:
> 
>> OOP not only
>> doesn't get one away from dealing with things as "structures", but
>> uses structures that were discredited in late 60's.
> 
> How can anybody discredit a data structure? Recently I was taught by our
> c.d.t. colleges that data are recorded facts. You didn't object them. So,
> may I humble ask you, who and how could discredit facts? (outside Usenet
> discussion forums, I mean... (:-))

Bryce is all hot and bothered about the vague similarity between 
network databases (which he asserts were discredited even though they 
remain the heart of nearly all directory systems and REST hierarchies) 
and object graphs.

-- 
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)
3/3/2008 10:21:05 PM
topmind wrote:

> On Mar 3, 10:54 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> 
>>topmind wrote:
>>
>>>JOG wrote:
>>
>>>>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>>
>>>>>All attempts by applications to access a DB's tables and columns
>>>>>directly violates design principles that guard against close-coupling.
>>>>>This is a basic design tenet for OO.  Violating it when jumping from OO
>>>>>to RDB is, I think, the source of problem that are collectively and
>>>>>popularly referred to as the object-relational impedance mismatch.
>>
>>>>I wondered if we might be able to come up with some agreement on what
>>>>object-relational impedence mismatch actually means. I always thought
>>>>the mismatch was centred on the issue that a single object != single
>>>>tuple, but it appears there may be more to it than that.
>>
>>>>I was hoping perhaps people might be able to offer perspectives on the
>>>>issues that they have encountered.  One thing I would like to avoid
>>>>(outside of almost flames of course), is the notion that database
>>>>technology is merely a persistence layer (do people still actually
>>>>think that?) - I wonder if the 'mismatch' stems from such a
>>>>perspective.
>>
>>>This came up in a nearby message. I borrowed the following text from
>>>wikipedia:
>>
>>The text had too many blatant errors to start enumerating them all.
> 
> Most of them are statements about philosophy or practice rather than
> absolutes; thus its hard for them to be objectively or "blatantly"
> wrong. Whether that's a good thing or not is another issue. I see the
> list as a starting point for discussion even if it does not settle
> everything.
> 
> It brings up interesting questions, such as why not have schema
> inheritance? If inheritance is good or OO, why is it not good for
> relational schema's? The answer is that OO and relational approach
> things differently.

Your question presupposes that inheritance is good for OO.
0
bbadour (434)
3/3/2008 10:24:03 PM
"Roy Hann" <specially@processed.almost.meat> wrote in message
news:nfWdnW05its1o1HanZ2dnUVZ8t2snZ2d@pipex.net...


> Until I know their reasons for their views on data structures I couldn't
> say.  However I notice that I am surrounded by programmers who consume
most
> the development budget writing code, and when a change request comes along
I
> can accommodate it in the database in minutes and they spend months
spewing
> out more code (sometimes after doing an extensive and expensive impact
> assessment).  Code may not be evil, but it sure has a case to answer.

I have to agree with this comment, based on my own experience.

*However*, my experience, and perhaps yours as well, may be biased towards
cases in business where relatively rich data is subjected to fairly
straightforward transformations. A lot of commercial data processing fits
that description.



0
cressey73 (124)
3/3/2008 10:28:46 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message 
news:2008030315531543042-unclebob@objectmentorcom...
> On 2008-03-03 11:24:20 -0600, "Roy Hann" <specially@processed.almost.meat> 
> said:
>
>> Code is evil.
>
> SQL is code.

SQL is a botch.  It is vile rather than evil.  :-)

Roy 


0
specially (35)
3/3/2008 10:30:42 PM
"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
news:47cc383f$0$4041$9a566e8b@news.aliant.net...


> It's pretty obvious to me: object-relational mismatch is to relations as
> assembler-object mismatch is to objects.

I didn't get this comment.  Now that someone else has flagged it as a
keeper, I feel the need to ask for an explanation.


0
cressey73 (124)
3/3/2008 10:31:43 PM
"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
news:47cc4766$0$4037$9a566e8b@news.aliant.net...
> David Cressey wrote:
> > "Roy Hann" <specially@processed.almost.meat> wrote in message
> > news:zpSdnSj5fPTYqVHanZ2dneKdnZydnZ2d@pipex.net...
> >
> >>"Thomas Gagne" <tgagne@wide-open-west.com> wrote in message
> >>news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d@wideopenwest.com...
> >>
> >>>JOG wrote:
> >>>
> >>>>I wondered if we might be able to come up with some agreement on what
> >>>>object-relational impedence mismatch actually means. I always thought
> >>>>the mismatch was centred on the issue that a single object != single
> >>>>tuple, but it appears there may be more to it than that.
> >>>>
> >>>
> >>>The issue as I've discovered it has to do with the fact OO systems are
> >>>composed of graphs of data and RDBs are two-dimensional.
> >>
> >>RDBs are not two-dimensional, they are n-dimensional.  You are confusing
> >
> > the
> >
> >>picture of the thing with the thing.  I have a three dimensional kitchen
> >>table.  I have an RDB table with three columns (dimensions) called
length,
> >>width and height that describes it.
> >
> > Stop!  You're both right!
> >
> > There is a certain level of abstraction where and RDB is definitely
> > n-dimensional.  This is the level of abstraction where I spend most of
my
> > time thinking.  So I tend to agree with you, Roy.
> >
> > There is, however, a different level of abstraction where an RDB is
> > two-dimensional.  So Tom is not "wrong" all the way.  And it may be at
that
> > level of abstraction where the OO RM impedance match comes about.
>
> David, the flaw in your logic is: At the level of abstraction where an
> RDB is two-dimensional, OO is uni-dimensional.
>

That would certainly explain the impedance mismatch!


0
cressey73 (124)
3/3/2008 10:33:58 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message 
news:2008030315573622503-unclebob@objectmentorcom...
> On 2008-03-03 12:08:39 -0600, "Roy Hann" <specially@processed.almost.meat> 
> said:
>
>> However I notice that I am surrounded by programmers who consume most
>> the development budget writing code, and when a change request comes 
>> along I
>> can accommodate it in the database in minutes and they spend months 
>> spewing
>> out more code (sometimes after doing an extensive and expensive impact
>> assessment).  Code may not be evil, but it sure has a case to answer.
>
> Silly developers and DBAs always have a case to answer.  Their tools are 
> innocent.

I admit I am just being provocative, so I probably deserve a  baffling non 
sequiter as a response.  However you seem to be claiming that code doesn't 
routinely take weeks and months to write (which is what I assume you mean 
when you say the tools are innocent).  That is nonsense, of course.

> BTW, "minutes"?  "weeks"?  Why didn't you make the change in "minutes" and 
> demonstrate it while everybody else was still working on the impact 
> analysis?

Well if I had something better than an improvised ad hoc language that has 
its roots in the late 1960s and early 1970s, which offers me a collection of 
datatypes barely richer than those of FORTRAN IV, I might have done.  But as 
long as most people think writing procedural code at the speed of human 
fingers is all we can reasonably aspire to, I won't be getting anything 
better to work with.

Roy 


0
specially (35)
3/3/2008 10:43:46 PM
On 2008-03-03 12:46:09 -0600, topmind <topmind@technologist.com> said:

> It depends on how you use the DB. In Robert Martin's version of the
> payroll application, the DB is almost reduced to a dumb filing system
> ("persistence layer") because the app code does all the work. However,
> in my version:
> 
> http://www.geocities.com/tablizer/payroll2.htm
> 
> I *leveraged* the DB so that much if not most of the work is done by
> the database and queries *instead* of the app code.


Well, that might be a bit of an exaggeration.  Here's just one part of 
the code in your example:

<cffunction name="printStubs">
    <cfquery name="stubQry" datasource="#dsn#">
        SELECT *
        FROM payStubs, employees, payItems
        WHERE empRef = empID AND payItemRef = payItemID
        ORDER BY payDate, empRef, lineNum
    </cfquery>
    <!--- <cfdump var="#stubQry#"> [for debugging] --->
    <h3>Pay Stub Samples</h3>
    <cfset shadeClr = "##f0f0f0">
    <cfoutput query="stubQry" group="empID">  <!--- outer group by empID --->
        <cfset sumPay = 0>    <!--- init --->
        <hr>
        <table border=1 cellpadding=2 cellspacing=0>
            <tr>
                <td bgcolor="#shadeClr#" width="25%">Name:</td>
                <td colspan=3>#stubQry.lastName#, #stubQry.firstName# 
#stubQry.middle#</td>
            </tr>
            <tr>
                <td bgcolor="#shadeClr#">Empl. ID:</td>
                <td colspan=3>#stubQry.empID#</td>
            </tr>
            <tr>
                <td  bgcolor="#shadeClr#">Payroll Date:</td>
                <td colspan=3>#stubQry.payDate#</td>
            </tr>
            <!--- column headings --->
            <tr bgcolor="#shadeClr#">
                <th colspan=2>Item<br>Description</th>
                <th>Reference<br>Value</th>
                <th>Pay<br>Amount</th>
            </tr>
            <!--- for each line item --->
            <cfoutput>
                <!--- skip line if zero-amount suppression is on --->
                <cfif Not (stubQry.displayOptions Contains '(supprzero)'
                    And stubQry.amount EQ 0.00)>
                    <tr>
                        <td colspan=2>#stubQry.lineDescript#</td>
                        <td align="right">
                            <cfif stubQry.sumMult is 0>
                                #stubQry.referenceAmt#
                            <cfelse>
                                &nbsp;
                            </cfif>
                        </td>
                        <td align="right">
                            <cfif stubQry.sumMult NEQ 0>
                                
#numberFormat(stubQry.amount,"-9,999,999,999.99")#
                            <cfelse>
                                &nbsp;
                            </cfif>
                        </td>
                    </tr>
                </cfif>
                <cfset sumPay = sumPay + stubQry.amount>
            </cfoutput>

            <!--- Total Line --->
            <tr>
                <td colspan=3 align="right"><b>Total</b></td>
                <td 
align="right">#numberFormat(sumPay,"-9,999,999,999.99")#</td>
            </tr>
        </table>
    </cfoutput>
</cffunction>

That's a lot of processing code.

However, I think your point is not completely invalid.  You *did* use 
more database facilities than I did.  Was your code smaller or better?  
From the above I would say that it was not better.  In the C++ example 
from my book "Agile Software Development, Principles, Patterns, and 
Practices" you won't see any methods that are even a quarter as long as 
what you have there.  As for whether it was smaller, it's hard to say 
because the two programs don't do very similar things.  You used a very 
different set of requirements than I did.

Still, your point is valid in that I purposely pulled out any kind of 
SQL from my example, and made use of C++ code rather than database 
tools -- to the extent that I even did a linear search through all 
employees rather than using the database to efficiently query them. 
This was done on purpose because the book is an exposition on OO design 
principles as opposed to database principles.

You might complain that a book about writing good software *should* 
have database concepts mixed in with it.  I sympathize, but authors 
must make choices, just as you did in your example.
-- 
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)
3/3/2008 10:48:10 PM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:2008030316112582327-unclebob@objectmentorcom...

> Ladies and gentlemen, there are certainly tasks that are better suited
> to SQL and stored procedures.  There are other tasks that are better
> suited to general purpose languages.  True wisdom comes from knowing
> the strengths and weaknesses of both.  Good architects build systems
> that combine the tools synergistically.

Agreed.  But often the suitability of a given task has less to do with the
language
than it does with the domain of responsibilities of either data managers or
code managers.

Both SQL and C++ are straw men in the sense that there are things that could
be done quite differently if one were to reimplement from scratch, know what
we now know.

I think it's relatively straight forward to extend a language like SQL so
that it becomes a general purpose language.  (Whether it becomes a good one
or a bad one is a matter for further discussion).  It doesn't seem as
straightforward to me to extend a language like C++ so that it becomes
suitable for declaring relational transformations on data.  If it is
straight forward, then I'd like to hear from people who are doing it.

But the idea of a single language that is suitable for everything remains an
elusive goal,  and probably an unproductive endeavor.



0
cressey73 (124)
3/3/2008 10:49:29 PM
"Robert Martin"

> Moreover, software that uses data structures is easy to add new
> functions to, but hard to add new data to.  On the other hand, software
> that uses objects is easy to add new objects to but hard to add new
> functions to.
>
> These two different affordances are the tools that a good architect
> will use to construct systems that are easy to change.  The architect
> will use data structures in those areas where new functions are likely
> to be added, and will use objects in those areas where new data is
> likely to be added.
>

I honestly think the above undervalues data independence.  It turns out to
be surprisingly easy to to add new data to a well designed database with
minimal impact on existing programs that access the data.  The impact on
programs that provide data is greater, but still quite manageable.





0
cressey73 (124)
3/3/2008 10:53:09 PM
Roy Hann wrote:
> "Thomas Gagne" <tgagne@wide-open-west.com> wrote in message 
> news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d@wideopenwest.com...
> 
>>JOG wrote:
>>
>>>I wondered if we might be able to come up with some agreement on what
>>>object-relational impedence mismatch actually means. I always thought
>>>the mismatch was centred on the issue that a single object != single
>>>tuple, but it appears there may be more to it than that.
>>
>>The issue as I've discovered it has to do with the fact OO systems are
>>composed of graphs of data and RDBs are two-dimensional.

That is a remarkably uninformed and ill-conceived sentence. It's rather 
like comparing boats and cars saying boats have hulls and cars are 
pretty. Regardless of truth, the comparison is pointless on its face.

One can represent any graph on two-dimensional media just as one can 
represent any relation on two-dimensional media. In fact, since a graph 
is merely a set of vertices and a set of directed edges and since one 
can easily represent vertices and directed edges as tuples, one can 
easily represent any graph using relations.

The Great Debate was had about 3 decades ago and graphs lost. Nothing 
has happened in the meantime to improve the outcome in the favour of graphs.


> RDBs are not two-dimensional, they are n-dimensional.  You are confusing the 
> picture of the thing with the thing.  I have a three dimensional kitchen 
> table.  I have an RDB table with three columns (dimensions) called length, 
> width and height that describes it.
> 
> 
>>What defines an account in an RDB may be composed of multiple tables.
>>An RDB might express multiple account types through multiple tables
>>where OO may reflect it as multiple classes.  Attempts to make RDBs
>>function as graphs through mapping tools results in disappointing
>>performance and, in my experience, too much mapping, too much

What moron would want to make an RDB function as graphs in the first 
place? We have known for 3 decades that graphs, themselves, result in 
disappointing performance and too much mapping. After all, every time 
one adds a new structural element, the design choices increase 
geometrically with no logical justification for choosing among them.

This leads people to discard logical independence and invent physical 
reasons. The arbitrary design choices then lead to query bias that 
effectively makes large numbers of useful queries prohibitively 
expensive to write or to execute.


>>infrastructure, and too much language/paradigm-specific layers.  In
>>short, way more code, way more maintenance, and way more job-security
>>for consultants, pundits, and tool providers.
> 
> I completely, 100% agree with that.  Code is evil.
> 
> Roy 
0
bbadour (434)
3/3/2008 11:02:40 PM
On 2008-03-03, Robert Martin <unclebob@objectmentor.com> wrote:
>
> There is indeed more to it than that.  OO and RDB are both strategies 
> for partitioning data.  However, the motivation behind the partitioning 
> is completely different.  OO partitions data based on the way a 
> particular application will process that data.  RDBs partition data 
> based on how many different applications will need to access that data.
>

No, RDBs partition data so that it is sensibly and easily available to
any possible application. So if you use OO you are saying "there will
never be any other application that will need my data". 

E
0
eric154 (81)
3/3/2008 11:03:41 PM
On Mar 3, 9:57 pm, topmind <topm...@technologist.com> wrote:
> On Mar 3, 10:54 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
>
>
> > topmind wrote:
> > > JOG wrote:
>
> > >>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
> > >>>All attempts by applications to access a DB's tables and columns
> > >>>directly violates design principles that guard against close-coupling.
> > >>>This is a basic design tenet for OO.  Violating it when jumping from OO
> > >>>to RDB is, I think, the source of problem that are collectively and
> > >>>popularly referred to as the object-relational impedance mismatch.
>
> > >>I wondered if we might be able to come up with some agreement on what
> > >>object-relational impedence mismatch actually means. I always thought
> > >>the mismatch was centred on the issue that a single object != single
> > >>tuple, but it appears there may be more to it than that.
>
> > >>I was hoping perhaps people might be able to offer perspectives on the
> > >>issues that they have encountered.  One thing I would like to avoid
> > >>(outside of almost flames of course), is the notion that database
> > >>technology is merely a persistence layer (do people still actually
> > >>think that?) - I wonder if the 'mismatch' stems from such a
> > >>perspective.
>
> > > This came up in a nearby message. I borrowed the following text from
> > > wikipedia:
>
> > The text had too many blatant errors to start enumerating them all.
>
> Most of them are statements about philosophy or practice rather than
> absolutes; thus its hard for them to be objectively or "blatantly"
> wrong. Whether that's a good thing or not is another issue. I see the
> list as a starting point for discussion even if it does not settle
> everything.
>
> It brings up interesting questions, such as why not have schema
> inheritance? If inheritance is good or OO, why is it not good for
> relational schema's? The answer is that OO and relational approach
> things differently.

This reminds me of a serious 'click' moment I had with data
structures. A long time ago, in a galaxy far far away, I once sat
blindly reinventing my own network model, with identifiers, pointers,
types, and all the fun of the fair. As an OO programmer it was the
only mindset I had. Then I considered encoding data similar to the
classic example of:

* Aristotle is a man
* All men are mortal
* |= Aristotle is mortal

Well, /clearly/ what I was dealing with here was a generic entity
class, of which Man was a subclass, and Aristotle an instance.
Something like:

class Entity
{
boolean mortal;
string name;
Entity(_name, _mortal) : name(_name), mortal(_mortal);
};

class Man : public Entity
{
date bday;
Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
};


But, as I extended the example, the structures got more convoluted,
and the result more and more of a mess. Finally something clicked. It
wasn't about types, objects or inheritance, it was about /inference/,
and what I actually had was:

Name(x, Aristotle) -> Species(x, Man)
Species(x, Man) -> Mortality(x, Mortal)
|= Name(x, Aristotle) -> Mortalilty(x, Mortal)

No types or reification in sight. Instead I had two groups of
statements:
People = {Name, Species, Bday}
Entities = {Species, Mortality}

A join of the two statements gave me the inference I required: {Name,
Mortality}. All of a sudden it seemed simple. So some questions:

1) So why not treat all 'inheritance' in this way?
2) Could one extend to include 'behaviour' as well?
3) And is this a crazy thing to suggest in a cross post to an OO
group?

>
> > The
> > problem with wikipedia is any ignorant fool can just start typing
> > nonsense. Even when one follows the requirements for references to
> > primary sources, the quality of the end product can vary over many
> > orders of magnitude.
>
> -T-

0
jog (83)
3/3/2008 11:06:05 PM

Robert Martin wrote:
> On 2008-03-03 12:46:09 -0600, topmind <topmind@technologist.com> said:
>
> > It depends on how you use the DB. In Robert Martin's version of the
> > payroll application, the DB is almost reduced to a dumb filing system
> > ("persistence layer") because the app code does all the work. However,
> > in my version:
> >
> > http://www.geocities.com/tablizer/payroll2.htm
> >
> > I *leveraged* the DB so that much if not most of the work is done by
> > the database and queries *instead* of the app code.
>
>
> Well, that might be a bit of an exaggeration.  Here's just one part of
> the code in your example:
>
> <cffunction name=3D"printStubs">
>     <cfquery name=3D"stubQry" datasource=3D"#dsn#">
>         SELECT *
>         FROM payStubs, employees, payItems
>         WHERE empRef =3D empID AND payItemRef =3D payItemID
>         ORDER BY payDate, empRef, lineNum
>     </cfquery>
>     <!--- <cfdump var=3D"#stubQry#"> [for debugging] --->
>     <h3>Pay Stub Samples</h3>
>     <cfset shadeClr =3D "##f0f0f0">
>     <cfoutput query=3D"stubQry" group=3D"empID">  <!--- outer group by emp=
ID --->
>         <cfset sumPay =3D 0>    <!--- init --->
>         <hr>
>         <table border=3D1 cellpadding=3D2 cellspacing=3D0>
>             <tr>
>                 <td bgcolor=3D"#shadeClr#" width=3D"25%">Name:</td>
>                 <td colspan=3D3>#stubQry.lastName#, #stubQry.firstName#
> #stubQry.middle#</td>
>             </tr>
>             <tr>
>                 <td bgcolor=3D"#shadeClr#">Empl. ID:</td>
>                 <td colspan=3D3>#stubQry.empID#</td>
>             </tr>
>             <tr>
>                 <td  bgcolor=3D"#shadeClr#">Payroll Date:</td>
>                 <td colspan=3D3>#stubQry.payDate#</td>
>             </tr>
>             <!--- column headings --->
>             <tr bgcolor=3D"#shadeClr#">
>                 <th colspan=3D2>Item<br>Description</th>
>                 <th>Reference<br>Value</th>
>                 <th>Pay<br>Amount</th>
>             </tr>
>             <!--- for each line item --->
>             <cfoutput>
>                 <!--- skip line if zero-amount suppression is on --->
>                 <cfif Not (stubQry.displayOptions Contains '(supprzero)'
>                     And stubQry.amount EQ 0.00)>
>                     <tr>
>                         <td colspan=3D2>#stubQry.lineDescript#</td>
>                         <td align=3D"right">
>                             <cfif stubQry.sumMult is 0>
>                                 #stubQry.referenceAmt#
>                             <cfelse>
>                                 &nbsp;
>                             </cfif>
>                         </td>
>                         <td align=3D"right">
>                             <cfif stubQry.sumMult NEQ 0>
>
> #numberFormat(stubQry.amount,"-9,999,999,999.99")#
>                             <cfelse>
>                                 &nbsp;
>                             </cfif>
>                         </td>
>                     </tr>
>                 </cfif>
>                 <cfset sumPay =3D sumPay + stubQry.amount>
>             </cfoutput>
>
>             <!--- Total Line --->
>             <tr>
>                 <td colspan=3D3 align=3D"right"><b>Total</b></td>
>                 <td
> align=3D"right">#numberFormat(sumPay,"-9,999,999,999.99")#</td>
>             </tr>
>         </table>
>     </cfoutput>
> </cffunction>
>
> That's a lot of processing code.

Compared to?

>
> However, I think your point is not completely invalid.  You *did* use
> more database facilities than I did.  Was your code smaller or better?
> From the above I would say that it was not better.  In the C++ example
> from my book "Agile Software Development, Principles, Patterns, and
> Practices" you won't see any methods that are even a quarter as long as
> what you have there.

I could have shortened it if I wanted to by splitting it up, but I saw
no need in this case. The size can be shortened without resorting to
OOP. Clarity and shortness of methods/functions are not necessarily
the same thing. Then again, everybody likes things a different way.
Software engineering is largely about psychology, and everybody's
psychology is different. What trips you up may not trip me up, and
vise versa.

But I think anybody inspecting both examples will clearly see that my
version is a lot less total code.

> As for whether it was smaller, it's hard to say
> because the two programs don't do very similar things.  You used a very
> different set of requirements than I did.

I satisfied almost everything on your opening list of requirements,
plus allowing more line items to be created without altering existing
code. You talk a lot about adding or changing things without it
impacting lots of code. By not hard-wiring formulas and line-items
into the code, I improved on this metric.

>
> Still, your point is valid in that I purposely pulled out any kind of
> SQL from my example, and made use of C++ code rather than database
> tools -- to the extent that I even did a linear search through all
> employees rather than using the database to efficiently query them.
> This was done on purpose because the book is an exposition on OO design
> principles as opposed to database principles.
>
> You might complain that a book about writing good software *should*
> have database concepts mixed in with it.  I sympathize, but authors
> must make choices, just as you did in your example.

If I was writing a formal book on software engineering, I hopefully
would at least point out the pro's and con's of various design
decisions. We both came up with very different designs for solving
essentially the same problem. This is because the implementation
options are wide open.

> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com
> Object Mentor Inc.=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=
=BD=EF=BF=BD| blog:=EF=BF=BD=EF=BF=BDwww.butunclebob.com

-T-
0
topmind (2124)
3/3/2008 11:25:48 PM
On Mar 3, 3:06 pm, JOG <j...@cs.nott.ac.uk> wrote:
> On Mar 3, 9:57 pm, topmind <topm...@technologist.com> wrote:
>
>
>
> > On Mar 3, 10:54 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
> > > topmind wrote:
> > > > JOG wrote:
>
> > > >>On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>
> > > >>>All attempts by applications to access a DB's tables and columns
> > > >>>directly violates design principles that guard against close-coupling.
> > > >>>This is a basic design tenet for OO.  Violating it when jumping from OO
> > > >>>to RDB is, I think, the source of problem that are collectively and
> > > >>>popularly referred to as the object-relational impedance mismatch.
>
> > > >>I wondered if we might be able to come up with some agreement on what
> > > >>object-relational impedence mismatch actually means. I always thought
> > > >>the mismatch was centred on the issue that a single object != single
> > > >>tuple, but it appears there may be more to it than that.
>
> > > >>I was hoping perhaps people might be able to offer perspectives on the
> > > >>issues that they have encountered.  One thing I would like to avoid
> > > >>(outside of almost flames of course), is the notion that database
> > > >>technology is merely a persistence layer (do people still actually
> > > >>think that?) - I wonder if the 'mismatch' stems from such a
> > > >>perspective.
>
> > > > This came up in a nearby message. I borrowed the following text from
> > > > wikipedia:
>
> > > The text had too many blatant errors to start enumerating them all.
>
> > Most of them are statements about philosophy or practice rather than
> > absolutes; thus its hard for them to be objectively or "blatantly"
> > wrong. Whether that's a good thing or not is another issue. I see the
> > list as a starting point for discussion even if it does not settle
> > everything.
>
> > It brings up interesting questions, such as why not have schema
> > inheritance? If inheritance is good or OO, why is it not good for
> > relational schema's? The answer is that OO and relational approach
> > things differently.
>
> This reminds me of a serious 'click' moment I had with data
> structures. A long time ago, in a galaxy far far away, I once sat
> blindly reinventing my own network model, with identifiers, pointers,
> types, and all the fun of the fair. As an OO programmer it was the
> only mindset I had. Then I considered encoding data similar to the
> classic example of:
>
> * Aristotle is a man
> * All men are mortal
> * |= Aristotle is mortal
>
> Well, /clearly/ what I was dealing with here was a generic entity
> class, of which Man was a subclass, and Aristotle an instance.
> Something like:
>
> class Entity
> {
> boolean mortal;
> string name;
> Entity(_name, _mortal) : name(_name), mortal(_mortal);
>
> };
>
> class Man : public Entity
> {
> date bday;
> Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
>
> };
>
> But, as I extended the example, the structures got more convoluted,
> and the result more and more of a mess. Finally something clicked. It
> wasn't about types, objects or inheritance, it was about /inference/,
> and what I actually had was:
>
> Name(x, Aristotle) -> Species(x, Man)
> Species(x, Man) -> Mortality(x, Mortal)
> |= Name(x, Aristotle) -> Mortalilty(x, Mortal)
>
> No types or reification in sight. Instead I had two groups of
> statements:
> People = {Name, Species, Bday}
> Entities = {Species, Mortality}
>
> A join of the two statements gave me the inference I required: {Name,
> Mortality}. All of a sudden it seemed simple. So some questions:
>
> 1) So why not treat all 'inheritance' in this way?
> 2) Could one extend to include 'behaviour' as well?
> 3) And is this a crazy thing to suggest in a cross post to an OO
> group?
>

I think you'd like Prolog. And, I think a Prolog-relational merger
would be easier than an OO-Prolog merger.

>
>
> > > The
> > > problem with wikipedia is any ignorant fool can just start typing
> > > nonsense. Even when one follows the requirements for references to
> > > primary sources, the quality of the end product can vary over many
> > > orders of magnitude.
>

-T-

0
topmind (2124)
3/3/2008 11:30:37 PM
topmind wrote:

> 
> Robert Martin wrote:
> 
>>On 2008-03-03 12:46:09 -0600, topmind <topmind@technologist.com> said:

[snip]

>>You might complain that a book about writing good software *should*
>>have database concepts mixed in with it.  I sympathize, but authors
>>must make choices, just as you did in your example.

Oh my god, the idiot is an author?!? For his sake, it's a good thing we 
don't have any concept of writing malpractice. He'd be giving a lot of 
refunds and spending a lot of time in court.
0
bbadour (434)
3/3/2008 11:36:38 PM
David Cressey wrote:

> "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> news:47cc383f$0$4041$9a566e8b@news.aliant.net...
> 
>>It's pretty obvious to me: object-relational mismatch is to relations as
>>assembler-object mismatch is to objects.
> 
> I didn't get this comment.  Now that someone else has flagged it as a
> keeper, I feel the need to ask for an explanation.

What do you know about assembler?
0
bbadour (434)
3/3/2008 11:37:40 PM
David Cressey wrote:

> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:2008030316112582327-unclebob@objectmentorcom...
> 
> 
>>Ladies and gentlemen, there are certainly tasks that are better suited
>>to SQL and stored procedures.  There are other tasks that are better
>>suited to general purpose languages.  True wisdom comes from knowing
>>the strengths and weaknesses of both.

Sadly, Robert Martin has demonstrated again and again that he lacks any 
wisdom let alone true wisdom.

[snip]
0
bbadour (434)
3/3/2008 11:46:19 PM
On Mar 3, 2:18 pm, JOG <j...@cs.nott.ac.uk> wrote:
> On Mar 3, 9:50 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>
> > There is indeed more to it than that.  OO and RDB are both strategies
> > for partitioning data.  However, the motivation behind the partitioning
> > is completely different.  OO partitions data based on the way a
> > particular application will process that data.
>
> Is it really as clean cut as that?

Boy howdy, no, it's not. For one thing, neither OO nor the RM
are strategies for partitioning data.

One's requirements dictate data with certain functional dependencies.
Among the easiest tasks in application design is one of the earliest:
structuring the data. The RM structures data as relations. Relational
structures lack query bias, which is one of the reasons why SQL
is so good at ad hoc queries (compared to the other choices.)
OO structures mandates an object structure (unsurprisingly): out the
gate, one has no choice but to build in a query bias, whether
one wants it or not.

Furthermore, since OOPLs lack physical independence, traversing
the graph may be quite expensive, particularly in the case where
the graph is backed by storage in a database, which is part of
why ORM is such a universally bad idea. Of course, one can
always build physical independence into one's objects, but
that has to be done manually, one pathway at a time.


> > > One thing I would like to avoid
> > > (outside of almost flames of course), is the notion that database
> > > technology is merely a persistence layer (do people still actually
> > > think that?) - I wonder if the 'mismatch' stems from such a
> > > perspective.
>
> > Take out the word "merely", and recognize that "persistence" is more
> > than just storage.
>
> Perhaps you could expand? I was referring to the fact that databases
> do more than 'persist' objects.

DBMSs don't even necessarily persist at all.

I've said in the past that persistence isn't even a first-tier dbms
feature.
It's a strong second-tier feature, to be sure! But a dbms with no
persistence still has strong use-cases. Which makes it clear enough
that anyone who considers SQL to be about persistence *primarily*
(if not exclusively) hasn't yet identified what the first-tier feature
even *are.*


Marshall
0
3/4/2008 12:24:33 AM
On Mar 3, 8:52 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> I was hoping perhaps people might be able to offer perspectives
> on the issues that they have encountered.

One piece of the puzzle that is often neglected is a qualitative
difference in the type systems of some of the most popular
OOPLs vs. SQL or a hypothetical relational language. This
difference doesn't get a lot of ink in industrial settings but
it's quite important.

C++ and Java and many similar languages are nominally
typed; SQL is structurally typed.

For example, suppose I have two Java classes as follows (toy
example for illustrative purposes):

  class Foo { int x; int  y; };
  class Bar { int x, int y; };

The two classes are different; one cannot use an instance of one
as an instance of the other under any circumstances, not even
with a cast.

In SQL, if I have two relations with x and y int columns, I can
union them, or join on them, or whatever. There is no way,
in fact, to forbid such a thing, just like in Java there is no way
to allow such a thing.

One particular manifestation of this difference is that if one
is writing an ORM for Java, one has to address the issue
that one needs a new class for every distinct column-set
of every query one has. This fact sometimes drives unfortunate
design decisions.


Marshall
0
3/4/2008 12:34:39 AM
"JOG" wrote:
>
> This reminds me of a serious 'click' moment I had with data
> structures. A long time ago, in a galaxy far far away, I once sat
> blindly reinventing my own network model, with identifiers, pointers,
> types, and all the fun of the fair. As an OO programmer it was the
> only mindset I had. Then I considered encoding data similar to the
> classic example of:
>
> * Aristotle is a man
> * All men are mortal
> * |= Aristotle is mortal
>
> Well, /clearly/ what I was dealing with here was a generic entity
> class, of which Man was a subclass, and Aristotle an instance.
> Something like:
>
> class Entity
> {
> boolean mortal;
> string name;
> Entity(_name, _mortal) : name(_name), mortal(_mortal);
> };
>
> class Man : public Entity
> {
> date bday;
> Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
> };
>
>
> But, as I extended the example, the structures got more convoluted,
> and the result more and more of a mess. Finally something clicked. It
> wasn't about types, objects or inheritance, it was about /inference/,
> and what I actually had was:
>
> Name(x, Aristotle) -> Species(x, Man)
> Species(x, Man) -> Mortality(x, Mortal)
> |= Name(x, Aristotle) -> Mortalilty(x, Mortal)
>
> No types or reification in sight. Instead I had two groups of
> statements:
> People = {Name, Species, Bday}
> Entities = {Species, Mortality}
>
> A join of the two statements gave me the inference I required: {Name,
> Mortality}. All of a sudden it seemed simple. So some questions:
>
> 1) So why not treat all 'inheritance' in this way?
> 2) Could one extend to include 'behaviour' as well?
> 3) And is this a crazy thing to suggest in a cross post to an OO
> group?

I'm jumping in realizing that I may be revealing a bit of ignorance here, so
bear with me.

If I need to send a message to all persons who are mortal, I could join
People and Entities together by species and where Mortality is true?

Once I've performed the join, I then dispatch a message to the resulting
group: "GetAnnualCheckUp()" or something?

In the application I'm currently writing, I have a large list of parameters.
These parameters share some values such as Name and Label. However, there
are different types of parameters such as those that represent a boolean
state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square",
etc., and other types. My current approach is traditional OO, and that's to
have a hierarchy of Parameter classes. I can then keep a list of
heterogeneous parameters and treat them polymorphically. For example:

params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f);
params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);

// Set a parameter value. All raw parameter values are in the range
// of [0, 1]. Each parameter class knows how to transform raw parameter
// values in an appropriate way.
params[parameterId].SetValue(value);

And all works well.

I'm trying to wrap my head around how I would approach this problem using
what you've described above. I could have a table representing attributes
common to all parameters. Then tables representing attributes specific to
one parameter type or another. I could relate the tables via foreign keys?
When I need to dispatch parameter changes, I could join the appropriate
tables and change the appropriate values?

I'm open to new ways of approaching things, but the mechanism to implement
all of this needs to be fast, in my case. Parameter changes can come in at
hundreds of times a second.



0
3/4/2008 12:47:45 AM
On Mar 4, 12:47 am, "Leslie Sanford" <jabberdab...@bitemehotmail.com>
wrote:
> "JOG" wrote:
>
> > This reminds me of a serious 'click' moment I had with data
> > structures. A long time ago, in a galaxy far far away, I once sat
> > blindly reinventing my own network model, with identifiers, pointers,
> > types, and all the fun of the fair. As an OO programmer it was the
> > only mindset I had. Then I considered encoding data similar to the
> > classic example of:
>
> > * Aristotle is a man
> > * All men are mortal
> > * |= Aristotle is mortal
>
> > Well, /clearly/ what I was dealing with here was a generic entity
> > class, of which Man was a subclass, and Aristotle an instance.
> > Something like:
>
> > class Entity
> > {
> > boolean mortal;
> > string name;
> > Entity(_name, _mortal) : name(_name), mortal(_mortal);
> > };
>
> > class Man : public Entity
> > {
> > date bday;
> > Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
> > };
>
> > But, as I extended the example, the structures got more convoluted,
> > and the result more and more of a mess. Finally something clicked. It
> > wasn't about types, objects or inheritance, it was about /inference/,
> > and what I actually had was:
>
> > Name(x, Aristotle) -> Species(x, Man)
> > Species(x, Man) -> Mortality(x, Mortal)
> > |= Name(x, Aristotle) -> Mortalilty(x, Mortal)
>
> > No types or reification in sight. Instead I had two groups of
> > statements:
> > People = {Name, Species, Bday}
> > Entities = {Species, Mortality}
>
> > A join of the two statements gave me the inference I required: {Name,
> > Mortality}. All of a sudden it seemed simple. So some questions:
>
> > 1) So why not treat all 'inheritance' in this way?
> > 2) Could one extend to include 'behaviour' as well?
> > 3) And is this a crazy thing to suggest in a cross post to an OO
> > group?
>
> I'm jumping in realizing that I may be revealing a bit of ignorance here, so
> bear with me.
>
> If I need to send a message to all persons who are mortal, I could join
> People and Entities together by species and where Mortality is true?
>
> Once I've performed the join, I then dispatch a message to the resulting
> group: "GetAnnualCheckUp()" or something?

Aye. Behaviour sits on top.

>
> In the application I'm currently writing, I have a large list of parameters.
> These parameters share some values such as Name and Label. However, there
> are different types of parameters such as those that represent a boolean
> state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square",
> etc., and other types. My current approach is traditional OO, and that's to
> have a hierarchy of Parameter classes. I can then keep a list of
> heterogeneous parameters and treat them polymorphically. For example:
>
> params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f);
> params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);
>
> // Set a parameter value. All raw parameter values are in the range
> // of [0, 1]. Each parameter class knows how to transform raw parameter
> // values in an appropriate way.
> params[parameterId].SetValue(value);
>
> And all works well.

If it works well don't touch it.

As if I need to tell you that.

>
> I'm trying to wrap my head around how I would approach this problem using
> what you've described above. I could have a table representing attributes
> common to all parameters. Then tables representing attributes specific to
> one parameter type or another. I could relate the tables via foreign keys?
> When I need to dispatch parameter changes, I could join the appropriate
> tables and change the appropriate values?

In your example all parameters had a name, and a value right? Well,
then you'd have a set of {paramName, value} tuples, where you could
update/insert values as necessary. (I'm assuming that we don't need
paramID and the paramName attribute uniquely identifies each
parameter).

In terms of other attributes recommended design would suggest a
relation for 'floatAttributes', and one for 'selectionAttibutes'. They
have different structures, and hence are collated under different
predicates (with just the paramName again in common and functioning as
a key). You'd join those to the values-relation as appropriate or
necessary via the paramName key.

I imagine that sounds wacky as hell if you are not used to a
relational approach, but there's no reason the functionality couldn't
be built into a programming language (as opposed to sitting in an
external db). As Codd showed in the 'great debate'  it'd certainly
simplify querying the data, compared to std::iterating like its 1999.

>
> I'm open to new ways of approaching things, but the mechanism to implement
> all of this needs to be fast, in my case. Parameter changes can come in at
> hundreds of times a second.

Well, I'm talking theoretically atm - I'd certainly not abandon
everything for mysql given your requirements...
0
jog (83)
3/4/2008 1:47:42 AM
On Mar 3, 11:52=A0am, JOG <j...@cs.nott.ac.uk> wrote:

> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means.

Yea, that will be the day. :-)

As I see it, the relational model deals with data, while the object
model deals with behavior. With the RM, data lies dormant unless it is
explicitly told to change state, and what state to change to. With OM,
an object is informed of the state of its environment and it changes
its state as *it* sees fit.

With the above two descriptions, the "impedance mismatch" can easily
be seen.


0
daniel_t (1960)
3/4/2008 2:00:48 AM

Leslie Sanford wrote:
> "JOG" wrote:

> I'm open to new ways of approaching things, but the mechanism to implement
> all of this needs to be fast, in my case. Parameter changes can come in at
> hundreds of times a second.

If the run-time performance needs to be predictable, then a RDBMS is
probably not the way to go. Garbage collection and index shifting/
restructuring may result in occasional pauses or slowdowns. Higher
abstraction often results in less predictable run-time performance.
(Less predictable and "slow" are not necessarily the same thing.)

-T-
0
topmind (2124)
3/4/2008 6:56:41 AM
On Mon, 3 Mar 2008 15:54:16 -0600, Robert Martin wrote:

> On 2008-03-03 11:36:50 -0600, "David Cressey" <cressey73@verizon.net> said:
> 
>> There is, however, a different level of abstraction where an RDB is
>> two-dimensional.  So Tom is not "wrong" all the way.  And it may be at that
>> level of abstraction where the OO RM impedance match comes about.
> 
> I don't know.  Computer memory is one-dimensional.

(I remotely remember some early works on associative memory. A spatial
memory would be very interesting to have.)

I think that probably more important was that an execution path is single
dimensional and that many algorithms require existence of an order (that
includes the algorithms used in RDBMS). The balance could change, for
example under super parallel architectures. In a molecular computer a CPU
might become cheaper than a memory cell...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/4/2008 8:45:11 AM
On Mon, 03 Mar 2008 19:02:40 -0400, Bob Badour wrote:

> One can represent any graph on two-dimensional media just as one can 
> represent any relation on two-dimensional media. In fact, since a graph 
> is merely a set of vertices and a set of directed edges and since one 
> can easily represent vertices and directed edges as tuples, one can 
> easily represent any graph using relations.

In fact graph *is* a binary relation over the set of nodes. The notation
used in graph theory is relational. For instance, edges are denoted as aGb.
G is the graph. So what?

That proves / refutes nothing. Observe that any program is an integer
number. This certainly should make integer arithmetic hugely useful in for
software design. Let Windows XP be n, then to n+m would be Vista, n/2 would
Windows ME...

Argumentation to Turing/other-completeness is a fallacy in software design
disciplines.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/4/2008 9:13:31 AM
On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:

> On 2008-03-03, Robert Martin <unclebob@objectmentor.com> wrote:
>>
>> There is indeed more to it than that.  OO and RDB are both strategies 
>> for partitioning data.

No. OO stands for modeling, that might include data being modeled or
serving as models. It also might mean absence of data. In short, data are
irrelevant.

>>  However, the motivation behind the partitioning 
>> is completely different.  OO partitions data based on the way a 
>> particular application will process that data.  RDBs partition data 
>> based on how many different applications will need to access that data.
> 
> No, RDBs partition data so that it is sensibly and easily available to
> any possible application. So if you use OO you are saying "there will
> never be any other application that will need my data". 

No, it is engineering which says so. It translates as "put the requirements
first," or simpler "pigs do not fly."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/4/2008 9:36:24 AM
On 4 mrt, 00:02, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> Roy Hann wrote:
> > "Thomas Gagne" <tga...@wide-open-west.com> wrote in message
> >news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d@wideopenwest.com...
>
> >>JOG wrote:
>
> >>>I wondered if we might be able to come up with some agreement on what
> >>>object-relational impedence mismatch actually means. I always thought
> >>>the mismatch was centred on the issue that a single object != single
> >>>tuple, but it appears there may be more to it than that.
>
> >>The issue as I've discovered it has to do with the fact OO systems are
> >>composed of graphs of data and RDBs are two-dimensional.
>
> That is a remarkably uninformed and ill-conceived sentence. It's rather
> like comparing boats and cars saying boats have hulls and cars are
> pretty. Regardless of truth, the comparison is pointless on its face.
>
> One can represent any graph on two-dimensional media just as one can
> represent any relation on two-dimensional media. In fact, since a graph
> is merely a set of vertices and a set of directed edges and since one
> can easily represent vertices and directed edges as tuples, one can
> easily represent any graph using relations.
>
> The Great Debate was had about 3 decades ago and graphs lost.

I beg to differ. What lost was the idea that a close coupling is
required between how the data is stored and how it is accessed /
queried, i.e., that in that sense you cannot have data independence.
But such data independence can be just as well achieved with graph-
based data models.

-- Jan Hidders
0
hidders (21)
3/4/2008 11:04:04 AM
Jan Hidders wrote:

> On 4 mrt, 00:02, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> 
>>Roy Hann wrote:
>>
>>>"Thomas Gagne" <tga...@wide-open-west.com> wrote in message
>>>news:7vqdnf21dLOnrVHanZ2dnUVZ_tuonZ2d@wideopenwest.com...
>>
>>>>JOG wrote:
>>
>>>>>I wondered if we might be able to come up with some agreement on what
>>>>>object-relational impedence mismatch actually means. I always thought
>>>>>the mismatch was centred on the issue that a single object != single
>>>>>tuple, but it appears there may be more to it than that.
>>
>>>>The issue as I've discovered it has to do with the fact OO systems are
>>>>composed of graphs of data and RDBs are two-dimensional.
>>
>>That is a remarkably uninformed and ill-conceived sentence. It's rather
>>like comparing boats and cars saying boats have hulls and cars are
>>pretty. Regardless of truth, the comparison is pointless on its face.
>>
>>One can represent any graph on two-dimensional media just as one can
>>represent any relation on two-dimensional media. In fact, since a graph
>>is merely a set of vertices and a set of directed edges and since one
>>can easily represent vertices and directed edges as tuples, one can
>>easily represent any graph using relations.
>>
>>The Great Debate was had about 3 decades ago and graphs lost.
> 
> I beg to differ. What lost was the idea that a close coupling is
> required between how the data is stored and how it is accessed /
> queried, i.e., that in that sense you cannot have data independence.
> But such data independence can be just as well achieved with graph-
> based data models.
> 
> -- Jan Hidders

Well, I have yet to see it. Until I see any real evidence of a 
graph-based data model with physical data independence, we will just 
have to disagree.
0
bbadour (434)
3/4/2008 2:20:07 PM
On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>
>> On 2008-03-03, Robert Martin <unclebob@objectmentor.com> wrote:
>>>
>>> There is indeed more to it than that.  OO and RDB are both strategies 
>>> for partitioning data.
>
> No. OO stands for modeling, that might include data being modeled or
> serving as models. It also might mean absence of data. In short, data are
> irrelevant.
>
>>>  However, the motivation behind the partitioning 
>>> is completely different.  OO partitions data based on the way a 
>>> particular application will process that data.  RDBs partition data 
>>> based on how many different applications will need to access that data.
>> 
>> No, RDBs partition data so that it is sensibly and easily available to
>> any possible application. So if you use OO you are saying "there will
>> never be any other application that will need my data". 
>
> No, it is engineering which says so. It translates as "put the requirements
> first," or simpler "pigs do not fly."
>

So no-one ever says "we should be able to get that stuff out of the xyz
application and combine it with our data so that we can..."!

E
0
eric154 (81)
3/4/2008 3:41:40 PM
On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:

> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>
>>> No, RDBs partition data so that it is sensibly and easily available to
>>> any possible application. So if you use OO you are saying "there will
>>> never be any other application that will need my data". 
>>
>> No, it is engineering which says so. It translates as "put the requirements
>> first," or simpler "pigs do not fly."
> 
> So no-one ever says "we should be able to get that stuff out of the xyz
> application and combine it with our data so that we can..."!

You should plan this use case in advance. That would be a requirement. A
system can only do things it was designed for. (This applies to RDBMS as
well). For each application exist things it cannot do. That implies: either
A) there will never be any other application that will ask to do these, or
B) the application is incorrect (= does not fulfill the requirements).

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/4/2008 4:36:24 PM
On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>
>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>
>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>> any possible application. So if you use OO you are saying "there will
>>>> never be any other application that will need my data". 
>>>
>>> No, it is engineering which says so. It translates as "put the requirements
>>> first," or simpler "pigs do not fly."
>> 
>> So no-one ever says "we should be able to get that stuff out of the xyz
>> application and combine it with our data so that we can..."!
>
> You should plan this use case in advance. That would be a requirement. A
> system can only do things it was designed for. (This applies to RDBMS as
> well). For each application exist things it cannot do. That implies: either
> A) there will never be any other application that will ask to do these, or
> B) the application is incorrect (= does not fulfill the requirements).
>

So you will always know, in advance, what all the possible future
applications will want! I hope you are not crazy enough to believe that.
So you are left with minimising "things it cannot do". I guess that
means you should have something which can make the data available to any
application that asks, according to any logically possible criterion.
Did you know that this is what an RDBMS does?

Perhaps not, since you have also said that "data are irrelevant".

E
0
eric154 (81)
3/4/2008 5:58:02 PM
Responding to JOG...

>> All attempts by applications to access a DB's tables and columns
>> directly violates design principles that guard against close-coupling.
>> This is a basic design tenet for OO.  Violating it when jumping from OO
>> to RDB is, I think, the source of problem that are collectively and
>> popularly referred to as the object-relational impedance mismatch.
> 
> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means. I always thought
> the mismatch was centred on the issue that a single object != single
> tuple, but it appears there may be more to it than that.

First, I think it is important to clarify that the 'relational' in the 
mismatch isn't referring to the fact that the OO paradigm uses something 
other than set theory's relational model. The nature of the impedance 
mismatch lies in the way the OO and RDB paradigms implement the same 
relational model.

I think the lack of 1:1 tuple mapping is just a symptom of the mismatch. 
There are several contributors to the mismatch...

Applications (not just OO) are designed to solve specific problems so 
they are highly tailored to the particular problem in hand. In contrast, 
databases are designed to provide ad hoc, generic access to data that is 
independent of particular problem contexts. If one had to choose a 
single characterization of the mismatch, this would be it; everything 
else stems from it.

Object properties include behavior. Behaviors interact in much more 
complex ways than data. Managing behaviors is the primary cause of 
failing to map 1:1 between OO Class Diagrams and Data Models of the same 
subject matter. That's because managing behavior places additional 
constraints on the way the software is constructed.

OO relationships are instantiated at the object (tuple) level rather 
than the class (table) level. This allows much better tailoring of 
optimization to the problem in hand. It also focuses on capturing 
business rules and policies in the way relationships are instantiated. 
That, in turn, emphasizes preselecting sets of entities before they are 
actually accessed. Thus query-like searches for object collaborations 
are relatively rare in well-formed OO applications.

Corollary: the OO paradigm navigates relationship paths consisting of 
individual binary associations and sequentially processes object sets 
resulting from such navigation. Thus there is no direct equivalent of an 
RDB join in OOPL or AAL syntax. (One can argue that the query/join 
approach is less tedious, but the OO paradigm has additional goals to 
satisfy, such as limiting access to knowledge.)

Object identity is usually not explicitly embedded as an attribute of 
the object; OO applications are designed around address-based identity 
in computer memory. This profoundly changes the way one manages 
referential integrity. Thus OO developers will avoid class-level 
identity searches whenever possible.

The relations in OO generalizations cannot be instantiated separately; a 
single tuple resolves the entire generalization. This is the one 
situation where a Class Model and a Data Model can never map 1:1. The 
reason lies in the OO paradigm's support of polymorphism.

> I was hoping perhaps people might be able to offer perspectives on the
> issues that they have encountered.  One thing I would like to avoid
> (outside of almost flames of course), is the notion that database
> technology is merely a persistence layer (do people still actually
> think that?) - I wonder if the 'mismatch' stems from such a
> perspective.

The short answer is that any OO application developer sees the DBMS as 
an implementation of a persistence layer.

I think it is important to distinguish between pure persistence in the 
form of an RDB and a bundle of specialized server-side applications that 
are layered on top of an RDB and form a DBMS. Some CRUD/USER processing 
can be quite complex, such as data mining, but from the end customer's 
perspective all the server-side applications are providing is data 
access and formatting.

Similarly, it is important to distinguish between CRUD/USER processing 
and other problems. In CRUD/USER processing the only problems being 
solved for the customer are data entry, data selection, and conversion 
to a convenient display representation. The RAD IDEs and layered model 
infrastructures already handle that sort of processing quite well (e.g., 
it is no accident that they employ form-based UIs that conveniently map 
into RDB tables) and applying OO development there would be largely 
redundant.

Thus OO developers always believe that a database is a persistence 
mechanism because they deal with problems outside CRUD/USER processing. 
IOW, the OO application's solution *starts* with accessing data from a 
persistent store and *ends* with shipping results off for display 
rendering. That problem solution doesn't care what kind of data access 
services the DBMS may provide; it just wants to access and store 
particular piles of data. Similarly, it doesn't care whether user 
communications are via GUI, web browser, or heliograph.

To put it more bluntly, from the OO application's solution perspective, 
the developer couldn't care less that the data was mined from multiple 
sources using exotic algorithms or whether it is stored in an RDB, an 
OODB, flat files, or on clay tablets. At the level of abstraction of the 
OO problem solution, only two services are required: "Save this pile of 
data I call 'X'" and "Give me the pile of data I call 'X'". Thus the 
entire interface for accessing persistence from an OO application's 
problem solution is typically just three messages of the form {message 
ID, [data packet]} that might look something like:

{SAVE_DATA, data ID, dataset} // to persistence

{GET_DATA, data ID} // to persistence

{HERE_IS_DATA, data ID, dataset}  // response from persistence

The application solution will provide its own unique encode/decode of 
the message data packets into its objects and their attributes that is 
completely independent of the persistence schemas, etc..
Bottom line: the DBMS may provide all sorts of elegant CRUD/USER access 
services but the OO application doesn't care about that; that belongs to 
a different trade union.

<aside>
As a practical matter, the client-side does care because somehow those 
messages need to be mapped into the server-side DBMS services (e.g., 
creating SQL queries, performance caching, and optimizing joins for the 
DBMS). But to do that one only needs to provide the mapping once in a 
subsystem that is reusable by any application that accesses that DBMS. 
Typically that subsystem would be designed and implemented by someone 
who has specialized DBA skills to utilize the DBMS services in an 
appropriately clever fashion. IOW, the subsystem represents a 
fundamental separation of concerns from the specific problem solution by 
isolating and encapsulating specific mechanisms and optimizations 
related to persistence access.

Note that when developing large OO applications, one does this sort of 
subsystem encapsulation for *all* subsystems within the application; UI 
and DB subsystems just happen to be ubiquitous concerns. One does OO 
development because one wants maintainable applications. Hence 
separation of concerns and encapsulation at the subsystem level is 
critically important for decoupling implementations in different parts 
of the application.
</aside>



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

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development".  Email
info@pathfindermda.com for your copy.
Pathfinder is hiring: 
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
0
hsl (257)
3/4/2008 7:14:48 PM
On Tue, 4 Mar 2008 17:58:02 +0000, Eric wrote:

> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>
>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>>
>>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>>> any possible application. So if you use OO you are saying "there will
>>>>> never be any other application that will need my data". 
>>>>
>>>> No, it is engineering which says so. It translates as "put the requirements
>>>> first," or simpler "pigs do not fly."
>>> 
>>> So no-one ever says "we should be able to get that stuff out of the xyz
>>> application and combine it with our data so that we can..."!
>>
>> You should plan this use case in advance. That would be a requirement. A
>> system can only do things it was designed for. (This applies to RDBMS as
>> well). For each application exist things it cannot do. That implies: either
>> A) there will never be any other application that will ask to do these, or
>> B) the application is incorrect (= does not fulfill the requirements).
>>
> So you will always know, in advance, what all the possible future
> applications will want! I hope you are not crazy enough to believe that.

No, I am. When I am looking for a solution I have to know what is the
problem. Is that crazy? Further, dealing with a generalized problem I shall
consider what would be the consequences of such generalization. There is
always a price to pay. You certainly have heard about computability, NP
problems and such stuff. But just going from 1ms to 100�s makes a huge
difference.

> So you are left with minimising "things it cannot do". I guess that
> means you should have something which can make the data available to any
> application that asks, according to any logically possible criterion.
> Did you know that this is what an RDBMS does?

No it does not, when "asking" is defined as diffuse as in the natural
language. There exist certain limitations on what and how can be asked.
These limitations should be specified as functional and non-functional
requirements. If you prefer to buy a cat in the bag named RDBMS (or
whatever), that's up to you. I merely state that there is always something
in any bag. As for the bag RDBMS, among the thing it contains are
object-relational impedance, SQL, poor performance, unpredictable behavior,
maintenance costs, etc.

> Perhaps not, since you have also said that "data are irrelevant".

Yes, I did. I am working mainly in the area of industrial data acquisition
and control. It might sound funny, but being so close to "data" one starts
to better understand why data are irrelevant.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/4/2008 7:22:03 PM
"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
news:4bza4t1lmhj9.1734ger7g3zac$.dlg@40tude.net...
> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>
> > On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
> >>
> >>> No, RDBs partition data so that it is sensibly and easily available to
> >>> any possible application. So if you use OO you are saying "there will
> >>> never be any other application that will need my data".
> >>
> >> No, it is engineering which says so. It translates as "put the
requirements
> >> first," or simpler "pigs do not fly."
> >
> > So no-one ever says "we should be able to get that stuff out of the xyz
> > application and combine it with our data so that we can..."!
>
> You should plan this use case in advance. That would be a requirement. A
> system can only do things it was designed for. (This applies to RDBMS as
> well). For each application exist things it cannot do. That implies:
either
> A) there will never be any other application that will ask to do these, or
> B) the application is incorrect (= does not fulfill the requirements).
>

This is true for an RDBMS.  But more to the point,  can a relational (or
SQL) database be designed in such a way that it has moderately good support
for thousands of anticipated queries,  of which only a few dozen will
actually come to be used ?  And will those few dozens of uses provide the
appropriate payback on the investment in building the database?


Based on my experience with databases,  I offer the firm opinion that the
answer is yes.




0
cressey73 (124)
3/4/2008 7:45:30 PM
On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 4 Mar 2008 17:58:02 +0000, Eric wrote:
>
>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>>
>>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>>>
>>>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>>>> any possible application. So if you use OO you are saying "there will
>>>>>> never be any other application that will need my data". 
>>>>>
>>>>> No, it is engineering which says so. It translates as "put the requirements
>>>>> first," or simpler "pigs do not fly."
>>>> 
>>>> So no-one ever says "we should be able to get that stuff out of the xyz
>>>> application and combine it with our data so that we can..."!
>>>
>>> You should plan this use case in advance. That would be a requirement. A
>>> system can only do things it was designed for. (This applies to RDBMS as
>>> well). For each application exist things it cannot do. That implies: either
>>> A) there will never be any other application that will ask to do these, or
>>> B) the application is incorrect (= does not fulfill the requirements).
>>>
>> So you will always know, in advance, what all the possible future
>> applications will want! I hope you are not crazy enough to believe that.
>
> No, I am. When I am looking for a solution I have to know what is the
> problem. Is that crazy? Further, dealing with a generalized problem I shall
> consider what would be the consequences of such generalization. There is
> always a price to pay. You certainly have heard about computability, NP
> problems and such stuff. But just going from 1ms to 100�s makes a huge
> difference.

Everything has a price. You have to choose. What I see is someone taking
only the short-term view.

>
>> So you are left with minimising "things it cannot do". I guess that
>> means you should have something which can make the data available to any
>> application that asks, according to any logically possible criterion.
>> Did you know that this is what an RDBMS does?
>
> No it does not, when "asking" is defined as diffuse as in the natural
> language. There exist certain limitations on what and how can be asked.

That's what I said - logically possible criteria.

> These limitations should be specified as functional and non-functional
> requirements.

If possible. What I meant was that you should minimise the limitations
on both the expected and the unknown futures.

> If you prefer to buy a cat in the bag named RDBMS (or
> whatever), that's up to you. I merely state that there is always something
> in any bag.

Cat? What cat? But actually, see what I said above about price.

> As for the bag RDBMS, among the thing it contains are
> object-relational impedance,

You made this one up because you don't understand.

> SQL,

OK, it's not the perfect language, but what is? And it is possible to
have an RDBMS that doesn't use it.

> poor performance,

Relative to what? Where are the tests? Do you install an RDBMS product
and just go with whatever myths you have heard lately, or do you get a
product specialist to sort it out?

> unpredictable behavior,

Please explain. Unless you're talking about bugs, but everything has
those.

> maintenance costs,

Everything has those too. Again, I have to assume that you take only the
short-term view.

> etc.

What else would you like to make up?

>
>> Perhaps not, since you have also said that "data are irrelevant".
>
> Yes, I did. I am working mainly in the area of industrial data acquisition
> and control. It might sound funny, but being so close to "data" one starts
> to better understand why data are irrelevant.
>

Aha! Your data is transient, and what you are mostly doing is
transforming it. I at least have no problem with using OO programming
for that. Also, that explains your short-term view. But what do you do
with the data (presumably transformed) that does get kept for longer?
Put it somewhere that will be available for a variety of expected and
unexpected uses? But we were here before!

E
0
eric154 (81)
3/4/2008 8:26:01 PM
On Tue, 04 Mar 2008 19:45:30 GMT, David Cressey wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
> news:4bza4t1lmhj9.1734ger7g3zac$.dlg@40tude.net...
>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>
>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>>
>>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>>> any possible application. So if you use OO you are saying "there will
>>>>> never be any other application that will need my data".
>>>>
>>>> No, it is engineering which says so. It translates as "put the requirements
>>>> first," or simpler "pigs do not fly."
>>>
>>> So no-one ever says "we should be able to get that stuff out of the xyz
>>> application and combine it with our data so that we can..."!
>>
>> You should plan this use case in advance. That would be a requirement. A
>> system can only do things it was designed for. (This applies to RDBMS as
>> well). For each application exist things it cannot do. That implies: either
>> A) there will never be any other application that will ask to do these, or
>> B) the application is incorrect (= does not fulfill the requirements).
>>
> 
> This is true for an RDBMS.  But more to the point,  can a relational (or
> SQL) database be designed in such a way that it has moderately good support
> for thousands of anticipated queries,  of which only a few dozen will
> actually come to be used ?  And will those few dozens of uses provide the
> appropriate payback on the investment in building the database?

> Based on my experience with databases,  I offer the firm opinion that the
> answer is yes.

That's OK to me. But the question, as I understood it, was about
qualitative design changes. My point was that there is always a presumption
of the nature of changes which can and of those that cannot happen. A
design is good when this presumption matches the reality. From this point
of view there is no difference between deployment of OO or RDB solutions.
As engineering both would solve some class of problems and anticipate
quantitative changes of certain kind, but not qualitative ones.

When I read what Eric wrote, that made me think that he believed that RDB
would solve all problems and thus anticipate any changes. This would be
obviously wrong. I guess that his hidden argument was "because RDB
apparently solves all problems, then data-centric view is the right one."
Yet another logical fallacy was a data-centric problem statement: "there
will never be any other application that will need my data," used in order
to prove data-centric view itself. In OO problems are not modeled in terms
of applications using data. This alone does not yet imply anything about
the problems being solved. Actually we all are solving similar problems,
otherwise there would be no such quarrel between us.

P.S. OO is especially focused on maintenance. H.S. Lahman already wrote
about it in another post, so I need not to repeat it here.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/4/2008 8:44:56 PM
"H. S. Lahman" <hsl@pathfindermda.com> writes:

> First, I think it is important to clarify that the 'relational' in
> the mismatch isn't referring to the fact that the OO paradigm uses
> something other than set theory's relational model. The nature of
> the impedance mismatch lies in the way the OO and RDB paradigms
> implement the same relational model.

Huh? I know of the lambda calculus as a foundation of functional
languages and the relation model as foundation of RDBs. But I wonder
what the formal foundations of the OO family of languages is
(references, please).

As far as I understand those matters I would say the relational model
is more abstract than the OO model (only the most common language use
for the relational model, SQL, is... improvable).

-- 
Stefan.
0
snobis (121)
3/4/2008 9:43:23 PM
On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:

> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Tue, 4 Mar 2008 17:58:02 +0000, Eric wrote:
>>
>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On Tue, 4 Mar 2008 15:41:40 +0000, Eric wrote:
>>>>
>>>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>>>> On Mon, 3 Mar 2008 23:03:41 +0000, Eric wrote:
>>>>>>
>>>>>>> No, RDBs partition data so that it is sensibly and easily available to
>>>>>>> any possible application. So if you use OO you are saying "there will
>>>>>>> never be any other application that will need my data". 
>>>>>>
>>>>>> No, it is engineering which says so. It translates as "put the requirements
>>>>>> first," or simpler "pigs do not fly."
>>>>> 
>>>>> So no-one ever says "we should be able to get that stuff out of the xyz
>>>>> application and combine it with our data so that we can..."!
>>>>
>>>> You should plan this use case in advance. That would be a requirement. A
>>>> system can only do things it was designed for. (This applies to RDBMS as
>>>> well). For each application exist things it cannot do. That implies: either
>>>> A) there will never be any other application that will ask to do these, or
>>>> B) the application is incorrect (= does not fulfill the requirements).
>>>>
>>> So you will always know, in advance, what all the possible future
>>> applications will want! I hope you are not crazy enough to believe that.
>>
>> No, I am. When I am looking for a solution I have to know what is the
>> problem. Is that crazy? Further, dealing with a generalized problem I shall
>> consider what would be the consequences of such generalization. There is
>> always a price to pay. You certainly have heard about computability, NP
>> problems and such stuff. But just going from 1ms to 100�s makes a huge
>> difference.
> 
> Everything has a price. You have to choose. What I see is someone taking
> only the short-term view.

Huh, now after all these cries that DB is not about persistency... What
makes a temporal aspect so relevant then?

>>> So you are left with minimising "things it cannot do". I guess that
>>> means you should have something which can make the data available to any
>>> application that asks, according to any logically possible criterion.
>>> Did you know that this is what an RDBMS does?
>>
>> No it does not, when "asking" is defined as diffuse as in the natural
>> language. There exist certain limitations on what and how can be asked.
> 
> That's what I said - logically possible criteria.

What about things which cannot be spelt in SQL? What about response times?
Can you specify/guess an upper bound for all requests? For a certain subset
of?

>> These limitations should be specified as functional and non-functional
>> requirements.
> 
> If possible. What I meant was that you should minimise the limitations
> on both the expected and the unknown futures.

No optimum exists under these conditions.

>> If you prefer to buy a cat in the bag named RDBMS (or
>> whatever), that's up to you. I merely state that there is always something
>> in any bag.
> 
> Cat? What cat? But actually, see what I said above about price.

You said that the price has to be paid. Right, but the question is about
performance/price ratio. You can buy a bigger car, but it would require
more gasoline and it would be more difficult to park. Software developing
is an expensive thing.

>> As for the bag RDBMS, among the thing it contains are
>> object-relational impedance,
> 
> You made this one up because you don't understand.

What didn't I? That impedance exists or that it does not?

>> SQL,
> 
> OK, it's not the perfect language, but what is? And it is possible to
> have an RDBMS that doesn't use it.
> 
>> poor performance,
> 
> Relative to what? Where are the tests? Do you install an RDBMS product
> and just go with whatever myths you have heard lately, or do you get a
> product specialist to sort it out?

Come on, show me the nearest neighbour search in ten-dimensional space
implemented in RDBMS. What would be the complexity of? You should clearly
understand that it is possible to break the neck of *any* indexing method.
This refutes the argument to "any logically possible criterion.".

>> unpredictable behavior,
> 
> Please explain. Unless you're talking about bugs, but everything has
> those.

And what are the means available in order to prevent bugs? How much RDBMS
support static analysis? SQL is practically untyped. Design by contract,
how? Code reuse is close to none, well, code is evil, why should we reuse
it? Upper bounds for memory footprint? For response times?

>> maintenance costs,
> 
> Everything has those too. Again, I have to assume that you take only the
> short-term view.

No,I mean long-term maintenance costs.

>> etc.
> 
> What else would you like to make up?

Actually I don't want to concentrate on critique of RDBMS. It is a hardware
to me. I would buy one in case I needed it.

My objective is rather data-centric view. Which is IMO the reason for
object-relational impedance. BTW, I see nothing wrong in RA, which has in
my view fully independent on the notion of data. RA would nicely fit into
OO as a set of types with corresponding operations.

>>> Perhaps not, since you have also said that "data are irrelevant".
>>
>> Yes, I did. I am working mainly in the area of industrial data acquisition
>> and control. It might sound funny, but being so close to "data" one starts
>> to better understand why data are irrelevant.
> 
> Aha! Your data is transient, and what you are mostly doing is
> transforming it.

Well, one viewed it this way in 50-60s, I guess. But it is a long time
since one dropped this data-centric view on the system as a huge signal
filter. This model does not scale and is inadequate (event controlled and
non-numeric things, GUI etc).

> I at least have no problem with using OO programming
> for that. Also, that explains your short-term view. But what do you do
> with the data (presumably transformed) that does get kept for longer?
> Put it somewhere that will be available for a variety of expected and
> unexpected uses? But we were here before!

Yes, here we go again. Data are meaningless if usage is unexpected. Nobody
can use a CD-ROM in a wind-up phonograph, deaf people notably.

The system does not keep anything it exists and behaves. Deployment of DB
there is always problematic. There are much ongoing efforts in this area in
recent years, mainly to standardize the schemas. That is not enough,
because relational model does not fit. Channels are largely event
controlled with time stamps. So you cannot make any reasonable relations
beyond (time, value) without data corruption. The queries would be like
"give me the oil temperature profile when the velocity was out of range for
longer than 10s before the event E." You need various interpolation
methods, calculated channels and ones simulated from previously recorded
measurements. Channels are created and destroyed, their properties change.
The end effect is that when DBs are used then only marginally. I remember
an amusing customer requirement: "we want to be able to run our tests even
if the DB server is off-line." (:-))

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/4/2008 10:19:42 PM
On Mar 3, 3:11=A0pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-03 12:29:02 -0600, TroyK <cs_tr...@juno.com> said:
>
> > My experience is somewhere between 2 and 3 orders of magnitude
> > difference between implementing a business rules change in the db vs.
> > the programming team doing it in OO code.
>
> Then you should be able to fly rings around the programmers and get
> them all fired. =A0Why haven't you?

If by "fly rings around the programmers" you mean having a fully
functioning reference implementation up and running in SQL within 2
weeks that ends up taking a team of 3 programmers over 3 months to
implement in code, then, yeah, I guess I do. But the architecture
called for the programming to be done in a business layer implemented
in C# -- we expected and planned for that, so, happily, no one gets
fired.


> Ladies and gentlemen, there are certainly tasks that are better suited
> to SQL and stored procedures. =A0There are other tasks that are better

Who said anything about stored procedures? I'm talking about
implementing the business rules via constraint declaration in the
database, and deriving new values throught the application of SQL
queries.

> suited to general purpose languages. =A0True wisdom comes from knowing
> the strengths and weaknesses of both. =A0Good architects build systems
> that combine the tools synergistically.

And good agile programmers know to use a high-level language in order
to enable iterating over design at a rapid pace.


TroyK
0
cs_troyk (11)
3/4/2008 11:29:01 PM
Stefan Nobis <snobis@gmx.de> writes:
>But I wonder what the formal foundations
>of the OO family of languages is

  �The formal foundation of a family of languages� is not a
  well-specified term. What is a �formal foundation�?

  The syntax and semantics of any specific object-oriented
  language is given in the specification of that language.

  But I do not know when you will deem a specification to be
  �formal� or a �formal foundation�.

0
ram (2986)
3/4/2008 11:39:43 PM
On Mar 4, 3:39 pm, r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Stefan Nobis <sno...@gmx.de> writes:
> >But I wonder what the formal foundations
> >of the OO family of languages is
>
>   =BBThe formal foundation of a family of languages=AB is not a
>   well-specified term. What is a =BBformal foundation=AB?
>   The syntax and semantics of any specific object-oriented
>   language is given in the specification of that language.

If it has one. And even if it has a spec, is it formal spec,
or a prose spec? The Java spec for example is not formal.
Still, that's better than you get from most. With many
languages the "spec" is the reference implementation.


>   But I do not know when you will deem a specification to be
>   =BBformal=AB or a =BBformal foundation=AB.

Start here:

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


Marshall
0
3/5/2008 12:11:43 AM
On 2008-03-03 16:49:29 -0600, "David Cressey" <cressey73@verizon.net> said:

> It doesn't seem as
> straightforward to me to extend a language like C++ so that it becomes
> suitable for declaring relational transformations on data.  If it is
> straight forward, then I'd like to hear from people who are doing it.

Take a look at LINQ.

-- 
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)
3/5/2008 6:45:54 AM
On 2008-03-03 16:49:29 -0600, "David Cressey" <cressey73@verizon.net> said:

> But the idea of a single language that is suitable for everything remains an
> elusive goal,  and probably an unproductive endeavor.

Agreed.

-- 
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)
3/5/2008 6:46:14 AM
On 2008-03-03 16:28:46 -0600, "David Cressey" <cressey73@verizon.net> said:

> 
> "Roy Hann" <specially@processed.almost.meat> wrote in message
> news:nfWdnW05its1o1HanZ2dnUVZ8t2snZ2d@pipex.net...
> 
> 
>> Until I know their reasons for their views on data structures I couldn't
>> say.  However I notice that I am surrounded by programmers who consume
> most
>> the development budget writing code, and when a change request comes along
> I
>> can accommodate it in the database in minutes and they spend months
> spewing
>> out more code (sometimes after doing an extensive and expensive impact
>> assessment).  Code may not be evil, but it sure has a case to answer.
> 
> I have to agree with this comment, based on my own experience.

OK, then I'll ask you the same question I asked Roy.  If you *could 
have* done it in minutes, why didn't you?

-- 
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)
3/5/2008 6:48:31 AM
On 2008-03-03 17:25:48 -0600, topmind <topmind@technologist.com> said:

> But I think anybody inspecting both examples will clearly see that my
> version is a lot less total code.

C++ is a pretty wordy language.  If I wrote it in Ruby I bet I'd beat 
you by a wide margin.
-- 
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)
3/5/2008 6:52:33 AM
On 2008-03-03 17:06:05 -0600, JOG <jog@cs.nott.ac.uk> said:

> A join of the two statements gave me the inference I required: {Name,
> Mortality}. All of a sudden it seemed simple.

Interesting story.  Yes, when you have a problem of inference, it's 
good to use an inference engine.

> So some questions:
> 
> 1) So why not treat all 'inheritance' in this way?

Because all inheritance is not about inference.

> 2) Could one extend to include 'behaviour' as well?

Yes.  See the Prolog language.

> 3) And is this a crazy thing to suggest in a cross post to an OO
> group?

I've seen a lot crazier things.

-- 
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)
3/5/2008 6:57:34 AM
On 2008-03-03 18:24:33 -0600, Marshall <marshall.spight@gmail.com> said:

> One's requirements dictate data with certain functional dependencies.
> Among the easiest tasks in application design is one of the earliest:
> structuring the data. The RM structures data as relations. Relational
> structures lack query bias, which is one of the reasons why SQL
> is so good at ad hoc queries (compared to the other choices.)
> OO structures mandates an object structure (unsurprisingly): out the
> gate, one has no choice but to build in a query bias, whether
> one wants it or not.

Agreed.  That "bias" can work very well if you only use the biased 
queries.  That works well in the context of a single application, or a 
single piece of an application.  It does not work well in the general 
case, which is why OODBs never quite took off.
> 
> Furthermore, since OOPLs lack physical independence, traversing
> the graph may be quite expensive, particularly in the case where
> the graph is backed by storage in a database, which is part of
> why ORM is such a universally bad idea.

No, you have this wrong.  ORMs generally use standard SQL queries to 
traverse and gather data from the DB.  Then that data is placed into OO 
structures so that the application can take advanage of the bias.

-- 
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)
3/5/2008 7:05:30 AM
On 2008-03-03 16:31:43 -0600, "David Cressey" <cressey73@verizon.net> said:

> 
> "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> news:47cc383f$0$4041$9a566e8b@news.aliant.net...
> 
> 
>> It's pretty obvious to me: object-relational mismatch is to relations as
>> assembler-object mismatch is to objects.
> 
> I didn't get this comment.  Now that someone else flagged it as a
> keeper, I feel the need to ask for an explanation.

Explanation:  "WAA WAA WAA WAA WAA WAA".  (The sound made by the adults 
in the Peanuts cartoons).


-- 
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)
3/5/2008 7:08:21 AM
On 2008-03-03 18:34:39 -0600, Marshall <marshall.spight@gmail.com> said:

> In SQL, if I have two relations with x and y int columns, I can
> union them, or join on them, or whatever. There is no way,
> in fact, to forbid such a thing, just like in Java there is no way
> to allow such a thing.

You are confusing OO with static typing.  In OO languages like Ruby, 
Python, or Smalltalk you can pass any object to any function 
irrespective of type.
-- 
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)
3/5/2008 7:10:01 AM
On Wed, 5 Mar 2008 00:46:14 -0600, Robert Martin wrote:

> On 2008-03-03 16:49:29 -0600, "David Cressey" <cressey73@verizon.net> said:
> 
>> But the idea of a single language that is suitable for everything remains an
>> elusive goal,  and probably an unproductive endeavor.
> 
> Agreed.

Disagreed.

The idea of multilingual system is the most damaging thing in software
developing history. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2008 8:56:02 AM
On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:

> On 2008-03-03 18:34:39 -0600, Marshall <marshall.spight@gmail.com> said:
> 
>> In SQL, if I have two relations with x and y int columns, I can
>> union them, or join on them, or whatever. There is no way,
>> in fact, to forbid such a thing, just like in Java there is no way
>> to allow such a thing.
> 
> You are confusing OO with static typing.  In OO languages like Ruby, 
> Python, or Smalltalk you can pass any object to any function 
> irrespective of type.

Which is a bad idea.

Nevertheless you don't need dynamic typing in order to deal with that. You
could have a class of relations in order to define operations (like join)
on them. That will give a static type to the result of any join.

The problem is elsewhere. How do I know in *advance* that the result of
join is a relation of certain narrower kind? Both "statically untyped" SQL
and "dynamically untyped" fancy languages have no answer to that until run
time. Note that this is a software design issue.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2008 9:13:59 AM
Stefan Nobis wrote:

> "H. S. Lahman" <hsl@pathfindermda.com> writes:

>>First, I think it is important to clarify that the 'relational' in
>>the mismatch isn't referring to the fact that the OO paradigm uses
>>something other than set theory's relational model. The nature of
>>the impedance mismatch lies in the way the OO and RDB paradigms
>>implement the same relational model.

> Huh? I know of the lambda calculus as a foundation of functional
> languages and the relation model as foundation of RDBs. But I wonder
> what the formal foundations of the OO family of languages is
> (references, please).

1. The prog lang (Simula) came first, not the formalisms.
Which then inspired +/- aligned with other notions (ADTs etc) that
were present/emerging in the CS community at that time.

2. The closest basic formalism that OO could be mapped to is ADTs.
ADT theory uses a number of formalisms (algebraic specification,
type theories etc) to define the behaviour of ADTs.

But these formalisms use the same 'language' (propositional/predicate
logic, set theory etc) as the Relational model.


> As far as I understand those matters I would say the relational model
> is more abstract than the OO model

The ADT formalisms suggest otherwise.


> (only the most common language use for the relational model, SQL, is... improvable).

Indeed.


Regards,
Steven Perryman
0
S
3/5/2008 9:21:23 AM
Robert Martin wrote:

> On 2008-03-03 18:34:39 -0600, Marshall <marshall.spight@gmail.com> said:

>> In SQL, if I have two relations with x and y int columns, I can
>> union them, or join on them, or whatever. There is no way,
>> in fact, to forbid such a thing, just like in Java there is no way
>> to allow such a thing.

> You are confusing OO with static typing. In OO languages like Ruby, 
> Python, or Smalltalk you can pass any object to any function 
> irrespective of type.

And you (both) are equating the (strong) typing model of Simula as the
only strong typing model. Go and look at Functional prog langs etc for
examples of how Marshalls' gripe would be done in a type-safe manner.


Regards,
Steven Perryman
0
S
3/5/2008 9:24:37 AM
On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 04 Mar 2008 19:45:30 GMT, David Cressey wrote:
>
 <snip>
>> 
>> This is true for an RDBMS.  But more to the point,  can a relational (or
>> SQL) database be designed in such a way that it has moderately good support
>> for thousands of anticipated queries,  of which only a few dozen will
>> actually come to be used ?  And will those few dozens of uses provide the
>> appropriate payback on the investment in building the database?
>
>> Based on my experience with databases,  I offer the firm opinion that the
>> answer is yes.
>
> That's OK to me.

Good.

> But the question, as I understood it, was about
> qualitative design changes. My point was that there is always a presumption
> of the nature of changes which can and of those that cannot happen. A
> design is good when this presumption matches the reality. From this point
> of view there is no difference between deployment of OO or RDB solutions.
> As engineering both would solve some class of problems and anticipate
> quantitative changes of certain kind, but not qualitative ones.
>
> When I read what Eric wrote, that made me think that he believed that RDB
> would solve all problems and thus anticipate any changes. This would be
> obviously wrong.

I don't believe that merely using an RDBMS will solve all problems. What
I meant was that, accepting what David said above, if you keep your data
in an RDBMS, it will be easily available for the solution of any
possible problem that can be solved using that data.

> I guess that his hidden argument was "because RDB
> apparently solves all problems, then data-centric view is the right one."

No, the argument is that the data-centric view is often (not necessarily
always) the right one to take, and that keeping the data in an RDBMS
provides a better basis for solving future problems using the data than
any other way of keeping it.

> Yet another logical fallacy was a data-centric problem statement: "there
> will never be any other application that will need my data," used in order
> to prove data-centric view itself.

There is no fallacy here. First there is a fact - you have data, however
you choose to view it. Do you want to deny this? If you do we may need
to sort out the meaning of the word "data". Given this fact, I am saying
that you can not guarantee that there will be no other uses for your
data, so you must keep open a way for those other uses to see your data.

> In OO problems are not modeled in terms
> of applications using data.

No, but the data is still there.

> This alone does not yet imply anything about
> the problems being solved. Actually we all are solving similar problems,
> otherwise there would be no such quarrel between us.
>
> P.S. OO is especially focused on maintenance. H.S. Lahman already wrote
> about it in another post, so I need not to repeat it here.
>

E
0
eric154 (81)
3/5/2008 11:34:05 AM
On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:
>

 <snip>

>> 
>> That's what I said - logically possible criteria.
>
> What about things which cannot be spelt in SQL?

Use the query language (not necessarily SQL) to pass the data to
something that can deal with it.

> What about response times?
> Can you specify/guess an upper bound for all requests? For a certain subset
> of?

This is just a prejudice - get the right RDBMS and the right expert to
tune it (specifically for what it must do, not generically) and you
might be surprised.

>
>>> These limitations should be specified as functional and non-functional
>>> requirements.
>> 
>> If possible. What I meant was that you should minimise the limitations
>> on both the expected and the unknown futures.
>
> No optimum exists under these conditions.
>
>>> If you prefer to buy a cat in the bag named RDBMS (or
>>> whatever), that's up to you. I merely state that there is always something
>>> in any bag.
>> 
>> Cat? What cat? But actually, see what I said above about price.
>
> You said that the price has to be paid. Right, but the question is about
> performance/price ratio. You can buy a bigger car, but it would require
> more gasoline and it would be more difficult to park. Software developing
> is an expensive thing.
>
>>> As for the bag RDBMS, among the thing it contains are
>>> object-relational impedance,
>> 
>> You made this one up because you don't understand.
>
> What didn't I? That impedance exists or that it does not?
>
>>> SQL,
>> 
>> OK, it's not the perfect language, but what is? And it is possible to
>> have an RDBMS that doesn't use it.
>> 
>>> poor performance,
>> 
>> Relative to what? Where are the tests? Do you install an RDBMS product
>> and just go with whatever myths you have heard lately, or do you get a
>> product specialist to sort it out?
>
> Come on, show me the nearest neighbour search in ten-dimensional space
> implemented in RDBMS. What would be the complexity of? You should clearly
> understand that it is possible to break the neck of *any* indexing method.
> This refutes the argument to "any logically possible criterion.".
>

But I don't believe that an RDBMS can do everything. I would not be
surprised to find the data defining the ten-dimensional space in an
RDBMS, but I would never expect to do such a calculation in the query
language.

>>> unpredictable behavior,
>> 
>> Please explain. Unless you're talking about bugs, but everything has
>> those.
>
> And what are the means available in order to prevent bugs? How much RDBMS
> support static analysis? SQL is practically untyped. Design by contract,
> how? Code reuse is close to none, well, code is evil, why should we reuse
> it? Upper bounds for memory footprint? For response times?
>
>>> maintenance costs,
>> 
>> Everything has those too. Again, I have to assume that you take only the
>> short-term view.
>
> No,I mean long-term maintenance costs.
>
>>> etc.
>> 
>> What else would you like to make up?
>
> Actually I don't want to concentrate on critique of RDBMS. It is a hardware
> to me. I would buy one in case I needed it.
>
> My objective is rather data-centric view. Which is IMO the reason for
> object-relational impedance. BTW, I see nothing wrong in RA, which has in
> my view fully independent on the notion of data. RA would nicely fit into
> OO as a set of types with corresponding operations.
>
>>>> Perhaps not, since you have also said that "data are irrelevant".
>>>
>>> Yes, I did. I am working mainly in the area of industrial data acquisition
>>> and control. It might sound funny, but being so close to "data" one starts
>>> to better understand why data are irrelevant.
>> 
>> Aha! Your data is transient, and what you are mostly doing is
>> transforming it.
>
> Well, one viewed it this way in 50-60s, I guess. But it is a long time
> since one dropped this data-centric view on the system as a huge signal
> filter. This model does not scale and is inadequate (event controlled and
> non-numeric things, GUI etc).
>
>> I at least have no problem with using OO programming
>> for that. Also, that explains your short-term view. But what do you do
>> with the data (presumably transformed) that does get kept for longer?
>> Put it somewhere that will be available for a variety of expected and
>> unexpected uses? But we were here before!
>
> Yes, here we go again. Data are meaningless if usage is unexpected. Nobody
> can use a CD-ROM in a wind-up phonograph, deaf people notably.

No collection of data is useful to everybody, so deaf people have got
nothing to do with it.

Other than that, you have just demonstrated a lack of understanding of
the difference between the logical and the physical. It is possible for
me to collect the necessary bits of technology to transfer a piece of
music from a CD-ROM to a disc or cylinder for the wind-up phonograph. It
is still the same piece of music.
>
> The system does not keep anything it exists and behaves.

But it has inputs and outputs. There may also be a need for it to record
some of its behaviour. There may be a reason to keep some of the
outputs, or even the inputs (for later extended analysis?). If you have
a system that genuinely keeps nothing, I have no argument with how you
choose to create it, as long as it works.

> Deployment of DB
> there is always problematic. There are much ongoing efforts in this area in
> recent years, mainly to standardize the schemas. That is not enough,
> because relational model does not fit. Channels are largely event
> controlled with time stamps. So you cannot make any reasonable relations
> beyond (time, value) without data corruption. The queries would be like
> "give me the oil temperature profile when the velocity was out of range for
> longer than 10s before the event E." You need various interpolation
> methods, calculated channels and ones simulated from previously recorded
> measurements. Channels are created and destroyed, their properties change.
> The end effect is that when DBs are used then only marginally. I remember
> an amusing customer requirement: "we want to be able to run our tests even
> if the DB server is off-line." (:-))
>

E

0
eric154 (81)
3/5/2008 12:12:47 PM
On 2008-03-05, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 5 Mar 2008 00:46:14 -0600, Robert Martin wrote:
>
>> On 2008-03-03 16:49:29 -0600, "David Cressey" <cressey73@verizon.net> said:
>> 
>>> But the idea of a single language that is suitable for everything remains an
>>> elusive goal,  and probably an unproductive endeavor.
>> 
>> Agreed.
>
> Disagreed.
>
> The idea of multilingual system is the most damaging thing in software
> developing history. 
>

Well, that opinion explains a lot of the things you have said. You also
appear to have assumed that other people agreed, leading you to
misinterpret what they said.

If you should not use multiple languages, there must be a universal
language. What is it, is it really universal _right now_, and if not,
when will it be and what should we do in the meantime?

E
0
eric154 (81)
3/5/2008 12:22:24 PM
On Mar 5, 6:57 am, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-03 17:06:05 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> > A join of the two statements gave me the inference I required: {Name,
> > Mortality}. All of a sudden it seemed simple.
>
> Interesting story.  Yes, when you have a problem of inference, it's
> good to use an inference engine.
>
> > So some questions:
>
> > 1) So why not treat all 'inheritance' in this way?
>
> Because all inheritance is not about inference.

Hmmm. Then might you give an example of a situation where inheritance
cannot be described in terms of inference?

>
> > 2) Could one extend to include 'behaviour' as well?
>
> Yes.  See the Prolog language.
>
> > 3) And is this a crazy thing to suggest in a cross post to an OO
> > group?
>
> I've seen a lot crazier things.
>
> --
> Robert C. Martin (Uncle Bob)  | email: uncle...@objectmentor.com
> Object Mentor Inc.            | blog:  www.butunclebob.com
> The Agile Transition Experts  | web:   www.objectmentor.com
> 800-338-6716                  |

0
jog (83)
3/5/2008 12:48:31 PM
Dmitry A. Kazakov wrote:
> On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:
>
>   
>> <snip>
>> You are confusing OO with static typing.  In OO languages like Ruby, 
>> Python, or Smalltalk you can pass any object to any function 
>> irrespective of type.
>>     
>
> Which is a bad idea.
>   
Why?
> Nevertheless you don't need dynamic typing in order to deal with that. You
> could have a class of relations in order to define operations (like join)
> on them. That will give a static type to the result of any join.
>   
At what cost given a similar benefit can be gained without the extra effort?
> The problem is elsewhere. How do I know in *advance* that the result of
> join is a relation of certain narrower kind? Both "statically untyped" SQL
> and "dynamically untyped" fancy languages have no answer to that until run
> time. Note that this is a software design issue.
>   
The result is what it is.  If it answers the messages sent it
predictably what does it matter?


-- 
Visit <http://blogs.instreamco.com/anything.php> to read 
my rants on technology and the finance industry.  Visit
<http://tggagne.blogspot.com/> for politics, society and culture.
0
tgagne (596)
3/5/2008 2:57:23 PM
Leslie Sanford wrote:

> "JOG" wrote:
> 
>>This reminds me of a serious 'click' moment I had with data
>>structures. A long time ago, in a galaxy far far away, I once sat
>>blindly reinventing my own network model, with identifiers, pointers,
>>types, and all the fun of the fair. As an OO programmer it was the
>>only mindset I had. Then I considered encoding data similar to the
>>classic example of:
>>
>>* Aristotle is a man
>>* All men are mortal
>>* |= Aristotle is mortal
>>
>>Well, /clearly/ what I was dealing with here was a generic entity
>>class, of which Man was a subclass, and Aristotle an instance.
>>Something like:
>>
>>class Entity
>>{
>>boolean mortal;
>>string name;
>>Entity(_name, _mortal) : name(_name), mortal(_mortal);
>>};
>>
>>class Man : public Entity
>>{
>>date bday;
>>Man(_name, _mortal) : Entity(_name, _mortal), bday(_bday);
>>};
>>
>>
>>But, as I extended the example, the structures got more convoluted,
>>and the result more and more of a mess. Finally something clicked. It
>>wasn't about types, objects or inheritance, it was about /inference/,
>>and what I actually had was:
>>
>>Name(x, Aristotle) -> Species(x, Man)
>>Species(x, Man) -> Mortality(x, Mortal)
>>|= Name(x, Aristotle) -> Mortalilty(x, Mortal)
>>
>>No types or reification in sight. Instead I had two groups of
>>statements:
>>People = {Name, Species, Bday}
>>Entities = {Species, Mortality}
>>
>>A join of the two statements gave me the inference I required: {Name,
>>Mortality}. All of a sudden it seemed simple. So some questions:
>>
>>1) So why not treat all 'inheritance' in this way?
>>2) Could one extend to include 'behaviour' as well?
>>3) And is this a crazy thing to suggest in a cross post to an OO
>>group?
> 
> 
> I'm jumping in realizing that I may be revealing a bit of ignorance here, so
> bear with me.
> 
> If I need to send a message to all persons who are mortal, I could join
> People and Entities together by species and where Mortality is true?
> 
> Once I've performed the join, I then dispatch a message to the resulting
> group: "GetAnnualCheckUp()" or something?
> 
> In the application I'm currently writing, I have a large list of parameters.
> These parameters share some values such as Name and Label. However, there
> are different types of parameters such as those that represent a boolean
> state ("on/off"), a selection of choices, e.g. "Sine", "Sawtooth", "Square",
> etc., and other types. My current approach is traditional OO, and that's to
> have a hierarchy of Parameter classes. I can then keep a list of
> heterogeneous parameters and treat them polymorphically. For example:
> 
> params[AmplitudeId] = new FloatParameter("Amplitude", "dB", 0.0f, 1.0f);
> params[WaveId] = new SelectionParameter("Wave", "Type", WaveNames);
> 
> // Set a parameter value. All raw parameter values are in the range
> // of [0, 1]. Each parameter class knows how to transform raw parameter
> // values in an appropriate way.
> params[parameterId].SetValue(value);
> 
> And all works well.
> 
> I'm trying to wrap my head around how I would approach this problem using
> what you've described above. I could have a table representing attributes
> common to all parameters. Then tables representing attributes specific to
> one parameter type or another. I could relate the tables via foreign keys?
> When I need to dispatch parameter changes, I could join the appropriate
> tables and change the appropriate values?
> 
> I'm open to new ways of approaching things, but the mechanism to implement
> all of this needs to be fast, in my case. Parameter changes can come in at
> hundreds of times a second.

Leslie,

Relationally, I would approach what you are doing almost exactly as you 
are now. The data type for parameter values would be a union type with 
sub-types as appropriate.

Whether one has a single base relation with all parameter types or one 
has a different base relation for each sub-type becomes almost moot. No 
matter which one chooses, one can have both using views. Either a 
restrict view to derive each sub-type relation from the single base 
relation or a single union view to derive the super-type relation from 
the individual sub-type base relations.

If this is a subject that interests you, I highly recommend Fabian 
Pascal's _Practical Issues in Database Management ..._
0
bbadour (434)
3/5/2008 3:17:04 PM
H. S. Lahman wrote:

> Responding to JOG...
> 
>>> All attempts by applications to access a DB's tables and columns
>>> directly violates design principles that guard against close-coupling.
>>> This is a basic design tenet for OO.  Violating it when jumping from OO
>>> to RDB is, I think, the source of problem that are collectively and
>>> popularly referred to as the object-relational impedance mismatch.
>>
>> I wondered if we might be able to come up with some agreement on what
>> object-relational impedence mismatch actually means. I always thought
>> the mismatch was centred on the issue that a single object != single
>> tuple, but it appears there may be more to it than that.
> 
> First, I think it is important to clarify that the 'relational' in the 
> mismatch isn't referring to the fact that the OO paradigm uses something 
> other than set theory's relational model. The nature of the impedance 
> mismatch lies in the way the OO and RDB paradigms implement the same 
> relational model.

Frankly, the paragraph above is nonsense.


> I think the lack of 1:1 tuple mapping is just a symptom of the mismatch. 
> There are several contributors to the mismatch...
> 
> Applications (not just OO) are designed to solve specific problems so 
> they are highly tailored to the particular problem in hand. In contrast, 
> databases are designed to provide ad hoc, generic access to data that is 
> independent of particular problem contexts. If one had to choose a 
> single characterization of the mismatch, this would be it; everything 
> else stems from it.
> 
> Object properties include behavior. Behaviors interact in much more 
> complex ways than data. Managing behaviors is the primary cause of 
> failing to map 1:1 between OO Class Diagrams and Data Models of the same 
> subject matter. That's because managing behavior places additional 
> constraints on the way the software is constructed.

The above three paragraphs are not much better.


> OO relationships are instantiated at the object (tuple) level rather 
> than the class (table) level.

Equating object instances with tuples and object classes with relations 
is a great blunder. One of two great blunders detailed in Date's and 
Darwen's _The Third Manifesto_.

A tuple is actually a logical join of N object values. An object class 
extent is a unary relation. OO has no concept equal to a binary 
relation--let alone an n-ary relation.

[remaining nonsense snipped]
0
bbadour (434)
3/5/2008 3:24:39 PM
On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> >
> > Furthermore, since OOPLs lack physical independence, traversing
> > the graph may be quite expensive, particularly in the case where
> > the graph is backed by storage in a database, which is part of
> > why ORM is such a universally bad idea.
>
> No, you have this wrong.  ORMs generally use standard SQL queries to
> traverse and gather data from the DB.  Then that data is placed into OO
> structures so that the application can take advanage of the bias.

Just the fact that they use SQL isn't sufficient. They have to
use it as well as a person could, though an interface that
is generally information-lossy enough (or at least, used in
a lossy way) that that's impossible.

The most gratuitous example I can think of was some early
EJB containers I played with, back when I was still thinking
that ORM was something that could possibly be done well.
Against a table of a few hundred rows, one could execute
"delete from table". The comparable command through the
ORM issued SQL to load every row as an object, then
in a loop called obj.delete() which issued a single DELETE
statement for that row. It was ten thousand times slower,
and that's for only a couple hundred rows. Of course this
example is extreme, but it's still illustrative of a general
principle.

I have *often* seen four and five order of magnitude
performance difference between straight SQL and
ORM SQL, across a wide variety of ORMs. The
very idea of ORM demands it: you have to try to
push a whole set-oriented language through a functional
interface.


Marshall
0
3/5/2008 3:48:45 PM
Responding to Nobis...

>> First, I think it is important to clarify that the 'relational' in
>> the mismatch isn't referring to the fact that the OO paradigm uses
>> something other than set theory's relational model. The nature of
>> the impedance mismatch lies in the way the OO and RDB paradigms
>> implement the same relational model.
> 
> Huh? I know of the lambda calculus as a foundation of functional
> languages and the relation model as foundation of RDBs. But I wonder
> what the formal foundations of the OO family of languages is
> (references, please).

The foundation is much broader because of the need to provide dynamic 
elements (i.e., the relational model is a subset of the OO foundation).

However, the point in this context is that a UML Class Diagram *is* an 
Entity Relationship Diagram and it is normalized exactly the same way as 
an ERD Data Model. But the Class Diagram is just one view of the overall 
solution and it needs to play with other views so the semantics of 
construction are somewhat different, as I indicated in my post.



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

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development".  Email
info@pathfindermda.com for your copy.
Pathfinder is hiring: 
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
0
hsl (257)
3/5/2008 3:58:07 PM
On Mar 4, 11:10 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-03 18:34:39 -0600, Marshall <marshall.spi...@gmail.com> said:
>
> > In SQL, if I have two relations with x and y int columns, I can
> > union them, or join on them, or whatever. There is no way,
> > in fact, to forbid such a thing, just like in Java there is no way
> > to allow such a thing.
>
> You are confusing OO with static typing.

How supremely annoying to have gone to some lengths
to carefully use the most strictly defined, modern type
system terminology, only to have it labeled as a novice
error by someone who missed my point entirely.

At least you didn't say "duck typing."


> In OO languages like Ruby,
> Python, or Smalltalk you can pass any object to any function
> irrespective of type.

Actually, the dimension I was referring to is
"nominal" vs. "structural" typing. This axis is independent
of static vs. "dynamic" typing. Ruby, Python
and Smalltalk all use structural, dynamic (aka runtime) typing.
C++ uses static, nominal typing. Java uses a static, nominal
type system with the addition of runtime types; SQL uses
static, structural typing.

I was speaking of nominal vs. structural.


Marshall
0
3/5/2008 3:58:43 PM

H. S. Lahman wrote:
> Responding to Nobis...
>
> >> First, I think it is important to clarify that the 'relational' in
> >> the mismatch isn't referring to the fact that the OO paradigm uses
> >> something other than set theory's relational model. The nature of
> >> the impedance mismatch lies in the way the OO and RDB paradigms
> >> implement the same relational model.
> >
> > Huh? I know of the lambda calculus as a foundation of functional
> > languages and the relation model as foundation of RDBs. But I wonder
> > what the formal foundations of the OO family of languages is
> > (references, please).
>
> The foundation is much broader because of the need to provide dynamic
> elements (i.e., the relational model is a subset of the OO foundation).

This "subset" thing is perhaps misleading. While trying to figure out
how to merge paradigms in another forum in order to make everybody
happy and stop the bickering, we eventually generally agreed that
paradigms are more about *constraints* than features. What a paradigm
*doesn't* allow is often more important to defining it than what it
does allow. The "no side-effects" rule of Functional Programming is an
example. If one tries to create a language or tool that allows
multiple paradigms, it often has to relax such constraints such that
the essence of the original paradigm is lost.

One cannot "reason" about the results as easily because they don't
know which rules a given thing will abide by. Paradigms are tools to
help human reasoning by providing rules for the "atoms" to follow. If
there are too many rules, or a lack of rules, then it becomes a big
ball of twine too hard to get one's head around because any assumption
you rely on to mentally narrow down the possible paths something can
take may just be all wrong.

>
> However, the point in this context is that a UML Class Diagram *is* an
> Entity Relationship Diagram and it is normalized exactly the same way as
> an ERD Data Model. But the Class Diagram is just one view of the overall
> solution and it needs to play with other views so the semantics of
> construction are somewhat different, as I indicated in my post.
>
>
> --
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman

-T-
0
topmind (2124)
3/5/2008 4:13:57 PM
On Mar 4, 10:52 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-03 17:25:48 -0600, topmind <topm...@technologist.com> said:
>
> > But I think anybody inspecting both examples will clearly see that my
> > version is a lot less total code.
>
> C++ is a pretty wordy language.  If I wrote it in Ruby I bet I'd beat
> you by a wide margin.

I am a skeptical, but you are welcome to try. And, it would probably
be the meta features of Ruby that cut it down, not OOP.

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

-T-
0
topmind (2124)
3/5/2008 4:16:30 PM
On Mar 5, 1:24 am, S Perryman <q...@q.com> wrote:
> Robert Martin wrote:
> > On 2008-03-03 18:34:39 -0600, Marshall <marshall.spi...@gmail.com> said:
> >> In SQL, if I have two relations with x and y int columns, I can
> >> union them, or join on them, or whatever. There is no way,
> >> in fact, to forbid such a thing, just like in Java there is no way
> >> to allow such a thing.
> > You are confusing OO with static typing. In OO languages like Ruby,
> > Python, or Smalltalk you can pass any object to any function
> > irrespective of type.
>
> And you (both) are equating the (strong) typing model of Simula as the
> only strong typing model.

No I most certainly am not, and there isn't anything in my post
that could lead one to conclude that I am.


Marshall
0
3/5/2008 4:47:17 PM
On Mar 4, 1:43 pm, Stefan Nobis <sno...@gmx.de> wrote:
> "H. S. Lahman" <h...@pathfindermda.com> writes:
>
> > First, I think it is important to clarify that the 'relational' in
> > the mismatch isn't referring to the fact that the OO paradigm uses
> > something other than set theory's relational model. The nature of
> > the impedance mismatch lies in the way the OO and RDB paradigms
> > implement the same relational model.
>
> Huh? I know of the lambda calculus as a foundation of functional
> languages and the relation model as foundation of RDBs. But I wonder
> what the formal foundations of the OO family of languages is
> (references, please).

The foundation of OO mostly hasn't been laid down yet.
Little work has been done. If you are interested:

http://www.google.com/search?q=theory+of+objects

Abadi and Cardelli have done some work in this area.
Cardelli in particular is a brilliant CS researcher; you cannot
go wrong paying attention to anything he has to say.


Marshall
0
3/5/2008 5:03:01 PM
On Mar 5, 7:58 am, "H. S. Lahman" <h...@pathfindermda.com> wrote:
>
> ... the relational model is a subset of the OO foundation ...

Please describe where JOIN and UNION for example,
are to be found in the OO foundation. Or in any OO language.


Marshall
0
3/5/2008 5:05:25 PM
On Mar 5, 8:13 am, topmind <topm...@technologist.com> wrote:
>
> [...] we eventually generally agreed that
> paradigms are more about *constraints* than features. What a paradigm
> *doesn't* allow is often more important to defining it than what it
> does allow. The "no side-effects" rule of Functional Programming is an
> example. If one tries to create a language or tool that allows
> multiple paradigms, it often has to relax such constraints such that
> the essence of the original paradigm is lost.

Nice post!


Marshall
0
3/5/2008 5:10:15 PM
On Mar 3, 8:52 am, JOG <j...@cs.nott.ac.uk> wrote:
>
> I was hoping perhaps people might be able to offer
> perspectives on the issues that they have encountered.

Another big difference:

Object oriented languages work in object-at-a-time terms.
Even when those objects are collections, if one wants to
operate on every object in the collection, one iterates
over the objects in the collection and calls methods on
those objects one at a time.

The relational model works in set-at-a-time terms. One
operates on entire sets at once.

The two don't fit together very well.

One context in which the set-at-a-time approach yields
dramatic performance benefits is in distributed programming.
It has been my experience that the single biggest performance
issue in programming for the datacenter (as opposed to
programming for single machines) is the nature of the
protocol used across edges in the server graph. The more
work the protocol can accomplish in a single message
the better. Set-at-a-time thinking, and tools, are necessary.


Marshall
0
3/5/2008 5:16:11 PM
Marshall wrote:

> On Mar 5, 1:24 am, S Perryman <q...@q.com> wrote:

>>And you (both) are equating the (strong) typing model of Simula as the
>>only strong typing model.

> No I most certainly am not, and there isn't anything in my post
> that could lead one to conclude that I am.

As clarified (thanks) by your subsequent posting to Robert Martin.


Regards,
Steven Perryman
0
S
3/5/2008 5:22:33 PM
On Mar 5, 9:22 am, S Perryman <q...@q.net> wrote:
> Marshall wrote:
> > On Mar 5, 1:24 am, S Perryman <q...@q.com> wrote:
> >>And you (both) are equating the (strong) typing model of Simula as the
> >>only strong typing model.
> > No I most certainly am not, and there isn't anything in my post
> > that could lead one to conclude that I am.
>
> As clarified (thanks) by your subsequent posting to Robert Martin.

Uh, sure. Please excuse me if I was a bit hot above.


Marshall

0
3/5/2008 5:25:39 PM
On Mar 5, 7:48=A0am, Marshall <marshall.spi...@gmail.com> wrote:
> The most gratuitous example I can think of was some early
> EJB containers I played with, back when I was still thinking
> that ORM was something that could possibly be done well.
> Against a table of a few hundred rows, one could execute
> "delete from table". The comparable command through the
> ORM issued SQL to load every row as an object, then
> in a loop called obj.delete() which issued a single DELETE
> statement for that row. It was ten thousand times slower,
> and that's for only a couple hundred rows. Of course this
> example is extreme, but it's still illustrative of a general
> principle.
>
> I have *often* seen four and five order of magnitude
> performance difference between straight SQL and
> ORM SQL, across a wide variety of ORMs. The
> very idea of ORM demands it: you have to try to
> push a whole set-oriented language through a functional
> interface.

Yep, this is "drive car to supermarket" analogy in Stephane Faroult
video
Part 2: http://www.youtube.com/watch?v=3DGbZgnAINjUw
It is a recurrent theme of application database performance meetings.

Why set oriented processing is more friendly to optimisation?
(Contrary to a moronic blanket statement that joins are bad). Because
there is a little nice algebra behind it, so that optimization is
essentially algebraic manipulation with query expressions. This is not
an easy subject to master of course, so why some people have chosen to
hide their head in the sand of imaginary code reorganisation problems
is perfectly understandable.

0
3/5/2008 5:26:39 PM
Marshall wrote:

> On Mar 3, 8:52 am, JOG <j...@cs.nott.ac.uk> wrote:

>>I was hoping perhaps people might be able to offer
>>perspectives on the issues that they have encountered.

> Another big difference:

> Object oriented languages work in object-at-a-time terms.
> Even when those objects are collections, if one wants to
> operate on every object in the collection, one iterates
> over the objects in the collection and calls methods on
> those objects one at a time.

> The relational model works in set-at-a-time terms. One
> operates on entire sets at once.

This is a fallacy.
In any system, if I have a set S of tuples (x,y) , and request the
following :

{ e IN S : e.x = 123 }

I have to examine each tuple in the set to find those that satisfy the 
predicate. The satisfying tuples do not appear by magic.


> The two don't fit together very well.

Particular *implementations* of OO prog langs may not fit well with a
relational execution engine. But some (OO implemented on Functional
programming infastructure etc) fit very well ( "lazy" programming
etc) .


Regards,
Steven Perryman
0
S
3/5/2008 5:31:32 PM
On Mar 5, 9:31=A0am, S Perryman <q...@q.net> wrote:
> Marshall wrote:
> > On Mar 3, 8:52 am, JOG <j...@cs.nott.ac.uk> wrote:
> >>I was hoping perhaps people might be able to offer
> >>perspectives on the issues that they have encountered.
> > Another big difference:
> > Object oriented languages work in object-at-a-time terms.
> > Even when those objects are collections, if one wants to
> > operate on every object in the collection, one iterates
> > over the objects in the collection and calls methods on
> > those objects one at a time.
> > The relational model works in set-at-a-time terms. One
> > operates on entire sets at once.
>
> This is a fallacy.
> In any system, if I have a set S of tuples (x,y) , and request the
> following :
>
> { e IN S : e.x =3D 123 }
>
> I have to examine each tuple in the set to find those that satisfy the
> predicate. The satisfying tuples do not appear by magic.

Sigh: "magic optimization" (this is indeed a legitimate technical
term) is not applied in this case. However, consider an index on
column x. Suddenly the execution engine choses an access path more
sophisticated than naive loop and application of a filter. The index
management and leverage in the queries is completely transparrent from
the user. This is one of the features that elevates relational model
to high level.

P.S. This de ja vu of the great debate is silly, one of the reason
being that the caliber of participants is smaller.

0
3/5/2008 5:48:33 PM
Tegiri Nenashi wrote:

> On Mar 5, 9:31 am, S Perryman <q...@q.net> wrote:

>>Marshall wrote:

>>>Object oriented languages work in object-at-a-time terms.
>>>Even when those objects are collections, if one wants to
>>>operate on every object in the collection, one iterates
>>>over the objects in the collection and calls methods on
>>>those objects one at a time.
>>>The relational model works in set-at-a-time terms. One
>>>operates on entire sets at once.

>>This is a fallacy.
>>In any system, if I have a set S of tuples (x,y) , and request the
>>following :

>>{ e IN S : e.x = 123 }

>>I have to examine each tuple in the set to find those that satisfy the
>>predicate. The satisfying tuples do not appear by magic.

> Sigh: "magic optimization" (this is indeed a legitimate technical
> term) is not applied in this case. However, consider an index on
> column x.

Sigh : in the text "{ e IN S : e.x = 123 }" there is no "index" .
Merely a Relational expression.

The use of index is an *implementation* technique.

Argue about implementation techniques as much as you want.
But you cannot claim that all OO prog langs will have an implementation
that forces the fallacious "one at a time" scheme (Functional programming
being a case in point) .


Regards,
Steven Perryman
0
S
3/5/2008 5:58:30 PM
On Mar 5, 9:16 am, Marshall <marshall.spi...@gmail.com> wrote:
>
> The relational model works in set-at-a-time terms. One
> operates on entire sets at once.

I forgot to mention: there's an amusing term used in this
area, which comes from the APL family: "no stinking loops."

http://www.nsl.com/


Marshall
0
3/5/2008 6:30:15 PM
On Mar 5, 9:31 am, S Perryman <q...@q.net> wrote:
> Marshall wrote:
> > On Mar 3, 8:52 am, JOG <j...@cs.nott.ac.uk> wrote:
> >>I was hoping perhaps people might be able to offer
> >>perspectives on the issues that they have encountered.
> > Another big difference:
> > Object oriented languages work in object-at-a-time terms.
> > Even when those objects are collections, if one wants to
> > operate on every object in the collection, one iterates
> > over the objects in the collection and calls methods on
> > those objects one at a time.
> > The relational model works in set-at-a-time terms. One
> > operates on entire sets at once.
>
> This is a fallacy.
> In any system, if I have a set S of tuples (x,y) , and request the
> following :
>
> { e IN S : e.x = 123 }
>
> I have to examine each tuple in the set to find those that satisfy the
> predicate. The satisfying tuples do not appear by magic.

I don't understand what point you're trying to make here.
Are you talking about the language or the implementation?

You use set-builder notation to describe a set. In the
relational model, something very nearly identical would be
used. It is a single set-oriented expression. In an OOPL,
one would iterate over a collection. Inside a loop, one
would find expressions or statements written against
single objects. The semantics might be the same;
the languages are different.


> > The two don't fit together very well.
>
> Particular *implementations* of OO prog langs may not fit well with a
> relational execution engine. But some (OO implemented on Functional
> programming infastructure etc) fit very well ( "lazy" programming
> etc) .

Again, I don't understand what you're trying to say. I am discussing
differences at the language level, not implementation differences.
Yes, we could implement either a relational or an OO language
with a functional SSA intermediate language; this doesn't affect
what the abstractions of that language are, or whether they
are set-oriented or object-oriented.

Also, lazy vs. strict seems a completely orthogonal issue; I don't
see why you bring it up.

As an *implementation* point, when one puts the two different
kinds on languages on the wire, one gets two different sorts
of performance characteristics. These characteristics heavily
favor set-oriented language. This isn't *necessarily* the case,
true, but it is *actually* the case in every circumstance
I'm aware of.


Marshall
0
3/5/2008 6:42:15 PM
On Wed, 5 Mar 2008 12:22:24 +0000, Eric wrote:

> If you should not use multiple languages, there must be a universal
> language.

Yep, it is called a universal/general purpose programming language.

> What is it, is it really universal _right now_, and if not,

It is, there exist many of them.

The mistake you make is in a wrong presumption that "universal purpose" <=>
"best possible."

> when will it be and what should we do in the meantime?

Not to develop pet domain-specific languages if the advantages of those are
unclear. If you, say, wanted to create a declarative language based on
inference, then that should be a universal purpose one.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2008 7:49:47 PM
On Mar 5, 9:58 am, S Perryman <q...@q.com> wrote:
> But you cannot claim that all OO prog langs will have an implementation
> that forces the fallacious "one at a time" scheme

Can you name one that doesn't? (I think I agree that
one could exist in theory, however.)


> (Functional programming being a case in point) .

Why are you bringing up functional programming when
talking about OOPLs?

Are you thinking of map(), by chance?


Marshall
0
3/5/2008 8:02:51 PM
On Wed, 05 Mar 2008 09:57:23 -0500, Thomas Gagne wrote:

> Dmitry A. Kazakov wrote:
>> On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:
>>
>>> <snip>
>>> You are confusing OO with static typing.  In OO languages like Ruby, 
>>> Python, or Smalltalk you can pass any object to any function 
>>> irrespective of type.
>>
>> Which is a bad idea.
>>   
> Why?

Because it is in fact untyped.

>> Nevertheless you don't need dynamic typing in order to deal with that. You
>> could have a class of relations in order to define operations (like join)
>> on them. That will give a static type to the result of any join.

> At what cost given a similar benefit can be gained without the extra effort?

No extra efforts. If I wanted to mix types T1 and T2, I put them in the
same class. It is purely a mental effort, which has been made. The class
was identified, it is what DB people call "relation." But this is too
little efforts to me.

>> The problem is elsewhere. How do I know in *advance* that the result of
>> join is a relation of certain narrower kind? Both "statically untyped" SQL
>> and "dynamically untyped" fancy languages have no answer to that until run
>> time. Note that this is a software design issue.
>>   
> The result is what it is.  If it answers the messages sent it
> predictably what does it matter?

How can you predict it? To answer to messages in a certain way is a
behavior. Let's denote it T. Now, the question is about ~T. Do all possible
objects expose T, so that ~T be empty? I bet some don't. Now, because T is
not statically determinable we could not predict T. That matters.

Clearly we cannot map all behavior to types in order to statically ensure
it. But we have always try to do it as much as possible. Giving up without
even a try is a bad idea from software design point of view.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2008 8:10:11 PM
Marshall wrote:

> On Mar 5, 9:58 am, S Perryman <q...@q.com> wrote:

>>But you cannot claim that all OO prog langs will have an implementation
>>that forces the fallacious "one at a time" scheme

> Can you name one that doesn't? (I think I agree that
> one could exist in theory, however.)

CLOS, OCaml etc (by virtue of being built on Functional prog langs) .


>>(Functional programming being a case in point) .

> Why are you bringing up functional programming when
> talking about OOPLs?

Because FP has :

- been able to support OO quite easily

- has an interesting execution infrastructure that IMHO makes it a
   good candidate for supporting the Relational paradigm


Given that the topic is "Object-relational impedence" , I am interested
in anything that may be able to remove the impedence. And you ??


> Are you thinking of map(), by chance?

Are you talking about the map function (map : Type x Func -> Type) ??
If so, no (in fact, no for any likely meaning of "map" ) .


Regards,
Steven Perryman
0
rugby
3/5/2008 8:19:50 PM
On Wed, 5 Mar 2008 11:34:05 +0000, Eric wrote:

> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

> I don't believe that merely using an RDBMS will solve all problems. What
> I meant was that, accepting what David said above, if you keep your data
> in an RDBMS, it will be easily available for the solution of any
> possible problem that can be solved using that data.

No, this as well is wrong. Keeping "data" in RDBMS puts certain
restrictions on what can be stored there and how it can be used later.

You propose a solution (DB on a RDBMS). What was the problem? From your
description the problem looks like a persistence layer. This what c.d.t.
people vehemently disagree. Isn't it interesting to see how quickly a great
theory of all degrades to storage?

>> I guess that his hidden argument was "because RDB
>> apparently solves all problems, then data-centric view is the right one."
> 
> No, the argument is that the data-centric view is often (not necessarily
> always) the right one to take, and that keeping the data in an RDBMS
> provides a better basis for solving future problems using the data than
> any other way of keeping it.

Ah, that's better. So data-centric view is not universal => then there
exist cases which cannot be viewed that way => data is not a fundamental
term => data do not unconditionally exist. Are we in agreement?

>> Yet another logical fallacy was a data-centric problem statement: "there
>> will never be any other application that will need my data," used in order
>> to prove data-centric view itself.
> 
> There is no fallacy here. First there is a fact - you have data, however
> you choose to view it. Do you want to deny this?

Certainly. Non-observable things do not exist. But the fallacy is that you
are putting existence of data as a fact from which you deduce data
existence.

>> In OO problems are not modeled in terms
>> of applications using data.
> 
> No, but the data is still there.

In which sense? Laplace has answered this two hundred years ago: "I did not
need to make such an assumption."

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2008 8:37:13 PM
Marshall wrote:

 > On Mar 5, 9:31 am, S Perryman <q...@q.net> wrote:

M>Object oriented languages work in object-at-a-time terms.
M>Even when those objects are collections, if one wants to
M>operate on every object in the collection, one iterates
M>over the objects in the collection and calls methods on
M>those objects one at a time.
M>The relational model works in set-at-a-time terms. One
M>operates on entire sets at once.

 >>This is a fallacy.
 >>In any system, if I have a set S of tuples (x,y) , and request the
 >>following :

 >>{ e IN S : e.x = 123 }

 >>I have to examine each tuple in the set to find those that satisfy the
 >>predicate. The satisfying tuples do not appear by magic.

 > I don't understand what point you're trying to make here.
 > Are you talking about the language or the implementation?

Both.


 > You use set-builder notation to describe a set. In the
 > relational model, something very nearly identical would be
 > used. It is a single set-oriented expression. In an OOPL,
 > one would iterate over a collection. Inside a loop, one
 > would find expressions or statements written against
 > single objects.

boolean f(Tuple t) { return (t.x = 123) ; }

Set<Tuple> S ;

Set<Tuple> t = S.match(f) ; // or match(S,f) if one prefers

1. How is the above not "set-oriented" ??

A set is given as input to a match operation which produces a
set as output.


2. I have no idea whatsoever *how* S performs the match by
    looking at the above.


 > The semantics might be the same; the languages are different.

The semantics are the same.
The syntax may be different.
The implementation (technique, performance) may well be the same.


M>The two don't fit together very well.

 >>Particular *implementations* of OO prog langs may not fit well with a
 >>relational execution engine. But some (OO implemented on Functional
 >>programming infastructure etc) fit very well ( "lazy" programming
 >>etc) .

 > Again, I don't understand what you're trying to say. I am discussing
 > differences at the language level, not implementation differences.

Are we arguing about whether one syntax for expressing set operations is
better than the other ??


 > Yes, we could implement either a relational or an OO language
 > with a functional SSA intermediate language; this doesn't affect
 > what the abstractions of that language are, or whether they
 > are set-oriented or object-oriented.

 > Also, lazy vs. strict seems a completely orthogonal issue; I don't
 > see why you bring it up.

If you are debating language syntax (are you ?? ) , then no point
whatsoever.


 > As an *implementation* point, when one puts the two different
 > kinds on languages on the wire

When one puts different kinds of *implementations* of the same
behaviour ...


 > one gets two different sorts of performance characteristics.

Can you define these "characteristics" for us ??


 > These characteristics heavily
 > favor set-oriented language. This isn't *necessarily* the case,
 > true, but it is *actually* the case in every circumstance
 > I'm aware of.

Unable to comment without above definitions.


Regards,
Steven Perryman
0
S
3/5/2008 8:41:59 PM
On Wed, 5 Mar 2008 12:12:47 +0000, Eric wrote:

> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:
>>
>>> That's what I said - logically possible criteria.
>>
>> What about things which cannot be spelt in SQL?
> 
> Use the query language (not necessarily SQL) to pass the data to
> something that can deal with it.

This does not equate to "logically possible criteria." It is "something
that can understand this."

>> What about response times?
>> Can you specify/guess an upper bound for all requests? For a certain subset
>> of?
> 
> This is just a prejudice - get the right RDBMS and the right expert to
> tune it (specifically for what it must do, not generically) and you
> might be surprised.

This is not a prejudice, this is the point. I don't want to be surprised.
Engineering is about predictability.

>>> Relative to what? Where are the tests? Do you install an RDBMS product
>>> and just go with whatever myths you have heard lately, or do you get a
>>> product specialist to sort it out?
>>
>> Come on, show me the nearest neighbour search in ten-dimensional space
>> implemented in RDBMS. What would be the complexity of? You should clearly
>> understand that it is possible to break the neck of *any* indexing method.
>> This refutes the argument to "any logically possible criterion.".
> 
> But I don't believe that an RDBMS can do everything. I would not be
> surprised to find the data defining the ten-dimensional space in an
> RDBMS, but I would never expect to do such a calculation in the query
> language.

From this I conclude incompleteness of the approach. There is nothing bad
in that. At this point you should have said, "OK, how could we reason about
the applicability of this approach (and other approaches)." A framework
where that could be done is that common ground where c.d.t. and c.o. would
unite.

>>> I at least have no problem with using OO programming
>>> for that. Also, that explains your short-term view. But what do you do
>>> with the data (presumably transformed) that does get kept for longer?
>>> Put it somewhere that will be available for a variety of expected and
>>> unexpected uses? But we were here before!
>>
>> Yes, here we go again. Data are meaningless if usage is unexpected. Nobody
>> can use a CD-ROM in a wind-up phonograph, deaf people notably.
> 
> No collection of data is useful to everybody, so deaf people have got
> nothing to do with it.

Theorem: for any collection of data, there exist somebody who does not need
it.
 
> Other than that, you have just demonstrated a lack of understanding of
> the difference between the logical and the physical. It is possible for
> me to collect the necessary bits of technology to transfer a piece of
> music from a CD-ROM to a disc or cylinder for the wind-up phonograph. It
> is still the same piece of music.

No. Any logical is physical on another abstraction level. Ants do not
listen to music. Information does not exist without a receiver.

>> The system does not keep anything it exists and behaves.
> 
> But it has inputs and outputs. There may also be a need for it to record
> some of its behaviour. There may be a reason to keep some of the
> outputs, or even the inputs (for later extended analysis?). If you have
> a system that genuinely keeps nothing, I have no argument with how you
> choose to create it, as long as it works.

No you get me wrong. Of course we do logging, in fact a lot of. The system
behaves as if it "kept" things. Whether it physically keeps them is an
implementation detail. Consider sine. Does it keep its output? It is a
meaningless question. You can tabulate sine and keep the table, you can use
Chebyshev's polynomials, or you can ask an oracle. It is no matter. Sine is
a behavior of real numbers.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/5/2008 9:08:04 PM
H. S. Lahman wrote:

> Responding to Nobis...
> 
>>> First, I think it is important to clarify that the 'relational' in
>>> the mismatch isn't referring to the fact that the OO paradigm uses
>>> something other than set theory's relational model. The nature of
>>> the impedance mismatch lies in the way the OO and RDB paradigms
>>> implement the same relational model.
>>
>> Huh? I know of the lambda calculus as a foundation of functional
>> languages and the relation model as foundation of RDBs. But I wonder
>> what the formal foundations of the OO family of languages is
>> (references, please).
> 
> The foundation is much broader because of the need to provide dynamic 
> elements (i.e., the relational model is a subset of the OO foundation).

You are so full of shit your eyes must be brown.

[nonsense snipped]
0
bbadour (434)
3/5/2008 9:36:17 PM
On Mar 5, 12:19 pm, rugby fan <q...@q.com> wrote:
> Marshall wrote:
> > On Mar 5, 9:58 am, S Perryman <q...@q.com> wrote:
> >>But you cannot claim that all OO prog langs will have an implementation
> >>that forces the fallacious "one at a time" scheme
> > Can you name one that doesn't? (I think I agree that
> > one could exist in theory, however.)
>
> CLOS, OCaml etc (by virtue of being built on Functional prog langs) .

Well, hrmm. Let's see. While those are certainly *interesting*
and *surprising* examples (in this context) I don't know that
they qualify as counterexamples to my point.

Take CLOS. It is an object system built on LISP. As such, is
it fair to consider it in terms of the primitives or "axioms" that
LISP is built on? (It may not be; the mechanisms required for its
complex function invocation rules may strengthen the system;
I'm not familiar enough with this to know.) Those primitives,
car, cdr, cons, quote, atom, eq, cond) are none of them
set-oriented. An argument could be made that some of
them (car, cdr, cons) are list-oriented, but even in that
case, it does not rise to the level I am thinking of. For
example, if we consider how one processes all the items
in a list, one finds a pattern (a very *nice* pattern, you
understand; I'm not complaining about it) in which we
take the head of the list, operate on it, and recurse
with the rest of the list. Many good things can be said
of this pattern, but it is not set-oriented.

I am not familiar enough with OCaml to say much. But
if we were talking SML, (a language I have the utmost
respect for) I would still not consider it set-oriented.
map(), filter(), fold(), while providing collection-oriented
interfaces, are typically not primitive in the language.


> >>(Functional programming being a case in point) .
> > Why are you bringing up functional programming when
> > talking about OOPLs?
>
> Because FP has :
>
> - been able to support OO quite easily
>
> - has an interesting execution infrastructure that IMHO makes it a
>    good candidate for supporting the Relational paradigm

Hrmmm, well, I have to admit you make a good argument here.
(Although you must grant me that, we people speak of OOPLs,
they are not usually thinking CLOS!)

But I am, rather, speaking of what languages' axiomatic natures are.
I could, in fact, write a Relation class in Java, and provide set-
oriented
methods for it, and a whole host of relational goodness. But that
wouldn't make Java a relational language per se.

Virtually no languages have primitive support for anything like a
collection. SQL and SETL and a few others; that's it. There are
some languages that were designed from the start with *list*
processing in mind: lisp (and I should probably also mention the
APL family here.) There are some *very* interesting things
in there, but not things I would say could be strictly described
as set-oriented.


> Given that the topic is "Object-relational impedence" , I am interested
> in anything that may be able to remove the impedence. And you ??
>
> > Are you thinking of map(), by chance?
>
> Are you talking about the map function (map : Type x Func -> Type) ??
> If so, no (in fact, no for any likely meaning of "map" ) .

Okay.


Marshall
0
3/5/2008 9:38:31 PM

Tegiri Nenashi wrote:
> On Mar 5, 7:48=EF=BF=BDam, Marshall <marshall.spi...@gmail.com> wrote:
> > The most gratuitous example I can think of was some early
> > EJB containers I played with, back when I was still thinking
> > that ORM was something that could possibly be done well.
> > Against a table of a few hundred rows, one could execute
> > "delete from table". The comparable command through the
> > ORM issued SQL to load every row as an object, then
> > in a loop called obj.delete() which issued a single DELETE
> > statement for that row. It was ten thousand times slower,
> > and that's for only a couple hundred rows. Of course this
> > example is extreme, but it's still illustrative of a general
> > principle.
> >
> > I have *often* seen four and five order of magnitude
> > performance difference between straight SQL and
> > ORM SQL, across a wide variety of ORMs. The
> > very idea of ORM demands it: you have to try to
> > push a whole set-oriented language through a functional
> > interface.
>
> Yep, this is "drive car to supermarket" analogy in Stephane Faroult
> video
> Part 2: http://www.youtube.com/watch?v=3DGbZgnAINjUw
> It is a recurrent theme of application database performance meetings.
>
> Why set oriented processing is more friendly to optimisation?
> (Contrary to a moronic blanket statement that joins are bad). Because
> there is a little nice algebra behind it, so that optimization is
> essentially algebraic manipulation with query expressions. This is not
> an easy subject to master of course, so why some people have chosen to
> hide their head in the sand of imaginary code reorganisation problems
> is perfectly understandable.

I think SQL itself is a large part of the comprehension problem. In
part, it doesn't easily allow one to break the problem down into
smaller sub-problems for a mental divide-and-conquer.  If the
optimizer wants to re-lump it all together internally for efficiency,
that's fine, but the query "formula" itself doesn't have to be written
as one big lump.

I've been kicking around an experimental relational language called
SMEQL (yes a hint of LOR in the name) that is more "programmer
friendly" and decomposable than SQL. And its designed to be DBA-extend-
able due to its simpler syntax. It is roughly based on IBM's BS-12
experimental language from the early 70's.

-T-
0
topmind (2124)
3/5/2008 10:15:04 PM

Dmitry A. Kazakov wrote:
> On Wed, 5 Mar 2008 11:34:05 +0000, Eric wrote:
>
> > On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
> > I don't believe that merely using an RDBMS will solve all problems. What
> > I meant was that, accepting what David said above, if you keep your data
> > in an RDBMS, it will be easily available for the solution of any
> > possible problem that can be solved using that data.
>
> No, this as well is wrong. Keeping "data" in RDBMS puts certain
> restrictions on what can be stored there and how it can be used later.

As far as "what can be stored", isn't this a vendor-implementation
issue? Most RDBMS strive for efficiency over flexibility in column
content, but the tradeoff can be tilted in favor of flexibility if
need be. As far as "how it can be used", what is an example? A RDMBS
cannot stop you from doing anything you want to with retrieved data.
And, you can stick all kinds of meta data about an item to make
retrieval simpler and/or faster.

I agree there are very specialized niches where RDBMS performance
cannot beat a custom-rolled database-like tool.  But a custom-built
tool for very specific and narrow usage patterns will almost always
beat a general-purpose DB.  RDBMS do better where any given data item
may be used by multiple people for multiple different purposes that
are hard to anticipate up-front.

> Regards,
> Dmitry A. Kazakov

-T-
0
topmind (2124)
3/5/2008 10:27:58 PM
S Perryman <q@q.com> wrote in news:fqn0ir$mdg$1@aioe.org:
 > single objects.
> 
> boolean f(Tuple t) { return (t.x = 123) ; }
> 
> Set<Tuple> S ;
> 
> Set<Tuple> t = S.match(f) ; // or match(S,f) if one prefers
> 
> 1. How is the above not "set-oriented" ??
> 
> A set is given as input to a match operation which produces a
> set as output.
> 
> 
> 2. I have no idea whatsoever *how* S performs the match by
>     looking at the above.
> 

'Match' is cool,  but what about more interesting operations like 
'project(join(R1,R2)), R1.a1, R2.b3)'  where R1 is a set of <c,a1,a2,a3> 
tuples and R2 is a set of <c, b1,b2,b3> tuples  ?  How do you express 
that in your fav OO language ?

0
ybk1 (19)
3/6/2008 4:10:31 AM
On 2008-03-04 17:29:01 -0600, TroyK <cs_troyk@juno.com> said:

> On Mar 3, 3:11�pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> On 2008-03-03 12:29:02 -0600, TroyK <cs_tr...@juno.com> said:
>> 
>>> My experience is somewhere between 2 and 3 orders of magnitude
>>> difference between implementing a business rules change in the db vs.
>>> the programming team doing it in OO code.
>> 
>> Then you should be able to fly rings around the programmers and get
>> them all fired. �Why haven't you?
> 
> If by "fly rings around the programmers" you mean having a fully
> functioning reference implementation up and running in SQL within 2
> weeks that ends up taking a team of 3 programmers over 3 months to
> implement in code, then, yeah, I guess I do. But the architecture
> called for the programming to be done in a business layer implemented
> in C# -- we expected and planned for that, so, happily, no one gets
> fired.

I'm sorry, but are you saying that you blithely allowed your 
organization to expend nine man months of fruitless labor?  Or are you 
saying that there was no way your SQL "reference implementation" could 
have been used in production?

-- 
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)
3/6/2008 6:19:59 AM
On 2008-03-05 02:56:02 -0600, "Dmitry A. Kazakov" 
<mailbox@dmitry-kazakov.de> said:

> On Wed, 5 Mar 2008 00:46:14 -0600, Robert Martin wrote:
> 
>> On 2008-03-03 16:49:29 -0600, "David Cressey" <cressey73@verizon.net> said:
>> 
>>> But the idea of a single language that is suitable for everything remains an
>>> elusive goal,  and probably an unproductive endeavor.
>> 
>> Agreed.
> 
> Disagreed.
> 
> The idea of multilingual system is the most damaging thing in software
> developing history.

Whooo!  Then I guess it's back to toggling in binary for us all.

-- 
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)
3/6/2008 6:21:22 AM
On 2008-03-05 10:16:30 -0600, topmind <topmind@technologist.com> said:

> On Mar 4, 10:52 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> On 2008-03-03 17:25:48 -0600, topmind <topm...@technologist.com> said:
>> 
>>> But I think anybody inspecting both examples will clearly see that my
>>> version is a lot less total code.
>> 
>> C++ is a pretty wordy language.  If I wrote it in Ruby I bet I'd beat
>> you by a wide margin.
> 
> I am a skeptical, but you are welcome to try. And, it would probably
> be the meta features of Ruby that cut it down, not OOP.

The "meta" features of Ruby *are* OO.

-- 
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)
3/6/2008 6:23:35 AM
On 2008-03-05 06:48:31 -0600, JOG <jog@cs.nott.ac.uk> said:

>>> 1) So why not treat all 'inheritance' in this way?
>> 
>> Because all inheritance is not about inference.
> 
> Hmmm. Then might you give an example of a situation where inheritance
> cannot be described in terms of inference?

Inheritance is simply the redeclaration of functions and variables in a 
subscope.  That's not inferrence.

-- 
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)
3/6/2008 6:26:12 AM
On 2008-03-05 09:48:45 -0600, Marshall <marshall.spight@gmail.com> said:

> On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>>> 
>>> Furthermore, since OOPLs lack physical independence, traversing
>>> the graph may be quite expensive, particularly in the case where
>>> the graph is backed by storage in a database, which is part of
>>> why ORM is such a universally bad idea.
>> 
>> No, you have this wrong.  ORMs generally use standard SQL queries to
>> traverse and gather data from the DB.  Then that data is placed into OO
>> structures so that the application can take advanage of the bias.
> 
> Just the fact that they use SQL isn't sufficient. They have to
> use it as well as a person could, though an interface that
> is generally information-lossy enough (or at least, used in
> a lossy way) that that's impossible.

Yeah, assembly language programmers used to say the same thing about 
compilers.  Then the compilers started writing more efficient code than 
the assembly language programmers could...

In any case, good ORMs allow you to tune the SQL, so you *can* use it 
as well as a person could.

> The most gratuitous example I can think of was some early
> EJB containers I played with, back when I was still thinking
> that ORM was something that could possibly be done well.
> Against a table of a few hundred rows, one could execute
> "delete from table". The comparable command through the
> ORM issued SQL to load every row as an object, then
> in a loop called obj.delete() which issued a single DELETE
> statement for that row. It was ten thousand times slower,
> and that's for only a couple hundred rows. Of course this
> example is extreme, but it's still illustrative of a general
> principle.

It is illustrative of a programmer who either doesn't know his tool or 
didn't select a reasonable tool.
> 
> I have *often* seen four and five order of magnitude
> performance difference between straight SQL and
> ORM SQL, across a wide variety of ORMs. The
> very idea of ORM demands it: you have to try to
> push a whole set-oriented language through a functional
> interface.

Bah.  You don't *have* to do any such thing.  I won't argue that there 
aren't programmers and teams who use their tools poorly.

-- 
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)
3/6/2008 6:32:54 AM
On 2008-03-05 03:13:59 -0600, "Dmitry A. Kazakov" 
<mailbox@dmitry-kazakov.de> said:

> On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:
> 
>> On 2008-03-03 18:34:39 -0600, Marshall <marshall.spight@gmail.com> said:
>> 
>>> In SQL, if I have two relations with x and y int columns, I can
>>> union them, or join on them, or whatever. There is no way,
>>> in fact, to forbid such a thing, just like in Java there is no way
>>> to allow such a thing.
>> 
>> You are confusing OO with static typing.  In OO languages like Ruby,
>> Python, or Smalltalk you can pass any object to any function
>> irrespective of type.
> 
> Which is a bad idea.

Bah.  It is neither a bad nor a good idea.  It is just an idea.  There 
are advantages to dynamic typing and there are disadvantages.

-- 
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)
3/6/2008 6:38:21 AM
On 2008-03-05 14:10:11 -0600, "Dmitry A. Kazakov" 
<mailbox@dmitry-kazakov.de> said:

> On Wed, 05 Mar 2008 09:57:23 -0500, Thomas Gagne wrote:
> 
>> Dmitry A. Kazakov wrote:
>>> On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:
>>> 
>>>> <snip>
>>>> You are confusing OO with static typing.  In OO languages like Ruby,
>>>> Python, or Smalltalk you can pass any object to any function
>>>> irrespective of type.
>>> 
>>> Which is a bad idea.
>>> 
>> Why?
> 
> Because it is in fact untyped.

No, it's just not statically typed.

-- 
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)
3/6/2008 6:40:18 AM
On 2008-03-05 03:24:37 -0600, S Perryman <q@q.com> said:

> Robert Martin wrote:
> 
>> On 2008-03-03 18:34:39 -0600, Marshall <marshall.spight@gmail.com> said:
> 
>>> In SQL, if I have two relations with x and y int columns, I can
>>> union them, or join on them, or whatever. There is no way,
>>> in fact, to forbid such a thing, just like in Java there is no way
>>> to allow such a thing.
> 
>> You are confusing OO with static typing. In OO languages like Ruby, 
>> Python, or Smalltalk you can pass any object to any function 
>> irrespective of type.
> 
> And you (both) are equating the (strong) typing model of Simula as the
> only strong typing model.

You presume too much.  Type inferrence can be nearly as flexible as 
dynamic typing.

> Go and look at Functional prog langs etc for
> examples of how Marshalls' gripe would be done in a type-safe manner.

Agreed.

-- 
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)
3/6/2008 6:42:42 AM
On 2008-03-05 09:58:43 -0600, Marshall <marshall.spight@gmail.com> said:

>> You are confusing OO with static typing.
> 
> How supremely annoying to have gone to some lengths
> to carefully use the most strictly defined, modern type
> system terminology, only to have it labeled as a novice
> error by someone who missed my point entirely.

How awful for you.

-- 
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)
3/6/2008 6:48:40 AM
On Mar 5, 10:48 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-05 09:58:43 -0600, Marshall <marshall.spi...@gmail.com> said:
>
> >> You are confusing OO with static typing.
>
> > How supremely annoying to have gone to some lengths
> > to carefully use the most strictly defined, modern type
> > system terminology, only to have it labeled as a novice
> > error by someone who missed my point entirely.
>
> How awful for you.

I accept you apology.


Marshall
0
3/6/2008 7:03:26 AM
On Mar 5, 10:40 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-05 14:10:11 -0600, "Dmitry A. Kazakov"
>
> >>>> <snip>
> >>>> You are confusing OO with static typing.  In OO languages like Ruby,
> >>>> Python, or Smalltalk you can pass any object to any function
> >>>> irrespective of type.
>
> >>> Which is a bad idea.
>
> >> Why?
>
> > Because it is in fact untyped.
>
> No, it's just not statically typed.

This issue is entirely tangential to the thread, but just FYI.
There is a strict, formal definition of "type" under which
languages like Python, Smalltalk, etc. are untyped.
This sense of the term is often favored in type theory,
and in fact is the one that introduced the word "type" to
mathematics.

In common parlance, however, untyped languages are
typically called "dynamically typed" in cases where they
employ a runtime tag system to classify values.

I propose the thread is already sufficiently contentious
without introducing further areas of controversy, such
as static typing vs. whatever you care to call the other thing.


Marshall
0
3/6/2008 8:12:17 AM
On Mar 5, 10:38 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-05 03:13:59 -0600, "Dmitry A. Kazakov"
> <mail...@dmitry-kazakov.de> said:
>
> > On Wed, 5 Mar 2008 01:10:01 -0600, Robert Martin wrote:
>
> >> On 2008-03-03 18:34:39 -0600, Marshall <marshall.spi...@gmail.com> said:
>
> >>> In SQL, if I have two relations with x and y int columns, I can
> >>> union them, or join on them, or whatever. There is no way,
> >>> in fact, to forbid such a thing, just like in Java there is no way
> >>> to allow such a thing.
>
> >> You are confusing OO with static typing.  In OO languages like Ruby,
> >> Python, or Smalltalk you can pass any object to any function
> >> irrespective of type.
>
> > Which is a bad idea.
>
> Bah.  It is neither a bad nor a good idea.  It is just an idea.

Yes. Specifically, it is a tradeoff. I still get to prefer one side
over the other though. :-) But that doesn't mean it's not a tradeoff.


Marshall
0
3/6/2008 8:14:14 AM
On Mar 5, 10:32 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-05 09:48:45 -0600, Marshall <marshall.spi...@gmail.com> said:
> > On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>
> >>> Furthermore, since OOPLs lack physical independence, traversing
> >>> the graph may be quite expensive, particularly in the case where
> >>> the graph is backed by storage in a database, which is part of
> >>> why ORM is such a universally bad idea.
>
> >> No, you have this wrong.  ORMs generally use standard SQL queries to
> >> traverse and gather data from the DB.  Then that data is placed into OO
> >> structures so that the application can take advanage of the bias.
>
> > Just the fact that they use SQL isn't sufficient. They have to
> > use it as well as a person could, though an interface that
> > is generally information-lossy enough (or at least, used in
> > a lossy way) that that's impossible.
>
> Yeah, assembly language programmers used to say the same thing about
> compilers.  Then the compilers started writing more efficient code than
> the assembly language programmers could...

I give you high marks for rhetoric here. Excellently argued!
You take the opposing side and compare them to assembly,
and compare yourself with compiled languages. That the
situation is most closely analogous to exactly the reverse
is only relevant if one is interested in a deep understanding
doesn't detract at all from the rhetorical effectiveness.

As an actual engineering argument, though, this fails.
Because it doesn't address the information-loss point I made.
No code generator can write optimal code if it's missing information
necessary to determine what is optimal. Object-graph traversal
in ORMs is *necessarily* more expensive than straightforward SQL.
In part exactly because it is *necessarily* missing the information
present in the head of the programmer who writes instead a single
SQL statement, information that is then embodied in that statement.


> In any case, good ORMs allow you to tune the SQL, so you *can* use it
> as well as a person could.
>
> > The most gratuitous example I can think of was some early
> > EJB containers I played with, back when I was still thinking
> > that ORM was something that could possibly be done well.
> > Against a table of a few hundred rows, one could execute
> > "delete from table". The comparable command through the
> > ORM issued SQL to load every row as an object, then
> > in a loop called obj.delete() which issued a single DELETE
> > statement for that row. It was ten thousand times slower,
> > and that's for only a couple hundred rows. Of course this
> > example is extreme, but it's still illustrative of a general
> > principle.
>
> It is illustrative of a programmer who either doesn't know his tool or
> didn't select a reasonable tool.

I agree that the ultimate problem here is the programmer not
selecting a reasonable tool. In particular, a programmer who
selects an ORM has not selected a reasonable tool.


> > I have *often* seen four and five order of magnitude
> > performance difference between straight SQL and
> > ORM SQL, across a wide variety of ORMs. The
> > very idea of ORM demands it: you have to try to
> > push a whole set-oriented language through a functional
> > interface.
>
> Bah.  You don't *have* to do any such thing.I won't argue that there
> aren't programmers and teams who use their tools poorly.

Nice dodge.

ORMs are a breeding ground for antipatterns. OO code written
in the style you advocate  (Employee.get("bob")) is a performance
disaster first, and benefit-free busy work last.


Marshall
0
3/6/2008 8:29:51 AM
Robert Martin wrote:

 > On 2008-03-05 03:24:37 -0600, S Perryman <q@q.com> said:

 >> Robert Martin wrote:

 >>> You are confusing OO with static typing. In OO languages like Ruby,
 >>> Python, or Smalltalk you can pass any object to any function
 >>> irrespective of type.

 >> And you (both) are equating the (strong) typing model of Simula as the
 >> only strong typing model.

 > You presume too much.

 > Type inferrence can be nearly as flexible as dynamic typing.

1. Type inferencing is *strongly-typed* .

All the process does is construct the effective type on behalf of the
programmer. The type system makes no distinctions between type-checking of
an inferred or manifestly-declared type (static or otherwise) .


2. The only thing that *weakly-typed* type systems (ie those for which
variables, input/output parameters etc have no evident type - which is
actually what most mean by "dynamic typing" ) allow, which strongly-typed
type systems do not, is the following :

op(T)
{
     T.op1() ;
     if(some-condition) { T.op2() ; }
}

Most strongly-typed systems will require T (or any type substitutable
with T) to possess both the op1 and op2 properties in order for an
invocation of op to be allowed (***) .

A weakly-typed system does not care, because all usage of non-existent
properties on a type results in runtime failure at the point of use.


*** Of course, tis a simple matter for a strongly-typed system to infer
     the conditional usage of op2, and generate a "caveat emptor" warning
     for any usage of op where the type of the T instance used does not
     possess the op2 property.


Regards,
Steven Perryman
0
S
3/6/2008 9:39:54 AM
Yagotta B. Kidding wrote:

> S Perryman <q@q.com> wrote in news:fqn0ir$mdg$1@aioe.org:

>>boolean f(Tuple t) { return (t.x = 123) ; }

>>Set<Tuple> S ;

>>Set<Tuple> t = S.match(f) ; // or match(S,f) if one prefers

>>1. How is the above not "set-oriented" ??

>>A set is given as input to a match operation which produces a
>>set as output.

>>2. I have no idea whatsoever *how* S performs the match by
>>    looking at the above.

> 'Match' is cool,  but what about more interesting operations like 
> 'project(join(R1,R2)), R1.a1, R2.b3)'  where R1 is a set of <c,a1,a2,a3> 
> tuples and R2 is a set of <c, b1,b2,b3> tuples  ?  How do you express 
> that in your fav OO language ?

As I have said on numerous occasions, the semantics of "joins" are an
issue for OO (specifically the fact that in OO any of the "values" of
c/a1..a3/b1..b3 could be a computational operation and not a data value
etc) .


Regards,
Steven Perryman
0
S
3/6/2008 9:49:46 AM
On Thu, 6 Mar 2008 00:21:22 -0600, Robert Martin wrote:

> On 2008-03-05 02:56:02 -0600, "Dmitry A. Kazakov" 
> <mailbox@dmitry-kazakov.de> said:
> 
>> On Wed, 5 Mar 2008 00:46:14 -0600, Robert Martin wrote:
>> 
>>> On 2008-03-03 16:49:29 -0600, "David Cressey" <cressey73@verizon.net> said:
>>> 
>>>> But the idea of a single language that is suitable for everything remains an
>>>> elusive goal,  and probably an unproductive endeavor.
>>> 
>>> Agreed.
>> 
>> Disagreed.
>> 
>> The idea of multilingual system is the most damaging thing in software
>> developing history.
> 
> Whooo!  Then I guess it's back to toggling in binary for us all.

That does not imply.

If you concede that in your system it would be OK to use SQL together with
an OOPL X, then your argument of hiding SQL behind the scenes does not
work. Because alleged technical merits of SQL should in some way show
themselves in the design. That is the DB-guys point. (They go further and
propose to scrap X.)

My position is opposite. It is that SQL does not have such merits, it is
there only as an interface to a legacy component. If that component had an
OOPL X interface I would take it instead. It might appear radical, but in
fact this is what all those zillions of language X-to-DBMS-Y bindings are
about.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2008 9:54:07 AM
On Wed, 5 Mar 2008 14:27:58 -0800 (PST), topmind wrote:

> Dmitry A. Kazakov wrote:
>> On Wed, 5 Mar 2008 11:34:05 +0000, Eric wrote:
>>
>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>
>>> I don't believe that merely using an RDBMS will solve all problems. What
>>> I meant was that, accepting what David said above, if you keep your data
>>> in an RDBMS, it will be easily available for the solution of any
>>> possible problem that can be solved using that data.
>>
>> No, this as well is wrong. Keeping "data" in RDBMS puts certain
>> restrictions on what can be stored there and how it can be used later.

[...] 
> A RDMBS
> cannot stop you from doing anything you want to with retrieved data.

Yes, exactly this is wrong. (I hope you don't have in mind retrieving all
content and continuing without RDBMS.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2008 10:08:32 AM
On 3 Mar, 23:37, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> David Cressey wrote:
> > "Bob Badour" <bbad...@pei.sympatico.ca> wrote in message
> >news:47cc383f$0$4041$9a566e8b@news.aliant.net...

> >>It's pretty obvious to me: object-relational mismatch is to relations as=

> >>assembler-object mismatch is to objects.
>
> > I didn't get this comment. =A0Now that someone else has flagged it as a
> > keeper, I feel the need to ask for an explanation.
>
> What do you know about assembler?

- it maps (almost) 1 to 1 to machine code
- the primitive operations are very primitive
- the facilities for combining primitives are crude
- hence doing anything non-trivial takes lots of primitives
- not portable between architectures

are any of those relevent to your statement?

so...
just as assmbler "mismatches" objects
     so objects  "mismatch" relations

so you are saying objects are too low a level of abstraction?


--
Nick Keighley

0
3/6/2008 12:09:58 PM
On Mar 6, 6:26 am, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-05 06:48:31 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> >>> 1) So why not treat all 'inheritance' in this way?
>
> >> Because all inheritance is not about inference.
>
> > Hmmm. Then might you give an example of a situation where inheritance
> > cannot be described in terms of inference?
>
> Inheritance is simply the redeclaration of functions and variables in a
> subscope.

Using nonsense words like 'subscope' doesn't do conversation any
favours Robert. Either way, lets consider the two concepts you
mention. First "variable" inheritance:

A person has a name (string)
A man is a person
|= A man has a name (string)

Okay, thats seems straightforward. So now functions:

A lock_view has an update()
A digital_clock_view is a clock_view
|= a digital_clock_view has an update()

Great, that makes sense too. In fact more than that, it seems entirely
straightforward.

> That's not inferrence.

Well that all jolly-well looks like inference to me. I must have
missed something.<scratches_head/> I don't know, maybe you've gotten
so involved with OO that you can't see the wood from the trees in
terms of abstracting away from the mechanism?

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

0
jog (83)
3/6/2008 12:37:19 PM
On Mar 6, 12:09 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 3 Mar, 23:37, Bob Badour <bbad...@pei.sympatico.ca> wrote:
>
> > David Cressey wrote:
> > > "Bob Badour" <bbad...@pei.sympatico.ca> wrote in message
> > >news:47cc383f$0$4041$9a566e8b@news.aliant.net...
> > >>It's pretty obvious to me: object-relational mismatch is to relations as
> > >>assembler-object mismatch is to objects.
>
> > > I didn't get this comment.  Now that someone else has flagged it as a
> > > keeper, I feel the need to ask for an explanation.
>
> > What do you know about assembler?
>
> - it maps (almost) 1 to 1 to machine code
What is mapping 1:1 between machine code and assembler.  Tis the first
time I hear somebody establishing cardinality between 2 languages.
What a bunch of crap.

> - the primitive operations are very primitive
Uh... I was afraid that primitive operations would be secondary

> - the facilities for combining primitives are crude
? nonsense

> - hence doing anything non-trivial takes lots of primitives
What does that mean?

> - not portable between architectures
>
> are any of those relevent to your statement?
What is relevant is the fact that you have only no clue how assembler
works...

> so...
> just as assmbler "mismatches" objects
>      so objects  "mismatch" relations
What the hell does that mean...

Object/assembler is a sloppy concept compared to a language
Object/Relation is a sloppy concept compared to a mathematical
construct

And you say both are equal...According to what?

> so you are saying objects are too low a level of abstraction?
*Objects* are just vague concept for sloppy thinkers to put their
ignorant teeth onto...

> Nick Keighley

0
cimode (135)
3/6/2008 1:57:58 PM
On 2008-03-05, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 5 Mar 2008 12:22:24 +0000, Eric wrote:
>
>> If you should not use multiple languages, there must be a universal
>> language.
>
> Yep, it is called a universal/general purpose programming language.
>
>> What is it, is it really universal _right now_, and if not,
>
> It is, there exist many of them.

So any general purpose language will do, as long as I use only that? Do
I have to use the same one for the next task?

>
> The mistake you make is in a wrong presumption that "universal purpose" <=>
> "best possible."
>

I presume no such thing. 

Any program can be written in any language, but particular combinations
may be unwise. Why should I not choose the most appropriate language of
those that are currently available to me?

If I bring in an existing API to do some part of the task, why should I
care what it is written in as long as I can call it? If it would help me
to create an additional abstraction layer (i.e. my own API), why should
I not use the most appropriate tool for it? What language do you use,
and what is your math library written in?

>> when will it be and what should we do in the meantime?
>
> Not to develop pet domain-specific languages if the advantages of those are
> unclear. If you, say, wanted to create a declarative language based on
> inference, then that should be a universal purpose one.
>

An API, or an abstraction layer, _is_ a domain-specific language. If it
can be made easier to use by bolting a parser on to the front of it, why
not do that?

E
0
eric154 (81)
3/6/2008 2:30:56 PM
"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
news:47cc8bc8$0$4038$9a566e8b@news.aliant.net...
> David Cressey wrote:
>
> > "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> > news:47cc383f$0$4041$9a566e8b@news.aliant.net...
> >
> >>It's pretty obvious to me: object-relational mismatch is to relations as
> >>assembler-object mismatch is to objects.
> >
> > I didn't get this comment.  Now that someone else has flagged it as a
> > keeper, I feel the need to ask for an explanation.
>
> What do you know about assembler?

I used to work in assembler, a long, long time ago.  Perhaps the most
ambitious project I wrote in assembler was an automatic garbage collector
for MDL,  a programming language in the Lisp family.  That was back in 1971.
I haven't done anything significant in assembler since 1978.



0
cressey73 (124)
3/6/2008 2:46:57 PM
On 2008-03-05, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 5 Mar 2008 11:34:05 +0000, Eric wrote:
>
>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>> I don't believe that merely using an RDBMS will solve all problems. What
>> I meant was that, accepting what David said above, if you keep your data
>> in an RDBMS, it will be easily available for the solution of any
>> possible problem that can be solved using that data.
>
> No, this as well is wrong. Keeping "data" in RDBMS puts certain
> restrictions on what can be stored there and how it can be used later.

No it doesn't, in either case.

>
> You propose a solution (DB on a RDBMS). What was the problem? From your
> description the problem looks like a persistence layer. This what c.d.t.
> people vehemently disagree. Isn't it interesting to see how quickly a great
> theory of all degrades to storage?

A persistence layer is "my program has X, I need put put it away
somewhere and get it back later". As long as what you get back is what
you put, it's OK - no need to worry about the internal details of X or
what it might be related to.

An RDBMS is not a persistence layer. No-one from c.d.t has said that it
can not be used as a persistence layer. What is often said is that using
an RDBMS _merely_ as a persistence layer is a grossly misguided use of
machine and human resources.

The relational model is not a great theory of all, it is a
logically-based recipe for the long-term management of data. You are the
sort of person who degrades it by arguing from a position of ignorance
of what it is really about.

>
>>> I guess that his hidden argument was "because RDB
>>> apparently solves all problems, then data-centric view is the right one."
>> 
>> No, the argument is that the data-centric view is often (not necessarily
>> always) the right one to take, and that keeping the data in an RDBMS
>> provides a better basis for solving future problems using the data than
>> any other way of keeping it.
>
> Ah, that's better. So data-centric view is not universal => then there
> exist cases which cannot be viewed that way => data is not a fundamental
> term => data do not unconditionally exist. Are we in agreement?
>

No we are not. "cannot be viewed" should be "are not best viewed", and
the rest of your implications are nonsense.

>>> Yet another logical fallacy was a data-centric problem statement: "there
>>> will never be any other application that will need my data," used in order
>>> to prove data-centric view itself.
>> 
>> There is no fallacy here. First there is a fact - you have data, however
>> you choose to view it. Do you want to deny this?
>
> Certainly. Non-observable things do not exist. But the fallacy is that you
> are putting existence of data as a fact from which you deduce data
> existence.

I have not deduced data existence from anything, I simply believe it to
be a fact.

>
>>> In OO problems are not modeled in terms
>>> of applications using data.
>> 
>> No, but the data is still there.
>
> In which sense? Laplace has answered this two hundred years ago: "I did not
> need to make such an assumption."
>

Your quote has insufficient context for me to have any idea what you
think it means, or what Laplace thought it meant.

What is your definition of "data"?

E
0
eric154 (81)
3/6/2008 2:58:35 PM
On 2008-03-06, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 5 Mar 2008 14:27:58 -0800 (PST), topmind wrote:
>
>> Dmitry A. Kazakov wrote:
>>> On Wed, 5 Mar 2008 11:34:05 +0000, Eric wrote:
>>>
>>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>
>>>> I don't believe that merely using an RDBMS will solve all problems. What
>>>> I meant was that, accepting what David said above, if you keep your data
>>>> in an RDBMS, it will be easily available for the solution of any
>>>> possible problem that can be solved using that data.
>>>
>>> No, this as well is wrong. Keeping "data" in RDBMS puts certain
>>> restrictions on what can be stored there and how it can be used later.
>
> [...] 
>> A RDMBS
>> cannot stop you from doing anything you want to with retrieved data.
>
> Yes, exactly this is wrong. (I hope you don't have in mind retrieving all
> content and continuing without RDBMS.)
>

This is how any database-using program works - it retrieves the _relevant_
data and does what it needs to do with it. This is not "continuing
without RDBMS". But then you are the person who thinks that a single
tool should be able to do everything. Here is a hammer, please take that
screw out.

E
0
eric154 (81)
3/6/2008 3:04:16 PM
S Perryman <q@q.net> wrote in news:fqoenv$fo4$1@news.datemas.de:

> Yagotta B. Kidding wrote:
> 
>> S Perryman <q@q.com> wrote in news:fqn0ir$mdg$1@aioe.org:
> 
>>>boolean f(Tuple t) { return (t.x = 123) ; }
> 
>>>Set<Tuple> S ;
> 
>>>Set<Tuple> t = S.match(f) ; // or match(S,f) if one prefers
> 
>>>1. How is the above not "set-oriented" ??
> 
>>>A set is given as input to a match operation which produces a
>>>set as output.
> 
>>>2. I have no idea whatsoever *how* S performs the match by
>>>    looking at the above.
> 
>> 'Match' is cool,  but what about more interesting operations like 
>> 'project(join(R1,R2)), R1.a1, R2.b3)'  where R1 is a set of
>> <c,a1,a2,a3> tuples and R2 is a set of <c, b1,b2,b3> tuples  ?  How
>> do you express that in your fav OO language ?
> 
> As I have said on numerous occasions, the semantics of "joins" are an
> issue for OO (specifically the fact that in OO any of the "values" of
> c/a1..a3/b1..b3 could be a computational operation and not a data
> value etc) .

Does "the semantics of "joins" are an issue for OO" mean that relational 
joins cannot be implemented in principle in an object-oriented way ?

> 
> 
> Regards,
> Steven Perryman
> 

0
ybk1 (19)
3/6/2008 3:06:29 PM
On 2008-03-05, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 5 Mar 2008 12:12:47 +0000, Eric wrote:
>
>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:
>>>
>>>> That's what I said - logically possible criteria.
>>>
>>> What about things which cannot be spelt in SQL?
>> 
>> Use the query language (not necessarily SQL) to pass the data to
>> something that can deal with it.
>
> This does not equate to "logically possible criteria." It is "something
> that can understand this."

My statement had two parts, they are about different things both interacting
with the same data. Why are you trying to claim that I said the two parts
are the same, just so you can say they are different?

>
>>> What about response times?
>>> Can you specify/guess an upper bound for all requests? For a certain subset
>>> of?
>> 
>> This is just a prejudice - get the right RDBMS and the right expert to
>> tune it (specifically for what it must do, not generically) and you
>> might be surprised.
>
> This is not a prejudice, this is the point. I don't want to be surprised.
> Engineering is about predictability.

The surprise is you discovering something you did not know, it is not
part of the engineering of the problem or the solution.

>
>>>> Relative to what? Where are the tests? Do you install an RDBMS product
>>>> and just go with whatever myths you have heard lately, or do you get a
>>>> product specialist to sort it out?
>>>
>>> Come on, show me the nearest neighbour search in ten-dimensional space
>>> implemented in RDBMS. What would be the complexity of? You should clearly
>>> understand that it is possible to break the neck of *any* indexing method.
>>> This refutes the argument to "any logically possible criterion.".
>> 
>> But I don't believe that an RDBMS can do everything. I would not be
>> surprised to find the data defining the ten-dimensional space in an
>> RDBMS, but I would never expect to do such a calculation in the query
>> language.
>
> From this I conclude incompleteness of the approach. There is nothing bad
> in that. At this point you should have said, "OK, how could we reason about
> the applicability of this approach (and other approaches)." A framework
> where that could be done is that common ground where c.d.t. and c.o. would
> unite.
>

No-one but you ever said that the approach was complete, and you seem to
have said that only to argue against it.

>>>> I at least have no problem with using OO programming
>>>> for that. Also, that explains your short-term view. But what do you do
>>>> with the data (presumably transformed) that does get kept for longer?
>>>> Put it somewhere that will be available for a variety of expected and
>>>> unexpected uses? But we were here before!
>>>
>>> Yes, here we go again. Data are meaningless if usage is unexpected. Nobody
>>> can use a CD-ROM in a wind-up phonograph, deaf people notably.
>> 
>> No collection of data is useful to everybody, so deaf people have got
>> nothing to do with it.
>
> Theorem: for any collection of data, there exist somebody who does not need
> it.
>  

That's what I said. I only said it to point out its irrelevance.

>> Other than that, you have just demonstrated a lack of understanding of
>> the difference between the logical and the physical. It is possible for
>> me to collect the necessary bits of technology to transfer a piece of
>> music from a CD-ROM to a disc or cylinder for the wind-up phonograph. It
>> is still the same piece of music.
>
> No. Any logical is physical on another abstraction level. Ants do not
> listen to music. Information does not exist without a receiver.
>

False, unknown, false. I might admit that information is not useful
without the possibility of a receiver, but I don't see that it gets us
anywhere. And I thought we were talking about data, not information.

>>> The system does not keep anything it exists and behaves.
>> 
>> But it has inputs and outputs. There may also be a need for it to record
>> some of its behaviour. There may be a reason to keep some of the
>> outputs, or even the inputs (for later extended analysis?). If you have
>> a system that genuinely keeps nothing, I have no argument with how you
>> choose to create it, as long as it works.
>
> No you get me wrong. Of course we do logging, in fact a lot of. The system
> behaves as if it "kept" things. Whether it physically keeps them is an
> implementation detail. Consider sine. Does it keep its output? It is a
> meaningless question. You can tabulate sine and keep the table, you can use
> Chebyshev's polynomials, or you can ask an oracle. It is no matter. Sine is
> a behavior of real numbers.
>

And you never analyse those logs? Anyway, you could, so they are data.

Sine is not a reasonable example, nor is it a behaviour. It is a
mathematical function, a mapping. How can a mapping keep anything? But a
computer program can keep the number that it passes in to an
implementation of sine, and the number that it gets back. They are data.

E
0
eric154 (81)
3/6/2008 3:20:48 PM
On 2008-03-06, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Thu, 6 Mar 2008 00:21:22 -0600, Robert Martin wrote:
>
>> On 2008-03-05 02:56:02 -0600, "Dmitry A. Kazakov" 
>> <mailbox@dmitry-kazakov.de> said:
>> 
>>> On Wed, 5 Mar 2008 00:46:14 -0600, Robert Martin wrote:
>>> 
>>>> On 2008-03-03 16:49:29 -0600, "David Cressey" <cressey73@verizon.net> said:
>>>> 
>>>>> But the idea of a single language that is suitable for everything remains an
>>>>> elusive goal,  and probably an unproductive endeavor.
>>>> 
>>>> Agreed.
>>> 
>>> Disagreed.
>>> 
>>> The idea of multilingual system is the most damaging thing in software
>>> developing history.
>> 
>> Whooo!  Then I guess it's back to toggling in binary for us all.
>
> That does not imply.
>
> If you concede that in your system it would be OK to use SQL together with
> an OOPL X, then your argument of hiding SQL behind the scenes does not
> work. Because alleged technical merits of SQL should in some way show
> themselves in the design. That is the DB-guys point. (They go further and
> propose to scrap X.)

Where do you get this stuff? None of the "DB-guys" said any such things.

>
> My position is opposite. It is that SQL does not have such merits, it is
> there only as an interface to a legacy component. If that component had an
> OOPL X interface I would take it instead. It might appear radical, but in
> fact this is what all those zillions of language X-to-DBMS-Y bindings are
> about.
>

I give up, you do not seem to make any effort to understand what others
are saying, and you argue, not against what is said, but what you think
is said - which you always get wrong!

E
0
eric154 (81)
3/6/2008 3:32:09 PM
Yagotta B. Kidding wrote:

> S Perryman <q@q.net> wrote in news:fqoenv$fo4$1@news.datemas.de:

>>Yagotta B. Kidding wrote:

>>>'Match' is cool,  but what about more interesting operations like 
>>>'project(join(R1,R2)), R1.a1, R2.b3)'  where R1 is a set of
>>><c,a1,a2,a3> tuples and R2 is a set of <c, b1,b2,b3> tuples  ?  How
>>>do you express that in your fav OO language ?

>>As I have said on numerous occasions, the semantics of "joins" are an
>>issue for OO (specifically the fact that in OO any of the "values" of
>>c/a1..a3/b1..b3 could be a computational operation and not a data
>>value etc) .

> Does "the semantics of "joins" are an issue for OO" mean that relational 
> joins cannot be implemented in principle in an object-oriented way ?

IMHO most things can be implemented in principle.
Efficiency etc is another (important) matter.

Thinking out loud ...

My unease about joins is that in the ADT/OO sense, for your example etc we
effectively create instances of a new type whose properties actually belong
to multiple (existing) object instances. Properties that may be realised as
computational operations.

I feel that prevailing impls of OO are not up to the job of doing the
above (although having a consistent Relational infrastructure that apart
from joins - works is and is programmed the same way for both ADT-based and
"data value only" types/tuples - is something I have long wanted) .

I similarly feel that Functional programming may have the answers to the
problems (the execution engines in particular) .

But thinking out loud and "feeling" is hardly knowing (one way or the
other) is it. :-( :-)


Regards,
Steven Perryman
0
S
3/6/2008 4:36:36 PM
S Perryman wrote:

> Yagotta B. Kidding wrote:
> 
>> S Perryman <q@q.com> wrote in news:fqn0ir$mdg$1@aioe.org:
> 
> 
>>> boolean f(Tuple t) { return (t.x = 123) ; }
> 
> 
>>> Set<Tuple> S ;
> 
> 
>>> Set<Tuple> t = S.match(f) ; // or match(S,f) if one prefers
> 
> 
>>> 1. How is the above not "set-oriented" ??
> 
> 
>>> A set is given as input to a match operation which produces a
>>> set as output.
> 
> 
>>> 2. I have no idea whatsoever *how* S performs the match by
>>>    looking at the above.
> 
> 
>> 'Match' is cool,  but what about more interesting operations like 
>> 'project(join(R1,R2)), R1.a1, R2.b3)'  where R1 is a set of 
>> <c,a1,a2,a3> tuples and R2 is a set of <c, b1,b2,b3> tuples  ?  How do 
>> you express that in your fav OO language ?
> 
> 
> As I have said on numerous occasions, the semantics of "joins" are an
> issue for OO (specifically the fact that in OO any of the "values" of
> c/a1..a3/b1..b3 could be a computational operation and not a data value
> etc) .

How is that any different than a relational view? Whether the data is 
calculated or stored directly is irrelevant.
0
bbadour (434)
3/6/2008 5:16:20 PM
S Perryman <q@q.com> wrote in news:fqp6ip$bje$1@aioe.org:

> Yagotta B. Kidding wrote:
 
>> Does "the semantics of "joins" are an issue for OO" mean that
>> relational joins cannot be implemented in principle in an
>> object-oriented way ? 
> 
> IMHO most things can be implemented in principle.
> Efficiency etc is another (important) matter.
> 
> Thinking out loud ...
> 
> My unease about joins is that in the ADT/OO sense, for your example
> etc we effectively create instances of a new type whose properties
> actually belong to multiple (existing) object instances. Properties
> that may be realised as computational operations.
> 
> I feel that prevailing impls of OO are not up to the job of doing the
> above (although having a consistent Relational infrastructure that
> apart from joins - works is and is programmed the same way for both
> ADT-based and "data value only" types/tuples - is something I have
> long wanted) . 


That was refreshingly honest ! Thank you.

However,  without joins what is left of the RM ?  I think that even 
projections are not very palatable to the OO model.  If so,  that leaves 
us with something not very useful for data management at all.


> 
> I similarly feel that Functional programming may have the answers to
> the problems (the execution engines in particular) .

There are some ( http://www.csd.abdn.ac.uk/
~pgray/graduate_course2004/monad.pdf ) but they have a bunch of their own 
issues,  mainly related to join performance (not surprisingly).  But,  I 
agree,  FP way may still bear some relational fruits as opposed to the 
barren OOP tree ;)

> 
> But thinking out loud and "feeling" is hardly knowing (one way or the
> other) is it. :-( :-)
> 
> 
> Regards,
> Steven Perryman
> 

0
ybk1 (19)
3/6/2008 5:19:33 PM
Nick Keighley wrote:

> On 3 Mar, 23:37, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> 
>>David Cressey wrote:
>>
>>>"Bob Badour" <bbad...@pei.sympatico.ca> wrote in message
>>>news:47cc383f$0$4041$9a566e8b@news.aliant.net...
> 
> 
>>>>It's pretty obvious to me: object-relational mismatch is to relations as
>>>>assembler-object mismatch is to objects.
>>
>>>I didn't get this comment.  Now that someone else has flagged it as a
>>>keeper, I feel the need to ask for an explanation.
>>
>>What do you know about assembler?
> 
> 
> - it maps (almost) 1 to 1 to machine code
> - the primitive operations are very primitive
> - the facilities for combining primitives are crude
> - hence doing anything non-trivial takes lots of primitives
> - not portable between architectures
> 
> are any of those relevent to your statement?
> 
> so...
> just as assmbler "mismatches" objects
>      so objects  "mismatch" relations
> 
> so you are saying objects are too low a level of abstraction?

Indeed.
0
bbadour (434)
3/6/2008 5:25:26 PM
David Cressey wrote:

> "Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
> news:47cc8bc8$0$4038$9a566e8b@news.aliant.net...
> 
>>David Cressey wrote:
>>
>>>"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message
>>>news:47cc383f$0$4041$9a566e8b@news.aliant.net...
>>>
>>>>It's pretty obvious to me: object-relational mismatch is to relations as
>>>>assembler-object mismatch is to objects.
>>>
>>>I didn't get this comment.  Now that someone else has flagged it as a
>>>keeper, I feel the need to ask for an explanation.
>>
>>What do you know about assembler?
> 
> I used to work in assembler, a long, long time ago.  Perhaps the most
> ambitious project I wrote in assembler was an automatic garbage collector
> for MDL,  a programming language in the Lisp family.  That was back in 1971.
> I haven't done anything significant in assembler since 1978.

What part of the analogy leaves you confused, then?
0
bbadour (434)
3/6/2008 5:26:28 PM
Marshall wrote:

> On Mar 5, 12:19 pm, rugby fan <q...@q.com> wrote:

SP>But you cannot claim that all OO prog langs will have an implementation
SP>that forces the fallacious "one at a time" scheme

M>Can you name one that doesn't? (I think I agree that
M>one could exist in theory, however.)

>>CLOS, OCaml etc (by virtue of being built on Functional prog langs) .

> Well, hrmm. Let's see. While those are certainly *interesting*
> and *surprising* examples (in this context) I don't know that
> they qualify as counterexamples to my point.

> Take CLOS. It is an object system built on LISP. As such, is
> it fair to consider it in terms of the primitives or "axioms" that
> LISP is built on? 

[ stuff snipped - but read and acknowledged - it helped to clarify
   the point you have wanted to put across. ]


> Many good things can be said of this pattern, but it is not set-oriented.

> I am not familiar enough with OCaml to say much. But
> if we were talking SML, (a language I have the utmost
> respect for) I would still not consider it set-oriented.
> map(), filter(), fold(), while providing collection-oriented
> interfaces, are typically not primitive in the language.

OK.
You regard "X-oriented" as something for which the facilities to support
X are provided at a fundamental level (like arithmetic ops, CAR/CDR in
Lisp etc) and not built (by whoever) from the fundamental constructs of
a prog lang.

Fair enough.


M>Why are you bringing up functional programming when
M>talking about OOPLs?

>>Because FP has :

>>- been able to support OO quite easily

>>- has an interesting execution infrastructure that IMHO makes it a
>>   good candidate for supporting the Relational paradigm

> Hrmmm, well, I have to admit you make a good argument here.
> (Although you must grant me that, we people speak of OOPLs,
> they are not usually thinking CLOS!)

I would not call it an "argument" as such.
More thinking out loud about candidate technologies for resolving
the impedence problem (conceptually and performance-wise) .


> But I am, rather, speaking of what languages' axiomatic natures are.
> I could, in fact, write a Relation class in Java, and provide set-
> oriented
> methods for it, and a whole host of relational goodness. But that
> wouldn't make Java a relational language per se.

> Virtually no languages have primitive support for anything like a
> collection. SQL and SETL and a few others; that's it. There are
> some languages that were designed from the start with *list*
> processing in mind: lisp (and I should probably also mention the
> APL family here.) There are some *very* interesting things
> in there, but not things I would say could be strictly described
> as set-oriented.

I take a slightly different view in that I obviously have the need
for various collection types, and support for a Relational "calculus"
to use on those collections. I also need support for collections of
ADTs in particular.

If possible I would like the prog lang user to be able to construct
specific collections such as sets etc, and for the prog lang env to be
within reasonable performance of something that is designed for the
support of some one specific aspect (as Lisp is for lists etc) .

I think that FP is the paradigm that could possibly do this.


Regards,
Steven Perryman
0
S
3/6/2008 5:27:44 PM
Bob Badour wrote:

> S Perryman wrote:

>> Yagotta B. Kidding wrote:

>>> 'Match' is cool,  but what about more interesting operations like 
>>> 'project(join(R1,R2)), R1.a1, R2.b3)'  where R1 is a set of 
>>> <c,a1,a2,a3> tuples and R2 is a set of <c, b1,b2,b3> tuples  ?  How 
>>> do you express that in your fav OO language ?

>> As I have said on numerous occasions, the semantics of "joins" are an
>> issue for OO (specifically the fact that in OO any of the "values" of
>> c/a1..a3/b1..b3 could be a computational operation and not a data value
>> etc) .

> How is that any different than a relational view?  Whether the data is
> calculated or stored directly is irrelevant.

I know this should be true, but something in my head keeps screaming
"its' not that simple !!!" . :-( :-)

I feel that thoughts of specific impls of both RDBs and OO prog langs are
perhaps preventing me from stepping back and seeing things cleanly.

But I am interested in exploring the notion of an 'ADT join' and
how it might be implemented by an OO prog lang.


Regards,
Steven Perryman
0
S
3/6/2008 5:39:12 PM
On Thu, 6 Mar 2008 14:58:35 +0000, Eric wrote:

> I have not deduced data existence from anything, I simply believe it to
> be a fact.

I see, it is a theological issue then. You are free too believe in what you
want. That is out of my interest. 

>>>> In OO problems are not modeled in terms
>>>> of applications using data.
>>> 
>>> No, but the data is still there.
>>
>> In which sense? Laplace has answered this two hundred years ago: "I did not
>> need to make such an assumption."
> 
> Your quote has insufficient context for me to have any idea what you
> think it means, or what Laplace thought it meant.

He meant beliefs.

> What is your definition of "data"?

I don't need it defined. But if you ask it is

   _value_

Specifically, one of some *built-in* type. A low-level abstraction concept
typical to early universal purpose programming languages without ADTs, like
FORTRAN. Data are aggregated mechanically without further abstraction.

Contemporary use examples are data-oriented domain-specific 4GL, like SQL
(data query), Simulink (signal processing). Weak point is presumption of
equality of the domain entities and the computational objects and thus 1)
built-in types, 2) deduced algorithms from a narrow set (indexing in RDBMS,
equation solving in Simulink). This is also the criterion of applicability
of a given data-oriented language.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2008 5:48:16 PM
On Thu, 6 Mar 2008 15:04:16 +0000, Eric wrote:

> On 2008-03-06, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 5 Mar 2008 14:27:58 -0800 (PST), topmind wrote:
>>
>>> Dmitry A. Kazakov wrote:
>>>> On Wed, 5 Mar 2008 11:34:05 +0000, Eric wrote:
>>>>
>>>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>>
>>>>> I don't believe that merely using an RDBMS will solve all problems. What
>>>>> I meant was that, accepting what David said above, if you keep your data
>>>>> in an RDBMS, it will be easily available for the solution of any
>>>>> possible problem that can be solved using that data.
>>>>
>>>> No, this as well is wrong. Keeping "data" in RDBMS puts certain
>>>> restrictions on what can be stored there and how it can be used later.
>>
>> [...] 
>>> A RDMBS
>>> cannot stop you from doing anything you want to with retrieved data.
>>
>> Yes, exactly this is wrong. (I hope you don't have in mind retrieving all
>> content and continuing without RDBMS.)
> 
> This is how any database-using program works - it retrieves the _relevant_
> data and does what it needs to do with it.

I wrote about "all" in order to exclude an argument to completeness. If it
is not all, then "anything" does not apply.

(Simple example: a stream can be accessed randomly only if all read.)

I.e. the argument is wrong.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2008 5:49:27 PM
Yagotta B. Kidding wrote:

> S Perryman <q@q.com> wrote in news:fqp6ip$bje$1@aioe.org:

>>Yagotta B. Kidding wrote:

YK>Does "the semantics of "joins" are an issue for OO" mean that
YK>relational joins cannot be implemented in principle in an
YK>object-oriented way ?

YK>IMHO most things can be implemented in principle.
YK>Efficiency etc is another (important) matter.

>>Thinking out loud ...

>>My unease about joins is that in the ADT/OO sense, for your example
>>etc we effectively create instances of a new type whose properties
>>actually belong to multiple (existing) object instances. Properties
>>that may be realised as computational operations.

>>I feel that prevailing impls of OO are not up to the job of doing the
>>above (although having a consistent Relational infrastructure that
>>apart from joins - works is and is programmed the same way for both
>>ADT-based and "data value only" types/tuples - is something I have
>>long wanted) . 

> That was refreshingly honest ! Thank you.

Which is in the main, only opinions. Nothing objectively provable etc.


> However, without joins what is left of the RM ?

The ability to construct arbitrary set/predicate-based expressions to
access entities in some given info base is still very valuable, is it not.


> I think that even projections are not very palatable to the OO model.

Projection is covered by type substitutability at the basic level.
It is only a problem for specific substitutability models (the Simula
model being a case in point) .


>>I similarly feel that Functional programming may have the answers to
>>the problems (the execution engines in particular) .

> There are some ( http://www.csd.abdn.ac.uk/
> ~pgray/graduate_course2004/monad.pdf ) but they have a bunch of their own 
> issues, mainly related to join performance (not surprisingly). But, I 
> agree, FP way may still bear some relational fruits as opposed to the 
> barren OOP tree ;)

 From my undergrad times, the things about FP execution envs that impressed
me was the organisation of programs as directed graphs, sharing the same
program graphs, lazy evaluation etc. A lot of this looks to me like it may
provide some of the performance gains needed for a 'Relational OO' system
to perform comparably to your typical SQL engine etc.

But again, merely opinion.


Regards,
Steven Perryman
0
S
3/6/2008 5:52:59 PM
On Thu, 6 Mar 2008 14:30:56 +0000, Eric wrote:

> On 2008-03-05, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 5 Mar 2008 12:22:24 +0000, Eric wrote:
>>
>>> If you should not use multiple languages, there must be a universal
>>> language.
>>
>> Yep, it is called a universal/general purpose programming language.
>>
>>> What is it, is it really universal _right now_, and if not,
>>
>> It is, there exist many of them.
> 
> So any general purpose language will do, as long as I use only that? Do
> I have to use the same one for the next task?

Yes, but purpose is not the only criterion. For that matter, VB is a
general purpose language.

>> The mistake you make is in a wrong presumption that "universal purpose" <=>
>> "best possible."
> 
> I presume no such thing. 
> 
> Any program can be written in any language, but particular combinations
> may be unwise. Why should I not choose the most appropriate language of
> those that are currently available to me?

Because it is bad engineering. Any possible local advantage will be
consumed by multilingual impedance.

> If I bring in an existing API to do some part of the task, why should I
> care what it is written in as long as I can call it? If it would help me
> to create an additional abstraction layer (i.e. my own API), why should
> I not use the most appropriate tool for it?

Because it is software design / performance / maintenance nightmare.

> What language do you use,
> and what is your math library written in?

This is a poor example.

Firstly math libraries of elementary functions are more or less well
defined, deeply studied, solid mathematical and CS background. The
interfaces and implementations are stable. It is not my system, I don't
program them.

Secondly, certainly I would like them rewritten in a language better than
K&R C / FORTRAN IV. These languages have undefined numeric behavior in
numerous cases. I prefer exceptions and interval computation based version.
I would like flexible precision control, as well as fixed-point versions
and dimensioned versions. Neither could be delivered in C/FORTRAN.

>>> when will it be and what should we do in the meantime?
>>
>> Not to develop pet domain-specific languages if the advantages of those are
>> unclear. If you, say, wanted to create a declarative language based on
>> inference, then that should be a universal purpose one.
> 
> An API, or an abstraction layer, _is_ a domain-specific language. If it
> can be made easier to use by bolting a parser on to the front of it, why
> not do that?

Because handicraft is not engineering. Statistically this does not pay off.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2008 6:12:20 PM
On Thu, 6 Mar 2008 15:20:48 +0000, Eric wrote:

> On 2008-03-05, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 5 Mar 2008 12:12:47 +0000, Eric wrote:
>>
>>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> On Tue, 4 Mar 2008 20:26:01 +0000, Eric wrote:
>>>>
>>>>> That's what I said - logically possible criteria.
>>>>
>>>> What about things which cannot be spelt in SQL?
>>> 
>>> Use the query language (not necessarily SQL) to pass the data to
>>> something that can deal with it.
>>
>> This does not equate to "logically possible criteria." It is "something
>> that can understand this."
> 
> My statement had two parts, they are about different things both interacting
> with the same data. Why are you trying to claim that I said the two parts
> are the same, just so you can say they are different?

I didn't. I just asked for a specification of "any logically possible
criterion" to give you enough rope to hang yourself.

>>>> What about response times?
>>>> Can you specify/guess an upper bound for all requests? For a certain subset
>>>> of?
>>> 
>>> This is just a prejudice - get the right RDBMS and the right expert to
>>> tune it (specifically for what it must do, not generically) and you
>>> might be surprised.
>>
>> This is not a prejudice, this is the point. I don't want to be surprised.
>> Engineering is about predictability.
> 
> The surprise is you discovering something you did not know, it is not
> part of the engineering of the problem or the solution.

Discovering new things is called research. If I were at a university I
would enjoy surprises, but then RDBMS would draw my attention even lesser
than now.

>>>>> Relative to what? Where are the tests? Do you install an RDBMS product
>>>>> and just go with whatever myths you have heard lately, or do you get a
>>>>> product specialist to sort it out?
>>>>
>>>> Come on, show me the nearest neighbour search in ten-dimensional space
>>>> implemented in RDBMS. What would be the complexity of? You should clearly
>>>> understand that it is possible to break the neck of *any* indexing method.
>>>> This refutes the argument to "any logically possible criterion.".
>>> 
>>> But I don't believe that an RDBMS can do everything. I would not be
>>> surprised to find the data defining the ten-dimensional space in an
>>> RDBMS, but I would never expect to do such a calculation in the query
>>> language.
>>
>> From this I conclude incompleteness of the approach. There is nothing bad
>> in that. At this point you should have said, "OK, how could we reason about
>> the applicability of this approach (and other approaches)." A framework
>> where that could be done is that common ground where c.d.t. and c.o. would
>> unite.
> 
> No-one but you ever said that the approach was complete, and you seem to
> have said that only to argue against it.

You already said that. But you didn't confirmed understanding the
implications I wrote about.
 
>>> Other than that, you have just demonstrated a lack of understanding of
>>> the difference between the logical and the physical. It is possible for
>>> me to collect the necessary bits of technology to transfer a piece of
>>> music from a CD-ROM to a disc or cylinder for the wind-up phonograph. It
>>> is still the same piece of music.
>>
>> No. Any logical is physical on another abstraction level. Ants do not
>> listen to music. Information does not exist without a receiver.
> 
> False, unknown, false. I might admit that information is not useful
> without the possibility of a receiver, but I don't see that it gets us
> anywhere. And I thought we were talking about data, not information.

In your other post you said that data is a belief. So information must be
another one, even more fuzzy and thus requiring a greater portion of
mysticism...

>>>> The system does not keep anything it exists and behaves.
>>> 
>>> But it has inputs and outputs. There may also be a need for it to record
>>> some of its behaviour. There may be a reason to keep some of the
>>> outputs, or even the inputs (for later extended analysis?). If you have
>>> a system that genuinely keeps nothing, I have no argument with how you
>>> choose to create it, as long as it works.
>>
>> No you get me wrong. Of course we do logging, in fact a lot of. The system
>> behaves as if it "kept" things. Whether it physically keeps them is an
>> implementation detail. Consider sine. Does it keep its output? It is a
>> meaningless question. You can tabulate sine and keep the table, you can use
>> Chebyshev's polynomials, or you can ask an oracle. It is no matter. Sine is
>> a behavior of real numbers.
> 
> And you never analyse those logs? Anyway, you could, so they are data.

How one follows from another?

> Sine is not a reasonable example, nor is it a behaviour. It is a
> mathematical function, a mapping. How can a mapping keep anything? But a
> computer program can keep the number that it passes in to an
> implementation of sine, and the number that it gets back. They are data.

Let I store all these data in a RDBMS, would in be same data but different
sine? Does SELECT y FROM sine WHEN x= behave differently from sine?

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/6/2008 6:38:53 PM
On Mar 6, 10:38=A0am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> Does SELECT y FROM sine WHEN x=3D behave differently from sine?

OK, this is actually a good Turing test. So what function the
following query

SELECT x FROM sine WHEN y=3D0.5

represent?
0
3/6/2008 6:55:35 PM
Tegiri Nenashi wrote:

> On Mar 6, 10:38 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>Does SELECT y FROM sine WHEN x= behave differently from sine?
> 
> 
> OK, this is actually a good Turing test. So what function the
> following query
> 
> SELECT x FROM sine WHEN y=0.5
> 
> represent?

arcsine(0.5)
0
bbadour (434)
3/6/2008 7:06:03 PM
Tegiri Nenashi wrote:

> On Mar 6, 10:38 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
> 
>>Does SELECT y FROM sine WHEN x= behave differently from sine?
> 
> 
> OK, this is actually a good Turing test. So what function the
> following query
> 
> SELECT x FROM sine WHEN y=0.5
> 
> represent?

Er, no wait! What are the attributes of sine?
0
bbadour (434)
3/6/2008 7:09:00 PM
On Mar 6, 11:06=A0am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> Tegiri Nenashi wrote:
> > On Mar 6, 10:38 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
>
> >>Does SELECT y FROM sine WHEN x=3D behave differently from sine?
>
> > OK, this is actually a good Turing test. So what function the
> > following query
>
> > SELECT x FROM sine WHEN y=3D0.5
>
> > represent?
>
> arcsine(0.5)

Eh, Bob, spoled all the fun -- I didn't doubt you (or anybody on
relational side) would solve this easily. I honestly wanted to clarify
how capable the other side is...
0
3/6/2008 7:12:34 PM
On Mar 6, 7:20 am, Eric <e...@deptj.demon.co.uk> wrote:
>
> Sine is not a reasonable example, nor is it a behaviour. It is a
> mathematical function, a mapping.

What is your definition of "behavior"? How specifically (if at all)
does it differ from "sending a message", "invoking a function"
and "invoking a method"? Does that distinction (if it exists)
exist for methods of value classes? Of classes with mutable
state?

I am curious. I am also curious to see the degree of agreement
between your answers and other comp.object regulars.


Marshall
0
3/6/2008 7:33:03 PM
On Mar 6, 9:39=A0am, S Perryman <q...@q.com> wrote:
> I am interested in exploring the notion of an 'ADT join' and
> how it might be implemented by an OO prog lang.

Join is indeed the most interesting operation. In the other message
you dismissed projection as being covered by the concept of
subclassing. Can you please be more specific? If we remove some [data]
attributes, does it mean the resulting "entity" is a subclass. Then
consider selection. One might be tempted to reason that it is a
selection that makes a subclass by restricting to a subset of
objects.

The duality between rows and columns (tuples and attributes) IMO has
something to do with those pepetuum motion LSP debates. I can suggest
that FCA method (which I mentioned in the very beginning of this flame
war) is the right foundation for class hierarchy.

0
3/6/2008 7:37:51 PM
Tegiri Nenashi wrote:

> On Mar 6, 9:39 am, S Perryman <q...@q.com> wrote:

>>I am interested in exploring the notion of an 'ADT join' and
>>how it might be implemented by an OO prog lang.

> Join is indeed the most interesting operation.

> In the other message
> you dismissed projection as being covered by the concept of
> subclassing.

No. Projection is covered by *type substitutability* .


> Can you please be more specific? If we remove some [data]
> attributes, does it mean the resulting "entity" is a subclass.

No, merely that the resulting entity is now deemed to be of
another type, substitutable with the original type.

type T
{
    x, y, z
}

Set<T> ts ;
Set< type { x, y } > ps = { e IN ts : e.x > 123 } ;

The elements of ps are effectively projections of the elements in ts.


> Then consider selection. One might be tempted to reason that it is a
> selection that makes a subclass by restricting to a subset of
> objects.

Here you might be talking about what Wegner and Zdonik (1988) termed
"subset subtypes" , whereby the set of values applicable to subtype
properties is a subset of those applicable to the supertype. Off-hand
mental recall of one of their examples :

type Person
{
    name : string ;
    age : [0..long-time] ;
}

type Employee
{
    name : string ;
    age : [16..long-time] ;
}


The set of Employee instances is a subset of the set of Person instances.


> The duality between rows and columns (tuples and attributes) IMO has
> something to do with those pepetuum motion LSP debates.

Not really.

The "LSP debates" come from the fact that Liskov/Wing types (and subtype
relationships thereof) are governed by semantics such as pre/post/invariant
conditions. Conflicts between such definitions cause substitutability
violations. But sadly are often claimed/confused as issues of "mutability"
etc.


Regards,
Steven Perryman
0
S
3/6/2008 8:08:51 PM
S Perryman <q@q.com> wrote in news:fqpj0o$lke$1@aioe.org:

> Tegiri Nenashi wrote:
> 
>> On Mar 6, 9:39 am, S Perryman <q...@q.com> wrote:
> 
>>>I am interested in exploring the notion of an 'ADT join' and
>>>how it might be implemented by an OO prog lang.
> 
>> Join is indeed the most interesting operation.
> 
>> In the other message
>> you dismissed projection as being covered by the concept of
>> subclassing.
> 
> No. Projection is covered by *type substitutability* .
> 
> 
>> Can you please be more specific? If we remove some [data]
>> attributes, does it mean the resulting "entity" is a subclass.
> 
> No, merely that the resulting entity is now deemed to be of
> another type, substitutable with the original type.
> 
> type T
> {
>     x, y, z
> }
> 
> Set<T> ts ;
> Set< type { x, y } > ps = { e IN ts : e.x > 123 } ;
> 
> The elements of ps are effectively projections of the elements in ts.
> 

Hold on,  you have a value of type Set<T> assigned to a variable of type 
Set<type{x,y}>.  How is it even syntactically correct ?  Is not 
assignment of a value of one type to a variable of another type illegal 
??? It's,  like, totally basic stuff they teach you about typing and such 
!  Methinks you've made an inadvertent mistake,  didn't you ?

0
ybk1 (19)
3/6/2008 8:30:00 PM
On Mar 6, 9:27 am, S Perryman <q...@q.com> wrote:
> Marshall wrote:
>
> > Many good things can be said of this pattern, but it is not set-oriented.
> > I am not familiar enough with OCaml to say much. But
> > if we were talking SML, (a language I have the utmost
> > respect for) I would still not consider it set-oriented.
> > map(), filter(), fold(), while providing collection-oriented
> > interfaces, are typically not primitive in the language.
>
> OK.
> You regard "X-oriented" as something for which the facilities to support
> X are provided at a fundamental level (like arithmetic ops, CAR/CDR in
> Lisp etc) and not built (by whoever) from the fundamental constructs of
> a prog lang.
>
> Fair enough.

Right. If we consider *potential* built constructs, and we are
speaking of general purpose programming languages, then
right away all languages collapse into a single category.

We might make some allowances for languages whose standard
library contains specific constructs, however. We might reasonably
classify some functional languages that make extensive use of
map, filter, and fold as being at least modestly list-oriented,
despite the fact that their list constructs are really recursively
defined union types. But it's probably better to consider the
recursively defined type together with the higher-order function
constructs as being the axiomatic signature of such languages.

Another important reason to consider the fundamental constructs
of a PL is so that we can treat the PL as an axiomatic system.
To me, the most interesting thing one can do with code is
*reason* about it. This is why type systems are interesting
(and "dynamically typed" languages not so much.) It's also
part of why the relational model is so interesting. And it's
why OOPLs don't hold my interest so much any more;
their axioms are complicated and often weak.


> M>Why are you bringing up functional programming when
> M>talking about OOPLs?
>
> >>Because FP has :
> >>- been able to support OO quite easily
> >>- has an interesting execution infrastructure that IMHO makes it a
> >>   good candidate for supporting the Relational paradigm
> > Hrmmm, well, I have to admit you make a good argument here.
> > (Although you must grant me that, we people speak of OOPLs,
> > they are not usually thinking CLOS!)
>
> I would not call it an "argument" as such.
> More thinking out loud about candidate technologies for resolving
> the impedence problem (conceptually and performance-wise) .

By all means, please continue to think out loud. You do it well.


> > But I am, rather, speaking of what languages' axiomatic natures are.
> > I could, in fact, write a Relation class in Java, and provide set-
> > oriented
> > methods for it, and a whole host of relational goodness. But that
> > wouldn't make Java a relational language per se.
> > Virtually no languages have primitive support for anything like a
> > collection. SQL and SETL and a few others; that's it. There are
> > some languages that were designed from the start with *list*
> > processing in mind: lisp (and I should probably also mention the
> > APL family here.) There are some *very* interesting things
> > in there, but not things I would say could be strictly described
> > as set-oriented.
>
> I take a slightly different view in that I obviously have the need
> for various collection types, and support for a Relational "calculus"
> to use on those collections. I also need support for collections of
> ADTs in particular.

The collections question is quite interesting: Lists, maps, bags,
sets, tables, trees. It is apparent after only a modest amount
of study that maps, sets, and tables are thoroughly and beautifully
handled with relations. It took me a lot longer but I've reached
the conclusion that lists fall in to the same category.

Trees no longer seem like a single category to me: there
are what I call "statically structured" trees, for example
Customers/ Invoices/InvoiceLineItems, and "dynamically
structured" trees, such as a parse tree. Statically structured
trees are are a particular strong point for SQL and also a
strong point for the RM. Dynamically structured trees *can be*
handled with the RM but I don't think it does as good a job
as is done in, say, FP languages with union types and
structural recursion. I conjecture that it may be possible
to develop best practices and/or tiny extensions to the
RM such that it does as good a job, but currently I'm
leaning in the direction of thinking this will not be possible.
I'm not completely thrilled with structural recursion, but
I have yet to see anything better.

Bags I have not looked at in any detail. They are certainly
the least important of the lot, however.


> If possible I would like the prog lang user to be able to construct
> specific collections such as sets etc, and for the prog lang env to be
> within reasonable performance of something that is designed for the
> support of some one specific aspect (as Lisp is for lists etc) .
>
> I think that FP is the paradigm that could possibly do this.

An important aspect of the performance requirement is physical
independence, something that is largely ignored in PL theory,
sadly.

FP is an important area for study, no doubt.

If we look at the mathematical universe, we usually encounter
an extensional viewpoint. And if something is expressed
intensionally, or algorithmically, mathematicians are free to
immediately think of its extension, because they do not have
to limit themselves to what is computable.

On the other hand, if we look at the computable universe, we
see more often the intensional viewpoint. And we are not
free to immediately shift into extensional mode, because
of the possibly-infinite, almost-certainly-prohibitive cost of
doing so.

The RM gives the best handle on the computably extensional
viewpoint I have encountered. FP gives the best handle
on the intensional viewpoint.

There's more to this line of thought, but it's lunchtime!


Marshall
0
3/6/2008 8:37:06 PM

Robert Martin wrote:
> On 2008-03-05 09:48:45 -0600, Marshall <marshall.spight@gmail.com> said:
>
> > On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> >>>
> >>> Furthermore, since OOPLs lack physical independence, traversing
> >>> the graph may be quite expensive, particularly in the case where
> >>> the graph is backed by storage in a database, which is part of
> >>> why ORM is such a universally bad idea.
> >>
> >> No, you have this wrong.  ORMs generally use standard SQL queries to
> >> traverse and gather data from the DB.  Then that data is placed into OO=

> >> structures so that the application can take advanage of the bias.
> >
> > Just the fact that they use SQL isn't sufficient. They have to
> > use it as well as a person could, though an interface that
> > is generally information-lossy enough (or at least, used in
> > a lossy way) that that's impossible.
>
> Yeah, assembly language programmers used to say the same thing about
> compilers.  Then the compilers started writing more efficient code than
> the assembly language programmers could...
>
> In any case, good ORMs allow you to tune the SQL, so you *can* use it
> as well as a person could.
>
> > The most gratuitous example I can think of was some early
> > EJB containers I played with, back when I was still thinking
> > that ORM was something that could possibly be done well.
> > Against a table of a few hundred rows, one could execute
> > "delete from table". The comparable command through the
> > ORM issued SQL to load every row as an object, then
> > in a loop called obj.delete() which issued a single DELETE
> > statement for that row. It was ten thousand times slower,
> > and that's for only a couple hundred rows. Of course this
> > example is extreme, but it's still illustrative of a general
> > principle.
>
> It is illustrative of a programmer who either doesn't know his tool or
> didn't select a reasonable tool.
> >
> > I have *often* seen four and five order of magnitude
> > performance difference between straight SQL and
> > ORM SQL, across a wide variety of ORMs. The
> > very idea of ORM demands it: you have to try to
> > push a whole set-oriented language through a functional
> > interface.
>
> Bah.  You don't *have* to do any such thing.  I won't argue that there
> aren't programmers and teams who use their tools poorly.

The industry is full of horror stories with regard to ORM mappers.
They are either a pain in the butt, or expensive to find and hire good
ORM experts for. It is a waste of resources to translate back and
forth between two fairly high-level paradigms. Embrace the RDB and
don't use heavy OOP for domain nouns, and you have less headaches.

>
> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com
> Object Mentor Inc.=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=
=BD=EF=BF=BD| blog:=EF=BF=BD=EF=BF=BDwww.butunclebob.com

-T-
0
topmind (2124)
3/6/2008 8:54:27 PM

Dmitry A. Kazakov wrote:
> On Wed, 5 Mar 2008 14:27:58 -0800 (PST), topmind wrote:
>
> > Dmitry A. Kazakov wrote:
> >> On Wed, 5 Mar 2008 11:34:05 +0000, Eric wrote:
> >>
> >>> On 2008-03-04, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> >>
> >>> I don't believe that merely using an RDBMS will solve all problems. What
> >>> I meant was that, accepting what David said above, if you keep your data
> >>> in an RDBMS, it will be easily available for the solution of any
> >>> possible problem that can be solved using that data.
> >>
> >> No, this as well is wrong. Keeping "data" in RDBMS puts certain
> >> restrictions on what can be stored there and how it can be used later.
>
> [...]
> > A RDMBS
> > cannot stop you from doing anything you want to with retrieved data.
>
> Yes, exactly this is wrong.

Is this turning into a strong-typing debate? I am not here to debate
types.  I am a dynamic/no-typing fan (although they do have their
domains where they have a net benefit).

> (I hope you don't have in mind retrieving all
> content and continuing without RDBMS.)

Huh?

>
> --
> Regards,
> Dmitry A. Kazakov
> http://www.dmitry-kazakov.de

-T-
0
topmind (2124)
3/6/2008 9:00:02 PM
Tegiri Nenashi wrote:

> On Mar 6, 11:06 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> 
>>Tegiri Nenashi wrote:
>>
>>>On Mar 6, 10:38 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
>>>wrote:
>>
>>>>Does SELECT y FROM sine WHEN x= behave differently from sine?
>>
>>>OK, this is actually a good Turing test. So what function the
>>>following query
>>
>>>SELECT x FROM sine WHEN y=0.5
>>
>>>represent?
>>
>>arcsine(0.5)
> 
> Eh, Bob, spoled all the fun -- I didn't doubt you (or anybody on
> relational side) would solve this easily. I honestly wanted to clarify
> how capable the other side is...

Actually, I take back my answer. I don't know the header of sine; it 
could have a header like:

sine(x,y,r,theta,sin,cos,tan)

where:
sin = y/r
cos = x/r
tan = y/x

etc.

In that case, the function you gave above is just the set of real 
numbers or whatever lame approximation of the reals we are using.
0
bbadour (434)
3/6/2008 10:17:23 PM
Cimode <cimode@hotmail.com> wrote:

>On Mar 6, 12:09 pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
>wrote:

[snip]

>> - it maps (almost) 1 to 1 to machine code
>What is mapping 1:1 between machine code and assembler.  Tis the first
>time I hear somebody establishing cardinality between 2 languages.
>What a bunch of crap.

     Nope.  Most assembler instructions translate to one machine
instruction each.  That is the mapping that is being referred to.  It
is not perfect as there are pseudo-ops and macros, but it holds in
general.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
genew (1214)
3/6/2008 10:20:50 PM
"Marshall" <marshall.spight@gmail.com> wrote in message
news:3847aed1-f962-4751-b7bb-d352d3e9bc24@d21g2000prf.googlegroups.com...

> Bags I have not looked at in any detail. They are certainly
> the least important of the lot, however.


But bags are so very, very easy to implement!

This is not intended to be facetious.  What I'm driving at is that practical
systems that evolve with little theoretical foundation tend to implement
bags because it's easier than not implementing bags.  An example might be
SQL, whose tables represent bags unless good luck, disciplined writing, or
declared constraints result in tables that always represent sets.



0
cressey73 (124)
3/7/2008 12:55:12 PM
On Mar 5, 11:19=A0pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-04 17:29:01 -0600, TroyK <cs_tr...@juno.com> said:
>
>
>
>
>
> > On Mar 3, 3:11=A0pm, Robert Martin <uncle...@objectmentor.com> wrote:
> >> On 2008-03-03 12:29:02 -0600, TroyK <cs_tr...@juno.com> said:
>
> >>> My experience is somewhere between 2 and 3 orders of magnitude
> >>> difference between implementing a business rules change in the db vs.
> >>> the programming team doing it in OO code.
>
> >> Then you should be able to fly rings around the programmers and get
> >> them all fired. =A0Why haven't you?
>
> > If by "fly rings around the programmers" you mean having a fully
> > functioning reference implementation up and running in SQL within 2
> > weeks that ends up taking a team of 3 programmers over 3 months to
> > implement in code, then, yeah, I guess I do. But the architecture
> > called for the programming to be done in a business layer implemented
> > in C# -- we expected and planned for that, so, happily, no one gets
> > fired.
>
> I'm sorry, but are you saying that you blithely allowed your
> organization to expend nine man months of fruitless labor? =A0Or are you
> saying that there was no way your SQL "reference implementation" could
> have been used in production?
>
> --
> Robert C. Martin (Uncle Bob)=A0=A0| email: uncle...@objectmentor.com
> Object Mentor Inc.=A0 =A0 =A0 =A0 =A0 =A0=A0| blog:=A0=A0www.butunclebob.c=
om
> The Agile Transition Experts=A0=A0| web:=A0=A0=A0www.objectmentor.com
> 800-338-6716=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=A0|- Hide quoted text -
>
> - Show quoted text -

The discussion is about the veracity of the claims of orders of
magnitude difference in the expression and implementation of business
rules in SQL vs. in "application code". The architectural decisions
and guidelines at play in my company, however, are not up for
discussion.

I'm assuming at this point that you accept the claims made by myself
and Roy. If you have experience or data that contradicts these claims,
feel free to present them.

By the way, I'm specifically talking about measures of code
(statements, LOC), not developer productivity (which was Roy's
original point). My own observations on the latter are simply an
interesting consequence of the former.

TroyK
0
cs_troyk (11)
3/7/2008 7:58:32 PM
TroyK  wrote:

>Who said anything about stored procedures? I'm talking about
>implementing the business rules via constraint declaration in the
>database, and deriving new values throught the application of SQL
>queries.

Do you also treat dynamic constraints in this way?

E.g. "unless otherwise specified, an employee shall get a 2%
salary increase after each full year of employment".
Or: "two movable 3D shapes shall never collide; collision is avoided
by the following repositioning algorithm that is guaranteed
to pull all objects apart that get too close: (...), however, this
algorithm may be replaced with another that has the same property".

-- 
Reinier
0
rpost (56)
3/8/2008 1:09:22 PM
Marshall wrote:

>On Mar 5, 7:58 am, "H. S. Lahman" <h...@pathfindermda.com> wrote:
>>
>> ... the relational model is a subset of the OO foundation ...
>
>Please describe where JOIN and UNION for example,
>are to be found in the OO foundation. Or in any OO language.

Generally, it requires a combination of OO with functional idioms
(higher order functions, closures).  Today's .NET languages support that;
so do more dynamic languages such as Smalltalk, Perl, Python or Ruby;
C++ templates support it.  In Java we still have to fake them with
inner classes, I believe.

Of course there is still a difference: JOIN and UNION are symmetric,
assuming a helicopter perspective in which the data manipulator
has full access to all of the data, while the OO world is inherently
asymmetric (code can only work see data explicitly exposed to
the class the code is in).

-- 
Reinier
0
rpost (56)
3/8/2008 1:38:59 PM
On 6 mar, 22:20, Gene Wirchenko <ge...@ocis.net> wrote:
> Cimode <cim...@hotmail.com> wrote:
[Snipped]
>      Nope.  Most assembler instructions translate to one machine
> instruction each.  That is the mapping that is being referred to.  It
> is not perfect as there are pseudo-ops and macros, but it holds in
> general.
So ? I am not blaming the *mapping* but rather the entire sloppy
reasonning behind.  (Water has oxygen, we breethe oxygen, therefore we
could breethe water.)

Do you think that the fact a physical *mov* is physicaly matching an
ram adress memory content the content of another is sufficient to
state an overgeneralized and simplyistic conclusion that

* just as assembler "mismatches" objects
      so objects  "mismatch" relations *

Nothing but an simplyistic attempt to draw a vague abstract from a
physical behavior when using assembler.
>
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
>      I have preferences.
>      You have biases.
>      He/She has prejudices.

0
cimode (135)
3/8/2008 2:33:45 PM
Cimode <cimode@hotmail.com> wrote:

>On 6 mar, 22:20, Gene Wirchenko <ge...@ocis.net> wrote:
>> Cimode <cim...@hotmail.com> wrote:
>[Snipped]
>>      Nope.  Most assembler instructions translate to one machine
>> instruction each.  That is the mapping that is being referred to.  It
>> is not perfect as there are pseudo-ops and macros, but it holds in
>> general.
>So ? I am not blaming the *mapping* but rather the entire sloppy
>reasonning behind.  (Water has oxygen, we breethe oxygen, therefore we
>could breethe water.)

     Your complaint about mapping was:
"What is mapping 1:1 between machine code and assembler.  Tis the
first time I hear somebody establishing cardinality between 2
languages. What a bunch of crap."

     I replied to that.

>Do you think that the fact a physical *mov* is physicaly matching an
>ram adress memory content the content of another is sufficient to
>state an overgeneralized and simplyistic conclusion that
>
>* just as assembler "mismatches" objects
>      so objects  "mismatch" relations *
>
>Nothing but an simplyistic attempt to draw a vague abstract from a
>physical behavior when using assembler.

     I can not parse the above.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
genew (1214)
3/8/2008 11:11:25 PM
Gene Wirchenko wrote:
> Cimode <cimode@hotmail.com> wrote:
> 
> 
>>On 6 mar, 22:20, Gene Wirchenko <ge...@ocis.net> wrote:
>>
>>>Cimode <cim...@hotmail.com> wrote:
>>
>>[Snipped]
>>
>>>     Nope.  Most assembler instructions translate to one machine
>>>instruction each.  That is the mapping that is being referred to.  It
>>>is not perfect as there are pseudo-ops and macros, but it holds in
>>>general.
>>
>>So ? I am not blaming the *mapping* but rather the entire sloppy
>>reasonning behind.  (Water has oxygen, we breethe oxygen, therefore we
>>could breethe water.)
> 
> 
>      Your complaint about mapping was:
> "What is mapping 1:1 between machine code and assembler.  Tis the
> first time I hear somebody establishing cardinality between 2
> languages. What a bunch of crap."
> 
>      I replied to that.
> 
> 
>>Do you think that the fact a physical *mov* is physicaly matching an
>>ram adress memory content the content of another is sufficient to
>>state an overgeneralized and simplyistic conclusion that
>>
>>* just as assembler "mismatches" objects
>>     so objects  "mismatch" relations *
>>
>>Nothing but an simplyistic attempt to draw a vague abstract from a
>>physical behavior when using assembler.
> 
> 
>      I can not parse the above.

That loud whooshing sound you heard was the point travelling 
effortlessly and at great speed between Cimode's ears.
0
bbadour (434)
3/8/2008 11:20:45 PM
On Mar 8, 5:38 am, rp...@pcwin518.campus.tue.nl (rpost) wrote:
> Marshall wrote:
> >On Mar 5, 7:58 am, "H. S. Lahman" <h...@pathfindermda.com> wrote:
>
> >> ... the relational model is a subset of the OO foundation ...
>
> >Please describe where JOIN and UNION for example,
> >are to be found in the OO foundation. Or in any OO language.
>
> Generally, it requires a combination of OO with functional idioms
> (higher order functions, closures).  Today's .NET languages support that;
> so do more dynamic languages such as Smalltalk, Perl, Python or Ruby;
> C++ templates support it.  In Java we still have to fake them with
> inner classes, I believe.

Well, I didn't say one couldn't code up JOIN and UNION in
an OOPL. For example in Java, Collections.addAll() as used
in classes implementing the Set interface is UNION. We are
approaching the edge of the Turing tarpit here.

My point was that JOIN and UNION are not to be found
in the *foundations* of OOPLs, so the claim that "the relational
model is a subset of the OO foundation" is false. That OOPLs
are Turing-complete and hence can implement any computable
function that could be expressed in the RM is the degenerate
case; it is true but it reveals nothing. One could as well say
that the RM is a subset of the foundations of finite state automata,
or that the lambda calculus is a subset of the OO foundation.
Or whatever.


Marshall
0
3/8/2008 11:37:46 PM
On 8 mar, 23:11, Gene Wirchenko <ge...@ocis.net> wrote:
[Snipped]
> >Nothing but an simplyistic attempt to draw a vague abstract from a
> >physical behavior when using assembler.
>
>      I can not parse the above.
Sorry. I should have been more explicit.  I perfectly understand the
relationship between assembler to machine language.  I just do not see
how one could use the term *cardinality* for that.  I may seem picky
on terminology but I do believe it is an apprpriate term to use.

And even if was to admit that it would be a good term and one could
see some form of cardinality between languages, quite frankly I don't
see how one can jump from that to the previous conclusion.

That was my point.
> Sincerely,
>
> Gene Wirchenko
>
> Computerese Irregular Verb Conjugation:
>      I have preferences.
>      You have biases.
>      He/She has prejudices.

0
cimode (135)
3/8/2008 11:39:47 PM
On 2008-03-06 06:37:19 -0600, JOG <jog@cs.nott.ac.uk> said:

> Using nonsense words like 'subscope' doesn't do conversation any
> favours Robert.

A sub scope is a scope that lives within another scope.  The simplest 
example is the following C code.


{ // parent scope
  int i;
  int j;
  { // sub scope
    int i;
  }
}
-- 
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)
3/9/2008 2:20:15 AM
On 2008-03-06 06:37:19 -0600, JOG <jog@cs.nott.ac.uk> said:

> On Mar 6, 6:26 am, Robert Martin <uncle...@objectmentor.com> wrote:

>> That's not inferrence.
> 
> Well that all jolly-well looks like inference to me.

I agree that you can infer what elements a subclass has by knowing the 
elements of the base class.  However, that's YOU making the inferrence. 
  The inheritance itself is the redeclaration of variables and 
functions of the base to the (sub)scope of the derived class.

-- 
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)
3/9/2008 2:23:13 AM
Robert Martin wrote:
> On 2008-03-06 06:37:19 -0600, JOG <jog@cs.nott.ac.uk> said:
> 
>> Using nonsense words like 'subscope' doesn't do conversation any
>> favours Robert.
> 
> A sub scope is a scope that lives within another scope.  The simplest 
> example is the following C code.
> 
> 
> { // parent scope
>  int i;
>  int j;
>  { // sub scope
>    int i;
>  }
> }


If high-falutin' lingo like 'lives within another scope' passes for 
explanation in OO circles no wonder they are perpetuate other babble 
besides.  A newcomer would profit not a bit from the above but a lot 
from an explanation of a logical stack, which is a simple and clear 
runtime mechanism (regardless of whether a hardware stack or heap is 
used).  Then he could call it what he wants, once he understands what is 
really happening on a typical machine.  Why are the regulars here 
encouraging these cross-posters and 'machine as animal' mystics?
0
paul
3/9/2008 2:59:53 AM
On Mar 9, 2:23 am, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-06 06:37:19 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> > On Mar 6, 6:26 am, Robert Martin <uncle...@objectmentor.com> wrote:
> >> That's not inferrence.
>
> > Well that all jolly-well looks like inference to me.
>
> I agree that you can infer what elements a subclass has by knowing the
> elements of the base class.

Well then you have conceded defeat, given our conversation has gone as
follows:

jog: "So why not treat all 'inheritance' in this way [as inference]?"
Robert: "Because all inheritance is not about inference."
jog: show me an example when it is not.
Robert: I'll ignore that, and just describe the OO mechanism again.
jog: Look, here is how everything you have listed could have been
described through inference
Robert: Ok, I agree that all inheritance can be described via
inference.

I guess we are done, your objection having been overcome.

> However, that's YOU making the inferrence.

This was a non-sequitur. I think because of your OO focus you haven't
recognized that (in this case) there is a danger of putting the cart
before the horse. Logic first, mechanism second, not t'other way
around. Regards, J.

>   The inheritance itself is the redeclaration of variables and
> functions of the base to the (sub)scope of the derived class.
>
> --
> Robert C. Martin (Uncle Bob)  | email: uncle...@objectmentor.com
> Object Mentor Inc.            | blog:  www.butunclebob.com
> The Agile Transition Experts  | web:   www.objectmentor.com
> 800-338-6716                  |

0
jog (83)
3/9/2008 3:39:37 AM
On Mar 8, 7:39 pm, JOG <j...@cs.nott.ac.uk> wrote:
>
> Logic first, mechanism second

Brilliant! And in just four words, too. I salute you sir!


Marshall
0
3/9/2008 7:05:10 AM
On Mar 8, 7:59 pm, paul c <toledoby...@ac.ooyah> wrote:
> Robert Martin wrote:
>
> >> Using nonsense words like 'subscope' doesn't do conversation any
> >> favours Robert.
>
> > A sub scope is a scope that lives within another scope.  The simplest
> > example is the following C code.
>
> > { // parent scope
> >  int i;
> >  int j;
> >  { // sub scope
> >    int i;
> >  }
> > }
>
> If high-falutin' lingo like 'lives within another scope' passes for
> explanation in OO circles no wonder they are perpetuate other babble
> besides.

Well, I dunno. "Scope" is a pretty well-established term. I could pick
at the anthropomorphism, but I'd just be picking. I'd say it is more
usual
to say "nested scope" but it's clear enough to me that's what he means
with "subscope."


Marshall
0
Marshall
3/9/2008 7:07:38 AM
Marshall wrote:
....
> Well, I dunno. "Scope" is a pretty well-established term. I could pick
> at the anthropomorphism, but I'd just be picking. I'd say it is more
> usual
> to say "nested scope" but it's clear enough to me that's what he means
> with "subscope."


Well, it's not clear to me what living in a scope could possibly mean, 
except of course for pure mumbo-jumbo.
0
paul
3/9/2008 7:45:36 AM
Yagotta B. Kidding wrote:

> S Perryman <q@q.com> wrote in news:fqpj0o$lke$1@aioe.org:

TN>In the other message
TN>you dismissed projection as being covered by the concept of
TN>subclassing.

SP>No. Projection is covered by *type substitutability* .

TN>Can you please be more specific? If we remove some [data]
TN>attributes, does it mean the resulting "entity" is a subclass.

>>No, merely that the resulting entity is now deemed to be of
>>another type, substitutable with the original type.

>>type T
>>{
>>    x, y, z
>>}
>>
>>Set<T> ts ;
>>Set< type { x, y } > ps = { e IN ts : e.x > 123 } ;

>>The elements of ps are effectively projections of the elements in ts.

> Hold on, you have a value of type Set<T> assigned to a variable of type 
> Set<type{x,y}>.

Basic type substitutability (structural equivalence) .
The { x, y } type has properties in common with T (the x/y properties) .
Therefore the assignment is legal.

So the assignment is a projection is of a type (x,y,z) to a type (x,y) .


Regards,
Steven Perryman
0
S
3/9/2008 11:25:42 AM
[Snipped]
> Sorry. I should have been more explicit.  I perfectly understand the
> relationship between assembler to machine language.  I just do not see
> how one could use the term *cardinality* for that.  I may seem picky
> on terminology but I do believe it is an apprpriate term to use.
Typo.  Sorry.  I meant

but I dot *not* believe it is an appropriate term to use.  One word
can make an entire difference.
[Snipped]
0
cimode (135)
3/9/2008 11:31:18 AM
"Marshall" <marshall.spight@gmail.com> wrote in message
news:35dfaf3a-6a60-41f1-b533-928211aae429@s8g2000prg.googlegroups.com...
> On Mar 8, 7:39 pm, JOG <j...@cs.nott.ac.uk> wrote:
> >
> > Logic first, mechanism second
>
> Brilliant! And in just four words, too. I salute you sir!
>

I agree.  This one is a keeper.  Any room for it in the glossary?


0
cressey73 (124)
3/9/2008 12:01:47 PM
"paul c" <toledobysea@ac.ooyah> wrote in message
news:AAMAj.63950$w94.63399@pd7urf2no...
> Marshall wrote:
> ...
> > Well, I dunno. "Scope" is a pretty well-established term. I could pick
> > at the anthropomorphism, but I'd just be picking. I'd say it is more
> > usual
> > to say "nested scope" but it's clear enough to me that's what he means
> > with "subscope."
>
>
> Well, it's not clear to me what living in a scope could possibly mean,
> except of course for pure mumbo-jumbo.

I disagree. It's clear enough for discussion purposes.  A value stored in a
variable lives in the scope of that variable,  until it's copied (forwarded)
to another place.


0
David
3/9/2008 12:20:06 PM
S Perryman <q@q.com> wrote in news:fr0hft$8gf$1@aioe.org:

> Yagotta B. Kidding wrote:
> 
>> S Perryman <q@q.com> wrote in news:fqpj0o$lke$1@aioe.org:
> 
> TN>In the other message
> TN>you dismissed projection as being covered by the concept of
> TN>subclassing.
> 
> SP>No. Projection is covered by *type substitutability* .
> 
> TN>Can you please be more specific? If we remove some [data]
> TN>attributes, does it mean the resulting "entity" is a subclass.
> 
>>>No, merely that the resulting entity is now deemed to be of
>>>another type, substitutable with the original type.
> 
>>>type T
>>>{
>>>    x, y, z
>>>}
>>>
>>>Set<T> ts ;
>>>Set< type { x, y } > ps = { e IN ts : e.x > 123 } ;
> 
>>>The elements of ps are effectively projections of the elements in ts.
> 
>> Hold on, you have a value of type Set<T> assigned to a variable of
>> type Set<type{x,y}>.
> 
> Basic type substitutability (structural equivalence) .
> The { x, y } type has properties in common with T (the x/y properties)
> . Therefore the assignment is legal.
> 
> So the assignment is a projection is of a type (x,y,z) to a type (x,y)

I think you are confused at least on two counts.  

In any OO langauage I am familiar wth,  you can assign a subtype value
to a supertype variable.  However,  you did not establish any
subtype/supertype relationship in your example,  therefore,  the
assignment is illegal. 

Even when you establish such relationship,  no projection really takes
place,  the information is still there,  it's just hidden,  as can
easily be seen by casting back to the original subtype. 



..
> 
> 
> Regards,
> Steven Perryman
> 

0
ybk1 (19)
3/9/2008 5:13:51 PM
On Mar 9, 9:13 am, "Yagotta B. Kidding" <y...@mymail.com> wrote:
> S Perryman <q...@q.com> wrote innews:fr0hft$8gf$1@aioe.org:
> > Yagotta B. Kidding wrote:
> >> S Perryman <q...@q.com> wrote innews:fqpj0o$lke$1@aioe.org:
>
> > TN>In the other message
> > TN>you dismissed projection as being covered by the concept of
> > TN>subclassing.
>
> > SP>No. Projection is covered by *type substitutability* .
>
> > TN>Can you please be more specific? If we remove some [data]
> > TN>attributes, does it mean the resulting "entity" is a subclass.
>
> >>>No, merely that the resulting entity is now deemed to be of
> >>>another type, substitutable with the original type.
>
> >>>type T
> >>>{
> >>>    x, y, z
> >>>}
>
> >>>Set<T> ts ;
> >>>Set< type { x, y } > ps = { e IN ts : e.x > 123 } ;
>
> >>>The elements of ps are effectively projections of the elements in ts.
>
> >> Hold on, you have a value of type Set<T> assigned to a variable of
> >> type Set<type{x,y}>.
>
> > Basic type substitutability (structural equivalence) .
> > The { x, y } type has properties in common with T (the x/y properties)
> > . Therefore the assignment is legal.
>
> > So the assignment is a projection is of a type (x,y,z) to a type (x,y)
>
> In any OO langauage I am familiar wth,  you can assign a subtype value
> to a supertype variable.  However,  you did not establish any
> subtype/supertype relationship in your example,  therefore,  the
> assignment is illegal.

If the system being discussed is based on structural rather
than nominal types (which he explicitly stated, although not
in a very obvious way) then it is sufficient to compare the
*structure* of two types to determine if one is a subtype of
the other. In this case, attributes {x, y} are a subset of
{x, y, z} and so a subtype relationship exists. No, this is
not how Java or C++ work; OCaml maybe?


> Even when you establish such relationship,  no projection really takes
> place,  the information is still there,  it's just hidden,  as can
> easily be seen by casting back to the original subtype.

Well, this is approximately true, but it's not clear how
important it is. What does it mean *logically* for a projection
to "really take place?" What if the language doesn't have
upcasting?

Note that we can translate Mr. Perryman's code into SQL
in a fairly straightforward way and preserve all the
properties he wants from his example. Which is unsurprising
since SQL is structurally typed.


Marshall
0
3/9/2008 6:04:16 PM
Yagotta B. Kidding wrote:

> S Perryman <q@q.com> wrote in news:fr0hft$8gf$1@aioe.org:

YK>Hold on, you have a value of type Set<T> assigned to a variable of
YK>type Set<type{x,y}>.

>>Basic type substitutability (structural equivalence) .
>>The { x, y } type has properties in common with T (the x/y properties)
>>. Therefore the assignment is legal.

>>So the assignment is a projection is of a type (x,y,z) to a type (x,y)

> I think you are confused at least on two counts.  

> In any OO langauage I am familiar wth, you can assign a subtype value
> to a supertype variable.

> However, you did not establish any
> subtype/supertype relationship in your example, therefore, the
> assignment is illegal.

1. You are correct, if you use the *Simula* model of type substitutability
   (ie Y is substitutable for X if there is an inheritance lineage from Y to
   X) .

2. There are OO prog langs, strongly and weakly typed, that are not
forced to use the Simula model.


> Even when you establish such relationship, no projection really takes
> place, the information is still there, it's just hidden, as can
> easily be seen by casting back to the original subtype. 

Is this not an implementation aspect, as opposed to a conceptual one ??
There could be prog langs that forbid coercion back the other way etc
(even if the underlying impl was using a "hidden" approach) .


Regards,
Steven Perryman
0
S
3/9/2008 9:20:22 PM
"David Cressey" <cressey73@verizon.net> wrote:

[snip]

>I disagree. It's clear enough for discussion purposes.  A value stored in a
>variable lives in the scope of that variable,  until it's copied (forwarded)
>to another place.

     Well, no, it does not.  A variable has its value during its
LIFETIME.  It can be referred to in its SCOPE.  These can be the same
for a variable, but they can be different.

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
     I have preferences.
     You have biases.
     He/She has prejudices.
0
Gene
3/10/2008 2:21:32 AM
Gene Wirchenko wrote:

> "David Cressey" <cressey73@verizon.net> wrote:
> 
> [snip]
> 
> 
>>I disagree. It's clear enough for discussion purposes.  A value stored in a
>>variable lives in the scope of that variable,  until it's copied (forwarded)
>>to another place.
> 
>      Well, no, it does not.  A variable has its value during its
> LIFETIME.  It can be referred to in its SCOPE.  These can be the same
> for a variable, but they can be different.

Even that is not always true. Sometimes a variable can be referred to 
outside its scope by using a scope qualifier. Sometimes not.
0
Bob
3/10/2008 3:12:09 AM
S Perryman <q@q.com> wrote in news:fr1kav$1su$1@aioe.org:

> Yagotta B. Kidding wrote:
> 
>> S Perryman <q@q.com> wrote in news:fr0hft$8gf$1@aioe.org:
> 
> YK>Hold on, you have a value of type Set<T> assigned to a variable of
> YK>type Set<type{x,y}>.
> 
>>>Basic type substitutability (structural equivalence) .
>>>The { x, y } type has properties in common with T (the x/y
>>>properties) . Therefore the assignment is legal.
> 
>>>So the assignment is a projection is of a type (x,y,z) to a type
>>>(x,y) 
> 
>> I think you are confused at least on two counts.  
> 
>> In any OO langauage I am familiar wth, you can assign a subtype value
>> to a supertype variable.
> 
>> However, you did not establish any
>> subtype/supertype relationship in your example, therefore, the
>> assignment is illegal.
> 
> 1. You are correct, if you use the *Simula* model of type
> substitutability 
>    (ie Y is substitutable for X if there is an inheritance lineage
>    from Y to X) .
> 
> 2. There are OO prog langs, strongly and weakly typed, that are not
> forced to use the Simula model.
> 

That's a good point.

> 
>> Even when you establish such relationship, no projection really takes
>> place, the information is still there, it's just hidden, as can
>> easily be seen by casting back to the original subtype. 
> 
> Is this not an implementation aspect, as opposed to a conceptual one
> ?? There could be prog langs that forbid coercion back the other way
> etc (even if the underlying impl was using a "hidden" approach) .
> 


I think you are right about the implementation aspect and I agree that 
the structural supertype assignment can be viewed as a projection.

> 
> Regards,
> Steven Perryman

0
ybk1 (19)
3/10/2008 3:14:51 AM
Marshall <marshall.spight@gmail.com> wrote in news:b5ab6022-5cea-45a1-
9e64-fe2b3a04e8de@e6g2000prf.googlegroups.com:
 
> If the system being discussed is based on structural rather
> than nominal types (which he explicitly stated, although not
> in a very obvious way) then it is sufficient to compare the
> *structure* of two types to determine if one is a subtype of
> the other. In this case, attributes {x, y} are a subset of
> {x, y, z} and so a subtype relationship exists. No, this is
> not how Java or C++ work; OCaml maybe?
> 

Yes, you are right about OCAML. I forgot that it indeed uses structural 
subtyping.


> 
>> Even when you establish such relationship,  no projection really takes
>> place,  the information is still there,  it's just hidden,  as can
>> easily be seen by casting back to the original subtype.
> 
> Well, this is approximately true, but it's not clear how
> important it is. What does it mean *logically* for a projection
> to "really take place?" What if the language doesn't have
> upcasting?
> 
> Note that we can translate Mr. Perryman's code into SQL
> in a fairly straightforward way and preserve all the
> properties he wants from his example. Which is unsurprising
> since SQL is structurally typed.

Superficially, you can perform the translation,  but the assignment 
required to imitate the projection makes any such language not 
referentially transparent.  You may consider the non-transparency a non-
issue of course.

> 
> 
> Marshall

0
ybk1 (19)
3/10/2008 3:25:15 AM
On Mar 9, 7:25 pm, "Yagotta B. Kidding" <y...@mymail.com> wrote:
> Marshall <marshall.spi...@gmail.com> wrote in news:b5ab6022-5cea-45a1-
>
> Superficially, you can perform the translation,  but the assignment
> required to imitate the projection makes any such language not
> referentially transparent.  You may consider the non-transparency a non-
> issue of course.

Um, how so? I'm not sure I see what you mean.


Marshall
0
3/10/2008 3:50:07 AM
Gene Wirchenko wrote:
> David Cressey wrote:
> 
> [snip]
> 
>> I disagree. It's clear enough for discussion purposes.  A value stored in a
>> variable lives in the scope of that variable,  until it's copied (forwarded)
>> to another place.
> 
>      Well, no, it does not.  A variable has its value during its
> LIFETIME.  It can be referred to in its SCOPE.  These can be the same
> for a variable, but they can be different.

The 'life' a variable hase outside it's scope is half-life at best.
The variable does occupy resources, but in order to be useful in
any way it has to be in scope.


0
mAsterdam
3/10/2008 7:57:26 AM
Marshall <marshall.spight@gmail.com> wrote in
news:95abb6fb-e5e1-4604-b0f9-9fe3d5bcfadc@e10g2000prf.googlegroups.com: 

> On Mar 9, 7:25 pm, "Yagotta B. Kidding" <y...@mymail.com> wrote:
>> Marshall <marshall.spi...@gmail.com> wrote in
>> news:b5ab6022-5cea-45a1- 
>>
>> Superficially, you can perform the translation,  but the assignment
>> required to imitate the projection makes any such language not
>> referentially transparent.  You may consider the non-transparency a
>> non- issue of course.
> 
> Um, how so? I'm not sure I see what you mean.
> 
> 
> Marshall
> 

"A language that supports the concept that ``equals can be substituted
for equals'' in an expresssion without changing the value of the
expression is said to be referentially transparent. Referential
transparency is violated when we include set! in our computer language.
This makes it tricky to determine when we can simplify expressions by
substituting equivalent expressions. Consequently, reasoning about
programs that use assignment becomes drastically more difficult." 

http://mitpress.mit.edu/sicp/full-text/sicp/book/node54.html
0
ybk1 (19)
3/10/2008 12:30:40 PM
"mAsterdam" <mAsterdam@vrijdag.org> wrote in message
news:47d4e9ac$0$14352$e4fe514c@news.xs4all.nl...
> Gene Wirchenko wrote:
> > David Cressey wrote:
> >
> > [snip]
> >
> >> I disagree. It's clear enough for discussion purposes.  A value stored
in a
> >> variable lives in the scope of that variable,  until it's copied
(forwarded)
> >> to another place.
> >
> >      Well, no, it does not.  A variable has its value during its
> > LIFETIME.  It can be referred to in its SCOPE.  These can be the same
> > for a variable, but they can be different.
>
> The 'life' a variable hase outside it's scope is half-life at best.
> The variable does occupy resources, but in order to be useful in
> any way it has to be in scope.
>
>
In addition,  the lifetime of the association betwen a variable and a given
value is different from the lifetime of the variable itself.



0
David
3/10/2008 12:52:09 PM
On Mar 10, 5:30 am, "Yagotta B. Kidding" <y...@mymail.com> wrote:
> Marshall <marshall.spi...@gmail.com> wrote
> > On Mar 9, 7:25 pm, "Yagotta B. Kidding" <y...@mymail.com> wrote:
>
> >> Superficially, you can perform the translation,  but the assignment
> >> required to imitate the projection makes any such language not
> >> referentially transparent.  You may consider the non-transparency a
> >> non- issue of course.
>
> > Um, how so? I'm not sure I see what you mean.
>
> "A language that supports the concept that ``equals can be substituted
> for equals'' in an expresssion without changing the value of the
> expression is said to be referentially transparent. Referential
> transparency is violated when we include set! in our computer language.
> This makes it tricky to determine when we can simplify expressions by
> substituting equivalent expressions. Consequently, reasoning about
> programs that use assignment becomes drastically more difficult."

Dude? I'm a language junkie with an interest in FP. It wasn't the
term "referential transparency" I was having trouble with. :-)

Rather, I don't see where the assignment comes in. Particularly
in discussing SQL, which, strictly speaking, lacks assignment.
(Although it does have other imperative operators, yes.) And
Mr. Perryman's example was written in a single-assignment,
mathematical style.



> http://mitpress.mit.edu/sicp/full-text/sicp/book/node54.html

Ah, SICP. Did you know that David Cressey's name appears
in it? Apparently he was at ground zero in the early days of
garbage collection, and coined a term that is still used. I told
that story when my languages discussion group had
Mr. Abelson for lunch.


Marshall

PS. Name dropping alert!!! I try to resist, but I am weak.
0
3/10/2008 3:38:38 PM
"Marshall" <marshall.spight@gmail.com> wrote in message
news:a8e31977-9f84-4c58-bca3-e0aa4e855676@s19g2000prg.googlegroups.com...
> On Mar 10, 5:30 am, "Yagotta B. Kidding" <y...@mymail.com> wrote:
> > Marshall <marshall.spi...@gmail.com> wrote
> > > On Mar 9, 7:25 pm, "Yagotta B. Kidding" <y...@mymail.com> wrote:
> >
> > >> Superficially, you can perform the translation,  but the assignment
> > >> required to imitate the projection makes any such language not
> > >> referentially transparent.  You may consider the non-transparency a
> > >> non- issue of course.
> >
> > > Um, how so? I'm not sure I see what you mean.
> >
> > "A language that supports the concept that ``equals can be substituted
> > for equals'' in an expresssion without changing the value of the
> > expression is said to be referentially transparent. Referential
> > transparency is violated when we include set! in our computer language.
> > This makes it tricky to determine when we can simplify expressions by
> > substituting equivalent expressions. Consequently, reasoning about
> > programs that use assignment becomes drastically more difficult."
>
> Dude? I'm a language junkie with an interest in FP. It wasn't the
> term "referential transparency" I was having trouble with. :-)
>
> Rather, I don't see where the assignment comes in. Particularly
> in discussing SQL, which, strictly speaking, lacks assignment.
> (Although it does have other imperative operators, yes.) And
> Mr. Perryman's example was written in a single-assignment,
> mathematical style.
>

Oh?

I thought that the SET clause of the UPDATE statement was an assignment in
disguise.

> > http://mitpress.mit.edu/sicp/full-text/sicp/book/node54.html
>
> Ah, SICP. Did you know that David Cressey's name appears
> in it? Apparently he was at ground zero in the early days of
> garbage collection, and coined a term that is still used. I told
> that story when my languages discussion group had
> Mr. Abelson for lunch.
>
>
> Marshall
>
> PS. Name dropping alert!!! I try to resist, but I am weak.


0
cressey73 (124)
3/10/2008 5:55:28 PM
"Marshall" <marshall.spight@gmail.com> wrote in message
news:a8e31977-9f84-4c58-bca3-e0aa4e855676@s19g2000prg.googlegroups.com...

> > http://mitpress.mit.edu/sicp/full-text/sicp/book/node54.html
>
> Ah, SICP. Did you know that David Cressey's name appears
> in it? Apparently he was at ground zero in the early days of
> garbage collection, and coined a term that is still used. I told
> that story when my languages discussion group had
> Mr. Abelson for lunch.

I don't think of 1971, when I wrote the garbage collector for MDL  as "the
early days of garbage collection."  The "early days would have been in the
1950s when McCarthy wrote the garbage collector for LISP.   The MDL garbage
collector was more ambitious than the Lisp garbage collector.  But I had the
advantage of learning from  the work that had already been done.

What made the MDL garbage collector more ambitious was that we supported a
data structure called a "vector"  that was addressable via the PDP-10
address arithmetic.   The use of a random access structure was 1000 times
faster than the use of a linked list,  for some of the things we wanted to
do.  The use of hardware address arithmetic made it even faster.  The
consequence of support for vectors was that the garbage collector had to not
only reclaim unused space,  but defragment it as well.

Somebody who came along after me got a PhD by rewriting the MDL garbage
collector so that it could do its work in the background, without suspending
all the MDL execution threads.  I have no idea how such a thing would have
worked.


>
>
> Marshall
>
> PS. Name dropping alert!!! I try to resist, but I am weak.


Thanks!  Normally the only people who drop my name are the people who cull
mailing lists of "important people".



0
cressey73 (124)
3/10/2008 6:06:55 PM
On Mar 10, 9:55 am, "David Cressey" <cresse...@verizon.net> wrote:
> "Marshall" <marshall.spi...@gmail.com> wrote in message
>
> > Rather, I don't see where the assignment comes in. Particularly
> > in discussing SQL, which, strictly speaking, lacks assignment.
> > (Although it does have other imperative operators, yes.) And
> > Mr. Perryman's example was written in a single-assignment,
> > mathematical style.
>
> Oh?
>
> I thought that the SET clause of the UPDATE statement was an assignment in
> disguise.

Roughly speaking, sure. Another way to say approximately what you just
said
would be to say "[SQL] does have other imperative operators, yes." :-)


Marshall
0
3/10/2008 6:08:14 PM
Marshall wrote:

> On Mar 10, 5:30 am, "Yagotta B. Kidding" <y...@mymail.com> wrote:
> 
>>Marshall <marshall.spi...@gmail.com> wrote
>>
>>>On Mar 9, 7:25 pm, "Yagotta B. Kidding" <y...@mymail.com> wrote:

[snip]

> had
> Mr. Abelson for lunch.

Cannibals!
0
bbadour (434)
3/10/2008 6:12:00 PM
On Mar 10, 10:12 am, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> Marshall wrote:
>
> > had Mr. Abelson for lunch.
>
> Cannibals!


With some fava beans, and a nice Chianti.

thp-thp-thp-thp-thp-thp-thp!


Marshall
0
3/10/2008 6:30:37 PM
Marshall <marshall.spight@gmail.com> wrote in
news:a8e31977-9f84-4c58-bca3-e0aa4e855676@s19g2000prg.googlegroups.com: 

> On Mar 10, 5:30 am, "Yagotta B. Kidding" <y...@mymail.com> wrote:
>> Marshall <marshall.spi...@gmail.com> wrote
>> > On Mar 9, 7:25 pm, "Yagotta B. Kidding" <y...@mymail.com> wrote:
>>
>> >> Superficially, you can perform the translation,  but the
>> >> assignment required to imitate the projection makes any such
>> >> language not referentially transparent.  You may consider the
>> >> non-transparency a non- issue of course.
>>
>> > Um, how so? I'm not sure I see what you mean.
>>
>> "A language that supports the concept that ``equals can be
>> substituted for equals'' in an expresssion without changing the value
>> of the expression is said to be referentially transparent.
>> Referential transparency is violated when we include set! in our
>> computer language. This makes it tricky to determine when we can
>> simplify expressions by substituting equivalent expressions.
>> Consequently, reasoning about programs that use assignment becomes
>> drastically more difficult." 
> 
> Dude? I'm a language junkie with an interest in FP. It wasn't the
> term "referential transparency" I was having trouble with. :-)
> 
> Rather, I don't see where the assignment comes in. 

You don't ?  


>And
> Mr. Perryman's example was written in a single-assignment,
> mathematical style.

And yet you still do not see where the assignment comes in in Mr.
Perryman's example. 



0
ybk1 (19)
3/10/2008 6:47:06 PM
David Cressey wrote:
....
> 
> I thought that the SET clause of the UPDATE statement was an assignment in
> disguise.
> ...

I would have thought UPDATE itself is assignment in disguise and SET is 
just an arbitrary language device, just as scope operators don't seem to 
have much to do with database theory, ;).  (I admit I have no idea 
whether UPDATE without SET is allowed.)


Regarding SICP, I think somewhere it states that FP languages don't have 
assignment, which I didn't see here, at least in the few OO cross-posts 
that I accidentally read.


As usual when replying to David C, no offence but can't resist 
mentioning that Date has  claimed that the ACID property that SQL 
vendors tout is basically incomplete (my words, not his), I think he 
might have been including SQL's UPDATE when he said that.


Regarding scope, I even question some of the deep thinkers, such as 
Pascal, when they seem to imply that rdbms 'logic' requires persistence. 
  Maybe that's misrepresenting them but I've never seen any need for an 
algebra or calculus per se to include operators that have to do with 
persistence, as practical as they might be.  For me, the greatest value 
of relational theory is from the point of view of the user and how he 
can test results in his head with merely a basic understanding of 
project and join and/or traditional first-order logic and without such 
users needing to concern themselves with how OO or machine techniques 
choose to obtain those results.
0
paul
3/10/2008 6:55:16 PM
On Mar 10, 10:47 am, "Yagotta B. Kidding" <y...@mymail.com> wrote:
> > Mr. Perryman's example was written in a single-assignment,
> > mathematical style.
>
> And yet you still do not see where the assignment comes in in Mr.
> Perryman's example.

You understand that single-assignment is different from
assignment, right? You know that single-assignment doesn't
cause any problems with referential transparency, right?

Well, we're into a subpoint of a subpoint of a subpoint.
Perhaps a refreshing Snapple is in order!


Marshall
0
3/10/2008 7:30:50 PM
On Mar 8, 7:09=A0am, rp...@pcwin518.campus.tue.nl (rpost) wrote:
> TroyK =A0wrote:
> >Who said anything about stored procedures? I'm talking about
> >implementing the business rules via constraint declaration in the
> >database, and deriving new values throught the application of SQL
> >queries.
>
> Do you also treat dynamic constraints in this way?
>
> E.g. "unless otherwise specified, an employee shall get a 2%
> salary increase after each full year of employment".
> Or: "two movable 3D shapes shall never collide; collision is avoided
> by the following repositioning algorithm that is guaranteed
> to pull all objects apart that get too close: (...), however, this
> algorithm may be replaced with another that has the same property".
>
> --
> Reinier

Inferring the definition of "dynamic constraint" from your examples,
in the first, I think that it would be sufficient to model and record
whatever attribute means "otherwise specified" and include that as
part of the condition in the constraint declaration.

I haven't had occasion to apply the technique to anything more complex
than such an example, so I'll have to say "I don't know" to the 3D
example.

TroyK
0
cs_troyk (11)
3/10/2008 9:56:47 PM
On Mar 10, 3:56=A0pm, TroyK <cs_tr...@juno.com> wrote:
> On Mar 8, 7:09=A0am, rp...@pcwin518.campus.tue.nl (rpost) wrote:
>
>
>
>
>
> > TroyK =A0wrote:
> > >Who said anything about stored procedures? I'm talking about
> > >implementing the business rules via constraint declaration in the
> > >database, and deriving new values throught the application of SQL
> > >queries.
>
> > Do you also treat dynamic constraints in this way?
>
> > E.g. "unless otherwise specified, an employee shall get a 2%
> > salary increase after each full year of employment".
> > Or: "two movable 3D shapes shall never collide; collision is avoided
> > by the following repositioning algorithm that is guaranteed
> > to pull all objects apart that get too close: (...), however, this
> > algorithm may be replaced with another that has the same property".
>
> > --
> > Reinier
>
> Inferring the definition of "dynamic constraint" from your examples,
> in the first, I think that it would be sufficient to model and record
> whatever attribute means "otherwise specified" and include that as
> part of the condition in the constraint declaration.
>
> I haven't had occasion to apply the technique to anything more complex
> than such an example, so I'll have to say "I don't know" to the 3D
> example.
>
> TroyK- Hide quoted text -
>
> - Show quoted text -

Sorry to self-reply, just wanted to state that the generalism behind
what I'm trying to describe is to implement exceptions to the rule as
nothing more than another rule.

TroyK
0
cs_troyk (11)
3/10/2008 10:07:12 PM
TroyK wrote:

> On Mar 8, 7:09 am, rp...@pcwin518.campus.tue.nl (rpost) wrote:
> 
>>TroyK  wrote:
>>
>>>Who said anything about stored procedures? I'm talking about
>>>implementing the business rules via constraint declaration in the
>>>database, and deriving new values throught the application of SQL
>>>queries.
>>
>>Do you also treat dynamic constraints in this way?
>>
>>E.g. "unless otherwise specified, an employee shall get a 2%
>>salary increase after each full year of employment".

with not_excluded_ee = (
  employees join ( employees{ee#} minus excluded_ees{ee#} )
), increases = extend (
   not_excluded_ee where is_anniversary_period(pay_period(now),hire_date)
) add increase = salary * percent(2)
....

>>Or: "two movable 3D shapes shall never collide; collision is avoided
>>by the following repositioning algorithm that is guaranteed
>>to pull all objects apart that get too close: (...), however, this
>>algorithm may be replaced with another that has the same property".

with other_objects = objects rename all prepending "other_"
, collisions = objects join other_objects
   where rank_attrib < other_rank_attrib
     and min_distance(polygons,other_polygons) < threshold_distance
, while exists(collisions) {
     update collisions
     set position = ...
     , other_position = ...
}


>>
>>--
>>Reinier
> 
> Inferring the definition of "dynamic constraint" from your examples,
> in the first, I think that it would be sufficient to model and record
> whatever attribute means "otherwise specified" and include that as
> part of the condition in the constraint declaration.

What was the constraint part again?


> I haven't had occasion to apply the technique to anything more complex
> than such an example, so I'll have to say "I don't know" to the 3D
> example.
> 
> TroyK
0
bbadour (434)
3/10/2008 10:53:34 PM
"paul c" <toledobysea@ac.ooyah> wrote in message
news:oufBj.69267$pM4.44570@pd7urf1no...
> David Cressey wrote:
> ...
> >
> > I thought that the SET clause of the UPDATE statement was an assignment
in
> > disguise.
> > ...
>
> I would have thought UPDATE itself is assignment in disguise and SET is
> just an arbitrary language device, just as scope operators don't seem to
> have much to do with database theory, ;).  (I admit I have no idea
> whether UPDATE without SET is allowed.)


Yes, that's probably more precise than what I said.


> Regarding SICP, I think somewhere it states that FP languages don't have
> assignment, which I didn't see here, at least in the few OO cross-posts
> that I accidentally read.
>
>
> As usual when replying to David C, no offence but can't resist
> mentioning that Date has  claimed that the ACID property that SQL
> vendors tout is basically incomplete (my words, not his), I think he
> might have been including SQL's UPDATE when he said that.

It's my understanding,  just from folowing c.d.t. discussions,  that Date &
Darwen,  in the D language,  aim for something more ambitious than ACID,
namely a language that permits all transactions to be expressed as a single
action.  If you do that,  then you get all the benefits of ACID and maybe a
few others.



0
David
3/10/2008 11:35:06 PM
On 2008-03-08 21:39:37 -0600, JOG <jog@cs.nott.ac.uk> said:

> On Mar 9, 2:23 am, Robert Martin <uncle...@objectmentor.com> wrote:
>> On 2008-03-06 06:37:19 -0600, JOG <j...@cs.nott.ac.uk> said:
>> 
>>> On Mar 6, 6:26 am, Robert Martin <uncle...@objectmentor.com> wrote:
>>>> That's not inferrence.
>> 
>>> Well that all jolly-well looks like inference to me.
>> 
>> I agree that you can infer what elements a subclass has by knowing the
>> elements of the base class.
> 
> Well then you have conceded defeat, given our conversation has gone as
> follows:
> 
> jog: "So why not treat all 'inheritance' in this way [as inference]?"
> Robert: "Because all inheritance is not about inference."
> jog: show me an example when it is not.
> Robert: I'll ignore that, and just describe the OO mechanism again.
> jog: Look, here is how everything you have listed could have been
> described through inference
> Robert: Ok, I agree that all inheritance can be described via
> inference.

Here's the starting point of the conversation.  You wrote:
>> Name(x, Aristotle) -> Species(x, Man)
>> Species(x, Man) -> Mortality(x, Mortal)
>> |= Name(x, Aristotle) -> Mortalilty(x, Mortal)
> 
>> No types or reification in sight. Instead I had two groups of
>> statements:
>> People = {Name, Species, Bday}
>> Entities = {Species, Mortality}
> 
>> A join of the two statements gave me the inference I required: {Name,
>> Mortality}. All of a sudden it seemed simple. So some questions:
> 
>> 1) So why not treat all 'inheritance' in this way?
>> 2) Could one extend to include 'behaviour' as well?
>> 3) And is this a crazy thing to suggest in a cross post to an OO
>> group?


I responded to your first question that when you need to make 
inferences, an inference engine is a good tool.  Inheritance is not an 
inference engine. And you challenged me:

>> Interesting story.  Yes, when you have a problem of inference, it's
>> good to use an inference engine.
>> 
>>> So some questions:
>> 
>>> 1) So why not treat all 'inheritance' in this way?
>> 
>> Because all inheritance is not about inference.
> 
> Hmmm. Then might you give an example of a situation where inheritance
> cannot be described in terms of inference?

To which I described what inheritance is:

> Inheritance is simply the redeclaration of functions and variables in a 
> subscope.  That's not inferrence.

To which you said "subscope" was a nonsense word, and we had to define 
our terms. (sigh).

Then you said:

> Well that all jolly-well looks like inference to me.

And I said ... well you can read it above.

> I guess we are done, your objection having been overcome.

JOG, you're original question was: Why not treat all inheritance as the 
kind of inferrence you get from a database join.

Answer:  Because inheritance is not inference.  Inheritance is the 
redeclaration of variables and functions in a subscope.

> I think because of your OO focus you haven't
> recognized that (in this case) there is a danger of putting the cart
> before the horse. Logic first, mechanism second, not t'other way
> around.

On the contrary, your initial question was:

Why can't the mechanism be treated like the logic.

My answer was: because it's a mechanism.

So it seems to me that you are the one with the problem discerning the 
difference between logic and mechanisms.

Now, I understand your original point.  You were trying to use 
inheritance as a way to make an inference, and then later found that a 
database join was a better approach.  Good!  Inference engines are 
usually better at making inferences than redeclaration mechanisms.  But 
the conclusion you apparently drew from this is that there was 
something wrong with the mechanism (inheritance) and that it should be 
more like a database join.  That's rather like pounding a nail with a 
screwdriver and then wishing it was more like a hammer.

-- 
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)
3/11/2008 1:05:55 AM
On 2008-03-06 02:29:51 -0600, Marshall <marshall.spight@gmail.com> said:

> On Mar 5, 10:32 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> On 2008-03-05 09:48:45 -0600, Marshall <marshall.spi...@gmail.com> said:
>>> On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> 
>>>>> Furthermore, since OOPLs lack physical independence, traversing
>>>>> the graph may be quite expensive, particularly in the case where
>>>>> the graph is backed by storage in a database, which is part of
>>>>> why ORM is such a universally bad idea.
>> 
>>>> No, you have this wrong.  ORMs generally use standard SQL queries to
>>>> traverse and gather data from the DB.  Then that data is placed into OO
>>>> structures so that the application can take advanage of the bias.
>> 
>>> Just the fact that they use SQL isn't sufficient. They have to
>>> use it as well as a person could, though an interface that
>>> is generally information-lossy enough (or at least, used in
>>> a lossy way) that that's impossible.
>> 
>> Yeah, assembly language programmers used to say the same thing about
>> compilers.  Then the compilers started writing more efficient code than
>> the assembly language programmers could...
> 
> I give you high marks for rhetoric here. Excellently argued!
> You take the opposing side and compare them to assembly,
> and compare yourself with compiled languages. That the
> situation is most closely analogous to exactly the reverse
> is only relevant if one is interested in a deep understanding
> doesn't detract at all from the rhetorical effectiveness.

Wow, it's sure getting deep in here.  I can't seem to make out the 
content for all the fuzz and snow.

1. ORMs generate SQL in a manner analagous to compilers generating 
assembly.  Why is it analagous?  Because the ORMs can infer a 
considerable amount of intent, and can therefore generate highly 
specific SQL.  (The fact that many don't is irrelevant).  This is just 
like compilers who infer intent from the code and generate highly 
specific and tuned assembler.

2. Compilers got so good at this that they generated more efficient 
(not better) assembler code than humans could (or would).  The compiler 
had no care for art or readability.  So the compiler did things that no 
human would dare.  ORMs have the same opportunity.

So, in fact, it is not a reverse analogy.  It is a very appropriate 
analogy.  The ORM lives at a higher level of abstraction than the SQL 
because it has access to application intent, that the SQL does not have.

> As an actual engineering argument, though, this fails.
> Because it doesn't address the information-loss point I made.
> No code generator can write optimal code if it's missing information
> necessary to determine what is optimal. Object-graph traversal
> in ORMs is *necessarily* more expensive than straightforward SQL.

You are all caught up on object graph traversals as though they were 
the only way to work with ORMs.  Indeed, most of us silly and sloppy OO 
programmers understand that you don't want to walk unfetched object 
graphs.  So we populate the necessary nodes in a set of efficient 
querries.

> In part exactly because it is *necessarily* missing the information
> present in the head of the programmer who writes instead a single
> SQL statement, information that is then embodied in that statement.

Since the programmer writes the object graph, he knows how to ensure 
that the best SQL gets written...  One day, the ORM will likely infer 
this from the structure of the object graph and (like a jitter) from 
the way the application executes.

>>> I have *often* seen four and five order of magnitude
>>> performance difference between straight SQL and
>>> ORM SQL, across a wide variety of ORMs. The
>>> very idea of ORM demands it: you have to try to
>>> push a whole set-oriented language through a functional
>>> interface.
>> 
>> Bah.  You don't *have* to do any such thing.I won't argue that there
>> aren't programmers and teams who use their tools poorly.
> 
> Nice dodge.
> 
> ORMs are a breeding ground for antipatterns.

RELIGION!

> OO code written
> in the style you advocate  (Employee.get("bob")) is a performance
> disaster first, and benefit-free busy work last.

Not in an application that only get's Bob.  Clearly, in application 
that do more interesting things, we'd use more interesting constructs.

-- 
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)
3/11/2008 1:17:23 AM
On 2008-03-06 14:54:27 -0600, topmind <topmind@technologist.com> said:

> The industry is full of horror stories with regard to ORM mappers.

The industry is full of horror stories with regard to SQL.  So what?
-- 
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)
3/11/2008 1:24:28 AM
On 2008-03-06 08:46:57 -0600, "David Cressey" <cressey73@verizon.net> said:

> I used to work in assembler, a long, long time ago.

Me too.  BAL from '69-71.  Varian 620 from '71-'73.  Then PDP-8, 
PDP-11, 8080, and 8086.  The largest assembler program I worked on was 
66,000 lines of code.  The most challenging was 20,000 lines of 8080.

I Finally started writing in C in 80.  C++ in 90.  Java in 98. C# in 
2002, and Python and Ruby in 2005.  Oh, and a gazilion other languages 
along the way like Smalltalk, Forth, Prolog, Snobol, Cobol, Fortran, 
PL/1, etc, etc.
> 


-- 
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)
3/11/2008 1:39:53 AM
On 2008-03-06 02:12:17 -0600, Marshall <marshall.spight@gmail.com> said:

> On Mar 5, 10:40 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> On 2008-03-05 14:10:11 -0600, "Dmitry A. Kazakov"
>> 
>>>>>> <snip>
>>>>>> You are confusing OO with static typing.  In OO languages like Ruby,
>>>>>> Python, or Smalltalk you can pass any object to any function
>>>>>> irrespective of type.
>> 
>>>>> Which is a bad idea.
>> 
>>>> Why?
>> 
>>> Because it is in fact untyped.
>> 
>> No, it's just not statically typed.
> 
> This issue is entirely tangential to the thread, but just FYI.
> There is a strict, formal definition of "type" under which
> languages like Python, Smalltalk, etc. are untyped.
> This sense of the term is often favored in type theory,
> and in fact is the one that introduced the word "type" to
> mathematics.

So let's go back to the thread. (up above this, I'm sure you can find 
it) I started talking about static and dynamic typing.  Somebody said 
dynamic typing was bad.  I asked why.  They said it was because it was 
untyped.

Now aside from the fact that the argument had, at that point, gone 
circular, I think the person who used the word 'un' was also imputing a 
pejorative meaning to it.  So I corrected him.

> In common parlance, however, untyped languages are
> typically called "dynamically typed" in cases where they
> employ a runtime tag system to classify values.

Agreed.  The term 'untyped', whether "formal" or not, is inaccurate 
when used to describe a dynamically typed language.  Every value has a 
type.
> 
> I propose the thread is already sufficiently contentious
> without introducing further areas of controversy, such
> as static typing vs. whatever you care to call the other thing.

So then this post was an attempt to attenuate controversy?


-- 
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)
3/11/2008 1:47:05 AM
On 2008-03-06 03:39:54 -0600, S Perryman <q@q.net> said:

> 1. Type inferencing is *strongly-typed* .

I know, Steve.

-- 
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)
3/11/2008 1:48:00 AM
On 2008-03-06 01:03:26 -0600, Marshall <marshall.spight@gmail.com> said:

> On Mar 5, 10:48 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> On 2008-03-05 09:58:43 -0600, Marshall <marshall.spi...@gmail.com> said:
>> 
>>>> You are confusing OO with static typing.
>> 
>>> How supremely annoying to have gone to some lengths
>>> to carefully use the most strictly defined, modern type
>>> system terminology, only to have it labeled as a novice
>>> error by someone who missed my point entirely.
>> 
>> How awful for you.
> 
> I accept you apology.

<grin>



-- 
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)
3/11/2008 1:48:43 AM
"David Cressey" <cressey73@verizon.net> writes:
> I don't think of 1971, when I wrote the garbage collector for MDL  as "the
> early days of garbage collection."  The "early days would have been in the
> 1950s when McCarthy wrote the garbage collector for LISP.   The MDL garbage
> collector was more ambitious than the Lisp garbage collector.  But I had the
> advantage of learning from  the work that had already been done.

apl also did new storage allocation on every assignment ... and did
garbage collection & compaction when space in workspace was exhausted.

the science center (4th flr of 545 tech sq) 
http://www.garlic.com/~lynn/subtopic.html#545tech

ported apl\360 to cp67/cms ... and had to rework the garbage
collection. typical apl\360 workspace was 16kbyte-32kbyte real storage
.... and whole workspace was always swapped as single unit.

cms allowed for multiple mbyte (virtual memory, paged) workspaces
.... and the apl\360 garbage collection implementation resulted in severe
page thrashing ... which had to be redone for virtual memory environment
before release of cms\apl.
http://www.garlic.com/~lynn/subtopic.html#hone

part of work on apl virtual memory garbage collection used some
application monitoring and modeling tools also done at the science
center ... which was eventually released as vs/repack product in the
mid-70s (included semi-automated program reorganization for virtual
memory operation).

vs/repack technology was used by a number of internal product groups
(including varioud dbms like IMS) as part of transition from real
storage to virtual storage environment.

the followon to cp67, vm370 was used (originally on 370/145 in bldg. 28) for
the original relational/sql implementation, system/r
http://www.garlic.com/~lynn/subtopic.html#systemr
0
lynn13 (400)
3/11/2008 2:02:57 AM
On Mar 10, 5:17 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>
> Wow, it's sure getting deep in here.  I can't seem to make out the
> content for all the fuzz and snow.

Indeed. Thread fatigue has set in. I suspect we are going to
have to "agree to disagree" as they say, the same way we
did when we had a big c.d.t/c.o. crosspost flamewar on the
topic of ORMs, just like we did when we had the same
conversation in 2007, and earlier in 2006 and 2005.

I'll be brief:

> So, in fact, it is not a reverse analogy.  It is a very appropriate
> analogy.  The ORM lives at a higher level of abstraction than the SQL
> because it has access to application intent, that the SQL does not have.

I disagree on every particular. ORMs are decidedly lower level. And
the reason they have written poor SQL historically, write poor SQL
today, and always will write poor SQL is because they do not have
access to application intent.

I recognize that I am merely making assertions and not arguments
at this point.


> > ORMs are a breeding ground for antipatterns.
>
> RELIGION!

Experience.

Let me just put it this way. Over the last ten years I have evaluated
something like 50 different ORMs. I have written at least three
myself.
I have participated in the industrial development of two, one at a
smallish consulting company and one at a Fortune 100 company
known for its engineering prowess. Further I have worked on
several applications with hand-written "entity layers"; effectively
these are manually-produced ad-hoc ORMs, sometimes running
to a hundred thousand lines of code.

I have yet to see even one ORM that didn't have egregious
logical errors on page one, the sort that indicate that the designer
didn't understand the basics of the relational model. I have yet
to see even one of them that didn't make some architectural
assumption that placed unnecessary if not ridiculous requirements
on the schema. I have yet to see even one of them produce
adequate performance under load.

Bleah. I have more experiences to relate, but I have to go
cook some rice.

So, is a good ORM possible? I am convinced not. Do I have
ironclad proof? I admit I don't. Alas, I shall have to make due
with a highly predictive explanatory model and overwhelming
supporting evidence merely.


Marshall
0
3/11/2008 2:40:48 AM
Marshall wrote:
....
> I disagree on every particular. ORMs are decidedly lower level. And
> the reason they have written poor SQL historically, write poor SQL
> today, and always will write poor SQL is because they do not have
> access to application intent.
> 
> I recognize that I am merely making assertions and not arguments
> at this point.
> ...


Okay, here is a question: what is the algebra or calculus of OO-style 
objects?
0
paul
3/11/2008 3:47:59 AM
On Mar 10, 5:47 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>
> So then this post was an attempt to attenuate controversy?

Yes. Not that I am necessarily against controversy, but
perhaps one at a time is a good working limit. :-)

Just as every superhero must have a nemesis,
so must every newsgroup have a nemesis. And just as
with superheroes, the hero/nemesis conflict is unresolvable,
fundamental; it is inseparably entangled in the very identity
of the participants. Only the destruction of one or the other
can resolve the conflict. And of course, each participant
self-identifies as the hero.

Clearly comp.object and comp.databases.theory form just
such a dyad, with data-centered vs. code-centered thinking
the unresolvable heart of the conflict. ORMs are just flashpoints
for the controversy. (ORMs being comparable to Gorilla Grodd's
attempt to turn all the humans on Earth into gorillas, thwarted
by the Justice League, thank goodness!)

Another such dyad is comp.lang.functional and comp.lang.lisp.
The unresolvable conflict between them is static vs. dynamic
typing. Once a year or so, the groups break out in open hostility.
Sometimes this is the result of a deliberate breaking of the cease
fire by an embedded agent provocateur, (such as the last time
Clan Object and Clan Database Theory fought) and sometimes
it is by an innocent (or was he?!) crosspost by a unwitting noob,
as in the current round of atrocities.

Ugh, I'm boring even myself. It's time to play some Halo.
If you like, reread this post in the voice of Comic Book Guy
and see if it gets any funnier.

No?


Marshall
0
3/11/2008 4:28:40 AM
Marshall wrote:
> On Mar 10, 5:47 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>> So then this post was an attempt to attenuate controversy?
> 
> Yes. Not that I am necessarily against controversy, but
> perhaps one at a time is a good working limit. :-)
> 
> Just as every superhero must have a nemesis,
> so must every newsgroup have a nemesis. And just as
> with superheroes, the hero/nemesis conflict is unresolvable,
> fundamental; it is inseparably entangled in the very identity
> of the participants. Only the destruction of one or the other
> can resolve the conflict. And of course, each participant
> self-identifies as the hero.
> 
> Clearly comp.object and comp.databases.theory form just
> such a dyad, with data-centered vs. code-centered thinking
> the unresolvable heart of the conflict. ORMs are just flashpoints
> for the controversy. (ORMs being comparable to Gorilla Grodd's
> attempt to turn all the humans on Earth into gorillas, thwarted
> by the Justice League, thank goodness!)
> 
> Another such dyad is comp.lang.functional and comp.lang.lisp.
> The unresolvable conflict between them is static vs. dynamic
> typing. Once a year or so, the groups break out in open hostility.
> Sometimes this is the result of a deliberate breaking of the cease
> fire by an embedded agent provocateur, (such as the last time
> Clan Object and Clan Database Theory fought) and sometimes
> it is by an innocent (or was he?!) crosspost by a unwitting noob,
> as in the current round of atrocities.
> 
> Ugh, I'm boring even myself. It's time to play some Halo.
> If you like, reread this post in the voice of Comic Book Guy
> and see if it gets any funnier.
> 
> No?
> 
> 
> Marshall

I thought it was pretty funny.

And accurate.

But before you fatigue completely from the thread:

Upthread, you mentioned you had gone to some length to use most strictly 
defined modern type system terminology. I don't suppose you have a cite 
for some of it? I'm clearly out of date.

I tend to think of typing systems as falling somewhere on a 
four-dimensional space with the axes:

   Latent/Manifest
   Structural/Nominal
   Static/Dynamic
   Strong/Weak

I wonder just how out of date I am....

Cheers,
Joe
0
Joe
3/11/2008 4:55:17 AM
"JOG" <jog@cs.nott.ac.uk> wrote in message 
news:0cd61579-0f26-422c-9aec-908ffdea59ff@i7g2000prf.googlegroups.com...
> On Mar 3, 2:07 pm, Thomas Gagne <tga...@wide-open-west.com> wrote:
>> All attempts by applications to access a DB's tables and columns
>> directly violates design principles that guard against close-coupling.
>> This is a basic design tenet for OO.  Violating it when jumping from OO
>> to RDB is, I think, the source of problem that are collectively and
>> popularly referred to as the object-relational impedance mismatch.
>
> I wondered if we might be able to come up with some agreement on what
> object-relational impedence mismatch actually means. I always thought
> the mismatch was centred on the issue that a single object != single
> tuple, but it appears there may be more to it than that.
>
> I was hoping perhaps people might be able to offer perspectives on the
> issues that they have encountered.  One thing I would like to avoid
> (outside of almost flames of course), is the notion that database
> technology is merely a persistence layer (do people still actually
> think that?) - I wonder if the 'mismatch' stems from such a
> perspective.

I think the mismatch has nothing to do with either.  The relational camp is 
focused on "what;" the object camp is focused on "how."  The relational camp 
seeks to determine whether a database state is possible; the object camp 
seeks to specify possible changes of state.  Where the impedance comes in is 
that there may be multiple paths from one possible database state to 
another.

The focus of a programmer is to get from point A to point B.  On the one 
hand, you can state which path you're going to take; on the other hand, you 
can specify which paths are valid.  But just because you take a particular 
path doesn't necessarily mean that another path is not just as valid: there 
may be more than one valid path from point A to point B.  But OO doesn't 
require that every valid path be specified--only that the paths specified be 
valid paths; neither does the RM have a mechanism to detect which path was 
taken.  (Candidate keys do not necessarily rigidly designate.)  This is the 
essence of the object-relational impedance mismatch.  There would be no 
impedance if there were a mechanism in the RM to detect which path was taken 
during a transition; there would be no impedance if OO required 
specification of /all/ possible paths.  If it were possible to detect which 
path was taken, then it should be possible to determine the set of all valid 
paths; if all valid paths were specified, it should be possible to determine 
which path is being taken. 


0
brian8537 (72)
3/11/2008 5:16:01 AM
On Mar 10, 8:55 pm, Joe Thurbon <use...@thurbon.com> wrote:
> Marshall wrote:
> >
> > Ugh, I'm boring even myself. It's time to play some Halo.
>
> I thought it was pretty funny.
>
> And accurate.

Thanks. I should mention that I had an awesome flag
capture. Most of the enemy team was occupied midfield,
and they left their base empty. I sailed in, grabbed the
flag, and hit the man-cannon. Midflight I hear a teammate
say on the comm "We'll be waiting for you." And flying
up to the drop point, I see a Warthog with driver and
gunner, right there. I hop in the passenger seat with
the flag and we hightail it back to our base. As we're
almost there I hear the unmistakable beep-beep of
an enemy lock on our vehicle; I immediately hop out
just seconds before missiles destroy the 'hog and
the other two guys, but I made it out in time and
scored.

I play under the tag "Natural Join".


> But before you fatigue completely from the thread:
>
> Upthread, you mentioned you had gone to some length to use most strictly
> defined modern type system terminology. I don't suppose you have a cite
> for some of it? I'm clearly out of date.

http://www.amazon.com/Types-Programming-Languages-Benjamin-Pierce/dp/0262162091

Pierce seems to be the guy everyone's citing these days,
at least for definitions and pithy summaries of the field.


> I tend to think of typing systems as falling somewhere on a
> four-dimensional space with the axes:
>
>    Latent/Manifest
>    Structural/Nominal
>    Static/Dynamic
>    Strong/Weak

Well, strong/weak has been deprecated pretty hard. There's
this term "safe" now, to describe what C isn't. "Latent" seems
to mostly be a synonym for "dynamic" now. There's also
the "explicitly annotated" term, to describe what languages
like C++ and Java are, and OCaml and Haskell aren't.


> I wonder just how out of date I am....

If you understand structural vs. nominal, you're way ahead
of most people.


Marshall
0
Marshall
3/11/2008 7:04:30 AM
Marshall wrote:
> On Mar 10, 8:55 pm, Joe Thurbon <use...@thurbon.com> wrote:
>> Marshall wrote:

[...]

> I immediately hop out
> just seconds before missiles destroy the 'hog and
> the other two guys, but I made it out in time and
> scored.
> 

Played.

> I play under the tag "Natural Join".

I used to play Bolo. I played as Fetid Dingo's Kidney. My play was no 
better than my name.

> 
> 
>> But before you fatigue completely from the thread:
>>
>> Upthread, you mentioned you had gone to some length to use most strictly
>> defined modern type system terminology. I don't suppose you have a cite
>> for some of it? I'm clearly out of date.
> 
> http://www.amazon.com/Types-Programming-Languages-Benjamin-Pierce/dp/0262162091
> 

Thanks for that. I'll have a look.

> Pierce seems to be the guy everyone's citing these days,
> at least for definitions and pithy summaries of the field.
> 
> 
>> I tend to think of typing systems as falling somewhere on a
>> four-dimensional space with the axes:
>>
>>    Latent/Manifest
>>    Structural/Nominal
>>    Static/Dynamic
>>    Strong/Weak
> 
> Well, strong/weak has been deprecated pretty hard. 

Not hard enough, I think (and I say that not knowing how hard you mean.) 
 From my perspective, weak only really ever seemed to have assembly and 
C in it, anyway.

> There's
> this term "safe" now, to describe what C isn't. 

That was 'strong' for me.

> "Latent" seems
> to mostly be a synonym for "dynamic" now. 

Oh. Wow. I used "latent" for things like Ocaml, where types are 
inferred, as well as things like Ruby where references are un-typed but 
objects are typed.

> There's also the "explicitly annotated" term, 
 > to describe what languages like C++ and Java are, and OCaml and
 > Haskell aren't.

My "manifest".

> 
> 
>> I wonder just how out of date I am....
> 
> If you understand structural vs. nominal, you're way ahead
> of most people.

Woot!

Anyway, back to my personal Java hell ...

Cheers,
Joe
0
Joe
3/11/2008 7:59:40 AM
Marshall <marshall.spight@gmail.com> wrote in news:026db19e-4064-4b37-
a98e-0826695ed5a7@s8g2000prg.googlegroups.com:

> On Mar 10, 10:47 am, "Yagotta B. Kidding" <y...@mymail.com> wrote:
>> > Mr. Perryman's example was written in a single-assignment,
>> > mathematical style.
>>
>> And yet you still do not see where the assignment comes in in Mr.
>> Perryman's example.
> 
> You understand that single-assignment is different from
> assignment, right? You know that single-assignment doesn't
> cause any problems with referential transparency, right?

I readily admit that I did not pay attention to the 'single' word until 
you've pointed out.

I must point out that no one except wikipedia or some misguided souls use 
the single 'assignment' term any more.  Now,  the accepted term is name 
binding or let binding to make the point than no assignment in the 
imperative sense takes place.  You wont find the term in either Haskell 
or OCAML manuals btw. Just to prevent a potential mud slinging contest, 
nobody disputes the fact that the mongrel language OCAML does have the 
real assignment.

Nevertheless, it is possible to express Mr. Perryman's projection with 
OCAML's structural subtyping and let binding,  that much is true, but the 
attempt would look butt ugly. It is worth to remind perhaps that let 
binding is an FP feature unavailable in any major OOP language.  A 
question arises,  then,  why bother and not go for a real thing,  FP ?

> 
> Well, we're into a subpoint of a subpoint of a subpoint.
> Perhaps a refreshing Snapple is in order!
> 
> 
> Marshall
> 

0
ybk1 (19)
3/11/2008 2:19:09 PM

Robert Martin wrote:
> On 2008-03-06 02:29:51 -0600, Marshall <marshall.spight@gmail.com> said:
>
> > On Mar 5, 10:32 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> >> On 2008-03-05 09:48:45 -0600, Marshall <marshall.spi...@gmail.com> said=
:
> >>> On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> >>
> >>>>> Furthermore, since OOPLs lack physical independence, traversing
> >>>>> the graph may be quite expensive, particularly in the case where
> >>>>> the graph is backed by storage in a database, which is part of
> >>>>> why ORM is such a universally bad idea.
> >>
> >>>> No, you have this wrong.  ORMs generally use standard SQL queries to
> >>>> traverse and gather data from the DB.  Then that data is placed into =
OO
> >>>> structures so that the application can take advanage of the bias.
> >>
> >>> Just the fact that they use SQL isn't sufficient. They have to
> >>> use it as well as a person could, though an interface that
> >>> is generally information-lossy enough (or at least, used in
> >>> a lossy way) that that's impossible.
> >>
> >> Yeah, assembly language programmers used to say the same thing about
> >> compilers.  Then the compilers started writing more efficient code than=

> >> the assembly language programmers could...
> >
> > I give you high marks for rhetoric here. Excellently argued!
> > You take the opposing side and compare them to assembly,
> > and compare yourself with compiled languages. That the
> > situation is most closely analogous to exactly the reverse
> > is only relevant if one is interested in a deep understanding
> > doesn't detract at all from the rhetorical effectiveness.
>
> Wow, it's sure getting deep in here.  I can't seem to make out the
> content for all the fuzz and snow.
>
> 1. ORMs generate SQL in a manner analagous to compilers generating
> assembly.  Why is it analagous?  Because the ORMs can infer a
> considerable amount of intent, and can therefore generate highly
> specific SQL.  (The fact that many don't is irrelevant).  This is just
> like compilers who infer intent from the code and generate highly
> specific and tuned assembler.

That is a huge stretch. SQL is *not* low-level.  I will agree there
are areas for improvement, but that's true with *any* language. What
ORM's do is more like translating Smalltalk to Python (or visa versa)
because Python fans don't want to deal with Smalltalk per dogma or
personal preference.

>
> 2. Compilers got so good at this that they generated more efficient
> (not better) assembler code than humans could (or would).  The compiler
> had no care for art or readability.  So the compiler did things that no
> human would dare.  ORMs have the same opportunity.

The RDBMS already has capabilities to select optimum (or better)
execution paths. If the ORM improves it even more, then good for it.
Often, however, that is not the case.

>
> So, in fact, it is not a reverse analogy.  It is a very appropriate
> analogy.  The ORM lives at a higher level of abstraction than the SQL
> because it has access to application intent, that the SQL does not have.

You attribute magic qualities to ORM's that they don't deserve. ORM's
are complex tools that require experts to use effectively and still
are a source for a lot of headaches and performance bottlenecks. I've
read a *lot* of gripes about ORM's on the web.

>
> > As an actual engineering argument, though, this fails.
> > Because it doesn't address the information-loss point I made.
> > No code generator can write optimal code if it's missing information
> > necessary to determine what is optimal. Object-graph traversal
> > in ORMs is *necessarily* more expensive than straightforward SQL.
>
> You are all caught up on object graph traversals as though they were
> the only way to work with ORMs.  Indeed, most of us silly and sloppy OO
> programmers understand that you don't want to walk unfetched object
> graphs.  So we populate the necessary nodes in a set of efficient
> querries.

Why not compare master SQL programmers with master OO'ers instead of
sub-par SQL'ers with master OO'ers?

>
> > In part exactly because it is *necessarily* missing the information
> > present in the head of the programmer who writes instead a single
> > SQL statement, information that is then embodied in that statement.
>
> Since the programmer writes the object graph, he knows how to ensure
> that the best SQL gets written...  One day, the ORM will likely infer
> this from the structure of the object graph and (like a jitter) from
> the way the application executes.

MindReader 2.0

> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com
> Object Mentor Inc.=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=
=BD=EF=BF=BD| blog:=EF=BF=BD=EF=BF=BDwww.butunclebob.com

-T-
0
topmind (2124)
3/11/2008 3:56:11 PM

Robert Martin wrote:
> On 2008-03-06 14:54:27 -0600, topmind <topmind@technologist.com> said:
>
> > The industry is full of horror stories with regard to ORM mappers.
>
> The industry is full of horror stories with regard to SQL.  So what?

Using ORM's effectively requires both decent knowledge of SQL/RDBMS
and the ORM tool. Using SQL/RDBMS effectively only requires the first.

If the ORM expert doesn't know SQL/RDBMS sufficiently, then they
cannot troubleshoot issues properly.

ORM's are a jobs program. (May be good for a paycheck, but is
otherwise an unnecessary expense to a company.)

> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com
> Object Mentor Inc.=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=
=BD=EF=BF=BD| blog:=EF=BF=BD=EF=BF=BDwww.butunclebob.com

-T-
0
topmind (2124)
3/11/2008 4:06:10 PM
On Mar 10, 4:53=A0pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> TroyK wrote:
> > On Mar 8, 7:09 am, rp...@pcwin518.campus.tue.nl (rpost) wrote:
>
> >>TroyK =A0wrote:
>
> >>>Who said anything about stored procedures? I'm talking about
> >>>implementing the business rules via constraint declaration in the
> >>>database, and deriving new values throught the application of SQL
> >>>queries.
>
> >>Do you also treat dynamic constraints in this way?
>
> >>E.g. "unless otherwise specified, an employee shall get a 2%
> >>salary increase after each full year of employment".
>
> with not_excluded_ee =3D (
> =A0 employees join ( employees{ee#} minus excluded_ees{ee#} )
> ), increases =3D extend (
> =A0 =A0not_excluded_ee where is_anniversary_period(pay_period(now),hire_da=
te)
> ) add increase =3D salary * percent(2)
> ...
>
> >>Or: "two movable 3D shapes shall never collide; collision is avoided
> >>by the following repositioning algorithm that is guaranteed
> >>to pull all objects apart that get too close: (...), however, this
> >>algorithm may be replaced with another that has the same property".
>
> with other_objects =3D objects rename all prepending "other_"
> , collisions =3D objects join other_objects
> =A0 =A0where rank_attrib < other_rank_attrib
> =A0 =A0 =A0and min_distance(polygons,other_polygons) < threshold_distance
> , while exists(collisions) {
> =A0 =A0 =A0update collisions
> =A0 =A0 =A0set position =3D ...
> =A0 =A0 =A0, other_position =3D ...
>
> }
>
> >>--
> >>Reinier
>
> > Inferring the definition of "dynamic constraint" from your examples,
> > in the first, I think that it would be sufficient to model and record
> > whatever attribute means "otherwise specified" and include that as
> > part of the condition in the constraint declaration.
>
> What was the constraint part again?
>

I suppose given a db that maintains some temporal dimension for the
employee facts ("history table" or somesuch) would have a constraint
that the tuples within it must be derived using your expression above.
Absent that, the expression itself constrains the values that can be
derived. Is that a fair statement?

>
> > I haven't had occasion to apply the technique to anything more complex
> > than such an example, so I'll have to say "I don't know" to the 3D
> > example.
>

Nice sketch of the 3D solution, Bob. I've set aside some time to play
with SQL Server's new spatial datatypes (Geography and Geometry), but
this cut of the feature only supports 2D.

TroyK
0
cs_troyk (11)
3/11/2008 5:04:46 PM
topmind wrote:

> 
> Robert Martin wrote:
> 
>>On 2008-03-06 02:29:51 -0600, Marshall <marshall.spight@gmail.com> said:
>>
>>
>>>On Mar 5, 10:32 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>>>
>>>>On 2008-03-05 09:48:45 -0600, Marshall <marshall.spi...@gmail.com> said:
>>>>
>>>>>On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>>>>
>>>>>>>Furthermore, since OOPLs lack physical independence, traversing
>>>>>>>the graph may be quite expensive, particularly in the case where
>>>>>>>the graph is backed by storage in a database, which is part of
>>>>>>>why ORM is such a universally bad idea.
>>>>
>>>>>>No, you have this wrong.  ORMs generally use standard SQL queries to
>>>>>>traverse and gather data from the DB.  Then that data is placed into OO
>>>>>>structures so that the application can take advanage of the bias.
>>>>
>>>>>Just the fact that they use SQL isn't sufficient. They have to
>>>>>use it as well as a person could, though an interface that
>>>>>is generally information-lossy enough (or at least, used in
>>>>>a lossy way) that that's impossible.
>>>>
>>>>Yeah, assembly language programmers used to say the same thing about
>>>>compilers.  Then the compilers started writing more efficient code than
>>>>the assembly language programmers could...
>>>
>>>I give you high marks for rhetoric here. Excellently argued!
>>>You take the opposing side and compare them to assembly,
>>>and compare yourself with compiled languages. That the
>>>situation is most closely analogous to exactly the reverse
>>>is only relevant if one is interested in a deep understanding
>>>doesn't detract at all from the rhetorical effectiveness.
>>
>>Wow, it's sure getting deep in here.  I can't seem to make out the
>>content for all the fuzz and snow.
>>
>>1. ORMs generate SQL in a manner analagous to compilers generating
>>assembly.  Why is it analagous?  Because the ORMs can infer a
>>considerable amount of intent, and can therefore generate highly
>>specific SQL.  (The fact that many don't is irrelevant).  This is just
>>like compilers who infer intent from the code and generate highly
>>specific and tuned assembler.
> 
> 
> That is a huge stretch. SQL is *not* low-level.  I will agree there
> are areas for improvement, but that's true with *any* language. What
> ORM's do is more like translating Smalltalk to Python (or visa versa)
> because Python fans don't want to deal with Smalltalk per dogma or
> personal preference.
> 
> 
>>2. Compilers got so good at this that they generated more efficient
>>(not better) assembler code than humans could (or would).  The compiler
>>had no care for art or readability.  So the compiler did things that no
>>human would dare.  ORMs have the same opportunity.
> 
> 
> The RDBMS already has capabilities to select optimum (or better)
> execution paths. If the ORM improves it even more, then good for it.
> Often, however, that is not the case.
> 
> 
>>So, in fact, it is not a reverse analogy.  It is a very appropriate
>>analogy.  The ORM lives at a higher level of abstraction than the SQL
>>because it has access to application intent, that the SQL does not have.
> 
> 
> You attribute magic qualities to ORM's that they don't deserve. ORM's
> are complex tools that require experts to use effectively and still
> are a source for a lot of headaches and performance bottlenecks. I've
> read a *lot* of gripes about ORM's on the web.
> 
> 
>>>As an actual engineering argument, though, this fails.
>>>Because it doesn't address the information-loss point I made.
>>>No code generator can write optimal code if it's missing information
>>>necessary to determine what is optimal. Object-graph traversal
>>>in ORMs is *necessarily* more expensive than straightforward SQL.
>>
>>You are all caught up on object graph traversals as though they were
>>the only way to work with ORMs.  Indeed, most of us silly and sloppy OO
>>programmers understand that you don't want to walk unfetched object
>>graphs.  So we populate the necessary nodes in a set of efficient
>>querries.
> 
> 
> Why not compare master SQL programmers with master OO'ers instead of
> sub-par SQL'ers with master OO'ers?

Better yet, just listen to those of us who are both already.
0
bbadour (434)
3/11/2008 5:10:01 PM
TroyK wrote:

> On Mar 10, 4:53 pm, Bob Badour <bbad...@pei.sympatico.ca> wrote:
> 
>>TroyK wrote:
>>
>>>On Mar 8, 7:09 am, rp...@pcwin518.campus.tue.nl (rpost) wrote:
>>
>>>>TroyK  wrote:
>>
>>>>>Who said anything about stored procedures? I'm talking about
>>>>>implementing the business rules via constraint declaration in the
>>>>>database, and deriving new values throught the application of SQL
>>>>>queries.
>>
>>>>Do you also treat dynamic constraints in this way?
>>
>>>>E.g. "unless otherwise specified, an employee shall get a 2%
>>>>salary increase after each full year of employment".
>>
>>with not_excluded_ee = (
>>  employees join ( employees{ee#} minus excluded_ees{ee#} )
>>), increases = extend (
>>   not_excluded_ee where is_anniversary_period(pay_period(now),hire_date)
>>) add increase = salary * percent(2)
>>...
>>
>>
>>>>Or: "two movable 3D shapes shall never collide; collision is avoided
>>>>by the following repositioning algorithm that is guaranteed
>>>>to pull all objects apart that get too close: (...), however, this
>>>>algorithm may be replaced with another that has the same property".
>>
>>with other_objects = objects rename all prepending "other_"
>>, collisions = objects join other_objects
>>   where rank_attrib < other_rank_attrib
>>     and min_distance(polygons,other_polygons) < threshold_distance
>>, while exists(collisions) {
>>     update collisions
>>     set position = ...
>>     , other_position = ...
>>
>>}
>>
>>>>--
>>>>Reinier
>>
>>>Inferring the definition of "dynamic constraint" from your examples,
>>>in the first, I think that it would be sufficient to model and record
>>>whatever attribute means "otherwise specified" and include that as
>>>part of the condition in the constraint declaration.
>>
>>What was the constraint part again?
> 
> I suppose given a db that maintains some temporal dimension for the
> employee facts ("history table" or somesuch) would have a constraint
> that the tuples within it must be derived using your expression above.
> Absent that, the expression itself constrains the values that can be
> derived. Is that a fair statement?

Oh, you mean a constraint like:

( ee# in excluded_ees{ee#} )
or ( not is_anniversary_period(pay_period(now),hire_date) )
or ( salary >= previous_salary * percent(1.02) )

What's so hard about that? Note, I used >= to allow for other 
coincidental raises.


>>>I haven't had occasion to apply the technique to anything more complex
>>>than such an example, so I'll have to say "I don't know" to the 3D
>>>example.
> 
> Nice sketch of the 3D solution, Bob. I've set aside some time to play
> with SQL Server's new spatial datatypes (Geography and Geometry), but
> this cut of the feature only supports 2D.

Thank you. I hope you have fun with the spatial datatypes, but I wish 
you had a nicer language than SQL for playing with them.
0
bbadour (434)
3/11/2008 9:19:06 PM
-snippage-
> Oh, you mean a constraint like:
>
> ( ee# in excluded_ees{ee#} )
> or ( not is_anniversary_period(pay_period(now),hire_date) )
> or ( salary >= previous_salary * percent(1.02) )
>
> What's so hard about that?

Nothing - That's been my point :)   Much easier to do this stuff using
relational (or, heck, even SQL) than by using "objects".

TroyK
0
cs_troyk (11)
3/11/2008 10:37:25 PM
TroyK wrote:

> -snippage-
> 
>>Oh, you mean a constraint like:
>>
>>( ee# in excluded_ees{ee#} )
>>or ( not is_anniversary_period(pay_period(now),hire_date) )
>>or ( salary >= previous_salary * percent(1.02) )
>>
>>What's so hard about that?
> 
> Nothing - That's been my point :)   Much easier to do this stuff using
> relational (or, heck, even SQL) than by using "objects".

Oops, there was a typo mistake in it. I guess avoiding those is the hard 
part.
0
bbadour (434)
3/11/2008 10:50:43 PM
"Bob Badour" <bbadour@pei.sympatico.ca> wrote in message 
news:47d6bced$0$4064$9a566e8b@news.aliant.net...
> topmind wrote:
>
>>
>> Robert Martin wrote:
>>
>>>On 2008-03-06 02:29:51 -0600, Marshall <marshall.spight@gmail.com> said:
>>>
>>>
>>>>On Mar 5, 10:32 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>>>>
>>>>>On 2008-03-05 09:48:45 -0600, Marshall <marshall.spi...@gmail.com> 
>>>>>said:
>>>>>
>>>>>>On Mar 4, 11:05 pm, Robert Martin <uncle...@objectmentor.com> wrote:
>>>>>
>>>>>>>>Furthermore, since OOPLs lack physical independence, traversing
>>>>>>>>the graph may be quite expensive, particularly in the case where
>>>>>>>>the graph is backed by storage in a database, which is part of
>>>>>>>>why ORM is such a universally bad idea.
>>>>>
>>>>>>>No, you have this wrong.  ORMs generally use standard SQL queries to
>>>>>>>traverse and gather data from the DB.  Then that data is placed into 
>>>>>>>OO
>>>>>>>structures so that the application can take advanage of the bias.
>>>>>
>>>>>>Just the fact that they use SQL isn't sufficient. They have to
>>>>>>use it as well as a person could, though an interface that
>>>>>>is generally information-lossy enough (or at least, used in
>>>>>>a lossy way) that that's impossible.
>>>>>
>>>>>Yeah, assembly language programmers used to say the same thing about
>>>>>compilers.  Then the compilers started writing more efficient code than
>>>>>the assembly language programmers could...
>>>>
>>>>I give you high marks for rhetoric here. Excellently argued!
>>>>You take the opposing side and compare them to assembly,
>>>>and compare yourself with compiled languages. That the
>>>>situation is most closely analogous to exactly the reverse
>>>>is only relevant if one is interested in a deep understanding
>>>>doesn't detract at all from the rhetorical effectiveness.
>>>
>>>Wow, it's sure getting deep in here.  I can't seem to make out the
>>>content for all the fuzz and snow.
>>>
>>>1. ORMs generate SQL in a manner analagous to compilers generating
>>>assembly.  Why is it analagous?  Because the ORMs can infer a
>>>considerable amount of intent, and can therefore generate highly
>>>specific SQL.  (The fact that many don't is irrelevant).  This is just
>>>like compilers who infer intent from the code and generate highly
>>>specific and tuned assembler.
>>
>>
>> That is a huge stretch. SQL is *not* low-level.  I will agree there
>> are areas for improvement, but that's true with *any* language. What
>> ORM's do is more like translating Smalltalk to Python (or visa versa)
>> because Python fans don't want to deal with Smalltalk per dogma or
>> personal preference.
>>
>>
>>>2. Compilers got so good at this that they generated more efficient
>>>(not better) assembler code than humans could (or would).  The compiler
>>>had no care for art or readability.  So the compiler did things that no
>>>human would dare.  ORMs have the same opportunity.
>>
>>
>> The RDBMS already has capabilities to select optimum (or better)
>> execution paths. If the ORM improves it even more, then good for it.
>> Often, however, that is not the case.
>>
>>
>>>So, in fact, it is not a reverse analogy.  It is a very appropriate
>>>analogy.  The ORM lives at a higher level of abstraction than the SQL
>>>because it has access to application intent, that the SQL does not have.
>>
>>
>> You attribute magic qualities to ORM's that they don't deserve. ORM's
>> are complex tools that require experts to use effectively and still
>> are a source for a lot of headaches and performance bottlenecks. I've
>> read a *lot* of gripes about ORM's on the web.
>>
>>
>>>>As an actual engineering argument, though, this fails.
>>>>Because it doesn't address the information-loss point I made.
>>>>No code generator can write optimal code if it's missing information
>>>>necessary to determine what is optimal. Object-graph traversal
>>>>in ORMs is *necessarily* more expensive than straightforward SQL.
>>>
>>>You are all caught up on object graph traversals as though they were
>>>the only way to work with ORMs.  Indeed, most of us silly and sloppy OO
>>>programmers understand that you don't want to walk unfetched object
>>>graphs.  So we populate the necessary nodes in a set of efficient
>>>querries.
>>
>>
>> Why not compare master SQL programmers with master OO'ers instead of
>> sub-par SQL'ers with master OO'ers?
>
> Better yet, just listen to those of us who are both already.

Mastery is evident in those who have attained it.  Fortunately, most can 
recognize those who self-aggrandize as the charlatans, pretenders and frauds 
that they are. 


0
brian8537 (72)
3/12/2008 1:03:46 AM
On 2008-03-10 23:28:40 -0500, Marshall <marshall.spight@gmail.com> said:

> Clearly comp.object and comp.databases.theory form just
> such a dyad, with data-centered vs. code-centered thinking
> the unresolvable heart of the conflict.

So, in this entire discussion, have you seen me attack database theory 
even once?
-- 
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)
3/12/2008 2:25:08 AM
On Mar 11, 6:25 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-10 23:28:40 -0500, Marshall <marshall.spi...@gmail.com> said:
>
> > Clearly comp.object and comp.databases.theory form just
> > such a dyad, with data-centered vs. code-centered thinking
> > the unresolvable heart of the conflict.
>
> So, in this entire discussion, have you seen me attack database theory
> even once?

Offhand, I would suggest that it's probably not a good idea to
pay too much attention to any post of mine in which I mention
Gorilla Grodd. And I say that despite being absolutely
convinced that Powers Boothe did a great job with the voice
during that whole arc where Grodd and Lex Luthor (voiced by
Clancy Brown) wrestle over control of the Legion of Doom
during season five.

Okay, "attack?" I dunno.

I believe that the policies you advocate more or less
reduce the DBMS to a dumb record-store. I've wasted
a lot of my life explaining why, so no redux tonight.

Hey, that Justice League show is awesome for trivia,
though. Clancy Brown, for example. The voice of Lex
Luthor. Did you know he also does the voice for Mr.
Krabs on Spongebob AND he played Rawhide in
"Buckaroo Banzai" AND was the villian in "Highlander."
Isn't that hilarious? Wasn't the evil Kurgan in Highlander
awesome? Then we have this weird episode
in which the Flash and Lex Luthor end up changing
bodies.  On the Justice League, Flash is voiced by
Michael Rosenbaum, who of course everyone knows
plays Lex Luthor on Smallville. So once they changed
bodies, you have Michael Rosenbaum playing ...
Lex Luthor on Justice League! I thought it was an
amusing joke. And then also you have Carl Lumbly,
who plays the Martian Manhunter on Justice League,
and he was ALSO in Buckaroo Banzai. He was one
of the Johns. John Parker I think. So there's two
people who voice major characters in Justice League
who were in Buckaroo Banzai.

This one time, I'm in the editing booth, (the director had
asked me over for some some advice on some effects
shots) and the director's cell phone rings, and he says he
has to take the call and he pops up and he's gone for
five minutes or so. When he comes back, he tells me
about the call. He says something like, you maybe don't
know who this is, but I just talked with Carl Lumbly. And
I said Carl Lumbly! Of course I know who Carl Lumbly is.
I just watched him beat the crap out of Edward James Olmos
a couple of weeks ago. You see, Lumbly had been the
guest star in an episode of BattleStar Galactica. He played
a pilot who had been lost to the Cylons many years before,
and somehow escapes. He got in a huge fight with Adama.
His character's name was ... M something. He was a lieutenant.
M? I can't remember. Novacek! That was it: lieutenant Novacek.
Where did that "M" come from? What's wrong with my
memory?


Marshall
0
3/12/2008 5:04:29 AM
Marshall wrote:

> On Mar 6, 9:27 am, S Perryman <q...@q.com> wrote:

>>You regard "X-oriented" as something for which the facilities to support
>>X are provided at a fundamental level (like arithmetic ops, CAR/CDR in
>>Lisp etc) and not built (by whoever) from the fundamental constructs of
>>a prog lang.

>>Fair enough.

> Right. If we consider *potential* built constructs, and we are
> speaking of general purpose programming languages, then
> right away all languages collapse into a single category.

> We might make some allowances for languages whose standard
> library contains specific constructs, however. We might reasonably
> classify some functional languages that make extensive use of
> map, filter, and fold as being at least modestly list-oriented,
> despite the fact that their list constructs are really recursively
> defined union types. But it's probably better to consider the
> recursively defined type together with the higher-order function
> constructs as being the axiomatic signature of such languages.

I wouldn't consider it so, but it does no harm in debate to do so.


> Another important reason to consider the fundamental constructs
> of a PL is so that we can treat the PL as an axiomatic system.
> To me, the most interesting thing one can do with code is
> *reason* about it. This is why type systems are interesting
> (and "dynamically typed" languages not so much.) It's also
> part of why the relational model is so interesting. And it's
> why OOPLs don't hold my interest so much any more;
> their axioms are complicated and often weak.

Which "axioms" in particular cause you pain ??


M>Virtually no languages have primitive support for anything like a
M>collection. SQL and SETL and a few others; that's it. There are
M>some languages that were designed from the start with *list*
M>processing in mind: lisp (and I should probably also mention the
M>APL family here.) There are some *very* interesting things
M>in there, but not things I would say could be strictly described
M>as set-oriented.

>>I take a slightly different view in that I obviously have the need
>>for various collection types, and support for a Relational "calculus"
>>to use on those collections. I also need support for collections of
>>ADTs in particular.

> The collections question is quite interesting: Lists, maps, bags,
> sets, tables, trees. It is apparent after only a modest amount
> of study that maps, sets, and tables are thoroughly and beautifully
> handled with relations.

Collections should be deliberately vague.
Insert and remove. Empty. Contains an item, how many occurrences of
an item etc.

A set is a specific form of collection (contains 0 or 1 instance of
any given element, insertion of a contained element has no effect etc) .

And so on.


> It took me a lot longer but I've reached
> the conclusion that lists fall in to the same category.

Sequences are conceptually a partial mapping of (Index,Element) tuples.
Certain mappings being undefined (hence partial) .


> Trees no longer seem like a single category to me: there
> are what I call "statically structured" trees, for example
> Customers/ Invoices/InvoiceLineItems, and "dynamically
> structured" trees, such as a parse tree.

A tree is a specific form of graph.
Graphs are conceptually two sets with an invariant relationship
between the sets. Trees merely define additional invariants on
those sets.


> Statically structured
> trees are are a particular strong point for SQL and also a
> strong point for the RM. Dynamically structured trees *can be*
> handled with the RM but I don't think it does as good a job
> as is done in, say, FP languages with union types and
> structural recursion. I conjecture that it may be possible
> to develop best practices and/or tiny extensions to the
> RM such that it does as good a job, but currently I'm
> leaning in the direction of thinking this will not be possible.
> I'm not completely thrilled with structural recursion, but
> I have yet to see anything better.

Is your issue with performance for things like breadth/depth
traversal etc ??


>>If possible I would like the prog lang user to be able to construct
>>specific collections such as sets etc, and for the prog lang env to be
>>within reasonable performance of something that is designed for the
>>support of some one specific aspect (as Lisp is for lists etc) .

>>I think that FP is the paradigm that could possibly do this.

> An important aspect of the performance requirement is physical
> independence, something that is largely ignored in PL theory,
> sadly.

The separation of specification (interface) from implementation is
something key to ADT theory. And for those prog langs (CLU, Modula-2
etc) that support one impl of each ADT per program unit, you have
the independence.

However, the coming of OO (unintentionally) threw a spanner in the
works. It became possible to have multiple *different* impls of one ADT
used *concurrently* in the same program unit.

A rough analogy (that AFAIK is not supported in commercial systems)
would be an SQL database that for some given table operates a B-tree
for certain records in the table, hashing for others etc. And expects
the performance for ops on the entire table to be the same whatever
predicates are applied to the table.


> If we look at the mathematical universe, we usually encounter
> an extensional viewpoint. And if something is expressed
> intensionally, or algorithmically, mathematicians are free to
> immediately think of its extension, because they do not have
> to limit themselves to what is computable.

> On the other hand, if we look at the computable universe, we
> see more often the intensional viewpoint. And we are not
> free to immediately shift into extensional mode, because
> of the possibly-infinite, almost-certainly-prohibitive cost of
> doing so.

> The RM gives the best handle on the computably extensional
> viewpoint I have encountered. FP gives the best handle
> on the intensional viewpoint.

I would say that FP has a strong extensional viewpoint too, solely
because it too is based on mathematical concepts (functions) .


Regards,
Steven Perryman
0
S
3/12/2008 8:54:42 AM
On Mar 11, 1:05 am, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-08 21:39:37 -0600, JOG <j...@cs.nott.ac.uk> said:
>
>
>
> > On Mar 9, 2:23 am, Robert Martin <uncle...@objectmentor.com> wrote:
> >> On 2008-03-06 06:37:19 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> >>> On Mar 6, 6:26 am, Robert Martin <uncle...@objectmentor.com> wrote:
> >>>> That's not inferrence.
>
> >>> Well that all jolly-well looks like inference to me.
>
> >> I agree that you can infer what elements a subclass has by knowing the
> >> elements of the base class.
>
> > Well then you have conceded defeat, given our conversation has gone as
> > follows:
>
> > jog: "So why not treat all 'inheritance' in this way [as inference]?"
> > Robert: "Because all inheritance is not about inference."
> > jog: show me an example when it is not.
> > Robert: I'll ignore that, and just describe the OO mechanism again.
> > jog: Look, here is how everything you have listed could have been
> > described through inference
> > Robert: Ok, I agree that all inheritance can be described via
> > inference.
>
> Here's the starting point of the conversation.  You wrote:
>
>
>
> >> Name(x, Aristotle) -> Species(x, Man)
> >> Species(x, Man) -> Mortality(x, Mortal)
> >> |= Name(x, Aristotle) -> Mortalilty(x, Mortal)
>
> >> No types or reification in sight. Instead I had two groups of
> >> statements:
> >> People = {Name, Species, Bday}
> >> Entities = {Species, Mortality}
>
> >> A join of the two statements gave me the inference I required: {Name,
> >> Mortality}. All of a sudden it seemed simple. So some questions:
>
> >> 1) So why not treat all 'inheritance' in this way?
> >> 2) Could one extend to include 'behaviour' as well?
> >> 3) And is this a crazy thing to suggest in a cross post to an OO
> >> group?
>
> I responded to your first question that when you need to make
> inferences, an inference engine is a good tool.  Inheritance is not an
> inference engine.

A red herring as far as I'm concerned this Robert - after all RM is
not an "inference engine" either. What I am questioning whether we
need the concept of inheritance /whatsoever/. It does not exist in
logic, it has no underlying theoretical justification, and is purely
an ad hoc mechanism thrown together at xerox parc. Is it not true that
inheritance has lost favour over the years - composition is generally
preferred, unless one is defining interfaces (and whether that should
still be called "inheritance" is open to debate).

> And you challenged me:
>
> >> Interesting story.  Yes, when you have a problem of inference, it's
> >> good to use an inference engine.
>
> >>> So some questions:
>
> >>> 1) So why not treat all 'inheritance' in this way?
>
> >> Because all inheritance is not about inference.
>
> > Hmmm. Then might you give an example of a situation where inheritance
> > cannot be described in terms of inference?
>
> To which I described what inheritance is:
>
> > Inheritance is simply the redeclaration of functions and variables in a
> > subscope.  That's not inferrence.

Yes, but I was asking for an example of when the /result/ of
inheritance could not be described by inference. You answered a
different question (albeit with the best of intentions I am sure). I
discuss this further on.

>
> To which you said "subscope" was a nonsense word, and we had to define
> our terms. (sigh).

I believed the word was nonsense in terms of relevancy to what I had
asked, not in terms of it having no definition (so 'sigh' right back
at you sunshine). Lets put it down as standard usenet fare and move
on.

>
> Then you said:
>
> > Well that all jolly-well looks like inference to me.
>
> And I said ... well you can read it above.
>
> > I guess we are done, your objection having been overcome.
>
> JOG, you're original question was: Why not treat all inheritance as the
> kind of inferrence you get from a database join.

Yes, I think you have missed my gist though. The question is why use a
"Redeclaration mechanism" (if you want to call it that) to handle data
transformation at all. An answer of "that's just how OO does it" is
not really what I was interested in exploring.

>
> Answer:  Because inheritance is not inference.  Inheritance is the
> redeclaration of variables and functions in a subscope.
>
> > I think because of your OO focus you haven't
> > recognized that (in this case) there is a danger of putting the cart
> > before the horse. Logic first, mechanism second, not t'other way
> > around.
>
> On the contrary, your initial question was:
>
> Why can't the mechanism be treated like the logic.

That was not my question at all. While you are referring to
inheritance as a mechanism, I am referring to what is /achieved/ via
the mechanism. Saying "redeclaration in a subscope" is no answer to
what I intended - it is like answering the question "why do we eat"
with "to put food into our stomachs".

Perhaps we are speaking across each other because you are focussing on
the T and not the I of IT (this sadly proliferates the field, so I'm
not intending to be disparaging to you personally, but rather to help
conversation). Information is the subject matter of our area, and that
is where we should start, not trying to squash it into whatever hole
are particular favourite tehcnology is. If noone the importance of
anlaysing the nature of information, we'd still all be using flipping
CODASYL right? So, I challenge you to step back from an individual
mechanism and look at data and behaviour theoretically.

I contend that if we can do that, we will find there is in fact some
middle ground in between OO and the prinicples behind relational
theory, where the conceputual layer (object boundaries and behvaiours)
can be decoupled from data (the logical layer) all in the same
language.

>
> My answer was: because it's a mechanism.
>
> So it seems to me that you are the one with the problem discerning the
> difference between logic and mechanisms.
>
> Now, I understand your original point.  You were trying to use
> inheritance as a way to make an inference, and then later found that a
> database join was a better approach.  Good!  Inference engines are
> usually better at making inferences than redeclaration mechanisms.  But
> the conclusion you apparently drew from this is that there was
> something wrong with the mechanism (inheritance) and that it should be
> more like a database join.  That's rather like pounding a nail with a
> screwdriver and then wishing it was more like a hammer.
>
> --
> Robert C. Martin (Uncle Bob)  | email: uncle...@objectmentor.com
> Object Mentor Inc.            | blog:  www.butunclebob.com
> The Agile Transition Experts  | web:   www.objectmentor.com
> 800-338-6716                  |

0
jog (83)
3/12/2008 9:21:53 AM
JOG wrote:

>>On 2008-03-08 21:39:37 -0600, JOG <j...@cs.nott.ac.uk> said:

> A red herring as far as I'm concerned this Robert - after all RM is
> not an "inference engine" either. What I am questioning whether we
> need the concept of inheritance /whatsoever/. It does not exist in
> logic, it has no underlying theoretical justification, and is purely
> an ad hoc mechanism thrown together at xerox parc.

1. Devised at the NCC in Norway, not Xerox PARC.

2. Devised because of the influence of academic work on data types (Hoares'
"record" types) , and noticing things having related properties/behaviours
in simulation systems.

So not really ad-hoc (thought went into providing the scheme) .


> Is it not true that
> inheritance has lost favour over the years - composition is generally
> preferred, unless one is defining interfaces (and whether that should
> still be called "inheritance" is open to debate).

As a property acquisition/composition scheme, certainly.
As a type substitutability mechanism, (sadly) no (Java, C# etc) .


Regards,
Steven Perryman
0
S
3/12/2008 9:34:32 AM
On Mar 12, 9:34 am, S Perryman <q...@q.com> wrote:
> JOG wrote:
> >>On 2008-03-08 21:39:37 -0600, JOG <j...@cs.nott.ac.uk> said:
> > A red herring as far as I'm concerned this Robert - after all RM is
> > not an "inference engine" either. What I am questioning whether we
> > need the concept of inheritance /whatsoever/. It does not exist in
> > logic, it has no underlying theoretical justification, and is purely
> > an ad hoc mechanism thrown together at xerox parc.
>
> 1. Devised at the NCC in Norway, not Xerox PARC.

Much obliged.

>
> 2. Devised because of the influence of academic work on data types (Hoares'
> "record" types) , and noticing things having related properties/behaviours
> in simulation systems.
>
> So not really ad-hoc (thought went into providing the scheme) .

Remember that there is a huge amount of 'academic work' on XML - that
doesn't make XML any the less ad-hoc, or without sound theoretical
foundation. But again thanks for the info, and if you have any links
to the things you site, I'd be interested to having a look.

>
> > Is it not true that
> > inheritance has lost favour over the years - composition is generally
> > preferred, unless one is defining interfaces (and whether that should
> > still be called "inheritance" is open to debate).
>
> As a property acquisition/composition scheme, certainly.
> As a type substitutability mechanism, (sadly) no (Java, C# etc) .
>
> Regards,
> Steven Perryman

0
jog (83)
3/12/2008 10:17:17 AM
"Robert Martin" <unclebob@objectmentor.com> wrote in message
news:200803112125087826-unclebob@objectmentorcom...
> On 2008-03-10 23:28:40 -0500, Marshall <marshall.spight@gmail.com> said:
>
> > Clearly comp.object and comp.databases.theory form just
> > such a dyad, with data-centered vs. code-centered thinking
> > the unresolvable heart of the conflict.
>
> So, in this entire discussion, have you seen me attack database theory
> even once?

No, but I have seen you be dismissive of ideas that someone capable of a
data centered viewpoint would probably not have dismissed.



0
cressey73 (124)
3/12/2008 10:35:35 AM
JOG wrote:

> On Mar 12, 9:34 am, S Perryman <q...@q.com> wrote:

>>JOG wrote:

>>>A red herring as far as I'm concerned this Robert - after all RM is
>>>not an "inference engine" either. What I am questioning whether we
>>>need the concept of inheritance /whatsoever/. It does not exist in
>>>logic, it has no underlying theoretical justification, and is purely
>>>an ad hoc mechanism thrown together at xerox parc.

>>2. Devised because of the influence of academic work on data types (Hoares'
>>"record" types) , and noticing things having related properties/behaviours
>>in simulation systems.

>>So not really ad-hoc (thought went into providing the scheme) .

> Remember that there is a huge amount of 'academic work' on XML - that
> doesn't make XML any the less ad-hoc, or without sound theoretical
> foundation.

Perhaps so.
But for the things we are discussing, these people and their work was
the *genesis* .


> But again thanks for the info, and if you have any links
> to the things you site, I'd be interested to having a look.

A search on simula + hoare + record, seems to yield a fair amount of
sources.


Regards,
Steven Perryman
0
S
3/12/2008 11:08:17 AM
David Cressey wrote:
> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:200803112125087826-unclebob@objectmentorcom...
> 
>>On 2008-03-10 23:28:40 -0500, Marshall <marshall.spight@gmail.com> said:
>>
>>
>>>Clearly comp.object and comp.databases.theory form just
>>>such a dyad, with data-centered vs. code-centered thinking
>>>the unresolvable heart of the conflict.
>>
>>So, in this entire discussion, have you seen me attack database theory
>>even once?
> 
> No, but I have seen you be dismissive of ideas that someone capable of a
> data centered viewpoint would probably not have dismissed.

And we have seen him prove his ignorance beyond any doubt while 
promoting himself.
0
bbadour (434)
3/12/2008 2:07:23 PM
On Mar 11, 7:25 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-10 23:28:40 -0500, Marshall <marshall.spi...@gmail.com> said:
>
> > Clearly comp.object and comp.databases.theory form just
> > such a dyad, with data-centered vs. code-centered thinking
> > the unresolvable heart of the conflict.
>
> So, in this entire discussion, have you seen me attack database theory
> even once?

You "downplay" RDBMS. You compared queries to "assembler language" in
one reply, for example. While not a direct "attack" it is the next
nearest thing.

> --
> Robert C. Martin (Uncle Bob)  | email: uncle...@objectmentor.com
> Object Mentor Inc.            | blog:  www.butunclebob.com

-T-
0
topmind (2124)
3/12/2008 3:11:54 PM

S Perryman wrote:
> JOG wrote:
>
> >>On 2008-03-08 21:39:37 -0600, JOG <j...@cs.nott.ac.uk> said:
>
> > A red herring as far as I'm concerned this Robert - after all RM is
> > not an "inference engine" either. What I am questioning whether we
> > need the concept of inheritance /whatsoever/. It does not exist in
> > logic, it has no underlying theoretical justification, and is purely
> > an ad hoc mechanism thrown together at xerox parc.
>
> 1. Devised at the NCC in Norway, not Xerox PARC.
>
> 2. Devised because of the influence of academic work on data types (Hoares'
> "record" types) , and noticing things having related properties/behaviours
> in simulation systems.

"Types" tend to rely on similar hierarchical taxonomies (or at least
DAG taxonomies) that inheritance does, and *suffer similar problems*.
It is difficult to reduce most non-trivial real-world things into such
trees/dags because they generally don't fit such, especially over the
longer run. Even numbers, the poster child of "types", tend to get
ugly if try to create a tree taxonomy with them.  Feature sets are a
more flexible and natural way to represent and manage variations-on-a-
theme. (Disclaimer: I have no objective metrics to measure "more
natural" and "flexible" at the moment.)

>
> So not really ad-hoc (thought went into providing the scheme) .
>
>
> > Is it not true that
> > inheritance has lost favour over the years - composition is generally
> > preferred, unless one is defining interfaces (and whether that should
> > still be called "inheritance" is open to debate).
>
> As a property acquisition/composition scheme, certainly.
> As a type substitutability mechanism, (sadly) no (Java, C# etc) .
>
>
> Regards,
> Steven Perryman

-T-
0
topmind (2124)
3/12/2008 3:23:05 PM
topmind wrote:

> S Perryman wrote:

>>JOG wrote:

>>>A red herring as far as I'm concerned this Robert - after all RM is
>>>not an "inference engine" either. What I am questioning whether we
>>>need the concept of inheritance /whatsoever/. It does not exist in
>>>logic, it has no underlying theoretical justification, and is purely
>>>an ad hoc mechanism thrown together at xerox parc.

>>1. Devised at the NCC in Norway, not Xerox PARC.

>>2. Devised because of the influence of academic work on data types (Hoares'
>>"record" types) , and noticing things having related properties/behaviours
>>in simulation systems.

> "Types" tend to rely on similar hierarchical taxonomies (or at least
> DAG taxonomies) that inheritance does, and *suffer similar problems*.
> It is difficult to reduce most non-trivial real-world things into such
> trees/dags because they generally don't fit such, especially over the
> longer run. Even numbers, the poster child of "types", tend to get
> ugly if try to create a tree taxonomy with them.  Feature sets are a
> more flexible and natural way to represent and manage variations-on-a-
> theme. (Disclaimer: I have no objective metrics to measure "more
> natural" and "flexible" at the moment.)

Your rantings :

1. pollute my pleasant experience of recent debate with people who actually
    know something about database fundamentals, and have contributions
    related to other areas

2. are off-topic rubbish

3. demonstrate a complete ignorance of anything relating to type theory in
    programming languages


So on all counts: on your way, little boy ...
0
S
3/12/2008 3:34:56 PM
topmind wrote:

> On Mar 11, 7:25 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> 
>>On 2008-03-10 23:28:40 -0500, Marshall <marshall.spi...@gmail.com> said:
>>
>>>Clearly comp.object and comp.databases.theory form just
>>>such a dyad, with data-centered vs. code-centered thinking
>>>the unresolvable heart of the conflict.
>>
>>So, in this entire discussion, have you seen me attack database theory
>>even once?
> 
> You "downplay" RDBMS. You compared queries to "assembler language" in
> one reply, for example. While not a direct "attack" it is the next
> nearest thing.

It's also incontrovertible proof of his profound ignorance.
0
bbadour (434)
3/12/2008 4:04:10 PM
On Mar 12, 12:54 am, S Perryman <q...@q.com> wrote:
> Marshall wrote:
> >
> > It's also
> > part of why the relational model is so interesting. And it's
> > why OOPLs don't hold my interest so much any more;
> > their axioms are complicated and often weak.
>
> Which "axioms" in particular cause you pain ??

The ones they leave out. The ones that would let me draw
stronger conclusions about my code.

Have you read, say, the Java language spec? It's very
long and detailed. It's also a prose spec. So it's ambiguous
in places, and there aren't any proofs done against it.
At the same time, the guarantees you can make with
the Java type system are useful, but they don't go nearly
far enough.

A goal of mine is to be able to take the "typeful programming"
idea to its logical conclusion.


> >>I take a slightly different view in that I obviously have the need
> >>for various collection types, and support for a Relational "calculus"
> >>to use on those collections. I also need support for collections of
> >>ADTs in particular.
> > The collections question is quite interesting: Lists, maps, bags,
> > sets, tables, trees. It is apparent after only a modest amount
> > of study that maps, sets, and tables are thoroughly and beautifully
> > handled with relations.
>
> Collections should be deliberately vague.

That is the current consensus in much of the PLT world.
Consider STL. All kinda collections; all kinda algorithms.
Certainly better than nothing! But still a long way from
as good as can be done.

The "vague collections" idea is not a good one IMHO.
Because you can get more or less everything you want
with relations. (Surprise! I like relations! :-)


> Insert and remove. Empty. Contains an item, how many occurrences of
> an item etc.
>
> A set is a specific form of collection (contains 0 or 1 instance of
> any given element, insertion of a contained element has no effect etc) .

What I consider ideal would be to have an axiomatic algebra that
can succinctly express the complete set of such operations, and
furthermore exactly specify the algebraic properties of such
operations. This enables not only a lot of automatic optimization,
but it also enables a lot more automated reasoning. (Actually
optimization is just a special case of automated reasoning.)


> > It took me a lot longer but I've reached
> > the conclusion that lists fall in to the same category.
>
> Sequences are conceptually a partial mapping of (Index,Element) tuples.
> Certain mappings being undefined (hence partial) .

Exactly. A partial mapping. Aka a relation.


> > Trees no longer seem like a single category to me: there
> > are what I call "statically structured" trees, for example
> > Customers/ Invoices/InvoiceLineItems, and "dynamically
> > structured" trees, such as a parse tree.
>
> A tree is a specific form of graph.
> Graphs are conceptually two sets with an invariant relationship
> between the sets. Trees merely define additional invariants on
> those sets.

Yes.

I still think my static/dynamic structure distinction is an important
one.


> > Statically structured
> > trees are are a particular strong point for SQL and also a
> > strong point for the RM. Dynamically structured trees *can be*
> > handled with the RM but I don't think it does as good a job
> > as is done in, say, FP languages with union types and
> > structural recursion. I conjecture that it may be possible
> > to develop best practices and/or tiny extensions to the
> > RM such that it does as good a job, but currently I'm
> > leaning in the direction of thinking this will not be possible.
> > I'm not completely thrilled with structural recursion, but
> > I have yet to see anything better.
>
> Is your issue with performance for things like breadth/depth
> traversal etc ??

Your question caused me to consider my feelings for structural
recursion, and I didn't really come up with much to say against
it. I guess the worst I can say is, I don't see how to get a handle
on how to transform them.

You know what 1NF is, the form in which the system requires
that attributes of relations have types that are not themselves
relations? This turns out to be sufficient for (virtually) everything.
However I don't think it's the best design choice. The problem
that results when you relax 1NF, though, is a psychological one:
everyone wants to start nesting everything deeply. And that's
a disaster.


> >>If possible I would like the prog lang user to be able to construct
> >>specific collections such as sets etc, and for the prog lang env to be
> >>within reasonable performance of something that is designed for the
> >>support of some one specific aspect (as Lisp is for lists etc) .
> >>I think that FP is the paradigm that could possibly do this.
> > An important aspect of the performance requirement is physical
> > independence, something that is largely ignored in PL theory,
> > sadly.
>
> The separation of specification (interface) from implementation is
> something key to ADT theory. And for those prog langs (CLU, Modula-2
> etc) that support one impl of each ADT per program unit, you have
> the independence.
>
> However, the coming of OO (unintentionally) threw a spanner in the
> works. It became possible to have multiple *different* impls of one ADT
> used *concurrently* in the same program unit.

I don't see that there's anything wrong with that necessarily. This is
a version of physical independence, and that's a good thing. The
problem comes more with the fact that objects are stateful; their
status as first class variables is what is problematic. ("State is
hell."
--Ken Arnold.)

And stateful objects aren't even necessarily a problem per se.
See for example Peter Van Roy's demonstration of objects
as mechanisms for increasing modularity in ways that are
unavailable to FP or LP languages. Or consider that closures
are isomorphic to objects in languages with (mutable local
variables + lexical scope + first class functions.) Some have
even made the case that threads are isomorphic to objects.

No, the problem comes up with the psychological factor again.
Once you admit stateful objects, people use them freaking
everywhere, and having state sprinkled like little grains of
sand all through the gears of your program, THAT's a problem.

(Although I believe that message passing (not the Smalltalk
sense of the word) may be able to reproduce the modularity
advantage Van Roy describes, without the disadvantages of
local state.)


> A rough analogy (that AFAIK is not supported in commercial systems)
> would be an SQL database that for some given table operates a B-tree
> for certain records in the table, hashing for others etc. And expects
> the performance for ops on the entire table to be the same whatever
> predicates are applied to the table.

Well, "expectation" is an attribute of people, not of programs. People
can be educated.

Performance tuning necessarily involves human input, because
performance requirements are not automatically inferable by
software. We have operation A and operation B, and it may be
that the requirements are that A has to be as fast as possible
and if that's at the expense of B, then so be it. Or vice versa.
Or the requirements may say to balance them. How can the
system know which way to optimize for? It needs to be told
the requirements. HOWEVER, once it knows them, obviously
the most desirable case is that it does the tuning itself. So what
we really want is a system that lets us specify our performance
requirements declaratively.

And at this point, Bob can pipe up and point out that the best
candidate for a system that will be able to support the sort of
features I'm describing is a relational system. (Oops, I guess
he doesn't have to now.)


> > If we look at the mathematical universe, we usually encounter
> > an extensional viewpoint. And if something is expressed
> > intensionally, or algorithmically, mathematicians are free to
> > immediately think of its extension, because they do not have
> > to limit themselves to what is computable.
> > On the other hand, if we look at the computable universe, we
> > see more often the intensional viewpoint. And we are not
> > free to immediately shift into extensional mode, because
> > of the possibly-infinite, almost-certainly-prohibitive cost of
> > doing so.
> > The RM gives the best handle on the computably extensional
> > viewpoint I have encountered. FP gives the best handle
> > on the intensional viewpoint.
>
> I would say that FP has a strong extensional viewpoint too, solely
> because it too is based on mathematical concepts (functions) .

Sure. I think it's just as fair to say that the RM has a strong
intensional
viewpoint, too:

  SELECT CustomerId, InvoiceId from Invoices  WHERE TotalCost > 100.00

See the lambda in there? It's camouflaged, but it's still there.
Hiding
behind a rock; clever thing.


Marshall
0
3/12/2008 4:15:27 PM

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> >>JOG wrote:
>
> >>>A red herring as far as I'm concerned this Robert - after all RM is
> >>>not an "inference engine" either. What I am questioning whether we
> >>>need the concept of inheritance /whatsoever/. It does not exist in
> >>>logic, it has no underlying theoretical justification, and is purely
> >>>an ad hoc mechanism thrown together at xerox parc.
>
> >>1. Devised at the NCC in Norway, not Xerox PARC.
>
> >>2. Devised because of the influence of academic work on data types (Hoares'
> >>"record" types) , and noticing things having related properties/behaviours
> >>in simulation systems.
>
> > "Types" tend to rely on similar hierarchical taxonomies (or at least
> > DAG taxonomies) that inheritance does, and *suffer similar problems*.
> > It is difficult to reduce most non-trivial real-world things into such
> > trees/dags because they generally don't fit such, especially over the
> > longer run. Even numbers, the poster child of "types", tend to get
> > ugly if try to create a tree taxonomy with them.  Feature sets are a
> > more flexible and natural way to represent and manage variations-on-a-
> > theme. (Disclaimer: I have no objective metrics to measure "more
> > natural" and "flexible" at the moment.)
>
> Your rantings :
>
> 1. pollute my pleasant experience of recent debate with people who actually
>     know something about database fundamentals, and have contributions
>     related to other areas

Did I say anything objectively wrong?

>
> 2. are off-topic rubbish

I disagree it is "off-topic".

>
> 3. demonstrate a complete ignorance of anything relating to type theory in
>     programming languages

Did I say anything objectively wrong? Or is this Soviet Justice?

>
>
> So on all counts: on your way, little boy ...

Net-etiquette dictates you simply ignore replies you don't like rather
than call people names.

Why not spend time coding up realistic examples of types curing cancer
and saving puppies instead of spending time insulting people? Show
gizmos being good instead of claiming people are bad.

-T-
0
topmind (2124)
3/12/2008 9:23:30 PM
topmind wrote:

> S Perryman wrote:

TM>"Types" tend to rely on similar hierarchical taxonomies (or at least
TM>DAG taxonomies) that inheritance does, and *suffer similar problems*.
TM>It is difficult to reduce most non-trivial real-world things into such
TM>trees/dags because they generally don't fit such, especially over the
TM>longer run. Even numbers, the poster child of "types", tend to get
TM>ugly if try to create a tree taxonomy with them.  Feature sets are a
TM>more flexible and natural way to represent and manage variations-on-a-
TM>theme. (Disclaimer: I have no objective metrics to measure "more
TM>natural" and "flexible" at the moment.)

>>Your rantings :

>>1. pollute my pleasant experience of recent debate with people who actually
>>    know something about database fundamentals, and have contributions
>>    related to other areas

> Did I say anything objectively wrong?

Yes.

Types do *not* "rely on similar hierarchical taxonomies (or at least
DAG taxonomies)" .

#1 If this is the case, then "objectively" show us why this is so.


>>2. are off-topic rubbish

> I disagree it is "off-topic".

Just to educate you before I send you on your way, you non english-
understanding muppet :

JOG made a statement about *who* and *what* made inheritance come to be
in OO. I corrected him on both matters.

Please feel free to show us how your silly rant contributes


>>3. demonstrate a complete ignorance of anything relating to type theory in
>>    programming languages

> Did I say anything objectively wrong?

We await your reply to #1 with interest.


Steven Perryman
0
S
3/13/2008 8:42:37 AM

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> TM>"Types" tend to rely on similar hierarchical taxonomies (or at least
> TM>DAG taxonomies) that inheritance does, and *suffer similar problems*.
> TM>It is difficult to reduce most non-trivial real-world things into such
> TM>trees/dags because they generally don't fit such, especially over the
> TM>longer run. Even numbers, the poster child of "types", tend to get
> TM>ugly if try to create a tree taxonomy with them.  Feature sets are a
> TM>more flexible and natural way to represent and manage variations-on-a-
> TM>theme. (Disclaimer: I have no objective metrics to measure "more
> TM>natural" and "flexible" at the moment.)
>
> >>Your rantings :
>
> >>1. pollute my pleasant experience of recent debate with people who actually
> >>    know something about database fundamentals, and have contributions
> >>    related to other areas
>
> > Did I say anything objectively wrong?
>
> Yes.
>
> Types do *not* "rely on similar hierarchical taxonomies (or at least
> DAG taxonomies)" .

I never said they "must", only "tend to".  You misrepresented me. Gee,
that's new.

>
> >>2. are off-topic rubbish
>
> > I disagree it is "off-topic".
>
> Just to educate you before I send you on your way, you non english-
> understanding muppet :

"Muppet"? You're weird.

>
> JOG made a statement about *who* and *what* made inheritance come to be
> in OO. I corrected him on both matters.
>
> Please feel free to show us how your silly rant contributes

This is where "types" were mentioned:

> 2. Devised because of the influence of academic work on data types (Hoares'
> "record" types) , and noticing things having related properties/behaviours
> in simulation systems.

And in the message just before that, JOG stated:

"What I am questioning whether we
need the concept of inheritance /whatsoever/."


> >>3. demonstrate a complete ignorance of anything relating to type theory in
> >>    programming languages
>
> > Did I say anything objectively wrong?
>
> We await your reply to #1 with interest.
>
>
> Steven Perryman

-T-
0
topmind (2124)
3/13/2008 3:30:40 PM
topmind wrote:

> S Perryman wrote:

TM>Did I say anything objectively wrong?

>>Yes.

>>Types do *not* "rely on similar hierarchical taxonomies (or at least
>>DAG taxonomies)" .

> I never said they "must", only "tend to".

Who said "must" ?? Not me, pal.
What is the word for that ... ?? Mis-representation, perhaps.

So getting back to it :

Feel free to "objectively" show us why types *tend* to "rely on similar
hierarchical taxonomies (or at least DAG taxonomies)" .


> You misrepresented me. Gee, that's new.

We can always rely on you to kill yourself with your own sword as quickly
as the next line of text. You never disappoint (LOL) .


>>JOG made a statement about *who* and *what* made inheritance come to be
>>in OO. I corrected him on both matters.

>>Please feel free to show us how your silly rant contributes

> This is where "types" were mentioned:

>>2. Devised because of the influence of academic work on data types (Hoares'
>>"record" types) , and noticing things having related properties/behaviours
>>in simulation systems.

> And in the message just before that, JOG stated:

> "What I am questioning whether we
> need the concept of inheritance /whatsoever/."

LOL !!! Classic topmind muppetry.

Posting rants to the wrong person altogether.
Rather than admitting the embarrassing truth, then tries to selectively
edit the entire posting to prevaricate.

So what do we have :

- you are claiming you are writing about something that was *not even
   present* in my posting

- a rant that *does not even relate* to that text anyway


Funny isn't it, that JOG in his reply had no problems understanding
what I was telling him (or replying accordingly) .

So, to send you on your way, you non english-understanding muppet ...

Here is the ref to my posting (in its *entirety* ) to JOG  :

http://groups.google.com/group/comp.databases.theory/msg/a25c4a9a21982df6

Please feel free to show us how your silly rant contributes to anything in
that posting. Just to help you, there are two points of note in the 
posting, denoted "1" and "2" .

1 tells JOG *who* invented inheritance in OOP.
2 tells JOG *why* (according to the inventors) inheritance came to be.


>>>Did I say anything objectively wrong?

>>We await your reply to #1 with interest.

Ah, the other classic topmind muppetry : demand something "objective" of
someone, but scuttles away quietly into a dark corner when the same is
demanded of him.


Steven Perryman
0
S
3/13/2008 3:59:33 PM
On 2008-03-12 04:21:53 -0500, JOG <jog@cs.nott.ac.uk> said:

> What I am questioning whether we
> need the concept of inheritance /whatsoever/.

Is inheritance necessary?  Certainly not.  Is it useful?  Certainly.

> It does not exist in
> logic, it has no underlying theoretical justification, and is purely
> an ad hoc mechanism thrown together at xerox parc.

I think it was "thrown together" in Norway by Dahl and Nygaard.  I 
could be wrong.  But so what?  It's a useful tool.

> Is it not true that
> inheritance has lost favour over the years -

Overuse, yes.  Not use.

> composition is generally preferred,

Generally, yes.

> unless one is defining interfaces (and whether that should
> still be called "inheritance" is open to debate).

Inheritance is the redeclaration of functions and variables within a 
subscope.  That fits rather well with the abstract methods of an 
interface.


-- 
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)
3/13/2008 5:02:23 PM
On 2008-03-12 05:35:35 -0500, "David Cressey" <cressey73@verizon.net> said:

> 
> "Robert Martin" <unclebob@objectmentor.com> wrote in message
> news:200803112125087826-unclebob@objectmentorcom...
>> On 2008-03-10 23:28:40 -0500, Marshall <marshall.spight@gmail.com> said:
>> 
>>> Clearly comp.object and comp.databases.theory form just
>>> such a dyad, with data-centered vs. code-centered thinking
>>> the unresolvable heart of the conflict.
>> 
>> So, in this entire discussion, have you seen me attack database theory
>> even once?
> 
> No, but I have seen you be dismissive of ideas that someone capable of a
> data centered viewpoint would probably not have dismissed.

That's a fair point.  I can't point to any incident, but I think it's 
likely.  However, I can also say that by participating in these 
discussions I have learned to be a lot less dismissive, and have gained 
much more respect for the views expressed on c.d.t (though not for some 
of the bad odor'd participants).


-- 
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)
3/13/2008 5:35:06 PM
On 2008-03-12 10:11:54 -0500, topmind <topmind@technologist.com> said:

> You "downplay" RDBMS.

Over the years I have learned to do that a lot less.  There was a time 
that I considered DBs to be "a bucket of bits".  Thanks, in part, to 
these crossposted discussions between c.o and c.d.t I have come to have 
a very different opinion.

> You compared queries to "assembler language" in
> one reply, for example. While not a direct "attack" it is the next
> nearest thing.

I can undertand why someone might take offense at that, if one thought 
that there was something awful about assembly language.

The real point of that remark was that the user of a tool is at a 
higher level of abstraction than the tool itself.  SQL is a tool.  ORMs 
are tools that use SQL to get their job done, just like compilers use 
assembly to get their job done.  In that sense ORMs live at a higher 
level of abstraction than SQL.

The members of c.d.t. might respond negatively to that idea because 
they see SQL as a better vehicle to do the job that the ORM is trying 
to do. That's fine, but does not change the fact that the ORM is using 
SQL as an implementation language.




-- 
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)
3/13/2008 5:40:22 PM

Robert Martin wrote:
> On 2008-03-12 10:11:54 -0500, topmind <topmind@technologist.com> said:
>
> > You "downplay" RDBMS.
>
> Over the years I have learned to do that a lot less.  There was a time
> that I considered DBs to be "a bucket of bits".  Thanks, in part, to
> these crossposted discussions between c.o and c.d.t I have come to have
> a very different opinion.
>
> > You compared queries to "assembler language" in
> > one reply, for example. While not a direct "attack" it is the next
> > nearest thing.
>
> I can undertand why someone might take offense at that, if one thought
> that there was something awful about assembly language.

It is very rarely one's first choice if machine speed is not the main
requirements factor.

>
> The real point of that remark was that the user of a tool is at a
> higher level of abstraction than the tool itself.  SQL is a tool.  ORMs
> are tools that use SQL to get their job done, just like compilers use
> assembly to get their job done.  In that sense ORMs live at a higher
> level of abstraction than SQL.

Often it seems that you and other OO proponents are more interested in
seeing objects and only objects rather than using the best
abstraction.  You automatically equate "using objects" with "higher
abstraction". (And all the repetitious set/get's and new new's make it
almost seem like OO assembler.)  Even if there was a slight difference
in abstraction level, it is often not great enough to bother
translating back and forth. Your "PARADIGM TRANSLATION TAX" is rather
high, uncomfortably so. (And ORM are far from seemless or simple,
raising more questions than they solve.)

>
> The members of c.d.t. might respond negatively to that idea because
> they see SQL as a better vehicle to do the job that the ORM is trying
> to do. That's fine, but does not change the fact that the ORM is using
> SQL as an implementation language.

I could use Java to impliment machine language and machine language to
impliment Java. Does that tell us anything useful?

>
>
> --
> Robert C. Martin (Uncle Bob)=EF=BF=BD=EF=BF=BD| email: unclebob@objectment=
or.com
> Object Mentor Inc.=EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=BD =EF=BF=
=BD=EF=BF=BD| blog:=EF=BF=BD=EF=BF=BDwww.butunclebob.com

-T-
0
topmind (2124)
3/13/2008 7:52:18 PM

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> TM>Did I say anything objectively wrong?
>
> >>Yes.
>
> >>Types do *not* "rely on similar hierarchical taxonomies (or at least
> >>DAG taxonomies)" .
>
> > I never said they "must", only "tend to".
>
> Who said "must" ?? Not me, pal.
> What is the word for that ... ?? Mis-representation, perhaps.

Let me rephrase the question. What SPECIFICLY did I say about "types"
that is objectively wrong?

>
> So getting back to it :
>
> Feel free to "objectively" show us why types *tend* to "rely on similar
> hierarchical taxonomies (or at least DAG taxonomies)" .

I don't know "why", for I didn't design the common languages that tend
to have dag/tree-based types. You'll have to ask Gosling etc. that.

> >>JOG made a statement about *who* and *what* made inheritance come to be
> >>in OO. I corrected him on both matters.
>
> >>Please feel free to show us how your silly rant contributes
>
> > This is where "types" were mentioned:
>
> >>2. Devised because of the influence of academic work on data types (Hoares'
> >>"record" types) , and noticing things having related properties/behaviours
> >>in simulation systems.
>
> > And in the message just before that, JOG stated:
>
> > "What I am questioning whether we
> > need the concept of inheritance /whatsoever/."
>
> LOL !!! Classic topmind muppetry.
>
> Posting rants to the wrong person altogether.

Even if true, that does not make it "off topic". It's only one reply
level away.

> Rather than admitting the embarrassing truth, then tries to selectively
> edit the entire posting to prevaricate.
>
> So what do we have :
>
> - you are claiming you are writing about something that was *not even
>    present* in my posting

I was trying to guess what you implied. You create vaguery and then
blame me when I try to clean it up by paraphrasing you with more
precision. Typical.

>
> - a rant that *does not even relate* to that text anyway
>
>
> Funny isn't it, that JOG in his reply had no problems understanding
> what I was telling him (or replying accordingly) .

And this relates to what?

[snapped longer he-said-she-said bickery]

> Steven Perryman

-T-
0
topmind (2124)
3/13/2008 7:59:28 PM
topmind wrote:

> S Perryman wrote:

> Let me rephrase the question. What SPECIFICLY did I say about "types"
> that is objectively wrong?

For the umpteenth time :

<quote>

types *tend* to "rely on similar
hierarchical taxonomies (or at least DAG taxonomies)

</quote>

And for the umpteenth time, feel free to "objectively" show us why
your quoted text is true (as opposed to being the rantings of an idiot) .


>>So getting back to it :

>>Feel free to "objectively" show us why types *tend* to "rely on similar
>>hierarchical taxonomies (or at least DAG taxonomies)" .

> I don't know "why", for I didn't design the common languages that tend
> to have dag/tree-based types. You'll have to ask Gosling etc. that.

Hang on. You have made a specific claim in your rant about "types" .
You cannot support how or why that claim is anything other than rubbish.
And then you have the gall to try to blame OO prog language designers as
to why you cannot support your claim.

Consider yourself promoted to uber-muppet.


>>LOL !!! Classic topmind muppetry.

>>Posting rants to the wrong person altogether.

> Even if true, that does not make it "off topic". It's only one reply
> level away.

1. Wrong.

Completely unrelated to anything I specifically posted in reply to JOG.


2. Is it true (rhetorical question) ??


>>Rather than admitting the embarrassing truth, then tries to selectively
>>edit the entire posting to prevaricate.

>>So what do we have :

>>- you are claiming you are writing about something that was *not even
>>   present* in my posting

> I was trying to guess what you implied. You create vaguery and then
> blame me when I try to clean it up by paraphrasing you with more
> precision. Typical.

ROFTLMAO.

How can informing someone as to who invented inheritance in OOP, and the
reasons why, be "vaguery" ??

Please feel free to tell us.


>>Funny isn't it, that JOG in his reply had no problems understanding
>>what I was telling him (or replying accordingly) .

> And this relates to what?

The fact that he can read and understand the English language, and
actually track and reply to the correct posting in a Usenet thread.
Which you evidently cannot.

So, once again :

On your way, you non english-understanding muppet ...
0
S
3/13/2008 8:43:53 PM

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> > Let me rephrase the question. What SPECIFICLY did I say about "types"
> > that is objectively wrong?
>
> For the umpteenth time :
>
> <quote>
>
> types *tend* to "rely on similar
> hierarchical taxonomies (or at least DAG taxonomies)

How many popular languages can you name that DON'T rely on trees or
DAGS for type matching and equivalency detection?

And that claim is not about types, but rather *usage* of types.

> >>Posting rants to the wrong person altogether.
>
> > Even if true, that does not make it "off topic". It's only one reply
> > level away.
>
> 1. Wrong.
>
> Completely unrelated to anything I specifically posted in reply to JOG.

Either way "off topic" is an exaggeration. Don't be a Drama Queen.

[el snippo]

>
>
> 2. Is it true (rhetorical question) ??
>
>
> >>Rather than admitting the embarrassing truth, then tries to selectively
> >>edit the entire posting to prevaricate.
>
> >>So what do we have :
>
> >>- you are claiming you are writing about something that was *not even
> >>   present* in my posting
>
> > I was trying to guess what you implied. You create vaguery and then
> > blame me when I try to clean it up by paraphrasing you with more
> > precision. Typical.
>
> ROFTLMAO.
>
> How can informing someone as to who invented inheritance in OOP, and the
> reasons why, be "vaguery" ??
>
> Please feel free to tell us.

I was addressing the issue raised by non-me of the utility of
inheritance, not its invention. I don't care if Kermit the Frog
invented it.

-T-
0
topmind (2124)
3/13/2008 11:59:33 PM
On 13 Mar, 18:40, Robert Martin <uncle...@objectmentor.com> wrote:
> The real point of that remark was that the user of a tool is at a
> higher level of abstraction than the tool itself. =A0SQL is a tool. =A0ORM=
s
> are tools that use SQL to get their job done, just like compilers use
> assembly to get their job done. =A0In that sense ORMs live at a higher
> level of abstraction than SQL.

Lets have an example: There are many "compiler" products translating
from a high-level language like ADA to a low-level language like C,
instead of translating to machine code directly. What if someone wrote
a "compiler" translating C source code to ADA source code, would that
make C more high level than ADA? Hardly? The existance of a product
translating from language A to language B doesn't say anything about
the levels of A and B.

> The members of c.d.t. might respond negatively to that idea because
> they see SQL as a better vehicle to do the job that the ORM is trying
> to do. That's fine, but does not change the fact that the ORM is using
> SQL as an implementation language.

If a RDBMS product is implemented using an OOPL, does that make
relational algebra more high level than OO?

//frebe
0
frebe73 (444)
3/14/2008 5:17:40 AM
On Mar 14, 2:17 pm, frebe <freb...@gmail.com> wrote:
> On 13 Mar, 18:40, Robert Martin <uncle...@objectmentor.com> wrote:
>
> > The real point of that remark was that the user of a tool is at a
> > higher level of abstraction than the tool itself.  SQL is a tool.  ORMs
> > are tools that use SQL to get their job done, just like compilers use
> > assembly to get their job done.  In that sense ORMs live at a higher
> > level of abstraction than SQL.
>
> Lets have an example: There are many "compiler" products translating
> from a high-level language like ADA to a low-level language like C,
> instead of translating to machine code directly. What if someone wrote
> a "compiler" translating C source code to ADA source code, would that
> make C more high level than ADA? Hardly? The existance of a product
> translating from language A to language B doesn't say anything about
> the levels of A and B.

In any case, Marshall nicely described the difficulty of writing a
reasonable ORM in the first place.  This has more to do with the
impedance mismatch than with some notion of "higher level".  The RM is
suited (and only suited) to representing and querying information in
the form of large sets of propositions, whereas OO is suited (and only
suited) to building state machines within an abstract computational
machine.   I would hardly call a set of propositions a state machine,
and I would hardly call a state machine a set of propositions.
Therefore there isn't really any overlap in the purpose of OO and RM.
Not surprisingly the best approach to build a system is often a hybrid
of the two.  The idea to directly map a tuple (or "record") to an
object reveals confusion.  A tuple is a non-scalar value representing
an immutable fact.  An object is an identifiable state machine within
a larger abstract computational machine.

The RM has a sound mathematical basis, and it's clear that the RM will
stand the test of time.  Any OO programmer who thinks it's reasonable
to wrap RM behind an ORM doesn't understand the RM, its fundamental
importance, the extent to which data can be decoupled from application
and the tremendous value in doing so.


0
davidbl (206)
3/14/2008 8:46:58 AM
On Thu, 13 Mar 2008 22:17:40 -0700 (PDT), frebe wrote:

> On 13 Mar, 18:40, Robert Martin <uncle...@objectmentor.com> wrote:

>> The real point of that remark was that the user of a tool is at a
>> higher level of abstraction than the tool itself. �SQL is a tool. �ORMs
>> are tools that use SQL to get their job done, just like compilers use
>> assembly to get their job done. �In that sense ORMs live at a higher
>> level of abstraction than SQL.
> 
> Lets have an example: There are many "compiler" products translating
> from a high-level language like ADA to a low-level language like C,
> instead of translating to machine code directly. What if someone wrote
> a "compiler" translating C source code to ADA source code, would that
> make C more high level than ADA? Hardly? The existance of a product
> translating from language A to language B doesn't say anything about
> the levels of A and B.

Right. What does it, is the difficulty of designing such a compiler.
Clearly within the set of Turing-complete languages you could translate
from whatever language to any other. But, while translation from Ada to C
is considerably difficult (mainly because C is ill-defined), a good
translation from C to Ada is almost impossible. "Good" means deducing
higher-level constructs from the code. It is much like literary
translation, and requires general intelligence.

Ah, ADA = The Americans with Disabilities Act of 1990, the programming
language is called "Ada", named after Augusta Ada King, Countess of
Lovelace

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

>> The members of c.d.t. might respond negatively to that idea because
>> they see SQL as a better vehicle to do the job that the ORM is trying
>> to do. That's fine, but does not change the fact that the ORM is using
>> SQL as an implementation language.
> 
> If a RDBMS product is implemented using an OOPL, does that make
> relational algebra more high level than OO?

That depends on the application domain, the comparison is conditional to
that. Further, some things might be incomparable.

I agree that the fact of use alone does not imply the outcome of a
comparison. There are all sorts of use, some are quite meaningless. I
remember in student times, we implemented gotos (which were prohibited)
using structural constructs, just to protest and to have fun. Abstraction
inversion is a quite common thing.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/14/2008 9:43:11 AM
Quoth S Perryman:
> Consider yourself promoted to uber-muppet.

When did "muppet" become an insult?
-- 
Jon
0
3/14/2008 9:54:13 AM
topmind wrote:

> S Perryman wrote:

SP>Let me rephrase the question. What SPECIFICLY did I say about "types"
SP>that is objectively wrong?
>>
>>For the umpteenth time :
>>
>><quote>

>>types *tend* to "rely on similar
>>hierarchical taxonomies (or at least DAG taxonomies)

> How many popular languages can you name that DON'T rely on trees or
> DAGS for type matching and equivalency detection?

> And that claim is not about types, but rather *usage* of types.

Here are some very popular prog langs for the following arenas :

commercial, general-purpose, Internet, safety-critical

The prog langs : COBOL, C, Javascript, Ada(83)

Which of them rely on "trees or DAGS for type matching and equivalency
detection" ??

None. QED.

Additionally, you exposed your (previously indicated)  ignorance
about the fundamentals of type theory. For type matching is always done
on the basis of type *name* and/or *structure* .

Neither of which require "trees or DAGs" .


TM>I was trying to guess what you implied. You create vaguery and then
TM>blame me when I try to clean it up by paraphrasing you with more
TM>precision. Typical.

>>How can informing someone as to who invented inheritance in OOP, and the
>>reasons why, be "vaguery" ??

>>Please feel free to tell us.

> I was addressing the issue raised by non-me of the utility of
> inheritance, not its invention.

1. Yes, in response to a *completely different* discussion.

2. You have not been able to show us anything in my posting that is
    "vaguery" (surprise surprise) .


Once again, you have suffered a 'typing Tourettes' attack, but couldn't
even direct it to a vaguely relevant posting in the debate.

It is has been most amusing watching you squirm like an impaled worm on
yet another episode of your muppetry. And as always, Usenet archives record
them for posterity


Regards,
Steven Perryman
0
S
3/14/2008 10:09:29 AM
"Jon Heggland" <jon.heggland@ntnu.no> wrote in message
news:frdi08$mvo$1@kuling.itea.ntnu.no...
> Quoth S Perryman:
> > Consider yourself promoted to uber-muppet.
>
> When did "muppet" become an insult?

Hey, it isn't easy being right!



0
cressey73 (124)
3/14/2008 12:15:57 PM
David Cressey wrote:

> "Jon Heggland" <jon.heggland@ntnu.no> wrote in message
> news:frdi08$mvo$1@kuling.itea.ntnu.no...

>>Quoth S Perryman:

>>>Consider yourself promoted to uber-muppet.

>>When did "muppet" become an insult?

http://en.wikipedia.org/wiki/Muppet_%28slang%29


> Hey, it isn't easy being right!

Not sure what your comment has to do with the term "muppet" .


Regards,
Steven Perryman
0
S
3/14/2008 12:23:29 PM
On 14 Mar, 10:43, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Thu, 13 Mar 2008 22:17:40 -0700 (PDT), frebe wrote:
> > On 13 Mar, 18:40, Robert Martin <uncle...@objectmentor.com> wrote:
> >> The real point of that remark was that the user of a tool is at a
> >> higher level of abstraction than the tool itself. =A0SQL is a tool. =A0=
ORMs
> >> are tools that use SQL to get their job done, just like compilers use
> >> assembly to get their job done. =A0In that sense ORMs live at a higher
> >> level of abstraction than SQL.
>
> > Lets have an example: There are many "compiler" products translating
> > from a high-level language like ADA to a low-level language like C,
> > instead of translating to machine code directly. What if someone wrote
> > a "compiler" translating C source code to ADA source code, would that
> > make C more high level than ADA? Hardly? The existance of a product
> > translating from language A to language B doesn't say anything about
> > the levels of A and B.
>
> Right. What does it, is the difficulty of designing such a compiler.
> Clearly within the set of Turing-complete languages you could translate
> from whatever language to any other. But, while translation from Ada to C
> is considerably difficult (mainly because C is ill-defined), a good
> translation from C to Ada is almost impossible.

That's why the OO camp has such problems with making a good ORM. If
SQL would have been low-level, compared to the network model, the task
would have been much easier.

//frebe
0
frebe73 (444)
3/14/2008 1:33:45 PM
On Mar 5, 11:23 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> On 2008-03-05 10:16:30 -0600, topmind <topm...@technologist.com> said:
>
> > On Mar 4, 10:52 pm, Robert Martin <uncle...@objectmentor.com> wrote:
> >> On 2008-03-03 17:25:48 -0600, topmind <topm...@technologist.com> said:
>
> >>> But I think anybody inspecting both examples will clearly see that my
> >>> version is a lot less total code.
>
> >> C++ is a pretty wordy language.  If I wrote it in Ruby I bet I'd beat
> >> you by a wide margin.
>
> > I am a skeptical, but you are welcome to try. And, it would probably
> > be the meta features of Ruby that cut it down, not OOP.
>
> The "meta" features of Ruby *are* OO.

You have a tendency to label everything and everyone as "OO". Plus,
doing meta in an OO way is not necessarily more compact than doing
meta in a non-OO way.

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

-T-
0
topmind (2124)
3/14/2008 2:57:28 PM

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> SP>Let me rephrase the question. What SPECIFICLY did I say about "types"
> SP>that is objectively wrong?
> >>
> >>For the umpteenth time :
> >>
> >><quote>
>
> >>types *tend* to "rely on similar
> >>hierarchical taxonomies (or at least DAG taxonomies)
>
> > How many popular languages can you name that DON'T rely on trees or
> > DAGS for type matching and equivalency detection?
>
> > And that claim is not about types, but rather *usage* of types.
>
> Here are some very popular prog langs for the following arenas :
>
> commercial, general-purpose, Internet, safety-critical
>
> The prog langs : COBOL, C, Javascript, Ada(83)
>
> Which of them rely on "trees or DAGS for type matching and equivalency
> detection" ??
>
> None. QED.

Can you demonstrate a type cycle (circular reference) allowed in C?

>
> Additionally, you exposed your (previously indicated)  ignorance
> about the fundamentals of type theory. For type matching is always done
> on the basis of type *name* and/or *structure* .
>
> Neither of which require "trees or DAGs" .

I never claimed "required". You are putting words in my mouth.

>
>
> TM>I was trying to guess what you implied. You create vaguery and then
> TM>blame me when I try to clean it up by paraphrasing you with more
> TM>precision. Typical.
>
> >>How can informing someone as to who invented inheritance in OOP, and the
> >>reasons why, be "vaguery" ??
>
> >>Please feel free to tell us.
>
> > I was addressing the issue raised by non-me of the utility of
> > inheritance, not its invention.
>
> 1. Yes, in response to a *completely different* discussion.

That still would not make it "off topic".

>
> 2. You have not been able to show us anything in my posting that is
>     "vaguery" (surprise surprise) .

It wouldn't do any good if I did. Delusional people are usually not
fixable.

>
>
> Once again, you have suffered a 'typing Tourettes' attack, but couldn't
> even direct it to a vaguely relevant posting in the debate.
>
> It is has been most amusing watching you squirm like an impaled worm on
> yet another episode of your muppetry. And as always, Usenet archives record
> them for posterity

Speaking of shameful record, were you the one who claimed a p/r
version of the publications exampled would have to have a
"combinatorial explosion", which you failed to prove and tried to
change the subject? Or was that lameman? I get the two of you mixed
up.

>
>
> Regards,
> Steven Perryman

-T-
0
topmind (2124)
3/14/2008 3:11:31 PM

S Perryman wrote:
> David Cressey wrote:
>
> > "Jon Heggland" <jon.heggland@ntnu.no> wrote in message
> > news:frdi08$mvo$1@kuling.itea.ntnu.no...
>
> >>Quoth S Perryman:
>
> >>>Consider yourself promoted to uber-muppet.
>
> >>When did "muppet" become an insult?
>
> http://en.wikipedia.org/wiki/Muppet_%28slang%29
>
>
> > Hey, it isn't easy being right!
>
> Not sure what your comment has to do with the term "muppet" .

It's a twist on a song by a muppet. Perhaps you should better study
your artifacts of insults before using them.  If a hooker shoves
things up her [bleep] without checking them first, she's asking for
it.

>
>
> Regards,
> Steven Perryman

-T-
0
topmind (2124)
3/14/2008 3:15:14 PM
On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote:

> On 14 Mar, 10:43, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Thu, 13 Mar 2008 22:17:40 -0700 (PDT), frebe wrote:
>>> On 13 Mar, 18:40, Robert Martin <uncle...@objectmentor.com> wrote:

>>>> The real point of that remark was that the user of a tool is at a
>>>> higher level of abstraction than the tool itself. �SQL is a tool. �ORMs
>>>> are tools that use SQL to get their job done, just like compilers use
>>>> assembly to get their job done. �In that sense ORMs live at a higher
>>>> level of abstraction than SQL.
>>
>>> Lets have an example: There are many "compiler" products translating
>>> from a high-level language like ADA to a low-level language like C,
>>> instead of translating to machine code directly. What if someone wrote
>>> a "compiler" translating C source code to ADA source code, would that
>>> make C more high level than ADA? Hardly? The existance of a product
>>> translating from language A to language B doesn't say anything about
>>> the levels of A and B.
>>
>> Right. What does it, is the difficulty of designing such a compiler.
>> Clearly within the set of Turing-complete languages you could translate
>> from whatever language to any other. But, while translation from Ada to C
>> is considerably difficult (mainly because C is ill-defined), a good
>> translation from C to Ada is almost impossible.
> 
> That's why the OO camp has such problems with making a good ORM. If
> SQL would have been low-level, compared to the network model, the task
> would have been much easier.

Not necessarily. Certain architectures are difficult to translate into, for
vector processors. It is related to the  presumption of computational
equivalence. A difficulty or impossibility to translate can come from
weakness of a given language. SQL is pretty weak.

Clearly when SQL is used as a intermediate language for an ORM, then to
have it lower level and more imperative than it is would be an advantage.

But I agree that ORM is wasting time. In my why other architectures are
needed (like WAN-wide persistent objects). In short DBMS to be scrapped as
a concept.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/14/2008 3:16:11 PM
On Mar 14, 8:16 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote:
> > On 14 Mar, 10:43, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Thu, 13 Mar 2008 22:17:40 -0700 (PDT), frebe wrote:
> >>> On 13 Mar, 18:40, Robert Martin <uncle...@objectmentor.com> wrote:
> >>>> The real point of that remark was that the user of a tool is at a
> >>>> higher level of abstraction than the tool itself.  SQL is a tool.  ORMs
> >>>> are tools that use SQL to get their job done, just like compilers use
> >>>> assembly to get their job done.  In that sense ORMs live at a higher
> >>>> level of abstraction than SQL.
>
> >>> Lets have an example: There are many "compiler" products translating
> >>> from a high-level language like ADA to a low-level language like C,
> >>> instead of translating to machine code directly. What if someone wrote
> >>> a "compiler" translating C source code to ADA source code, would that
> >>> make C more high level than ADA? Hardly? The existance of a product
> >>> translating from language A to language B doesn't say anything about
> >>> the levels of A and B.
>
> >> Right. What does it, is the difficulty of designing such a compiler.
> >> Clearly within the set of Turing-complete languages you could translate
> >> from whatever language to any other. But, while translation from Ada to C
> >> is considerably difficult (mainly because C is ill-defined), a good
> >> translation from C to Ada is almost impossible.
>
> > That's why the OO camp has such problems with making a good ORM. If
> > SQL would have been low-level, compared to the network model, the task
> > would have been much easier.
>
> Not necessarily. Certain architectures are difficult to translate into, for
> vector processors. It is related to the  presumption of computational
> equivalence. A difficulty or impossibility to translate can come from
> weakness of a given language. SQL is pretty weak.
>
> Clearly when SQL is used as a intermediate language for an ORM, then to
> have it lower level and more imperative than it is would be an advantage.
>
> But I agree that ORM is wasting time. In my why other architectures are
> needed (like WAN-wide persistent objects). In short DBMS to be scrapped as
> a concept.
>

One of the problems in translation is that OO usually makes a big
distinction between an individual object and a collection of objects,
whereas in RDBMS there is no real difference: going from 1 to a
million is seamless (outside of performance issues). In OO, the
collection is usually a different object/class than the items in the
collection. (This is a manifestation of the set-oriented thinking
versus navigational structures of OO.)  Nobody has figured out how to
use encapsulation to hide the difference.

Cursor-like techniques can be applied, but that just makes OO look
like a half-finished (navigational) database because objects then must
start following global collection-oriented rules, losing the self-
handling-noun feel that makes OO feel like OO.

I don't think anyone can solve the impedance mismatch without turning
one into the other. Each allows/requires different areas of freedoms
and restrictions. If you plug up one, you have to open another to
compensate, and visa versa.

> --
> Regards,
> Dmitry A. Kazakovhttp://www.dmitry-kazakov.de

-T-
0
topmind (2124)
3/14/2008 3:55:55 PM
On Fri, 14 Mar 2008 08:55:55 -0700 (PDT), topmind wrote:

> One of the problems in translation is that OO usually makes a big
> distinction between an individual object and a collection of objects,
> whereas in RDBMS there is no real difference: going from 1 to a
> million is seamless (outside of performance issues). In OO, the
> collection is usually a different object/class than the items in the
> collection. (This is a manifestation of the set-oriented thinking
> versus navigational structures of OO.)  Nobody has figured out how to
> use encapsulation to hide the difference.

LOL. Dear you should really read something introductory on set theory, just
in order to never post anything like that. The distinction between set and
the elements of, plays a central role in modern mathematics. Otherwise see

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

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/14/2008 5:32:43 PM
topmind wrote:

> S Perryman wrote:

TM>How many popular languages can you name that DON'T rely on trees or
TM>DAGS for type matching and equivalency detection?

TM>And that claim is not about types, but rather *usage* of types.

>>Here are some very popular prog langs for the following arenas :

>>commercial, general-purpose, Internet, safety-critical

>>The prog langs : COBOL, C, Javascript, Ada(83)

>>Which of them rely on "trees or DAGS for type matching and equivalency
>>detection" ??

>>None. QED.

> Can you demonstrate a type cycle (circular reference) allowed in C?

For what purpose ??

The definition or use of such a type does not "rely on trees or DAGS for
type matching and equivalency detection" .


>>Additionally, you exposed your (previously indicated)  ignorance
>>about the fundamentals of type theory. For type matching is always done
>>on the basis of type *name* and/or *structure* .

>>Neither of which require "trees or DAGs" .

> I never claimed "required". You are putting words in my mouth.

Feel free to show us how/why :

"type matching and equivalency detection"
"tend to rely on similar hierarchical taxonomies (or at least DAG
taxonomies)" .


>>2. You have not been able to show us anything in my posting that is
>>   "vaguery" (surprise surprise) .

> It wouldn't do any good if I did.

Of course it would. For the sake of other people, and Usenet archive
posterity at least.

But tis a convenient excuse *not* to have your claims scrutinised, is it
not.


> Delusional people are usually not fixable.

Good of you to own up to that mental defect that you suffer.


>>It is has been most amusing watching you squirm like an impaled worm on
>>yet another episode of your muppetry. And as always, Usenet archives record
>>them for posterity

> Speaking of shameful record, were you the one who claimed a p/r
> version of the publications exampled would have to have a
> "combinatorial explosion", which you failed to prove and tried to
> change the subject? Or was that lameman? I get the two of you mixed up.

Did you actually manage to understand your own "solution" well enough
to be able to show what it outputs with the required input data (ie
provide a functional equivalent of the type substitutabilty example as was
defined on day 1) ??

If so, and you can demonstrate so to me, I am only too happy to resume that
particular debate and show you the combinatorial problem inherent in your
"solution" .

If not, *shame on you* for prevaricating (and wasting Usenet resource) , in
order to avoid admitting (again) insufficient understanding of english to 
do the things asked of you.


Regards,
Steven Perryman
0
S
3/14/2008 5:50:41 PM
S Perryman wrote:
> ... (various trolling snipped, nothing that matters). 

Topmind, you speak a higher class of language than this cross-poster who 
doesn't seem to know it.   As much as I would miss your comments, were 
you to ignore him, I for one would be happy to see his irrelevancies go 
away.  Just my two cents.
0
paul
3/14/2008 9:09:18 PM
paul c wrote:

> S Perryman wrote:
> 
>> ... (various trolling snipped, nothing that matters). 
> 
> 
> Topmind, you speak a higher class of language than this cross-poster who 
> doesn't seem to know it.   As much as I would miss your comments, were 
> you to ignore him, I for one would be happy to see his irrelevancies go 
> away.  Just my two cents.

I am not sure topmind will see the post if you only post it in c.d.t
0
Bob
3/14/2008 9:22:05 PM
On Mar 14, 9:32 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> LOL. Dear you should really read something introductory on set theory, just
> in order to never post anything like that. The distinction between set and
> the elements of, plays a central role in modern mathematics.

If you read something *introductory* on set theory, you will in
general see sets described using one set of terms, and elements
of sets in different terms. (Although you won't necessarily see
them described as belonging to distinct classes; it is usually left
unspecified.) If you get past the introductory phase, however,
the distinction evaporates. The specific axiomatic set theory that
could most be said to play a central role is modern mathematics
is ZFC, an axiomatic theory which does not admit the existence
of anything that is *not* a set. *Every* element of every set in
ZFC is itself a set; numbers are encoded as sets, etc.

Of course there are less popular axiomatic theories such as
Quine's New Foundations, which has a variant, NFU, which
*does* draw a formal distinction between sets and elements.
But by and large, the distinction between sets and elements
does not exist in modern mathematics.


Marshall
0
3/14/2008 11:34:20 PM
On Mar 14, 7:16 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
>
> In short DBMS to be scrapped as a concept.

Oh, I absolutely agree. In the modern context, things like structure,
integrity, and manipulation of data are passe! For my own tastes,
data corruption cannot happen fast enough. Why waste time *managing*
you data when you can just splat it out on the network to fend for
itself? What the hell did data ever do for me anyway?


Marshall

0
3/14/2008 11:45:02 PM
"Marshall" <marshall.spight@gmail.com> wrote in message 
news:2232ca10-8176-4511-9ba9-ef1822fd83dd@e25g2000prg.googlegroups.com...
> On Mar 14, 7:16 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>
>> In short DBMS to be scrapped as a concept.
>
> Oh, I absolutely agree. In the modern context, things like structure,
> integrity, and manipulation of data are passe! For my own tastes,
> data corruption cannot happen fast enough. Why waste time *managing*
> you data when you can just splat it out on the network to fend for
> itself? What the hell did data ever do for me anyway?
>

Funny...for a moment I thought you were referring to the news media.  They 
aren't to be bothered with integrity, they're corrupt--slanting the 
information to further their own agenda, and lately they haven't even been 
checking sources--just splat it out on the network whether it's true or not.

>
> Marshall
> 


0
brian8537 (72)
3/15/2008 1:00:32 AM
Bob Badour wrote:
....
> I am not sure topmind will see the post if you only post it in c.d.t

Oh, pardon me I thought topmind had posted db-only topics but maybe I 
have him mixed up with somebody else.  I like a little nonsense, post 
some myself and absurd points sometimes help me get my bearings but 
every once in a while some people persist ad nauseum and make a real 
nuisance of themselves and sometimes it helps if a relative stranger 
tells them so.  The only way I could get a guy I once worked with off 
his one-track pathway was to curse him up and down the hallway every six 
months in easy earshot of the whole office.  I wouldn't try that with 
everybody but it worked with him, he would immediately become contrite 
and for the next five months he'd be reasonable and consider what other 
people had to say, then he'd slip back into his natural ways - he was 
very clever but I thought he was also a mild sociopath.
0
paul
3/15/2008 1:10:51 AM
On Mar 15, 12:16 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote:
>
> > That's why the OO camp has such problems with making a good ORM. If
> > SQL would have been low-level, compared to the network model, the task
> > would have been much easier.
>
> Not necessarily. Certain architectures are difficult to translate into, for
> vector processors. It is related to the  presumption of computational
> equivalence. A difficulty or impossibility to translate can come from
> weakness of a given language. SQL is pretty weak.
>
> Clearly when SQL is used as a intermediate language for an ORM, then to
> have it lower level and more imperative than it is would be an advantage.
>
> But I agree that ORM is wasting time. In my why other architectures are
> needed (like WAN-wide persistent objects). In short DBMS to be scrapped as
> a concept.

I expect you like the idea of distributed OO, orthogonal persistence,
location transparency and so on.   However the literature is hardly
compelling.   There is the problem of

-  finding a consistent cut (ie that respects the
   happened-before relation)

-  the contradiction between transactions and orthogonal
   persistence

-  the contradiction between rolling back a transaction
   and orthogonal persistence

-  the impossibility of reliable distributed transactions

-  the fact that synchronous messages over the wire can easily
   be a million times slower than in-process calls

-  the fallibility of distributed synchronous messages which
   contradicts location transparency

-  the enormously difficult problem of distributed locking
   *  how to avoid concurrency bottlenecks
   *  when to release locks in the presence of network or machine
      failures
   *  distributed deadlock detection.
   *  rolling back a distributed transaction.

-  how to schema evolve a distributed OO system assuming
   orthogonal persistence and location transparency.

-  how to manage security when a process exposes many of its
   objects for direct communication with objects in another
   process.

Persistent, distributed state machines raise more questions than
answers. Persistent distributed encoded values provide a much better
basis for building a system.

SOA suggests that a large system should be decomposed by behaviour (ie
"services") which is basically an OO way of thinking.   It is a flawed
approach to the extent that it is promoted as the main way to build
enterprise systems.  The only proven scalable approach is to remain
data-centric at ever increasing scales.

The easiest way for distributed applications to communicate is
indirectly via shared data rather than by direct communication.  This
is implicit with a data-centric approach.

The WWW is data-centric.  It is not at all surprising that Http on
port 80 is *much* more common than RPC, CORBA, DCOM, RMI and SOAP put
together.  Http concerns messages used to access data instead of
messages used to elicit behaviour.

0
davidbl (206)
3/15/2008 1:59:49 AM
On Mar 14, 5:59 pm, David BL <davi...@iinet.net.au> wrote:
>
> -  the impossibility of reliable distributed transactions

Are they actually impossible? I know that distributed consensus
is impossible; Byzantine generals and all. I know little about
transactions, but my vague impression was that 2PC was
stronger than just an illusion.


> -  the fact that synchronous messages over the wire can easily
>    be a million times slower than in-process calls

This is *crucial.*


> -  the fallibility of distributed synchronous messages which
>    contradicts location transparency

This is manageable when you combine synchronous and
asynchronous messaging. Synchronous idempotent messaging
that does not depend on the identity of the receiver is actually
pretty easy; asynchronous messaging should handle as much
as possible. Synchronous messaging that does depend on
the identity of the receiver should be kept to an absolute
minimum, and has to be tolerant of failure. The guidelines
I just described might exclude certain classes of applications
(I'm not certain) but many, many things can be done this way.

Location transparency as a practical reality is achievable and
in fact absolutely tits when done well.


> -  how to schema evolve a distributed OO system assuming
>    orthogonal persistence and location transparency.

This is one of the things that convinces me of the superiority
of structural type systems for distributed computing. My expectation
is that languages are going to face evolutionary pressure in
the direction of features that are distributed- and multi-core-
friendly.

Schema evolution for nominally typed languages has proven
to be quite brittle. I am not convinced it is *necessarily* so,
but it begins to look like it.


> SOA suggests that a large system should be decomposed by behaviour (ie
> "services") which is basically an OO way of thinking.   It is a flawed
> approach to the extent that it is promoted as the main way to build
> enterprise systems.  The only proven scalable approach is to remain
> data-centric at ever increasing scales.

Mmmm, I mostly agree but maybe you said it a bit too strong.
Datacenter-services as an approach works okay, and even
scales, provided you don't need much flexibility and can keep
clients and servers closely coupled. Okay come to think of it
that's a pretty bad situation to be in. I changed my mind: you
have a good point.


> The WWW is data-centric.  It is not at all surprising that Http on
> port 80 is *much* more common than RPC, CORBA, DCOM, RMI and SOAP put
> together.  Http concerns messages used to access data instead of
> messages used to elicit behaviour.

Interesting point.

My high-level viewpoint: two important success factors for
distributed computing turn out to be<drumroll>: logical independence
and physical independence, at the (network) protocol level!

Surprise!


(I apologize for the buzzword-density of this post.)


Marshall
0
3/15/2008 3:14:26 AM
On Mar 15, 12:14 pm, Marshall <marshall.spi...@gmail.com> wrote:
> On Mar 14, 5:59 pm, David BL <davi...@iinet.net.au> wrote:
>
>
>
> > -  the impossibility of reliable distributed transactions
>
> Are they actually impossible? I know that distributed consensus
> is impossible; Byzantine generals and all. I know little about
> transactions, but my vague impression was that 2PC was
> stronger than just an illusion.

I mean 100% reliable in the face of arbitrary network failures

Date says it like this...

"There does not exist any finite protocol that will guarantee that all
participants will commit successful transactions in unison and roll
back unsuccessful transactions in unison, in the face of arbitrary
failures"

The proof is very simple.  See "An introduction  to DB systems"
edition 8, page 668.


> > -  the fact that synchronous messages over the wire can easily
> >    be a million times slower than in-process calls
>
> This is *crucial.*
>
> > -  the fallibility of distributed synchronous messages which
> >    contradicts location transparency
>
> This is manageable when you combine synchronous and
> asynchronous messaging. Synchronous idempotent messaging
> that does not depend on the identity of the receiver is actually
> pretty easy; asynchronous messaging should handle as much
> as possible. Synchronous messaging that does depend on
> the identity of the receiver should be kept to an absolute
> minimum, and has to be tolerant of failure. The guidelines
> I just described might exclude certain classes of applications
> (I'm not certain) but many, many things can be done this way.
>
> Location transparency as a practical reality is achievable and
> in fact absolutely tits when done well.

I'm certainly not saying the idea of location transparency is
completely worthless.  Clearly there exist useful distributed state
machines where location transparency has been achieved.  However,
there exist many more examples where in-process objects cannot be
moved out of process without breaking the system (in the presence of
network failure or the many orders of magnitude drop in
performance).   In practise location transparency has to be designed
for, which in a way is at odds with its premise.


> > -  how to schema evolve a distributed OO system assuming
> >    orthogonal persistence and location transparency.
>
> This is one of the things that convinces me of the superiority
> of structural type systems for distributed computing. My expectation
> is that languages are going to face evolutionary pressure in
> the direction of features that are distributed- and multi-core-
> friendly.
>
> Schema evolution for nominally typed languages has proven
> to be quite brittle. I am not convinced it is *necessarily* so,
> but it begins to look like it.

I believe I understand the distinction between nominal/structural, but
I don't know why you would say structural is better for distributed
computing.  Can you elaborate?

True orthogonal persistence implies that everything persists - even
threads.  In its purist form the idea is to be able to turn off a
computer and later turn it on again and all threads and processes
continue running as if it never was switched off.   This eliminates
the need for transactions and in fact for the programmer to care at
all about the distinction between persistent and transient objects.
This depends on finding a so called "consistent cut".  This is bad
enough on a single machine never mind trying to do it in a distributed
system.   BTW I know you are interested in lattice theory, so you
might be interested to know that the consistent cuts form a lattice.

Remarkably some research projects have tried to achieve this (eg
Grasshopper).  However the problem of schema evolution is a show
stopper.  How do you evolve a state machine while it is running (or
has been snapshot using a consistent cut).

> > SOA suggests that a large system should be decomposed by behaviour (ie
> > "services") which is basically an OO way of thinking.   It is a flawed
> > approach to the extent that it is promoted as the main way to build
> > enterprise systems.  The only proven scalable approach is to remain
> > data-centric at ever increasing scales.
>
> Mmmm, I mostly agree but maybe you said it a bit too strong.
> Datacenter-services as an approach works okay, and even
> scales, provided you don't need much flexibility and can keep
> clients and servers closely coupled. Okay come to think of it
> that's a pretty bad situation to be in. I changed my mind: you
> have a good point.

>
> > The WWW is data-centric.  It is not at all surprising that Http on
> > port 80 is *much* more common than RPC, CORBA, DCOM, RMI and SOAP put
> > together.  Http concerns messages used to access data instead of
> > messages used to elicit behaviour.
>
> Interesting point.
>
> My high-level viewpoint: two important success factors for
> distributed computing turn out to be<drumroll>: logical independence
> and physical independence, at the (network) protocol level!
>
> Surprise!
>
> (I apologize for the buzzword-density of this post.)


0
davidbl (206)
3/15/2008 4:28:16 AM

S Perryman wrote:
> topmind wrote:
>
> > S Perryman wrote:
>
> TM>How many popular languages can you name that DON'T rely on trees or
> TM>DAGS for type matching and equivalency detection?
>
> TM>And that claim is not about types, but rather *usage* of types.
>
> >>Here are some very popular prog langs for the following arenas :
>
> >>commercial, general-purpose, Internet, safety-critical
>
> >>The prog langs : COBOL, C, Javascript, Ada(83)
>
> >>Which of them rely on "trees or DAGS for type matching and equivalency
> >>detection" ??
>
> >>None. QED.
>
> > Can you demonstrate a type cycle (circular reference) allowed in C?
>
> For what purpose ??

What structure would you describe them as? Compilers use search
algorithms against internal data structures of program/syntax
representation to determine what type something is (or is compatible
with). Such can usually be characterized by data structures such as
trees, stacks, DAGs, graphs, etc.

I should point out that many set systems don't have cycles either, and
could be represented with DAGs if one wanted to.

>
> The definition or use of such a type does not "rely on trees or DAGS for
> type matching and equivalency detection" .
>
>
> >>Additionally, you exposed your (previously indicated)  ignorance
> >>about the fundamentals of type theory. For type matching is always done
> >>on the basis of type *name* and/or *structure* .
>
> >>Neither of which require "trees or DAGs" .
>
> > I never claimed "required". You are putting words in my mouth.
>
> Feel free to show us how/why :
>
> "type matching and equivalency detection"
> "tend to rely on similar hierarchical taxonomies (or at least DAG
> taxonomies)" .
>

Those are two different things. Requiring trees/dags and "usually
using" trees/dags are not equivalent.

>
> >>2. You have not been able to show us anything in my posting that is
> >>   "vaguery" (surprise surprise) .
>
> > It wouldn't do any good if I did.
>
> Of course it would. For the sake of other people, and Usenet archive
> posterity at least.
>
> But tis a convenient excuse *not* to have your claims scrutinised, is it
> not.
>
>
> > Delusional people are usually not fixable.
>
> Good of you to own up to that mental defect that you suffer.

Neener Neener to you too.

>
>
> >>It is has been most amusing watching you squirm like an impaled worm on
> >>yet another episode of your muppetry. And as always, Usenet archives record
> >>them for posterity
>
> > Speaking of shameful record, were you the one who claimed a p/r
> > version of the publications exampled would have to have a
> > "combinatorial explosion", which you failed to prove and tried to
> > change the subject? Or was that lameman? I get the two of you mixed up.
>
> Did you actually manage to understand your own "solution" well enough
> to be able to show what it outputs with the required input data (ie
> provide a functional equivalent of the type substitutabilty example as was
> defined on day 1) ??

Those were your MADE UP internal goddam requirements. I am NOT
obligated to mirror them.

>
> If so, and you can demonstrate so to me, I am only too happy to resume that
> particular debate and show you the combinatorial problem inherent in your
> "solution" .
>
> If not, *shame on you* for prevaricating (and wasting Usenet resource) , in
> order to avoid admitting (again) insufficient understanding of english to
> do the things asked of you.

You got yourself into a corner and are making up requirements to
backpeddle. You lost, dude! Fess up. No "combinatorial explosion" is
required.

Eat the Truth! Toppie won that one.

>
>
> Regards,
> Steven Perryman

-T-
0
topmind (2124)
3/15/2008 5:21:22 AM
On Fri, 14 Mar 2008 18:59:49 -0700 (PDT), David BL wrote:

> On Mar 15, 12:16 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote:
>>
>>> That's why the OO camp has such problems with making a good ORM. If
>>> SQL would have been low-level, compared to the network model, the task
>>> would have been much easier.
>>
>> Not necessarily. Certain architectures are difficult to translate into, for
>> vector processors. It is related to the  presumption of computational
>> equivalence. A difficulty or impossibility to translate can come from
>> weakness of a given language. SQL is pretty weak.
>>
>> Clearly when SQL is used as a intermediate language for an ORM, then to
>> have it lower level and more imperative than it is would be an advantage.
>>
>> But I agree that ORM is wasting time. In my why other architectures are
>> needed (like WAN-wide persistent objects). In short DBMS to be scrapped as
>> a concept.
> 
> I expect you like the idea of distributed OO,

Well, distributed OO is a different thing to me. It is when an object is
distributed over a set of nodes, a kind of wave, rather than a particle...

> orthogonal persistence,
> location transparency and so on.

Issues which might be too big to swallow in one gulp.

> However the literature is hardly
> compelling. There is the problem of
> 
> -  finding a consistent cut (ie that respects the
>    happened-before relation)
> 
> -  the contradiction between transactions and orthogonal
>    persistence
>
> -  the contradiction between rolling back a transaction
>    and orthogonal persistence

Complementarity, rather than mere contradiction.
 
> -  the impossibility of reliable distributed transactions

There is no such thing as unconditionally reliable computing anyway.

> -  the fact that synchronous messages over the wire can easily
>    be a million times slower than in-process calls

Huh, don't buy multi-core processors, don't use any memory except registers
etc. This is not an argument, so long no concrete time constraint put down.
Below you mentioned HTTP as an example. It is milliard times slower, who
cares? "Bright" minds use XML as a transport level, and for that matter,
interpreted SQL...

> -  the fallibility of distributed synchronous messages which
>    contradicts location transparency

That depends on what is transparent to what. I don't see why
synchronization should play any role here. I assume you meant something
like routing to moving targets, then that would apply to both.

> -  the enormously difficult problem of distributed locking
>    *  how to avoid concurrency bottlenecks
>    *  when to release locks in the presence of network or machine
>       failures
>    *  distributed deadlock detection.
>    *  rolling back a distributed transaction.

This is a sort of mixing lower and higher level synchronization
abstractions. If you use transactions then locking is an implementation
detail. Anyway all these problems are ones of concurrent computing in
general, they are not specific to distributed computing and even less than
that to OO. You can always consider concurrent remote tasks running local.

> -  how to schema evolve a distributed OO system assuming
>    orthogonal persistence and location transparency.
> 
> -  how to manage security when a process exposes many of its
>    objects for direct communication with objects in another
>    process.

On per object basis.

> Persistent, distributed state machines raise more questions than
> answers. Persistent distributed encoded values provide a much better
> basis for building a system.

I am not sure what you mean here. Referential vs. by-value semantics of
objects, or user-defined vs. inferred behavior of? Clearly you cannot get
rid of values as well as of references (values of identity).

Are you arguing for inference? Do you believe that distributed inference
would help in any way? No, it will have all the problems you listed plus
uncountable new others. When the behaviour is defined by the
programmer/user, that moves the burden from the system to him. This makes
things a lot easier. You don't need to infer that l = 2 Pi r in the
steering wheel microcontroller, you can take it for granted, if the
programmer says so.

So long we will remain more intelligent than our programs, inference will
always play a subordinate role. Once/if computers will surpass us, we will
no more program them. Inference is clearly a dead end, a mental laziness.

> SOA suggests that a large system should be decomposed by behaviour (ie
> "services") which is basically an OO way of thinking.

Well, IMO SOA is a "hype way of thinking," a marketing slogan with no
substance...

> It is a flawed
> approach to the extent that it is promoted as the main way to build
> enterprise systems.

But it sells good...

> The only proven scalable approach is to remain
> data-centric at ever increasing scales.

RDBMS sells good as well... (:-))
 
> The easiest way for distributed applications to communicate is
> indirectly via shared data rather than by direct communication.  This
> is implicit with a data-centric approach.

Ooch, shared data is the worst possible way. Note how hardware
architectures have been moving away from shared memory. Sooner or later it
should hit software design.

BTW, data sharing is much in OO way. Many understand OO equivalent to
referential semantics. It is a wrong perception, but taking it for
simplicity of argument, functional (value semantics) fits massively
parallel architectures much better.

But again, it a wrong perception. OO adds user-defined semantics to values.
Identity is user-defined as well. You can share or exchange, it is
orthogonal to OO.

> The WWW is data-centric.  It is not at all surprising that Http on
> port 80 is *much* more common than RPC, CORBA, DCOM, RMI and SOAP put
> together.  Http concerns messages used to access data instead of
> messages used to elicit behaviour.

That does not wonder me. WWW evolves from bottom to top. Mammals have the
gills when they undergo the embryo stage of development.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
0
mailbox2 (6357)
3/15/2008 9:12:04 AM
On Mar 15, 6:12 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> On Fri, 14 Mar 2008 18:59:49 -0700 (PDT), David BL wrote:
> > On Mar 15, 12:16 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> > wrote:
> >> On Fri, 14 Mar 2008 06:33:45 -0700 (PDT), frebe wrote:
>
> >>> That's why the OO camp has such problems with making a good ORM. If
> >>> SQL would have been low-level, compared to the network model, the task
> >>> would have been much easier.
>
> >> Not necessarily. Certain architectures are difficult to translate into, for
> >> vector processors. It is related to the  presumption of computational
> >> equivalence. A difficulty or impossibility to translate can come from
> >> weakness of a given language. SQL is pretty weak.
>
> >> Clearly when SQL is used as a intermediate language for an ORM, then to
> >> have it lower level and more imperative than it is would be an advantage.
>
> >> But I agree that ORM is wasting time. In my why other architectures are
> >> needed (like WAN-wide persistent objects). In short DBMS to be scrapped as
> >> a concept.
>
> > I expect you like the idea of distributed OO,
>
> Well, distributed OO is a different thing to me. It is when an object is
> distributed over a set of nodes, a kind of wave, rather than a particle...

That sounds like fragmented objects.

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

> > orthogonal persistence,
> > location transparency and so on.
>
> Issues which might be too big to swallow in one gulp.
>
> > However the literature is hardly
> > compelling. There is the problem of
>
> > -  finding a consistent cut (ie that respects the
> >    happened-before relation)
>
> > -  the contradiction between transactions and orthogonal
> >    persistence
>
> > -  the contradiction between rolling back a transaction
> >    and orthogonal persistence
>
> Complementarity, rather than mere contradiction.

The following argument appears in "Concurrency, the fly in the
ointment" by Blackburn and Zigman:

The transactional model implicitly requires the dichotomy of two
worlds - an internal one for the persistent data, and an external non
persistent world that issues transactions over the first.  This
follows from the impossibility of an ACID transaction being invoked
from within an (atomic) transaction - ie a transaction cannot be the
basis for its own nested invocation.

By definition of atomicity of a parent transaction, the durability of
any nested (ie child) transaction is subject to the atomicity of the
parent transaction.  This is in conflict with an independent
durability required by a child ACID transaction.


> > -  the impossibility of reliable distributed transactions
>
> There is no such thing as unconditionally reliable computing anyway.

Sure, but it is customary to assume infallibility within a process and
fallibility between processes.


> > -  the fact that synchronous messages over the wire can easily
> >    be a million times slower than in-process calls
>
> Huh, don't buy multi-core processors, don't use any memory except registers
> etc. This is not an argument, so long no concrete time constraint put down.
> Below you mentioned HTTP as an example. It is milliard times slower, who
> cares? "Bright" minds use XML as a transport level, and for that matter,
> interpreted SQL...

You missed the point.  Fine grained interchanges of messages are
useful within a process but are something to be avoided between
processes.   The penalty is so high that distributed computing systems
must account for it in the high level design.

Between processes it is better to stream data asynchronously, such as
the way OpenGL drawing commands are piped between client/server
without any round trip delay for each drawing command.


> > -  the fallibility of distributed synchronous messages which
> >    contradicts location transparency
>
> That depends on what is transparent to what. I don't see why
> synchronization should play any role here. I assume you meant something
> like routing to moving targets, then that would apply to both.

By definition, the call of an asynchronous messages (a "post") can
return without knowing whether the message was received, whereas a
synchronous message must block.  That raises the question of what to
do when the network fails.  This impacts design by contract (in
conflict with location transparency).


> > -  the enormously difficult problem of distributed locking
> >    *  how to avoid concurrency bottlenecks
> >    *  when to release locks in the presence of network or machine
> >       failures
> >    *  distributed deadlock detection.
> >    *  rolling back a distributed transaction.
>
> This is a sort of mixing lower and higher level synchronization
> abstractions. If you use transactions then locking is an implementation
> detail. Anyway all these problems are ones of concurrent computing in
> general, they are not specific to distributed computing and even less than
> that to OO. You can always consider concurrent remote tasks running local.

The point is that concurrency interacts very badly with orthogonal
persistence and location transparency - to the extent that it places
serious doubts on whether orthogonal persistence and location
transparency are useful concepts in the first place.


> > -  how to schema evolve a distributed OO system assuming
> >    orthogonal persistence and location transparency.
>
> > -  how to manage security when a process exposes many of its
> >    objects for direct communication with objects in another
> >    process.
>
> On per object basis.

In reality security can only be controlled at the boundary between
processes and that conflicts with location transparency.   Allowing
direct communication between objects opens up security holes
everywhere.   By contrast, the data centric approach allows the inter-
process message protocol to be simple and implemented entirely within
the DBMS layers.


> > Persistent, distributed state machines raise more questions than
> > answers. Persistent distributed encoded values provide a much better
> > basis for building a system.
>
> I am not sure what you mean here. Referential vs. by-value semantics of
> objects, or user-defined vs. inferred behavior of? Clearly you cannot get
> rid of values as well as of references (values of identity).

I'm saying persistent data should be nothing more that persistent
encoded values instead of snapshots (ie consistent cuts) of
multithreaded or distributed state machines.   The former is much
simpler than the latter.

> Are you arguing for inference? Do you believe that distributed inference
> would help in any way? No, it will have all the problems you listed plus
> uncountable new others. When the behaviour is defined by the
> programmer/user, that moves the burden from the system to him. This makes
> things a lot easier. You don't need to infer that l = 2 Pi r in the
> steering wheel microcontroller, you can take it for granted, if the
> programmer says so.
>
> So long we will remain more intelligent than our programs, inference will
> always play a subordinate role. Once/if computers will surpass us, we will
> no more program them. Inference is clearly a dead end, a mental laziness.
>
> > SOA suggests that a large system should be decomposed by behaviour (ie
> > "services") which is basically an OO way of thinking.
>
> Well, IMO SOA is a "hype way of thinking," a marketing slogan with no
> substance...

> > It is a flawed
> > approach to the extent that it is promoted as the main way to build
> > enterprise systems.
>
> But it sells good...
>
> > The only proven scalable approach is to remain
> > data-centric at ever increasing scales.
>
> RDBMS sells good as well... (:-))
>
> > The easiest way for distributed applications to communicate is
> > indirectly via shared data rather than by direct communication.  This
> > is implicit with a data-centric approach.
>
> Ooch, shared data is the worst possible way. Note how hardware
> architectures have been moving away from shared memory. Sooner or later it
> should hit software design.

Really? Are you suggesting there is a trend away from SMP?

Here is an example of the benefits of indirect communication between
applications with a shared data model.  We have the following
applications
1.   The company timesheet entry system
2.   The company payroll system
3.   The company email system
Consider that the list of employees is managed by a DBMS and is
accessible to each of these applications.   Whenever any of these
applications changes the shared data, all the other applications will
reflect the changes.

An alternative is for the applications to avoid shared data and
special message protocols are developed to allow them to talk to each
other.  Do you agree that's not a very good solution?

A third approach is to develop some kind of message oriented service
that centralises the information about the employees.  However then
all the problems arise about distributed OO (such as terrible
performance of synchronous messages, causality and consistent cuts
etc).


> BTW, data sharing is much in OO way. Many understand OO equivalent to
> referential semantics. It is a wrong perception, but taking it for
> simplicity of argument, functional (value semantics) fits massively
> parallel architectures much better.
>
> But again, it a wrong perception. OO adds user-defined semantics to values.
> Identity is user-defined as well. You can share or exchange, it is
> orthogonal to OO.

OO has little to do with the shared data for an enterprise


> > The WWW is data-centric.  It is not at all surprising that Http on
> > port 80 is *much* more common than RPC, CORBA, DCOM, RMI and SOAP put
> > together.  Http concerns messages used to access data instead of
> > messages used to elicit behaviour.
>
> That does not wonder me. WWW evolves from bottom to top. Mammals have the
> gills when they undergo the embryo stage of development.

0
davidbl (206)
3/15/2008 12:58:23 PM
On Sat, 15 Mar 2008 05:58:23 -0700 (PDT), David BL wrote:

> On Mar 15, 6:12 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>> On Fri, 14 Mar 2008 18:59:49 -0700 (PDT), David BL wrote:

>>> I expect you like the idea of distributed OO,
>>
>> Well, distributed OO is a different thing to me. It is when an object is
>> distributed over a set of nodes, a kind of wave, rather than a particle...
> 
> That sounds like fragmented objects.
> 
>     http://en.wikipedia.org/wiki/Fragmented_object

Yep, that thing.

>>> However the literature is hardly
>>> compelling. There is the problem of
>>
>>> -  finding a consistent cut (ie that respects the
>>>    happened-before relation)
>>
>>> -  the contradiction between transactions and orthogonal
>>>    persistence
>>
>>> -  the contradiction between rolling back a transaction
>>>    and orthogonal persistence
>>
>> Complementarity, rather than mere contradiction.
> 
> The following argument appears in "Concurrency, the fly in the
> ointment" by Blackburn and Zigman:
> 
> The transactional model implicitly requires the dichotomy of two
> worlds - an internal one for the persistent data, and an external non
> persistent world that issues transactions over the first.  This
> follows from the impossibility of an ACID transaction being invoked
> from within an (atomic) transaction - ie a transaction cannot be the
> basis for its own nested invocation.
> 
> By definition of atomicity of a parent transaction, the durability of
> any nested (ie child) transaction is subject to the atomicity of the
> parent transaction.  This is in conflict with an independent
> durability required by a child ACID transaction.

Clearly, durability of any effect is conditional. So what?

Anyway it is about composition of transactions, I don't see how this can
collide with persistence. The latter is merely a matter of the scope where
an object exists. Each object has a scope. Each object is persistent within
it. Whether the scope is contained by the scope of OS, or its file system,
or a cluster of hosts, is no matter to the issue (when scopes are nested.)

>>> -  the impossibility of reliable distributed transactions
>>
>> There is no such thing as unconditionally reliable computing anyway.
> 
> Sure, but it is customary to assume infallibility within a process and
> fallibility between processes.

Inter process communications are as [un]reliable as any other. In each case
you should specify what is taken for granted (premises) and what is the
subject of QoS enforcing.

>>> -  the fact that synchronous messages over the wire can easily
>>>    be a million times slower than in-process calls
>>
>> Huh, don't buy multi-core processors, don't use any memory except registers
>> etc. This is not an argument, so long no concrete time constraint put down.
>> Below you mentioned HTTP as an example. It is milliard times slower, who
&g