Does OOP assume something about human nature? [T]

0 views
Skip to first unread message

Topmind

unread,
Jan 21, 2002, 3:24:00 AM1/21/02
to

Title: Does OOP assume something about human nature?

This question came up on an old debate (by somebody else), but nobody
answered it that I could find.

I think it is an excellent question.

-T-

Helmut Leitner

unread,
Jan 21, 2002, 8:10:26 AM1/21/02
to

IMO OOP doesn't assume something about human nature,
but it partially reflects human thinking.

--
Helmut Leitner lei...@hls.via.at
Graz, Austria www.hls-software.com

Beyeler, Eric

unread,
Jan 21, 2002, 8:05:19 AM1/21/02
to
Does Procedural Programming assume something about human nature?
Does Functional Programming assume something about human nature?

Computer languages are ways of expressing human ideas to a computer. An
OOP language tries to make the translation from human description of the
solution to computer language as transparent as possible in the general
case.
Other kinds of languages try to make problems from certain domains
easier to express (take Prolog for example). OOP languages deal with the
general case of categorizing ideas/things into related types and
describing the interrelational behavior of those types.
So in answer to your question, whether this assumes something about
human nature, e.g. the way humans comprehend and understand the world
around them, OOP would assumes that people comprehend by categorization
& relating behavor of different objects.

Eric Beyeler

Topmind

unread,
Jan 21, 2002, 12:44:53 PM1/21/02
to
>
>
> Topmind wrote:
> >
> > Title: Does OOP assume something about human nature?
> >
> > This question came up on an old debate (by somebody else), but nobody
> > answered it that I could find.
> >
> > I think it is an excellent question.
>
> IMO OOP doesn't assume something about human nature,
> but it partially reflects human thinking.


Would you then conclude that it reflects some kind of
"universal truth", in a mathematical-like sense?


>
> --
> Helmut Leitner lei...@hls.via.at
> Graz, Austria www.hls-software.com
>

-T-

Topmind

unread,
Jan 21, 2002, 12:51:55 PM1/21/02
to
> Does Procedural Programming assume something about human nature?
> Does Functional Programming assume something about human nature?
>
> Computer languages are ways of expressing human ideas to a computer. An
> OOP language tries to make the translation from human description of the
> solution to computer language as transparent as possible in the general
> case.
> Other kinds of languages try to make problems from certain domains
> easier to express (take Prolog for example). OOP languages deal with the
> general case of categorizing ideas/things into related types and
> describing the interrelational behavior of those types.


Do you mean hierarchical taxonomies? (Or at least division
into mutually exclusive groups or types.)

I would indeed agree that, in general, people are comfortable with
hierarchical taxonomies, but I do question that it is the best fit for
how the real world is organized and changes. I lean toward set-based
classifications for that.

Perhaps there is a conflict between what makes humans comfortable
and what best fits actual world changes and variation. If so, which
one should we give up?

Shayne Wissler

unread,
Jan 21, 2002, 1:29:06 PM1/21/02
to

"Topmind" <top...@technologist.com> wrote in message
news:MPG.16b5712aa...@news.earthlink.net...

Why?

Helmut Leitner

unread,
Jan 21, 2002, 2:45:16 PM1/21/02
to

Topmind wrote:
>
> >
> >
> > Topmind wrote:
> > >
> > > Title: Does OOP assume something about human nature?
> > >
> > > This question came up on an old debate (by somebody else), but nobody
> > > answered it that I could find.
> > >
> > > I think it is an excellent question.
> >
> > IMO OOP doesn't assume something about human nature,
> > but it partially reflects human thinking.
>
> Would you then conclude that it reflects some kind of
> "universal truth", in a mathematical-like sense?

No, not at all. Human thinking has IMO nothing to do with
"universal truth" and I don't see how this relates to OOP.

Topmind

unread,
Jan 21, 2002, 3:53:32 PM1/21/02
to
>
>
> Topmind wrote:
> >
> > >
> > >
> > > Topmind wrote:
> > > >
> > > > Title: Does OOP assume something about human nature?
> > > >
> > > > This question came up on an old debate (by somebody else), but nobody
> > > > answered it that I could find.
> > > >
> > > > I think it is an excellent question.
> > >
> > > IMO OOP doesn't assume something about human nature,
> > > but it partially reflects human thinking.
> >
> > Would you then conclude that it reflects some kind of
> > "universal truth", in a mathematical-like sense?
>
> No, not at all. Human thinking has IMO nothing to do with
> "universal truth" and I don't see how this relates to OOP.


I am confused about your position then. I figure either
OOP is optimized for how human thought works, or it
fits some universal truth for formulaically reducing
complexity, code size, change-point quantities, etc.
(Or, something in-between.)

IOW, would *any* intelligent, rational group of beings
prefer OOP? Or may it just be an (alleged) human thing?


>
> --
> Helmut Leitner lei...@hls.via.at
> Graz, Austria www.hls-software.com
>

-T-

Topmind

unread,
Jan 21, 2002, 3:57:24 PM1/21/02
to

It gets to the heart of clarifying exactly what the
benefits (allegedly) are.

Should one be looking at it from psychologist's
standpoint, or a clinical, quantitative[1]
measurement standpoint?

[1] such as code size, change impact points reduction, etc.

-T-

Helmut Leitner

unread,
Jan 21, 2002, 4:18:44 PM1/21/02
to

Topmind wrote:
> > > > > Title: Does OOP assume something about human nature?
> > > > >
> > > > > This question came up on an old debate (by somebody else), but nobody
> > > > > answered it that I could find.
> > > > >
> > > > > I think it is an excellent question.
> > > >
> > > > IMO OOP doesn't assume something about human nature,
> > > > but it partially reflects human thinking.
> > >
> > > Would you then conclude that it reflects some kind of
> > > "universal truth", in a mathematical-like sense?
> >
> > No, not at all. Human thinking has IMO nothing to do with
> > "universal truth" and I don't see how this relates to OOP.
>
> I am confused about your position then.

Sorry for being unclear.

> I figure either OOP is optimized for how human thought works, or

As I said, OOP IMO "partially reflects" = "somehow fits" human
thinking. But this doesn't mean that it is optimized for it.

> it fits some universal truth for formulaically reducing
> complexity, code size, change-point quantities, etc.
> (Or, something in-between.)

In my experience OOP doesn't reduce complexity or code size.



> IOW, would *any* intelligent, rational group of beings
> prefer OOP? Or may it just be an (alleged) human thing?

IMO OOP solves enough problems to be preferred for the majority
of programming situations, but I don't think that OOP is able
to solve all problems.

Shayne Wissler

unread,
Jan 21, 2002, 4:52:49 PM1/21/02
to

"Topmind" <top...@technologist.com> wrote in message
news:MPG.16b621cac...@news.earthlink.net...

> >
> > "Topmind" <top...@technologist.com> wrote in message
> > news:MPG.16b5712aa...@news.earthlink.net...
> > >
> > > Title: Does OOP assume something about human nature?
> > >
> > > This question came up on an old debate (by somebody else), but nobody
> > > answered it that I could find.
> > >
> > > I think it is an excellent question.
> >
> > Why?
> >
>
> It gets to the heart of clarifying exactly what the
> benefits (allegedly) are.
>
> Should one be looking at it from psychologist's
> standpoint, or a clinical, quantitative[1]
> measurement standpoint?

Neither (and in particular, psychology has NOTHING to do with the issue).

However, philosophy is relevant to programming language design. In
particular, the standard of value for a programming language is not whether
it allows you to do the job (this is not a standard of value, but a basic
requirement), but how efficient it makes programmers--and this is a function
of human nature. E.g., it is a fact that you can only hold around 7 elements
in your consciousness at once. This fact leads to the need for things like
subordination (e.g., an object has elements; each element has elements,
etc.).

--
Shayne Wissler

"The high-minded man must care more for the truth than for what people
think." -- Aristotle

JRStern

unread,
Jan 21, 2002, 6:17:44 PM1/21/02
to
On Mon, 21 Jan 2002 08:24:00 GMT, top...@technologist.com (Topmind)
wrote:

Yes, it is an excellent question. It is somewhat more difficult to
come up with an excellent answer! I think Eric Beyeler gave a pretty
good response (appended at bottom here), but I'm going to try to add
to it.

I like his statement that "Computer languages are ways of expressing
human ideas to a computer." Not everyone would put things that way, I
believe many people say that computer languages are ways of
representing mathematical relationships between real-world objects,
human ideas might or might not figure into it.

My earliest recollections of how OOP was described was along those
lines, that it allowed one to organize code the way the real world was
organized, and that this produced a more intuitive and optimally
modularized set of code. This may be true to a large extent. The
problem with either the ontological view (that it represents the
world) or the epistemological view (that it represents human ideas) is
that different people have different ideas, including different ideas
about exactly how the real world is to be described. If there is no
cannonical view, some of the putative benefits of OOP cannot be
realized. However, even if not, it may still be the best possible
approach. Or at least no worse than others.

So, for my answer to your subject question, I could argue it either
way, but I think the best answer is yes, that it does assume
something, specifically that human programmers think -- either must
think or do think or can think -- about the world as if it was made up
of objects more or less like the ones they can code using this
approach. And, that coding under this approach is pragmatically
better than other known approaches, whatever the philosophical or
metaphysical issues involved.

Joshua Stern
JRS...@gte.net


On Mon, 21 Jan 2002 08:05:19 -0500, "Beyeler, Eric"
<ebey...@geodecisions.com> wrote:
>Does Procedural Programming assume something about human nature?
>Does Functional Programming assume something about human nature?
>
>Computer languages are ways of expressing human ideas to a computer. An
>OOP language tries to make the translation from human description of the
>solution to computer language as transparent as possible in the general
>case.
>Other kinds of languages try to make problems from certain domains
>easier to express (take Prolog for example). OOP languages deal with the
>general case of categorizing ideas/things into related types and
>describing the interrelational behavior of those types.

>So in answer to your question, whether this assumes something about
>human nature, e.g. the way humans comprehend and understand the world
>around them, OOP would assumes that people comprehend by categorization
>& relating behavor of different objects.

Joshua Stern
JRS...@gte.net

Universe

unread,
Jan 21, 2002, 9:46:20 PM1/21/02
to
"Shayne Wissler" <thal...@yahoo.com> wrote:

>"Topmind" <top...@technologist.com> wrote in message
>>

>> Title: Does OOP assume something about human nature?
>>
>> This question came up on an old debate (by somebody else), but nobody
>> answered it that I could find.
>>
>> I think it is an excellent question.

>Why?

Because he is not hemmed in by a selfish justifying philosophy that
narrowly proscribes the range of topics to what helps or hinders the
moneybags and wanna be moneybags.

Does OO assume something about human nature?

Yes.

Our mental growth passes various stages self<=>object understanding
and realization. Secondly, our thought processes one level below
stream of consciousness seems anchored in the self<=>object dialectic.

These combine to make the chief power of OO - object abstraction and
object abstraction collaboration.

Piaget, the well known cognitive psychologist and the guy with the Van
Dyke who narrated and produced a great psychology tele-series
(Psychology of the Mind?) frequently shown on PBS channels late at
night have both done research on self<=>object and concluded that
stages of self<=>object understanding and realization play critical,
necessary roles in the development of right thinking and healthy
minds.

A lot more to it, but, I'll roll that ball onto the court for now.

Elliott
--
Representation=Model * Model=Abstraction * Abstraction=Simulation
^ Analysis|Synthesis|Encapsulation|Modularization|Input ^
^ Process|Output|Control|Measurement|Fun|Beauty ^
--
http://www.radix.net/~universe ~*~ Enjoy! ~*~
Hail OO Modelling! * Hail the Wireless Web!
@Elliott 2001 my comments ~ newsgroups+bitnet quote ok

Topmind

unread,
Jan 22, 2002, 12:14:33 AM1/22/02
to
>
>
> Topmind wrote:
> > > > > > Title: Does OOP assume something about human nature?
> > > > > >
> > > > > > This question came up on an old debate (by somebody else), but nobody
> > > > > > answered it that I could find.
> > > > > >
> > > > > > I think it is an excellent question.
> > > > >
> > > > > IMO OOP doesn't assume something about human nature,
> > > > > but it partially reflects human thinking.
> > > >
> > > > Would you then conclude that it reflects some kind of
> > > > "universal truth", in a mathematical-like sense?
> > >
> > > No, not at all. Human thinking has IMO nothing to do with
> > > "universal truth" and I don't see how this relates to OOP.
> >
> > I am confused about your position then.
>
> Sorry for being unclear.

It is a hard question to ask properly and answer properly.

>
> > I figure either OOP is optimized for how human thought works, or
>
> As I said, OOP IMO "partially reflects" = "somehow fits" human
> thinking. But this doesn't mean that it is optimized for it.

Do you mean sort of a "happy accident" then?

>
> > it fits some universal truth for formulaically reducing
> > complexity, code size, change-point quantities, etc.
> > (Or, something in-between.)
>
> In my experience OOP doesn't reduce complexity or code size.


I get different responses for exactly what it (allegedly) does
improve. However, most decypherable answers usually
fall into one or more of grok-ability, change-friendliness,
or reuse improvement.

I don't see where the advantage(s) of OOP is, so I try to
find ways to get people to express their perception of
the benefits.


>
> > IOW, would *any* intelligent, rational group of beings
> > prefer OOP? Or may it just be an (alleged) human thing?
>
> IMO OOP solves enough problems to be preferred for the majority
> of programming situations, but I don't think that OOP is able
> to solve all problems.

Is there are particular problem type or problem pattern
in which you feel comfortable in identifying it as an area
where OOP does *not* solve it the best? (Besides really
small programs)

>
> --
> Helmut Leitner lei...@hls.via.at
> Graz, Austria www.hls-software.com
>

-T-

Topmind

unread,
Jan 22, 2002, 12:14:36 AM1/22/02
to
>
> "Topmind" <top...@technologist.com> wrote in message
> news:MPG.16b621cac...@news.earthlink.net...
> > >
> > > "Topmind" <top...@technologist.com> wrote in message
> > > news:MPG.16b5712aa...@news.earthlink.net...
> > > >
> > > > Title: Does OOP assume something about human nature?
> > > >
> > > > This question came up on an old debate (by somebody else), but nobody
> > > > answered it that I could find.
> > > >
> > > > I think it is an excellent question.
> > >
> > > Why?
> > >
> >
> > It gets to the heart of clarifying exactly what the
> > benefits (allegedly) are.
> >
> > Should one be looking at it from psychologist's
> > standpoint, or a clinical, quantitative[1]
> > measurement standpoint?
>
> Neither (and in particular, psychology has NOTHING to do with the issue).

What would be the 3rd option then?

>
> However, philosophy is relevant to programming language design. In
> particular, the standard of value for a programming language is not whether
> it allows you to do the job (this is not a standard of value, but a basic
> requirement), but how efficient it makes programmers--and this is a function
> of human nature. E.g., it is a fact that you can only hold around 7 elements
> in your consciousness at once.


But how is programming language design/choice philosophy really
different from paradigm design/choice? Is OOP *not* about
"how efficient it makes programmers"?


> This fact leads to the need for things like
> subordination (e.g., an object has elements; each element has elements,
> etc.).


Subordination should be used carefully, though. If done wrong,
it can lock you into a single view of element relations that need
multiple viewpoints. That is why I prefer to use formulas to
specify the subordination (or any view) pattern rather than physically
arranging the elements that way on paper (or code). IMO, it is
a higher-order (more abstract) way of managing things. I
don't understand the OOP preference in that area.

>
> --
> Shayne Wissler
>
> "The high-minded man must care more for the truth than for what people
> think." -- Aristotle
>

-T-

Topmind

unread,
Jan 22, 2002, 12:14:40 AM1/22/02
to
> On Mon, 21 Jan 2002 08:24:00 GMT, top...@technologist.com (Topmind)
> wrote:
> >Title: Does OOP assume something about human nature?
> >
> >This question came up on an old debate (by somebody else), but nobody
> >answered it that I could find.
> >
> >I think it is an excellent question.
>
> Yes, it is an excellent question. It is somewhat more difficult to
> come up with an excellent answer! I think Eric Beyeler gave a pretty
> good response (appended at bottom here), but I'm going to try to add
> to it.
>
> I like his statement that "Computer languages are ways of expressing
> human ideas to a computer." Not everyone would put things that way, I
> believe many people say that computer languages are ways of
> representing mathematical relationships between real-world objects,
> human ideas might or might not figure into it.


I would have to amend that. "Computer languages are a way of
expressing ideas to other developers first, and to the machine
second." I word it this way because humans have to do the
maintenance, not the machine.


>
> My earliest recollections of how OOP was described was along those
> lines, that it allowed one to organize code the way the real world was
> organized, and that this produced a more intuitive and optimally
> modularized set of code. This may be true to a large extent. The
> problem with either the ontological view (that it represents the
> world) or the epistemological view (that it represents human ideas) is
> that different people have different ideas, including different ideas
> about exactly how the real world is to be described. If there is no
> cannonical view, some of the putative benefits of OOP cannot be
> realized. However, even if not, it may still be the best possible
> approach. Or at least no worse than others.


So, it is a (allegedly) successful way of connonizing models
for common communication among developers, in your view?


>
> So, for my answer to your subject question, I could argue it either
> way, but I think the best answer is yes, that it does assume
> something, specifically that human programmers think -- either must
> think or do think or can think -- about the world as if it was made up
> of objects more or less like the ones they can code using this
> approach. And, that coding under this approach is pragmatically
> better than other known approaches, whatever the philosophical or
> metaphysical issues involved.


What if some programmers think better under other models?
Should they succumb to the majority and either conform
or change careers in your opinion? (This is a side-issue
I suppose.)

I would also note that there is no evidence that the
*majority* programmers have voted for OOP, (except
maybe for using the dot syntax for components developed
by the tool builders.) Thus, any suggestions about what
programmers actually prefer is speculation at this point.


>
> Joshua Stern
> JRS...@gte.net
>
>
> On Mon, 21 Jan 2002 08:05:19 -0500, "Beyeler, Eric"
> <ebey...@geodecisions.com> wrote:
> >Does Procedural Programming assume something about human nature?
> >Does Functional Programming assume something about human nature?
> >
> >Computer languages are ways of expressing human ideas to a computer. An
> >OOP language tries to make the translation from human description of the
> >solution to computer language as transparent as possible in the general
> >case.
> >Other kinds of languages try to make problems from certain domains
> >easier to express (take Prolog for example). OOP languages deal with the
> >general case of categorizing ideas/things into related types and
> >describing the interrelational behavior of those types.
> >So in answer to your question, whether this assumes something about
> >human nature, e.g. the way humans comprehend and understand the world
> >around them, OOP would assumes that people comprehend by categorization
> >& relating behavor of different objects.
>
>
>
> Joshua Stern
> JRS...@gte.net
>
>

-T-

Topmind

unread,
Jan 22, 2002, 12:14:43 AM1/22/02
to
> "Shayne Wissler" <thal...@yahoo.com> wrote:
>
> >"Topmind" <top...@technologist.com> wrote in message
> >>
> >> Title: Does OOP assume something about human nature?
> >>
> >> This question came up on an old debate (by somebody else), but nobody
> >> answered it that I could find.
> >>
> >> I think it is an excellent question.
>
> >Why?
>
> Because he is not hemmed in by a selfish justifying philosophy that
> narrowly proscribes the range of topics to what helps or hinders the
> moneybags and wanna be moneybags.
>
> Does OO assume something about human nature?
>
> Yes.
>
> Our mental growth passes various stages self<=>object understanding
> and realization. Secondly, our thought processes one level below
> stream of consciousness seems anchored in the self<=>object dialectic.


Elliot, you are not going to get very far if you are gonna tell
me that the mirco-code in my own head is really OOP.


>
> These combine to make the chief power of OO - object abstraction and
> object abstraction collaboration.
>
> Piaget, the well known cognitive psychologist and the guy with the Van
> Dyke who narrated and produced a great psychology tele-series
> (Psychology of the Mind?) frequently shown on PBS channels late at
> night have both done research on self<=>object and concluded that
> stages of self<=>object understanding and realization play critical,
> necessary roles in the development of right thinking and healthy
> minds.


And opinions of psychologists are a dime a dozen. You can
choose from thousands of theories to match just about anything
you want. Kinda like the writings of Isiah.


>
> A lot more to it, but, I'll roll that ball onto the court for now.
>
> Elliott
> --
> Representation=Model * Model=Abstraction * Abstraction=Simulation
> ^ Analysis|Synthesis|Encapsulation|Modularization|Input ^
> ^ Process|Output|Control|Measurement|Fun|Beauty ^
> --
> http://www.radix.net/~universe ~*~ Enjoy! ~*~
> Hail OO Modelling! * Hail the Wireless Web!
> @Elliott 2001 my comments ~ newsgroups+bitnet quote ok
>

-T-

Shayne Wissler

unread,
Jan 22, 2002, 12:36:30 AM1/22/02
to

"Topmind" <top...@technologist.com> wrote in message
news:MPG.16b69104b...@news.earthlink.net...

> > > It gets to the heart of clarifying exactly what the
> > > benefits (allegedly) are.
> > >
> > > Should one be looking at it from psychologist's
> > > standpoint, or a clinical, quantitative[1]
> > > measurement standpoint?
> >
> > Neither (and in particular, psychology has NOTHING to do with the
issue).
>
> What would be the 3rd option then?

Well, you could look at it from a software engineer's perspective.

> > However, philosophy is relevant to programming language design. In
> > particular, the standard of value for a programming language is not
whether
> > it allows you to do the job (this is not a standard of value, but a
basic
> > requirement), but how efficient it makes programmers--and this is a
function
> > of human nature. E.g., it is a fact that you can only hold around 7
elements
> > in your consciousness at once.
>
> But how is programming language design/choice philosophy really
> different from paradigm design/choice? Is OOP *not* about
> "how efficient it makes programmers"?

I don't know what you mean by "paradigm choice".

I believe that language design in general has to be about productivity. I
don't see any other issues as being relevant. This is engineering after all.

> > This fact leads to the need for things like
> > subordination (e.g., an object has elements; each element has elements,
> > etc.).
>
> Subordination should be used carefully, though. If done wrong,
> it can lock you into a single view of element relations that need
> multiple viewpoints. That is why I prefer to use formulas to
> specify the subordination (or any view) pattern rather than physically
> arranging the elements that way on paper (or code). IMO, it is
> a higher-order (more abstract) way of managing things. I
> don't understand the OOP preference in that area.

First let me say that, like you, I'm not in the OO mainstream. E.g., I don't
buy information hiding as a principle (it's nice, but it isn't fundamental
and it isn't a rule to be dogmatically applied everywhere). But unlike you,
I think that OO, in essence, embodies THE correct way to build software. I
don't say that any particular language has pulled it off perfectly, but I
think that 100 years from now, the best language will be an OO language.

Do you think that viewing a car as being composed of more basic
elements--like an engine, a transmission, and a body--and those of being so
composed, is an arbitrary preference? I think software should be designed
similarly to the car, with a primary hierarchy of elements. "A place for
everything, and everything in its place." Sure, you can have other views
depending on some goal or other, but these are views of something--the
primary thing.

Why view software as if it were a physical object? I might post my answer
one of these days. It certainly isn't because that's what we're used to
looking at in the "real world". There's a more substantial and objective
reason than that.

Helmut Leitner

unread,
Jan 22, 2002, 2:41:40 AM1/22/02
to

Topmind wrote:
> > > > > > > Title: Does OOP assume something about human nature?

> ...


> > > > > >
> > > > > > IMO OOP doesn't assume something about human nature,
> > > > > > but it partially reflects human thinking.
> > > > >
> > > > > Would you then conclude that it reflects some kind of
> > > > > "universal truth", in a mathematical-like sense?
> > > >
> > > > No, not at all. Human thinking has IMO nothing to do with
> > > > "universal truth" and I don't see how this relates to OOP.

> ...


> >
> > > I figure either OOP is optimized for how human thought works, or
> >
> > As I said, OOP IMO "partially reflects" = "somehow fits" human
> > thinking. But this doesn't mean that it is optimized for it.
>
> Do you mean sort of a "happy accident" then?

No, not at all. They main features of OOP solve real world
programming problems, but they also create new problems.

E. g. encapsulation gets rid of certain types of errors, but
it potentially creates new rigidity problems. It is great for
"team programming" but does not in itself contribute anything
to the solution of a problem.



> > > it fits some universal truth for formulaically reducing
> > > complexity, code size, change-point quantities, etc.
> > > (Or, something in-between.)
> >
> > In my experience OOP doesn't reduce complexity or code size.
>
> I get different responses for exactly what it (allegedly) does
> improve. However, most decypherable answers usually
> fall into one or more of grok-ability, change-friendliness,
> or reuse improvement.
>
> I don't see where the advantage(s) of OOP is, so I try to
> find ways to get people to express their perception of
> the benefits.

If you optimize PP you arrive at some kind of OO PP, but it
is really hard to teach and to enforce this.
OOP enforces OO programming, so you get a certain level of
consistency even with low level programmers.
But OOP doesn't imply OO thinking and because everything you
do and can do is OO, it seems right. But it isn't.

> > > IOW, would *any* intelligent, rational group of beings
> > > prefer OOP? Or may it just be an (alleged) human thing?
> >
> > IMO OOP solves enough problems to be preferred for the majority
> > of programming situations, but I don't think that OOP is able
> > to solve all problems.
>
> Is there are particular problem type or problem pattern
> in which you feel comfortable in identifying it as an area
> where OOP does *not* solve it the best? (Besides really
> small programs)

I think that OOP should be seen as a "low level" implementation
detail. The large abstractions a programmer builds are done by
using OO thinking but in the form of a problem specific language
currently best expressed by a set of plain (static) procedures.
In the end I'm interested to have building blocks like
s=UrlRetString("hhtp://www.google.com");
revenue=ProjectByNameRetRevenue("MyInsuranceProject");
FileByNameGetSizeDate("my.config",out size,out date);
and this is about real world objects and their properties.
But I often don't see any programming objects at this level of
abstraction and I don't care. What hurts is, that within OOP
these abstractions have no natural context free namespace.

JRStern

unread,
Jan 22, 2002, 1:12:40 PM1/22/02
to
On Tue, 22 Jan 2002 05:14:40 GMT, top...@technologist.com (Topmind)
wrote:

>> I like his statement that "Computer languages are ways of expressing
>> human ideas to a computer." Not everyone would put things that way, I
>> believe many people say that computer languages are ways of
>> representing mathematical relationships between real-world objects,
>> human ideas might or might not figure into it.
>
>I would have to amend that. "Computer languages are a way of
>expressing ideas to other developers first, and to the machine
>second." I word it this way because humans have to do the
>maintenance, not the machine.

An excellent point that I heartily endorse. However, that does not
exactly resolve questions of just how (if?) any language can truly
correspond to real-world objects.

>> If there is no
>> cannonical view, some of the putative benefits of OOP cannot be
>> realized. However, even if not, it may still be the best possible
>> approach. Or at least no worse than others.
>
>So, it is a (allegedly) successful way of connonizing models
>for common communication among developers, in your view?

Oh, no, not in my view. I think that is an issue, for most people,
though. My view is that there is no unique cannonical form. There
may be a minimal form for any given set of particulars, but the best
schema might change as the data changes -- something that no software
system could tolerate! That is in principle, of course. In practice,
I think that the normal forms of relational database design are
generally satisfactory, ... though just which normal form one should
use remains a practical issue on most projects, showing yet another
layer of problems.

And don't get me going on the ignorance of most OOP programmers to
relational theory and practice, ...

>What if some programmers think better under other models?
>Should they succumb to the majority and either conform
>or change careers in your opinion? (This is a side-issue
>I suppose.)

De gustibus non disputandum.

The original question was about human nature, which is polymorphic, or
as the kids today say, diverse. There may be people, applications,
situations where some other models would be more felicitous. What
then? I dunno.

>I would also note that there is no evidence that the
>*majority* programmers have voted for OOP, (except
>maybe for using the dot syntax for components developed
>by the tool builders.) Thus, any suggestions about what
>programmers actually prefer is speculation at this point.

"You can't always get what you want," is perhaps the operative
principle. A marketplace for languages remains, but sometimes you
just use whatever's on the shelf already.

Joshua Stern
JRS...@gte.net

Universe

unread,
Jan 22, 2002, 2:36:51 PM1/22/02
to
Topmind <top...@technologist.com> wrote:
>> "Shayne Wissler" <thal...@yahoo.com> wrote:
>>
>> >"Topmind" <top...@technologist.com> wrote in message
>> >>
>> >> Title: Does OOP assume something about human nature?
>> >>
>> >> This question came up on an old debate (by somebody else), but nobody
>> >> answered it that I could find.
>> >>
>> >> I think it is an excellent question.
>>
>> >Why?
>>
>> Because he is not hemmed in by a selfish justifying philosophy that
>> narrowly proscribes the range of topics to what helps or hinders the
>> moneybags and wanna be moneybags.
>>
>> Does OO assume something about human nature?
>>
>> Yes.
>>
>> Our mental growth passes various stages self<=>object understanding
>> and realization. Secondly, our thought processes one level below
>> stream of consciousness seems anchored in the self<=>object dialectic.
>
>
> Elliot, you are not going to get very far if you are gonna tell
> me that the mirco-code in my own head is really OOP.

Well it is advanced for Smallmind.

Elliott

Universe

unread,
Jan 22, 2002, 2:42:47 PM1/22/02
to
Universe <univ...@radix.undonet> wrote:
> Topmind <top...@technologist.com> wrote:
>>> "Shayne Wissler" <thal...@yahoo.com> wrote:
>>>
>>> >"Topmind" <top...@technologist.com> wrote in message
>>> >>
>>> >> Title: Does OOP assume something about human nature?
>>> >>
>>> >> This question came up on an old debate (by somebody else), but nobody
>>> >> answered it that I could find.
>>> >>
>>> >> I think it is an excellent question.
>>>
>>> >Why?
>>>
>>> Because he is not hemmed in by a selfish justifying philosophy that
>>> narrowly proscribes the range of topics to what helps or hinders the
>>> moneybags and wanna be moneybags.
>>>
>>> Does OO assume something about human nature?
>>>
>>> Yes.
>>>
>>> Our mental growth passes various stages self<=>object understanding
>>> and realization. Secondly, our thought processes one level below
>>> stream of consciousness seems anchored in the self<=>object dialectic.
>>
>>
>> Elliot, you are not going to get very far if you are gonna tell
>> me that the mirco-code in my own head is really OOP.
>
> Well it is advanced for Smallmind.

What the heck do you think a concept is Outtamind?

Elliott

Kurt M. Alonso

unread,
Jan 22, 2002, 2:52:26 PM1/22/02
to

Topmind wrote:

Change the title to:

"Is OOP methodologically more akin to human thinking than PP (procedural
programming)?"

Your original title is probably too vague. I can only assume that you
would end up saying
something along the lines of "but OO programmers can err (quia errare
humanum est)"


By the way, in case you accept the change, what would you accept as a
proof that
the sentence must be regarded as true?


Kurt


Topmind

unread,
Jan 22, 2002, 3:34:29 PM1/22/02
to
Helmut Leitner <helmut....@chello.at> wrote in message news:<3C4D177D...@chello.at>...

> Topmind wrote:
> > > > > > > > Title: Does OOP assume something about human nature?
> ...
> > > > > > >
> > > > > > > IMO OOP doesn't assume something about human nature,
> > > > > > > but it partially reflects human thinking.
> > > > > >
> > > > > > Would you then conclude that it reflects some kind of
> > > > > > "universal truth", in a mathematical-like sense?
> > > > >
> > > > > No, not at all. Human thinking has IMO nothing to do with
> > > > > "universal truth" and I don't see how this relates to OOP.
> ...
>
> > > > I figure either OOP is optimized for how human thought works, or
> > >
> > > As I said, OOP IMO "partially reflects" = "somehow fits" human
> > > thinking. But this doesn't mean that it is optimized for it.
> >
> > Do you mean sort of a "happy accident" then?
>
> No, not at all. They main features of OOP solve real world
> programming problems, but they also create new problems.
>
> E. g. encapsulation gets rid of certain types of errors, but
> it potentially creates new rigidity problems. It is great for
> "team programming" but does not in itself contribute anything
> to the solution of a problem.


How is it better for dividing up the work (which is what I assume
you mean by "team") than say subroutines and/or procedural
"modules"? Perhaps because the state management (data tables)
have to generally be agreed upon first in p/r? Whether this is good
or bad probably depends on how tightly one feels that
data and and "its" operations should be coupled. OOP thinking
generally assumes a tighter relationship (or assumes it
is more important) than procedural/relational (p/r) programming.
In p/r, the "state" tends to be assumed global, for good or bad.
(Global state models the real world better IMO.)

>
> > > > it fits some universal truth for formulaically reducing
> > > > complexity, code size, change-point quantities, etc.
> > > > (Or, something in-between.)
> > >
> > > In my experience OOP doesn't reduce complexity or code size.
> >
> > I get different responses for exactly what it (allegedly) does
> > improve. However, most decypherable answers usually
> > fall into one or more of grok-ability, change-friendliness,
> > or reuse improvement.
> >
> > I don't see where the advantage(s) of OOP is, so I try to
> > find ways to get people to express their perception of
> > the benefits.
>
> If you optimize PP you arrive at some kind of OO PP, but it
> is really hard to teach and to enforce this.
> OOP enforces OO programming, so you get a certain level of
> consistency even with low level programmers.


Well, I won't dispute that OOP helps you do and manage
OOP-style designs better. However, IMO good p/r makes
different modeling assumptions, which generally are
not easier to impliment under OOP.


> But OOP doesn't imply OO thinking and because everything you
> do and can do is OO, it seems right. But it isn't.

I am not quite sure what you mean by this.

>
> > > > IOW, would *any* intelligent, rational group of beings
> > > > prefer OOP? Or may it just be an (alleged) human thing?
> > >
> > > IMO OOP solves enough problems to be preferred for the majority
> > > of programming situations, but I don't think that OOP is able
> > > to solve all problems.
> >
> > Is there are particular problem type or problem pattern
> > in which you feel comfortable in identifying it as an area
> > where OOP does *not* solve it the best? (Besides really
> > small programs)
>
> I think that OOP should be seen as a "low level" implementation
> detail. The large abstractions a programmer builds are done by
> using OO thinking but in the form of a problem specific language
> currently best expressed by a set of plain (static) procedures.
> In the end I'm interested to have building blocks like
> s=UrlRetString("hhtp://www.google.com");
> revenue=ProjectByNameRetRevenue("MyInsuranceProject");
> FileByNameGetSizeDate("my.config",out size,out date);
> and this is about real world objects and their properties.
> But I often don't see any programming objects at this level of
> abstraction and I don't care. What hurts is, that within OOP
> these abstractions have no natural context free namespace.

Is this similar to the example that pops up here every
now and then:

print("foobar")

instead of

p = new printer()
p.print("foobar")

?

-T-

Helmut Leitner

unread,
Jan 22, 2002, 5:22:35 PM1/22/02
to

I can't prove it, but I think it has an advantage here.

> Perhaps because the state management (data tables)
> have to generally be agreed upon first in p/r?

Now I don't know, what you mean.

> Whether this is good or bad probably depends on how tightly one
> feels that data and and "its" operations should be coupled.
> OOP thinking generally assumes a tighter relationship (or assumes it
> is more important) than procedural/relational (p/r) programming.

This is surely true. OOP typically binds more methods to an object
than necessary, because its feels "right" to do so. PP makes objects
easier to extend, because of higher (procedural) granularity.

> In p/r, the "state" tends to be assumed global, for good or bad.
> (Global state models the real world better IMO.)

Usually you can both ways in OOP and PP.



> > > > > it fits some universal truth for formulaically reducing
> > > > > complexity, code size, change-point quantities, etc.
> > > > > (Or, something in-between.)
> > > >
> > > > In my experience OOP doesn't reduce complexity or code size.
> > >
> > > I get different responses for exactly what it (allegedly) does
> > > improve. However, most decypherable answers usually
> > > fall into one or more of grok-ability, change-friendliness,
> > > or reuse improvement.
> > >
> > > I don't see where the advantage(s) of OOP is, so I try to
> > > find ways to get people to express their perception of
> > > the benefits.
> >
> > If you optimize PP you arrive at some kind of OO PP, but it
> > is really hard to teach and to enforce this.
> > OOP enforces OO programming, so you get a certain level of
> > consistency even with low level programmers.
>
> Well, I won't dispute that OOP helps you do and manage
> OOP-style designs better.

I think "manage" is a good word. OOP helps to manage
development.

> However, IMO good p/r makes different modeling assumptions,
> which generally are not easier to impliment under OOP.

You typically have more freedom in p/r.
But p/r hurts, *if* you need inheritance or polymorphism.



> > But OOP doesn't imply OO thinking and because everything you
> > do and can do is OO, it seems right. But it isn't.
>
> I am not quite sure what you mean by this.

That would be a long story...

The example doesn't feel right, although there is some similarity.

If you compare
p=PrinterOpen();
PrinterDrawString(p,s,position);
PrinterDrawImage(p,im,position);
PrinterClose(p);
to
p = new printer();
p.DrawString(...);
p.DrawImage(...);
p.Close();
you would find hardly a difference between PP and OOP.

But if you write
error=CustomerByNameDeleteAllData("Xyz Smith");
then you need not know or care about whether this is implemented
by using some kind of objects or a plain SQL statement or no
database at all. It would feel like using Assembler to write more
than just this single (or a similar) procedure call.

Universe

unread,
Jan 22, 2002, 5:52:14 PM1/22/02
to
One will *never* really understand how OO is *actually* linked to the
nature of humans, as long as one sees OO mainly as OOP. And it's
really limiting by reaching over OOD to OOP.

As long as one fails to understand the predominant guiding, and
leading role that OOA plays relative to OOD and OOP, you will *never*
really understand OO's link to humans, much less understanding the
fundamental power and benefits of OO itself.

This failure is related to and reinforces why most software
engineering empiricists and pragmatists oppose scope relevant, domain
modelled based OO programming.

Elliott
--
Optimal software abstraction layers have project vocabulary and
key scope relevant role objects corresponding to the layer's reality.
entities.

______________________________________________________________________
Posted Via Uncensored-News.Com - Still Only $9.95 - http://www.uncensored-news.com
With NINE Servers In California And Texas - The Worlds Uncensored News Source

Warren R. Zeigler

unread,
Jan 23, 2002, 12:22:41 AM1/23/02
to
Of course. All stupid arguments aside, OO is designed to reduce complexity,
allowing the average person to view the current "work area" all at once,
even in complex programs.

--
Warren R. Zeigler
Understanding Objects - The class people have been looking for - even if
they don't know it.
www.UnderstandingObjects.com


"Topmind" <top...@technologist.com> wrote in message

news:MPG.16b5712aa...@news.earthlink.net...


>
> Title: Does OOP assume something about human nature?
>

Topmind

unread,
Jan 23, 2002, 1:08:17 AM1/23/02
to


Most OO fans do. However, I have yet to see a convincing
example.


>
> > Perhaps because the state management (data tables)
> > have to generally be agreed upon first in p/r?
>
> Now I don't know, what you mean.


The entity structuring effort is generally seperate
from dividing up of tasks.


>
> > Whether this is good or bad probably depends on how tightly one
> > feels that data and and "its" operations should be coupled.
> > OOP thinking generally assumes a tighter relationship (or assumes it
> > is more important) than procedural/relational (p/r) programming.
>
> This is surely true. OOP typically binds more methods to an object
> than necessary, because its feels "right" to do so. PP makes objects
> easier to extend, because of higher (procedural) granularity.

By "higher" do you mean "smaller"?

>
> > In p/r, the "state" tends to be assumed global, for good or bad.
> > (Global state models the real world better IMO.)
>
> Usually you can both ways in OOP and PP.


I suppose it depends on one's design philosophy.


>
> > > > > > it fits some universal truth for formulaically reducing
> > > > > > complexity, code size, change-point quantities, etc.
> > > > > > (Or, something in-between.)
> > > > >
> > > > > In my experience OOP doesn't reduce complexity or code size.
> > > >
> > > > I get different responses for exactly what it (allegedly) does
> > > > improve. However, most decypherable answers usually
> > > > fall into one or more of grok-ability, change-friendliness,
> > > > or reuse improvement.
> > > >
> > > > I don't see where the advantage(s) of OOP is, so I try to
> > > > find ways to get people to express their perception of
> > > > the benefits.
> > >
> > > If you optimize PP you arrive at some kind of OO PP, but it
> > > is really hard to teach and to enforce this.
> > > OOP enforces OO programming, so you get a certain level of
> > > consistency even with low level programmers.
> >
> > Well, I won't dispute that OOP helps you do and manage
> > OOP-style designs better.
>
> I think "manage" is a good word. OOP helps to manage
> development.


Perhaps it is subjective. Good management for some is not
good management for others. I prefer to manage lots of
similar things in tables, where I can view it from
different virtual perspectives using query-like commands.


>
> > However, IMO good p/r makes different modeling assumptions,
> > which generally are not easier to impliment under OOP.
>
> You typically have more freedom in p/r.
> But p/r hurts, *if* you need inheritance or polymorphism.


Which, I find I don't in the domain of custom biz apps.
Mutually-exclusive divisions into "types" usually is not
very flexible. If you know of any decent division examples,
then can I ask for an outline/list of them?

I am not sure what you mean exactly.

I beleive that referential integrity rules can be used to
delete dependent records, BTW. However, in reality you
want to limit this so that you don't delete log data, etc.

> --
> Helmut Leitner lei...@hls.via.at
> Graz, Austria www.hls-software.com
>

-T-

Topmind

unread,
Jan 23, 2002, 1:08:23 AM1/23/02
to
>
>
> Topmind wrote:
>
> > Title: Does OOP assume something about human nature?
> >
> > This question came up on an old debate (by somebody else), but nobody
> > answered it that I could find.
> >
> > I think it is an excellent question.
> >
> > -T-
>
> Change the title to:
>
> "Is OOP methodologically more akin to human thinking than PP (procedural
> programming)?"
>
> Your original title is probably too vague. I can only assume that you
> would end up saying
> something along the lines of "but OO programmers can err (quia errare
> humanum est)"
>

Huh? I don't see the connection here to our Y2K debates.

Topmind

unread,
Jan 23, 2002, 1:08:27 AM1/23/02
to
> On Tue, 22 Jan 2002 05:14:40 GMT, top...@technologist.com (Topmind)
> wrote:
> >> I like his statement that "Computer languages are ways of expressing
> >> human ideas to a computer." Not everyone would put things that way, I
> >> believe many people say that computer languages are ways of
> >> representing mathematical relationships between real-world objects,
> >> human ideas might or might not figure into it.
> >
> >I would have to amend that. "Computer languages are a way of
> >expressing ideas to other developers first, and to the machine
> >second." I word it this way because humans have to do the
> >maintenance, not the machine.
>
> An excellent point that I heartily endorse. However, that does not
> exactly resolve questions of just how (if?) any language can truly
> correspond to real-world objects.


Perhaps one can claim that it better models the parts of
the real world that are important to the project. IOW,
a better subset choice.

.....

-T-

Topmind

unread,
Jan 23, 2002, 1:08:30 AM1/23/02
to
>
> "Topmind" <top...@technologist.com> wrote in message
> news:MPG.16b69104b...@news.earthlink.net...
>
> > > > It gets to the heart of clarifying exactly what the
> > > > benefits (allegedly) are.
> > > >
> > > > Should one be looking at it from psychologist's
> > > > standpoint, or a clinical, quantitative[1]
> > > > measurement standpoint?
> > >
> > > Neither (and in particular, psychology has NOTHING to do with the
> issue).
> >
> > What would be the 3rd option then?
>
> Well, you could look at it from a software engineer's perspective.


IMO, a good software engineer would hunt for objective, or at
least externally demonstratable ways to compare. This would
be similar to the quantitative hunt above. For example, counting
the number of spots that need changing for a set of change
scenarios.

If a good SE looks at phsychological factors, then they
will try to isolate who and when it affects things. IOW,
old fashioned western reductionalism.

IOW2, abstract out the benefit reasons.


>
> > > However, philosophy is relevant to programming language design. In
> > > particular, the standard of value for a programming language is not
> whether
> > > it allows you to do the job (this is not a standard of value, but a
> basic
> > > requirement), but how efficient it makes programmers--and this is a
> function
> > > of human nature. E.g., it is a fact that you can only hold around 7
> elements
> > > in your consciousness at once.
> >
> > But how is programming language design/choice philosophy really
> > different from paradigm design/choice? Is OOP *not* about
> > "how efficient it makes programmers"?
>
> I don't know what you mean by "paradigm choice".


The larger-scale equivalent of "language choice".


>
> I believe that language design in general has to be about productivity. I
> don't see any other issues as being relevant. This is engineering after all.
>
> > > This fact leads to the need for things like
> > > subordination (e.g., an object has elements; each element has elements,
> > > etc.).
> >
> > Subordination should be used carefully, though. If done wrong,
> > it can lock you into a single view of element relations that need
> > multiple viewpoints. That is why I prefer to use formulas to
> > specify the subordination (or any view) pattern rather than physically
> > arranging the elements that way on paper (or code). IMO, it is
> > a higher-order (more abstract) way of managing things. I
> > don't understand the OOP preference in that area.
>
> First let me say that, like you, I'm not in the OO mainstream. E.g., I don't
> buy information hiding as a principle (it's nice, but it isn't fundamental
> and it isn't a rule to be dogmatically applied everywhere). But unlike you,
> I think that OO, in essence, embodies THE correct way to build software. I
> don't say that any particular language has pulled it off perfectly, but I
> think that 100 years from now, the best language will be an OO language.


Would you venture to try to measure, or at least comparitively
illustrate "correct way to build"?


>
> Do you think that viewing a car as being composed of more basic
> elements--like an engine, a transmission, and a body--and those of being so
> composed, is an arbitrary preference?


YES!

Somebody might want to look at all valves *regardless* of where they
are in the car (or secondary to). Another may want to sort parts by
manafacturing costs. Their physical location in the car or to other parts
is *one of many* possible viewpoints. Another may want to analyze the
materials things are made of. There are multiple orthogonal
organizational possibilities.

Relational modeling better manages and simplifies supplying
multiple viewpoints of nodes. IOW, has-a view instead of
is-a.


> I think software should be designed
> similarly to the car, with a primary hierarchy of elements. "A place for
> everything, and everything in its place."

And I view "everything in its place" as relative to a given need.

> Sure, you can have other views
> depending on some goal or other, but these are views of something--the
> primary thing.

Entity instances?

>
> Why view software as if it were a physical object? I might post my answer
> one of these days. It certainly isn't because that's what we're used to
> looking at in the "real world". There's a more substantial and objective
> reason than that.

Well, IMO p/r has transcended that. It is the holodeck of information
management. You project the viewpoint you need for a given task or
need. An out-of-body experience. (OOP on the other hand is
an out-of-mind experience :-)

>
> --
> Shayne Wissler
>
> "The high-minded man must care more for the truth than for what people
> think." -- Aristotle
>

-T-

Topmind

unread,
Jan 23, 2002, 1:08:33 AM1/23/02
to
> Universe <univ...@radix.undonet> wrote:
> > Topmind <top...@technologist.com> wrote:
> >>> "Shayne Wissler" <thal...@yahoo.com> wrote:
> >>>
> >>> >"Topmind" <top...@technologist.com> wrote in message
> >>> >>
> >>> >> Title: Does OOP assume something about human nature?
> >>> >>
> >>> >> This question came up on an old debate (by somebody else), but nobody
> >>> >> answered it that I could find.
> >>> >>
> >>> >> I think it is an excellent question.
> >>>
> >>> >Why?
> >>>
> >>> Because he is not hemmed in by a selfish justifying philosophy that
> >>> narrowly proscribes the range of topics to what helps or hinders the
> >>> moneybags and wanna be moneybags.
> >>>
> >>> Does OO assume something about human nature?
> >>>
> >>> Yes.
> >>>
> >>> Our mental growth passes various stages self<=>object understanding
> >>> and realization. Secondly, our thought processes one level below
> >>> stream of consciousness seems anchored in the self<=>object dialectic.
> >>
> >>
> >> Elliot, you are not going to get very far if you are gonna tell
> >> me that the mirco-code in my own head is really OOP.
> >
> > Well it is advanced for Smallmind.
>
> What the heck do you think a concept is Outtamind?


A series of neurons that "light-up"


-T-

Topmind

unread,
Jan 23, 2002, 1:08:37 AM1/23/02
to
> One will *never* really understand how OO is *actually* linked to the
> nature of humans, as long as one sees OO mainly as OOP. And it's
> really limiting by reaching over OOD to OOP.
>
> As long as one fails to understand the predominant guiding, and
> leading role that OOA plays relative to OOD and OOP, you will *never*
> really understand OO's link to humans, much less understanding the
> fundamental power and benefits of OO itself.


Probably because it is not representable in anything more
than zen-talk.


>
> This failure is related to and reinforces why most software
> engineering empiricists and pragmatists oppose scope relevant, domain
> modelled based OO programming.

I guess I should listen for the sound of grass growing
and talk to the pebbles.

Everybody models, just in different ways.

Topmind

unread,
Jan 23, 2002, 1:25:42 AM1/23/02
to

> Of course. All stupid arguments aside, OO is designed to reduce complexity,
> allowing the average person to view the current "work area" all at once,
> even in complex programs.


Odd. That is exactly how I feel about tables and schemas:
no clutter from algorithms blocking or distracting your
grok-ing efforts. Pure, naked noun descriptions in a
compact, queriable, view-alterable format.

Algorithms take a while to grok no matter how you
package them. Thus, what p/r does is seperate the
parts that are easy to grok (attributes) from the
parts that are hard to grok. IOW, it is better to
be able to quickly grok 50 percent than zero percent,
which is what you get if you intertwine them.

Even managers can grok ER diagrams and schemas.

They make equiv of things like the OO-observer pattern
crystal clear to view, sort, search, etc. The
table is "a list of things that want to be
notified". You cannot get conceptually and
representationally simpler than that.

You just can't.

Anybody who can read a bus schedule can relate.

>
> --
> Warren R. Zeigler
> Understanding Objects - The class people have been looking for - even if
> they don't know it.
> www.UnderstandingObjects.com
>
>
> "Topmind" <top...@technologist.com> wrote in message
> news:MPG.16b5712aa...@news.earthlink.net...
> >
> > Title: Does OOP assume something about human nature?
> >
> > This question came up on an old debate (by somebody else), but nobody
> > answered it that I could find.
> >
> > I think it is an excellent question.
> >
> > -T-
> >
>

-T-

Helmut Leitner

unread,
Jan 23, 2002, 2:18:19 AM1/23/02
to

Ilja Preuss wrote:
>
> Hi Helmut! :-)


>
> > But if you write
> > error=CustomerByNameDeleteAllData("Xyz Smith");
> > then you need not know or care about whether this is implemented
> > by using some kind of objects or a plain SQL statement or no
> > database at all. It would feel like using Assembler to write more
> > than just this single (or a similar) procedure call.
>

> How would you feel about
>
> error = CustomerRepository.getCustomerByName("Xyz Smith").deleteAllData();
>

I don't like it.

The role of CustomerRepository is unclear. Is it just a utility class for
static procedures or does it provide some form of cash? Do I have to commit?
How many Repositories do we have? One for each business entity?
There are many things you start to think about without necessity.

What will we do in multi-project-reuse-situation with common libraries
and projects extending "Customer" in various ways. What classes will
you create and use? How will you organize reuse between projects.

What happens if we want to extend to a multiple database situation:
error=DatabaseCustomerByNameDeleteAllData(LondonData,"Xyz Smith");
What effect will this have on CustomerRepository?

It's clear that you can do everything in OOP and PP, but PP is simpler and
more natural for the topmost abstractions.

Helmut Leitner

unread,
Jan 23, 2002, 3:03:17 AM1/23/02
to

But I'm not a OOP fan. I'm an OOT fan usually using PP.



> > > Perhaps because the state management (data tables)
> > > have to generally be agreed upon first in p/r?
> >
> > Now I don't know, what you mean.
>
> The entity structuring effort is generally seperate
> from dividing up of tasks.

Ok, you talk about management.

> > > Whether this is good or bad probably depends on how tightly one
> > > feels that data and and "its" operations should be coupled.
> > > OOP thinking generally assumes a tighter relationship (or assumes it
> > > is more important) than procedural/relational (p/r) programming.
> >
> > This is surely true. OOP typically binds more methods to an object
> > than necessary, because its feels "right" to do so. PP makes objects
> > easier to extend, because of higher (procedural) granularity.
>
> By "higher" do you mean "smaller"?

Yes, sorry. OOP has a deficiency with respect to granularity.



> > > In p/r, the "state" tends to be assumed global, for good or bad.
> > > (Global state models the real world better IMO.)
> >
> > Usually you can both ways in OOP and PP.
>
> I suppose it depends on one's design philosophy.

Yes, but there should be no need to stick to a certain philosophy.



> > > > > > > it fits some universal truth for formulaically reducing
> > > > > > > complexity, code size, change-point quantities, etc.
> > > > > > > (Or, something in-between.)
> > > > > >
> > > > > > In my experience OOP doesn't reduce complexity or code size.
> > > > >
> > > > > I get different responses for exactly what it (allegedly) does
> > > > > improve. However, most decypherable answers usually
> > > > > fall into one or more of grok-ability, change-friendliness,
> > > > > or reuse improvement.
> > > > >
> > > > > I don't see where the advantage(s) of OOP is, so I try to
> > > > > find ways to get people to express their perception of
> > > > > the benefits.
> > > >
> > > > If you optimize PP you arrive at some kind of OO PP, but it
> > > > is really hard to teach and to enforce this.
> > > > OOP enforces OO programming, so you get a certain level of
> > > > consistency even with low level programmers.
> > >
> > > Well, I won't dispute that OOP helps you do and manage
> > > OOP-style designs better.
> >
> > I think "manage" is a good word. OOP helps to manage
> > development.
>
> Perhaps it is subjective. Good management for some is not
> good management for others. I prefer to manage lots of
> similar things in tables, where I can view it from
> different virtual perspectives using query-like commands.

Ok, but it seems to me, that you have a database-centric
perspective. What if you do image processing without a
single data table.

> > > However, IMO good p/r makes different modeling assumptions,
> > > which generally are not easier to impliment under OOP.
> >
> > You typically have more freedom in p/r.
> > But p/r hurts, *if* you need inheritance or polymorphism.
>
> Which, I find I don't in the domain of custom biz apps.
> Mutually-exclusive divisions into "types" usually is not
> very flexible. If you know of any decent division examples,
> then can I ask for an outline/list of them?

This is database-centric. I don't see any need for inheritance or
polymorphism there. Anything should be in the data.

> > But if you write
> > error=CustomerByNameDeleteAllData("Xyz Smith");
> > then you need not know or care about whether this is implemented
> > by using some kind of objects or a plain SQL statement or no
> > database at all. It would feel like using Assembler to write more
> > than just this single (or a similar) procedure call.

I think that programming is not about "using languages" but
"creating languages". If you are clear about what you want to
handle (the real world object, the actions) then you can talk
about it using your own words and your own syntax:

im=ImageCreateScannerResolutionColorspaceRectangle(300,RGB,rect);
WindowDrawImagePosition(w,im,pos);

This is like a form of pseudocode. The simplest thing is to make
this pseudocode - and so your language - work. This is very simple
and very abstract and usually easy in PP but a PITA in OOP.

Universe

unread,
Jan 23, 2002, 4:42:29 AM1/23/02
to
Helmut Leitner <helmut....@chello.at> wrote:

>> The entity structuring effort is generally seperate
>> from dividing up of tasks.

Completely, partially, less rather than more?

What exactly do you mean by entity structuring?

What exactly do you mean by dividing up tasks?

Elliott
--
Windows - A thirty two bit extension and gui shell to a sixteen bit
patch to an eight bit operating system originally coded for a four bit
microprocessor and sold by a two bit company that can't stand one bit.
~ Andy

Helmut Leitner

unread,
Jan 23, 2002, 5:44:35 AM1/23/02
to

Universe wrote:
>
> Helmut Leitner <helmut....@chello.at> wrote:

Wrong. Topmind wrote:

> >> The entity structuring effort is generally seperate
> >> from dividing up of tasks.

Please ask him.

Shayne Wissler

unread,
Jan 23, 2002, 2:06:20 PM1/23/02
to

"Topmind" <top...@technologist.com> wrote in message
news:MPG.16b7f1adf...@news.earthlink.net...

> >
> > "Topmind" <top...@technologist.com> wrote in message
> > news:MPG.16b69104b...@news.earthlink.net...
> >
> > > > > It gets to the heart of clarifying exactly what the
> > > > > benefits (allegedly) are.
> > > > >
> > > > > Should one be looking at it from psychologist's
> > > > > standpoint, or a clinical, quantitative[1]
> > > > > measurement standpoint?
> > > >
> > > > Neither (and in particular, psychology has NOTHING to do with the
> > issue).
> > >
> > > What would be the 3rd option then?
> >
> > Well, you could look at it from a software engineer's perspective.
>
> IMO, a good software engineer would hunt for objective, or at
> least externally demonstratable ways to compare.

So why is it objective to look at software from a non-software perspective?

> > > But how is programming language design/choice philosophy really
> > > different from paradigm design/choice? Is OOP *not* about
> > > "how efficient it makes programmers"?
> >
> > I don't know what you mean by "paradigm choice".
>
> The larger-scale equivalent of "language choice".

Well, that clears it up. Do you not know what you're referring to well
enough to say what you mean?

> > First let me say that, like you, I'm not in the OO mainstream. E.g., I
don't
> > buy information hiding as a principle (it's nice, but it isn't
fundamental
> > and it isn't a rule to be dogmatically applied everywhere). But unlike
you,
> > I think that OO, in essence, embodies THE correct way to build software.
I
> > don't say that any particular language has pulled it off perfectly, but
I
> > think that 100 years from now, the best language will be an OO language.
>
> Would you venture to try to measure, or at least comparitively
> illustrate "correct way to build"?

What do you mean by "measure"? Have you measured such things? How do you
prove that your standard of measurement is right?

> > Do you think that viewing a car as being composed of more basic
> > elements--like an engine, a transmission, and a body--and those of being
so
> > composed, is an arbitrary preference?
>
> YES!
>
> Somebody might want to look at all valves *regardless* of where they
> are in the car (or secondary to). Another may want to sort parts by
> manafacturing costs. Their physical location in the car or to other parts
> is *one of many* possible viewpoints. Another may want to analyze the
> materials things are made of. There are multiple orthogonal
> organizational possibilities.

Well, your examples prove my point. Regardless of how you want to look at
it, the valves ARE in a given part of the car. And looking at them from
another perspective requires that you first are aware of this fact. You
can't even know what a valve is without knowing where it is and what role it
plays.

> Relational modeling better manages and simplifies supplying
> multiple viewpoints of nodes. IOW, has-a view instead of
> is-a.

I think the has-a view is more important than the is-a view. Is that what
you're saying too?

> > I think software should be designed
> > similarly to the car, with a primary hierarchy of elements. "A place for
> > everything, and everything in its place."
>
> And I view "everything in its place" as relative to a given need.

Then you're wrong. The need to inventory valves pressupposes that they exist
somewhere to begin with. Sure, we can ignore place for some purposes, but
even if we do that, they still presuppose a place, it's just that we don't
care where it is for that purpose.

> > Sure, you can have other views
> > depending on some goal or other, but these are views of something--the
> > primary thing.
>
> Entity instances?

Yes, things.

> > Why view software as if it were a physical object? I might post my
answer
> > one of these days. It certainly isn't because that's what we're used to
> > looking at in the "real world". There's a more substantial and objective
> > reason than that.
>
> Well, IMO p/r has transcended that. It is the holodeck of information
> management. You project the viewpoint you need for a given task or
> need. An out-of-body experience. (OOP on the other hand is
> an out-of-mind experience :-)

I went to your website to try to understand what it was you were proposing.
I couldn't understand. How about a small calculator application written in
the style you prefer?


Shayne Wissler

@objectmentor.com Robert C. Martin

unread,
Jan 23, 2002, 2:22:02 PM1/23/02
to
On Mon, 21 Jan 2002 08:24:00 GMT, top...@technologist.com (Topmind)
wrote:

>
>Title: Does OOP assume something about human nature?
>

>This question came up on an old debate (by somebody else), but nobody
>answered it that I could find.

I think OOP, being created by certain humans, is a result of certain
human's natures. One could probably assume that those who find OOP
beneficial shared some similarity with those certain human's nature.


Robert C. Martin | "Uncle Bob" | Software Consultants
Object Mentor Inc. | rma...@objectmentor.com | We'll help you get
PO Box 5757 | Tel: (800) 338-6716 | your projects done.
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python|

"One of the great commandments of science is:
'Mistrust arguments from authority.'" -- Carl Sagan

Helmut Leitner

unread,
Jan 23, 2002, 5:13:55 PM1/23/02
to

Ilja Preuss wrote:
> > WindowDrawImagePosition(w,im,pos);
>
> window draw: myImage at: imagePosition
>

This is only a small syntactical difference. If you define
certain transformations you can view them almost as isomorphic.

What remains is that PP is more flexible in certain areas because
you can work within a context free namespace with procedures as the
smallest units of reuse.

> The trick is to read it as a request to the first object, so
>
> ilja getSerious: immediately
>
> translates to:
>
> "Ilja, get serious immediately!" :-)

That depends on the language. "get" is not used consistently
as far as I know your favourite language (still Java?).

In my language you would say:

SleepSec(0.3);
ProgrammerModeSetValue("Ilja",SERIOUSNESS,0.90);

and this would tell you what "immediately" means, what object
Ilja is, that there may be more than one modes defined and
that I don't request maximum seriousness. :-)

Topmind

unread,
Jan 23, 2002, 8:51:25 PM1/23/02
to
"Shayne Wissler" <thal...@yahoo.com> wrote in message news:<MQD38.1051$5B4....@rwcrnsc52.ops.asp.att.net>...

> "Topmind" <top...@technologist.com> wrote in message
> news:MPG.16b7f1adf...@news.earthlink.net...
> > >
> > > "Topmind" <top...@technologist.com> wrote in message
> > > news:MPG.16b69104b...@news.earthlink.net...
> > >
> > > > > > It gets to the heart of clarifying exactly what the
> > > > > > benefits (allegedly) are.
> > > > > >
> > > > > > Should one be looking at it from psychologist's
> > > > > > standpoint, or a clinical, quantitative[1]
> > > > > > measurement standpoint?
> > > > >
> > > > > Neither (and in particular, psychology has NOTHING to do with the
> issue).
> > > >
> > > > What would be the 3rd option then?
> > >
> > > Well, you could look at it from a software engineer's perspective.
> >
> > IMO, a good software engineer would hunt for objective, or at
> > least externally demonstratable ways to compare.
>
> So why is it objective to look at software from a non-software perspective?


Huh? I did not say anything about "non-software". Counting
change-spots using a set of change-scenarios is "software
related", no?


>
> > > > But how is programming language design/choice philosophy really
> > > > different from paradigm design/choice? Is OOP *not* about
> > > > "how efficient it makes programmers"?
> > >
> > > I don't know what you mean by "paradigm choice".
> >
> > The larger-scale equivalent of "language choice".
>
> Well, that clears it up. Do you not know what you're referring to well
> enough to say what you mean?

You lost me here. Let's skip this.

>
> > > First let me say that, like you, I'm not in the OO mainstream. E.g., I
> don't
> > > buy information hiding as a principle (it's nice, but it isn't
> fundamental
> > > and it isn't a rule to be dogmatically applied everywhere). But unlike
> you,
> > > I think that OO, in essence, embodies THE correct way to build software.
> I
> > > don't say that any particular language has pulled it off perfectly, but
> I
> > > think that 100 years from now, the best language will be an OO language.
> >
> > Would you venture to try to measure, or at least comparitively
> > illustrate "correct way to build"?
>
> What do you mean by "measure"? Have you measured such things? How do you
> prove that your standard of measurement is right?


There will never be 100% "proof" in this business. But every
respectable metric does not show OOP objectively (or at
least externally demonstratably) better.

These would include metrics like code size (token counts)
and change-scenario impact analyses.


>
> > > Do you think that viewing a car as being composed of more basic
> > > elements--like an engine, a transmission, and a body--and those of being
> so
> > > composed, is an arbitrary preference?
> >
> > YES!
> >
> > Somebody might want to look at all valves *regardless* of where they
> > are in the car (or secondary to). Another may want to sort parts by
> > manafacturing costs. Their physical location in the car or to other parts
> > is *one of many* possible viewpoints. Another may want to analyze the
> > materials things are made of. There are multiple orthogonal
> > organizational possibilities.
>
> Well, your examples prove my point. Regardless of how you want to look at
> it, the valves ARE in a given part of the car.


And no matter how you look at it, they are a cost item to accountants,
a materials consumer to manufacturer of the part and weight analysts,
etc.

IOW, parts are lot of different things. In my domain,
any entity instance may be viewed and accessed from
all kinds of different perspectives, many not forseeable
up front. Thus, I don't hard-wire any one viewpoint
into my model. This is where OOP often goes wrong IMO.


> And looking at them from
> another perspective requires that you first are aware of this fact. You
> can't even know what a valve is without knowing where it is and what role it
> plays.

An accountant may not have to know.

>
> > Relational modeling better manages and simplifies supplying
> > multiple viewpoints of nodes. IOW, has-a view instead of
> > is-a.
>
> I think the has-a view is more important than the is-a view. Is that what
> you're saying too?

More flexible.

>
> > > I think software should be designed
> > > similarly to the car, with a primary hierarchy of elements. "A place for
> > > everything, and everything in its place."
> >
> > And I view "everything in its place" as relative to a given need.
>
> Then you're wrong. The need to inventory valves pressupposes that they exist
> somewhere to begin with.

Yes. Existence is covered by both approaches.

> Sure, we can ignore place for some purposes, but
> even if we do that, they still presuppose a place, it's just that we don't
> care where it is for that purpose.
>
> > > Sure, you can have other views
> > > depending on some goal or other, but these are views of something--the
> > > primary thing.
> >
> > Entity instances?
>
> Yes, things.
>
> > > Why view software as if it were a physical object? I might post my
> answer
> > > one of these days. It certainly isn't because that's what we're used to
> > > looking at in the "real world". There's a more substantial and objective
> > > reason than that.
> >
> > Well, IMO p/r has transcended that. It is the holodeck of information
> > management. You project the viewpoint you need for a given task or
> > need. An out-of-body experience. (OOP on the other hand is
> > an out-of-mind experience :-)
>
> I went to your website to try to understand what it was you were proposing.
> I couldn't understand. How about a small calculator application written in
> the style you prefer?
>


I would generally not consider building a calculator typical of my
scope of fussing (custom biz apps). It is probably closer to the
systems software domain, or perhaps embedded systems domains. (I don't
claim my approach is the best for all domains. I have already
tentatively agreed that OOP may be better for writing device drivers.)

>
> Shayne Wissler

-T-

Shayne Wissler

unread,
Jan 23, 2002, 9:55:57 PM1/23/02
to

"Topmind" <top...@technologist.com> wrote in message
news:4e705869.02012...@posting.google.com...

> > > IMO, a good software engineer would hunt for objective, or at
> > > least externally demonstratable ways to compare.
> >
> > So why is it objective to look at software from a non-software
perspective?
>
> Huh? I did not say anything about "non-software". Counting
> change-spots using a set of change-scenarios is "software
> related", no?

Perhaps I don't know what you mean by "externally demonstratable".

> > > Would you venture to try to measure, or at least comparitively
> > > illustrate "correct way to build"?
> >
> > What do you mean by "measure"? Have you measured such things? How do you
> > prove that your standard of measurement is right?
>
> There will never be 100% "proof" in this business. But every
> respectable metric does not show OOP objectively (or at
> least externally demonstratably) better.

I don't believe in metrics.

> These would include metrics like code size (token counts)
> and change-scenario impact analyses.

IMO, these studies are so much subject to other factors that they are
meaningless when it comes to comparing languages.

> > Well, your examples prove my point. Regardless of how you want to look
at
> > it, the valves ARE in a given part of the car.
>
> And no matter how you look at it, they are a cost item to accountants,
> a materials consumer to manufacturer of the part and weight analysts,
> etc.

I don't dispute the other perspectives. I argue that there is a fundamental
one. The thing IS somewhere. Everything else depends on that primary fact.

> IOW, parts are lot of different things. In my domain,
> any entity instance may be viewed and accessed from
> all kinds of different perspectives, many not forseeable
> up front. Thus, I don't hard-wire any one viewpoint
> into my model. This is where OOP often goes wrong IMO.

Well, you're missing the point.

But I don't blame you; I'm not a big fan of most OO approaches I've seen.

> > And looking at them from
> > another perspective requires that you first are aware of this fact. You
> > can't even know what a valve is without knowing where it is and what
role it
> > plays.
>
> An accountant may not have to know.

Irrelevant. The primary fact is still the primary fact.

> > > Relational modeling better manages and simplifies supplying
> > > multiple viewpoints of nodes. IOW, has-a view instead of
> > > is-a.
> >
> > I think the has-a view is more important than the is-a view. Is that
what
> > you're saying too?
>
> More flexible.

Please elaborate.

> > Then you're wrong. The need to inventory valves pressupposes that they
exist
> > somewhere to begin with.
>
> Yes. Existence is covered by both approaches.

"Covered" isn't the issue. One aspect is more fundamental than the other.

> > I went to your website to try to understand what it was you were
proposing.
> > I couldn't understand. How about a small calculator application written
in
> > the style you prefer?
> >
>
> I would generally not consider building a calculator typical of my
> scope of fussing (custom biz apps). It is probably closer to the
> systems software domain, or perhaps embedded systems domains. (I don't
> claim my approach is the best for all domains. I have already
> tentatively agreed that OOP may be better for writing device drivers.)

So you don't think your approach would be good for building a simple
calculator?

Why the hell are you arguing with OOPers when you don't have a solution
yourself?

Universe

unread,
Jan 23, 2002, 11:05:24 PM1/23/02
to
Robert C. Martin <rmartin @ objectmentor . com> wrote:

>On Mon, 21 Jan 2002 08:24:00 GMT, top...@technologist.com (Topmind)
>wrote:
>
>>
>>Title: Does OOP assume something about human nature?
>>
>>This question came up on an old debate (by somebody else), but nobody
>>answered it that I could find.

>I think OOP, being created by certain humans, is a result of certain
>human's natures. One could probably assume that those who find OOP
>beneficial shared some similarity with those certain human's nature.

Really *fawlty* assumption. Or awful faulty presumption.

Agreeing with *genuine* OO character and spirit presupposes that hey!
first all one indeed concurs with and also views as essential, the
OO-OOADP definition held by it's founders and most leading OO sw
engineers.

Ahhh.... YOU DO NOT. That's BLATANTLY obvious:

RCM's OOP:
> Object oriented programming is the technique of manipulating variables
> using functions called using an indirect dispatch mechnism associated
> with those variable.
> OOP is a strategy of programming in which variables are organized into
> structures and then manipulated solely by functions that are called
> through a jump table contained by that data structure.
> Structured programming is discipline imposed upon direct transfer of
> control.
> Object oriented programming is discipline imposed upon indirect
> transfer of control.
> OOP is the use of jump tables to manage interdependencies between
> modules.

And that of course is WAY, WAY, WAY out of wack with the Nygaard's and
most leading OO engineers agreement that scope relevant domain object
abstraction modelling/simulation is the primary quiddity (essential
nature) of, or what is qua (in the spirit of), OO.

Nygaard et al OO-OOADP:
"Object-oriented [OO] programming. A program execution is regarded as
a physical model, simulating the behavior of either a real or
imaginary part of the world...The notion of a physical model should be
taken literally."
~ Computerized physical models
Madsen, Moeller-Pederson, Nygaard (co-founder of OO)

"We will introduce concepts such as information processes and systems
and discuss abstraction, concepts, classification and composition. The
framework provides a means to be used when modeling phenomena and
concepts from the real world, it is thus a fundamental basis for
object-oriented analysis and design. It is, however, also important
for implementation, since it provides a means for structuring and
understanding the objects and patterns generated by a program
execution. The approach presented in this book is that analysis,
design and implementation are programming or modeling activities, but
at different abstraction levels."
~ Object-Oriented Programming in the BETA Programming Language
Ole Lehrmann Madsen, Birger Møller-Pedersen, Kristen Nygaard

Based upon the above we can only conclude that one can use an
OOPLanguage and a specific OOPL's idioms, yet still not be practicing
OO quiddity in the main.

Elliott
--
Thus, do bees fly higher than wanna bees.

Universe

unread,
Jan 23, 2002, 11:21:15 PM1/23/02
to
"Shayne Wissler" <thal...@yahoo.com> wrote:

>"Topmind" <top...@technologist.com> wrote in message

>>"Shayne Wissler" <thal...@yahoo.com> wrote:
> >> And looking at them from another perspective requires that you
>>> first are aware of this fact. You can't even know what a valve is
>>> without knowing where it is and what role it plays.

>> An accountant may not have to know.

>Irrelevant. The primary fact is still the primary fact.

What's primary in one context is definitely not always primary in
every other context.

The fact of an object existing despite how we think about it is
significant philosophically. Still the significance of an object's
dimensions are rooted upon contextually relevancy.

Elliott
--
Ideas are proven by long term correspondence with validated contextual
practice.
--
Correctness is proven by long term success validated in contextual
practice

Shayne Wissler

unread,
Jan 23, 2002, 11:33:41 PM1/23/02
to

"Universe" <univ...@directvinternet.undocom> wrote in message
news:c32v4ucqnsl9supn3...@4ax.com...

> "Shayne Wissler" <thal...@yahoo.com> wrote:
>
> >"Topmind" <top...@technologist.com> wrote in message
>
> >>"Shayne Wissler" <thal...@yahoo.com> wrote:
> > >> And looking at them from another perspective requires that you
> >>> first are aware of this fact. You can't even know what a valve is
> >>> without knowing where it is and what role it plays.
>
> >> An accountant may not have to know.
>
> >Irrelevant. The primary fact is still the primary fact.
>
> What's primary in one context is definitely not always primary in
> every other context.
>
> The fact of an object existing despite how we think about it is
> significant philosophically. Still the significance of an object's
> dimensions are rooted upon contextually relevancy.

Either an object is there (in the software) or it isn't. And if it's there,
it's somewhere, i.e., standing in a certain relationship to other objects.
This is a primary; the starting point for an object-oriented software
system. The other aspects are merely aspects on this primary metaphysical
fact.

Topmind

unread,
Jan 24, 2002, 12:12:19 AM1/24/02
to
> > im=ImageCreateScannerResolutionColorspaceRectangle(300,RGB,rect);
> > WindowDrawImagePosition(w,im,pos);
> >
> > This is like a form of pseudocode. The simplest thing is to make
> > this pseudocode - and so your language - work. This is very simple
> > and very abstract and usually easy in PP but a PITA in OOP.
>
> Funny - I don't understand the first procedure call. From the name I would
> suspect that an image is asked to create a
> "ScannerResolutionColorspaceRectangle"; but I don't think that such a thing
> exists, and "im" seems to be an image...
>
> Additionally, I think Smalltalk reads much more natural for your second
> example:

>
> window draw: myImage at: imagePosition


Another procedural possibility:


draw(window #what myImage #at imagePosition)

OR

draw window #what myImage #at imagePosition


IOW, named parameters (or a mix). BTW, I *don't* claim that one
paradigm is necessarily more natural than another
(at least universal). It is the larger-scale modeling
and feature management abilities that seperate them
IMO, not the syntax expressability. (Just don't compare
C to Smalltalk.)


>
> Mhh, as I think about it, your first example probably was meant to mean:
>
> image = scanner getImageFromShape: aRectangle atResolution: 300
> usingColorSpace: RGB


>
> The trick is to read it as a request to the first object, so
>
> ilja getSerious: immediately
>
> translates to:
>
> "Ilja, get serious immediately!" :-)
>

> Regards, Ilja
>
>
>

Topmind

unread,
Jan 24, 2002, 12:27:31 AM1/24/02
to
>
> "Topmind" <top...@technologist.com> wrote in message
> news:4e705869.02012...@posting.google.com...
>
> > > > IMO, a good software engineer would hunt for objective, or at
> > > > least externally demonstratable ways to compare.
> > >
> > > So why is it objective to look at software from a non-software
> perspective?
> >
> > Huh? I did not say anything about "non-software". Counting
> > change-spots using a set of change-scenarios is "software
> > related", no?
>
> Perhaps I don't know what you mean by "externally demonstratable".
>
> > > > Would you venture to try to measure, or at least comparitively
> > > > illustrate "correct way to build"?
> > >
> > > What do you mean by "measure"? Have you measured such things? How do you
> > > prove that your standard of measurement is right?
> >
> > There will never be 100% "proof" in this business. But every
> > respectable metric does not show OOP objectively (or at
> > least externally demonstratably) better.
>
> I don't believe in metrics.


Then we have *only* feelings, yelling, fads, and appeals to authorities
to settle decisions about which paradigms to bash and discredit so
that they disappear?

If something is significantly better, then it's benefits
*are* going to be demonstratable.


>
> > These would include metrics like code size (token counts)
> > and change-scenario impact analyses.
>
> IMO, these studies are so much subject to other factors that they are
> meaningless when it comes to comparing languages.
>

And the alternative?

>
> > > Well, your examples prove my point. Regardless of how you want to look
> at
> > > it, the valves ARE in a given part of the car.
> >
> > And no matter how you look at it, they are a cost item to accountants,
> > a materials consumer to manufacturer of the part and weight analysts,
> > etc.
>
> I don't dispute the other perspectives. I argue that there is a fundamental
> one. The thing IS somewhere. Everything else depends on that primary fact.

I disagree.

>
> > IOW, parts are lot of different things. In my domain,
> > any entity instance may be viewed and accessed from
> > all kinds of different perspectives, many not forseeable
> > up front. Thus, I don't hard-wire any one viewpoint
> > into my model. This is where OOP often goes wrong IMO.
>
> Well, you're missing the point.
>
> But I don't blame you; I'm not a big fan of most OO approaches I've seen.


People tend to select the approaches that best fit the
way they view the world and how the world changes, in my
observation.


>
> > > And looking at them from
> > > another perspective requires that you first are aware of this fact. You
> > > can't even know what a valve is without knowing where it is and what
> role it
> > > plays.
> >
> > An accountant may not have to know.
>
> Irrelevant. The primary fact is still the primary fact.


And what is your criteria for determining "primary"?


>
> > > > Relational modeling better manages and simplifies supplying
> > > > multiple viewpoints of nodes. IOW, has-a view instead of
> > > > is-a.
> > >
> > > I think the has-a view is more important than the is-a view. Is that
> what
> > > you're saying too?
> >
> > More flexible.
>
> Please elaborate.


In my observation, is-a tends to "crown" one perspective at the
expense of others. If you don't know which perspectives will be
the most important down the road, then has-a is better optimized
for that. It is like those "aspect" graphs on my webpages.


>
> > > Then you're wrong. The need to inventory valves pressupposes that they
> exist
> > > somewhere to begin with.
> >
> > Yes. Existence is covered by both approaches.
>
> "Covered" isn't the issue. One aspect is more fundamental than the other.


Well, we have a fundamental disagreement here.


>
> > > I went to your website to try to understand what it was you were
> proposing.
> > > I couldn't understand. How about a small calculator application written
> in
> > > the style you prefer?
> > >
> >
> > I would generally not consider building a calculator typical of my
> > scope of fussing (custom biz apps). It is probably closer to the
> > systems software domain, or perhaps embedded systems domains. (I don't
> > claim my approach is the best for all domains. I have already
> > tentatively agreed that OOP may be better for writing device drivers.)
>
> So you don't think your approach would be good for building a simple
> calculator?


I don't know; I have insufficient experience doing such things.
I doubt my first try would be the optimum for may lang/paradigm.


>
> Why the hell are you arguing with OOPers when you don't have a solution
> yourself?


"Solution" is relative also, such as relative to domain I suspect.

In some domains, hard-wiring (optimizing) for a single perspective
may indeed be the better solution. Just not mine.


>
> --
> Shayne Wissler
>
> "The high-minded man must care more for the truth than for what people
> think." -- Aristotle
>
>

-T-

Topmind

unread,
Jan 24, 2002, 12:38:44 AM1/24/02
to

Interesting.

>
> > > > Perhaps because the state management (data tables)
> > > > have to generally be agreed upon first in p/r?
> > >
> > > Now I don't know, what you mean.
> >
> > The entity structuring effort is generally seperate
> > from dividing up of tasks.
>
> Ok, you talk about management.
>
> > > > Whether this is good or bad probably depends on how tightly one
> > > > feels that data and and "its" operations should be coupled.
> > > > OOP thinking generally assumes a tighter relationship (or assumes it
> > > > is more important) than procedural/relational (p/r) programming.
> > >
> > > This is surely true. OOP typically binds more methods to an object
> > > than necessary, because its feels "right" to do so. PP makes objects
> > > easier to extend, because of higher (procedural) granularity.
> >
> > By "higher" do you mean "smaller"?
>
> Yes, sorry. OOP has a deficiency with respect to granularity.


Well, we have a mutual agreement there. It is Summary Point
Number 3 on my webpage IIRC.


>
> > > > In p/r, the "state" tends to be assumed global, for good or bad.
> > > > (Global state models the real world better IMO.)
> > >
> > > Usually you can both ways in OOP and PP.
> >
> > I suppose it depends on one's design philosophy.
>
> Yes, but there should be no need to stick to a certain philosophy.


IMO, some consistency is important for grok-ability. People
shift jobs too often to assume intimate optimization in
most cases. Mixing of diverse philosophies only should
be done if there is a significant gain, and OOP has not
shown that IMO.


Like I said, I don't necessarily believe in one-paradigm-fits-
all. I don't work in the commercial image processing biz,
so I don't have enuf experience to weigh things like
change probabilities for different features/aspects
there.


>
> > > > However, IMO good p/r makes different modeling assumptions,
> > > > which generally are not easier to impliment under OOP.
> > >
> > > You typically have more freedom in p/r.
> > > But p/r hurts, *if* you need inheritance or polymorphism.
> >
> > Which, I find I don't in the domain of custom biz apps.
> > Mutually-exclusive divisions into "types" usually is not
> > very flexible. If you know of any decent division examples,
> > then can I ask for an outline/list of them?
>
> This is database-centric. I don't see any need for inheritance or
> polymorphism there. Anything should be in the data.
>
> > > But if you write
> > > error=CustomerByNameDeleteAllData("Xyz Smith");
> > > then you need not know or care about whether this is implemented
> > > by using some kind of objects or a plain SQL statement or no
> > > database at all. It would feel like using Assembler to write more
> > > than just this single (or a similar) procedure call.
>
> I think that programming is not about "using languages" but
> "creating languages".


Yes. But note that everybody will communicate with
themselves in different ways. Conventions that I
dig, others will complain about.

Helmut Leitner

unread,
Jan 24, 2002, 2:10:50 AM1/24/02
to

Topmind wrote:
> > > > > Perhaps because the state management (data tables)
> > > > > have to generally be agreed upon first in p/r?
> > > >
> > > > Now I don't know, what you mean.
> > >
> > > The entity structuring effort is generally seperate
> > > from dividing up of tasks.
> >
> > Ok, you talk about management.
> >
> > > > > Whether this is good or bad probably depends on how tightly one
> > > > > feels that data and and "its" operations should be coupled.
> > > > > OOP thinking generally assumes a tighter relationship (or assumes it
> > > > > is more important) than procedural/relational (p/r) programming.
> > > >
> > > > This is surely true. OOP typically binds more methods to an object
> > > > than necessary, because its feels "right" to do so. PP makes objects
> > > > easier to extend, because of higher (procedural) granularity.
> > >
> > > By "higher" do you mean "smaller"?
> >
> > Yes, sorry. OOP has a deficiency with respect to granularity.
>
> Well, we have a mutual agreement there. It is Summary Point
> Number 3 on my webpage IIRC.

Could you give me the link?



> > > > > In p/r, the "state" tends to be assumed global, for good or bad.
> > > > > (Global state models the real world better IMO.)
> > > >
> > > > Usually you can both ways in OOP and PP.
> > >
> > > I suppose it depends on one's design philosophy.
> >
> > Yes, but there should be no need to stick to a certain philosophy.
>
> IMO, some consistency is important for grok-ability.

Consistency is IMO not a philosophy but a necessity.

> People shift jobs too often to assume intimate optimization in
> most cases. Mixing of diverse philosophies only should
> be done if there is a significant gain, and OOP has not
> shown that IMO.

What do you mean by "mixing of philosphies" and what languages
do you have in mind?

There are many other areas that are not database-centric.
Any kind of text-processing, large parts of scientific computing,
game programming, ...

Do you mean that OOP usually creates systems that are
- hard to change?
- hard to extend?
- hard to maintain?
- hard to understand?
because they
- lack simplicity?
- lack consistency?
- lack flexibility?
and
- enforce their way of thinking?

> > I think that programming is not about "using languages" but
> > "creating languages".
>
> Yes. But note that everybody will communicate with
> themselves in different ways. Conventions that I
> dig, others will complain about.

Then we should seek for a common language - as always.

I have described parts of such a language in WardsWiki.

But the concrete syntax is unimportant, its unimportant
whether we communicate in English, German or Chinese as
long as we have a common language and use it according
to its rules. Programming needs its own language.

Shayne Wissler

unread,
Jan 24, 2002, 2:59:55 AM1/24/02
to

"Topmind" <top...@technologist.com> wrote in message
news:MPG.16b93c42...@news.earthlink.net...

> > > There will never be 100% "proof" in this business. But every
> > > respectable metric does not show OOP objectively (or at
> > > least externally demonstratably) better.
> >
> > I don't believe in metrics.
>
> Then we have *only* feelings, yelling, fads, and appeals to authorities
> to settle decisions about which paradigms to bash and discredit so
> that they disappear?
>
> If something is significantly better, then it's benefits
> *are* going to be demonstratable.

I didn't say I didn't believe in demonstration or evidence. But statistics
aren't a substitute for causality. And that's all metrics are. Mere
statistics.

> > > These would include metrics like code size (token counts)
> > > and change-scenario impact analyses.
> >
> > IMO, these studies are so much subject to other factors that they are
> > meaningless when it comes to comparing languages.
> >
> And the alternative?

Principles. E.g., the argument we're having below leads to certain language
implications.

> > > > Well, your examples prove my point. Regardless of how you want to
look
> > at
> > > > it, the valves ARE in a given part of the car.
> > >
> > > And no matter how you look at it, they are a cost item to accountants,
> > > a materials consumer to manufacturer of the part and weight analysts,
> > > etc.
> >
> > I don't dispute the other perspectives. I argue that there is a
fundamental
> > one. The thing IS somewhere. Everything else depends on that primary
fact.
>
> I disagree.

That's that eh? No rationale, just "I disagree"?

> > > IOW, parts are lot of different things. In my domain,
> > > any entity instance may be viewed and accessed from
> > > all kinds of different perspectives, many not forseeable
> > > up front. Thus, I don't hard-wire any one viewpoint
> > > into my model. This is where OOP often goes wrong IMO.
> >
> > Well, you're missing the point.
> >
> > But I don't blame you; I'm not a big fan of most OO approaches I've
seen.
>
> People tend to select the approaches that best fit the
> way they view the world and how the world changes, in my
> observation.

Then what's the purpose of this discussion?

> > Irrelevant. The primary fact is still the primary fact.
>
> And what is your criteria for determining "primary"?

That on which everything else depends. The existence of an entity has
primacy over its aspects or attributes. A blue car--"blue" is an attribute;
it would have no existence without the car that it is an attribute of. A
speeding car--"speed" is an attribute, a way of looking at the car; without
the car, there would be no speed; without speed, the car is there, it's just
standing still.

Is it really that complicated, or are you just trying to be argumentative?

> > > Yes. Existence is covered by both approaches.
> >
> > "Covered" isn't the issue. One aspect is more fundamental than the
other.
>
> Well, we have a fundamental disagreement here.

If all you're going to do is disagree without justification and assert your
opinion, then I don't care to have this discussion with you. Now, "put up or
shut up", as it were.

> > So you don't think your approach would be good for building a simple
> > calculator?
>
> I don't know; I have insufficient experience doing such things.
> I doubt my first try would be the optimum for may lang/paradigm.

Well, if that's the case, then I think you have a lot of gall telling people
that OO sucks. You should educate yourself on the big picture before you
start preaching about a new paradigm (and I think I'm being very easy on
you: a calculator app is the most trivial program I could think of).

Warren R. Zeigler

unread,
Jan 24, 2002, 8:55:50 AM1/24/02
to
Your same garbage.

Yes, entities (objects) can be stored offline and accessed P/r.

Why not add to your repeater, allowing them to be expressed in memory as
well?

NO NO NO!!! I CAN"T DO OBJECTS!!!!! - That's all we hear!

Sad.

--
Warren R. Zeigler
Understanding Objects - The class people have been looking for - even if
they don't know it.
www.UnderstandingObjects.com

"Topmind" <top...@technologist.com> wrote in message

news:MPG.16b7f8681...@news.earthlink.net...

Warren R. Zeigler

unread,
Jan 24, 2002, 9:32:10 PM1/24/02
to
"repeater" was a spellchecker mess-up. Try repertoire

--
Warren R. Zeigler
Understanding Objects - The class people have been looking for - even if
they don't know it.
www.UnderstandingObjects.com

"Warren R. Zeigler" <wzei...@UnderstandingObjects.com> wrote in message
news:cnU38.723$7Y6.2...@news.uswest.net...

Topmind

unread,
Jan 24, 2002, 10:45:28 PM1/24/02