Does OOP assume something about human nature? [T]
Topmind
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
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
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
>
> 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
> 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
Helmut Leitner
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
>
> 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
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
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
> >
> > "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
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
>"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
>
> 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
> "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
> 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
>
> >"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
> > > 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
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
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
>> "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
> 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
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
> 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
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
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
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
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
>
> 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
> 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
> "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
> > 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
> 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
> 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
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
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
>> 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
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
> >
> > "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
>
>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
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
> "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
> > > 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
>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
>"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
"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
> > 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.
>
> 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
> "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
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
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
> > > 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
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
--
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
>
> Yes, entities (objects) can be stored offline and accessed P/r.
Anything is possible. Whether it makes things better or not is
another matter.
Show me how it makes things better for developers/maintainers,
and I might buy into it.
>
> Why not add to your [repertoire] allowing them to be expressed in memory as
Topmind
> "repeater" was a spellchecker mess-up. Try repertoire
>
Too much Morph in your Poly?
_______________
Topmind
> "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.
I genernally agree. For example, change-scenario impact analysis
involves a (assumed) random sample of change scenarios. But most
industrial metrics are the same thing: a series of tests that attempt
to mirror real-world conditions. Chip makers use benchmarks and user
scenerios for example, both of which more or less try to recreate
real-world usage situations. Fighter jet tests would probably also
have a suite of maneuvers to test, and so forth.
>
> > > > 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.
Okay, but in practice these usually lead into messy philosophical
discussions. Often people over-focus on one principle, ignoring
others. IOW, "pet principles". It takes the pavement of realistic, or
at least semi-realistic settings to filter out extremism IMO.
>
> > > > > 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"?
I don't see the heavy dependence that you (allegedly) do.
Please provide more evidence that there is such a
heavy dependence.
>
> > > > 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?
To find out what the base assumptions are
among those with differing opinions, and then
to explore those further.
>
> > > 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?
Like I said, most models *would* involve the existence of the car.
But,
that is not what you were talking about. You were talking about the
physical relationships between the parts in the car being the
*primary* relationship, and proposed that any software model
reflect this *above* all else (as I interpreted your stance).
>
> > > > 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.
More precisely, OOP is overhyped and is thus spreading into
areas where it probably does not belong. I never said it
belongs nowhere. It is in a bubble state, just like the
dot-coms were. It needs a little deflating.
> 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).
I don't think *any* human has a "big picture". We only live one life
and nobody has time to explore every domain long enough to be the
ultimate authority on the ultimate paradigm for everything.
I would also note that most OOP fans appear to not be in the same
domain as I am. This suggests something.
-T-
Shayne Wissler
> > 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.
>
> I genernally agree. For example, change-scenario impact analysis
> involves a (assumed) random sample of change scenarios. But most
> industrial metrics are the same thing: a series of tests that attempt
> to mirror real-world conditions. Chip makers use benchmarks and user
> scenerios for example, both of which more or less try to recreate
> real-world usage situations. Fighter jet tests would probably also
> have a suite of maneuvers to test, and so forth.
None of these things are comparable to language design.
> > > > > 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.
>
> Okay, but in practice these usually lead into messy philosophical
> discussions. Often people over-focus on one principle, ignoring
> others. IOW, "pet principles". It takes the pavement of realistic, or
> at least semi-realistic settings to filter out extremism IMO.
And here we are at the real root of the problem. Yes, indeed they do get
"messy". Just about as messy as things are when they get messed up by bad
philosophy.
> I don't see the heavy dependence that you (allegedly) do.
> Please provide more evidence that there is such a
> heavy dependence.
I'm not sure how to spell it out any more clearly. You can't see that a
thing's existence is presupposed by every statement about it? There isn't a
"heavy dependence"; there's a total dependence.
> > > > 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?
>
> Like I said, most models *would* involve the existence of the car.
> But,
> that is not what you were talking about. You were talking about the
> physical relationships between the parts in the car being the
> *primary* relationship, and proposed that any software model
> reflect this *above* all else (as I interpreted your stance).
If the piston isn't there, it doesn't do a lot of good to talk about its
weight, age, type, etc. So yes, the existence of a thing has primacy over
everything else.
> I don't think *any* human has a "big picture". We only live one life
> and nobody has time to explore every domain long enough to be the
> ultimate authority on the ultimate paradigm for everything.
It sounds to me like you are anti-philosophical. Again, not a good position
for someone arguing against OO. I guess you're just reacting against less
opportunity for you in your domain then, and all the talk is just talk.
Shayne Wissler
Universe
>I would also note that most OOP fans appear to not be in the same
>domain as I am. This suggests something.
You're out of it.
Elliott
--
Holistic Methods & Simulationist Design: Better Systems For the People
Topmind
>
> >I would also note that most OOP fans appear to not be in the same
> >domain as I am. This suggests something.
>
> You're out of it.
Good thing you are here to fix me.
Topmind
>
> "Topmind" <top...@technologist.com> wrote in message
> news:4e705869.02012...@posting.google.com...
>
> > > 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.
> >
> > I genernally agree. For example, change-scenario impact analysis
> > involves a (assumed) random sample of change scenarios. But most
> > industrial metrics are the same thing: a series of tests that attempt
> > to mirror real-world conditions. Chip makers use benchmarks and user
> > scenerios for example, both of which more or less try to recreate
> > real-world usage situations. Fighter jet tests would probably also
> > have a suite of maneuvers to test, and so forth.
>
> None of these things are comparable to language design.
I am not sure what you are getting at.
>
> > > > > > 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.
> >
> > Okay, but in practice these usually lead into messy philosophical
> > discussions. Often people over-focus on one principle, ignoring
> > others. IOW, "pet principles". It takes the pavement of realistic, or
> > at least semi-realistic settings to filter out extremism IMO.
>
> And here we are at the real root of the problem. Yes, indeed they do get
> "messy". Just about as messy as things are when they get messed up by bad
> philosophy.
"Bad" philosophy is usually defined as "not thinking like me".
I used to think my fav programming and SE approaches were
universally the best. However, I have grown to conclude that
it is generally subjective. Our software models tend to
end up modeling our personal views of the world. IOW,
we are micro-gods when it comes to software. We
create worlds in our head's image.
>
> > I don't see the heavy dependence that you (allegedly) do.
> > Please provide more evidence that there is such a
> > heavy dependence.
>
> I'm not sure how to spell it out any more clearly. You can't see that a
> thing's existence is presupposed by every statement about it? There isn't a
> "heavy dependence"; there's a total dependence.
I am sorry, but I don't. Perhaps I have been tainted by the
virtual relationships created by relational philosophy such
that I stopped looking for a physical base. The physical
is only one of many views of any given element.
>
> > > > > 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?
> >
> > Like I said, most models *would* involve the existence of the car.
> > But,
> > that is not what you were talking about. You were talking about the
> > physical relationships between the parts in the car being the
> > *primary* relationship, and proposed that any software model
> > reflect this *above* all else (as I interpreted your stance).
>
> If the piston isn't there, it doesn't do a lot of good to talk about its
> weight, age, type, etc. So yes, the existence of a thing has primacy over
> everything else.
I am thinking in software terms, not
(just) mechanics terms. An accountant
will have a different view of things than the physical engineers.
However, accounting is just as important; for if each cylinder
costs $800.00 to aquire, then you could not market such a
car EVEN if the cyclinders and engine all worked.
>
> > I don't think *any* human has a "big picture". We only live one life
> > and nobody has time to explore every domain long enough to be the
> > ultimate authority on the ultimate paradigm for everything.
>
> It sounds to me like you are anti-philosophical.
I have my opinions, I just don't necessarily project those
onto everyone's else's neuron structure. Us table-heads deserve
just as many tools and research as OOP-heads.
> Again, not a good position
> for someone arguing against OO. I guess you're just reacting against less
> opportunity for you in your domain then, and all the talk is just talk.
>
Don't like talk? Then find some decent metrics.
Otherwise YOUR philosophical BS is no better than
my philosophical BS. We would get further talking
about sex, politics, and religion. Would you
rather talk about screwing the Pope in the
Lincoln bedroom?
>
> Shayne Wissler
>
-T-
Shayne Wissler
> Don't like talk? Then find some decent metrics.
> Otherwise YOUR philosophical BS is no better than
> my philosophical BS. We would get further talking
> about sex, politics, and religion. Would you
> rather talk about screwing the Pope in the
> Lincoln bedroom?
Yes. If you think philosophy is BS, then we have nothing important to talk
about. So we may as well shoot the breeze. But that's kind of hard on the
fingers, and since you probably don't live near here, let's just be on our
way.
Good luck.
Shayne
Paul Campbell
.
>
> 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.
To me an object model is a local optimisation, an artifact,
a convient way of viewing the entity for *that* system.
Many of the relationships will only be of concern to that
one system/application. No view is the "primary"
one in some absolute sence.
This is why object models do not make good enterprise wide
data stores.
Paul C.
Shayne Wissler
"Paul Campbell" <pncam...@bigfoot.nospam.com> wrote in message
news:a2u6ov$tlu$1...@news6.svr.pol.co.uk...
>
> "Shayne Wissler" <thal...@yahoo.com> wrote in message
> news:F8M38.2359$bP1....@rwcrnsc51.ops.asp.att.net...
> .
> >
> > 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.
>
> To me an object model is a local optimisation, an artifact,
> a convient way of viewing the entity for *that* system.
>
> Many of the relationships will only be of concern to that
> one system/application. No view is the "primary"
> one in some absolute sence.
Ah, but I'm not a modeler. For me, the main concern is the system I'm
building. When I say "has a has primacy", I'm not talking about the has a
hierarchy for the "real world". I'm talking about the software system
itself, its parts, qua machine, not how it's modeling something else.
Topmind
> "Shayne Wissler" <thal...@yahoo.com> wrote in message
> news:F8M38.2359$bP1....@rwcrnsc51.ops.asp.att.net...
> .
> >
> > 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.
>
> To me an object model is a local optimisation, an artifact,
> a convient way of viewing the entity for *that* system.
What if a system needs two views? Do you partition
your "system" by single views?
>
> Many of the relationships will only be of concern to that
> one system/application. No view is the "primary"
> one in some absolute sence.
Same issue, just at a smaller scale.
>
> This is why object models do not make good enterprise wide
> data stores.
>
> Paul C.
>
>
-T-
Topmind
> "Topmind" <top...@technologist.com> wrote in message
> news:MPG.16bbd0b38...@news.earthlink.net...
>
> > Don't like talk? Then find some decent metrics.
> > Otherwise YOUR philosophical BS is no better than
> > my philosophical BS. We would get further talking
> > about sex, politics, and religion. Would you
> > rather talk about screwing the Pope in the
> > Lincoln bedroom?
>
> Yes. If you think philosophy is BS, then we have nothing important to talk
> about.
I am just saying that it should be *backed* by something
more imperical. IOW, one cannot determine benefits by
the philosophy alone. The philosophy gives you new ways
to look at things and maybe new ways to test, but
Philosophy != Metric
> So we may as well shoot the breeze. But that's kind of hard on the
> fingers, and since you probably don't live near here, let's just be on our
> way.
>
> Good luck.
>
>
> Shayne
>
>
-T-
Universe
>I am just saying that it should be *backed* by something
>more imperical. IOW, one cannot determine benefits by
>the philosophy alone. The philosophy gives you new ways
>to look at things and maybe new ways to test, but
>
>Philosophy != Metric
Right. We need both *and* more! But we do *need* them all in
approaching and utilizing OO software engineering and the OO modelling
abstraction paradigm generally.
Philosophy is key, not the sole factor, to comprehending the "big
picture". The "big picture", for the most part, should guide and lead
us in virtually everything we do in life.
Elliott
--
XP: Gutter Programming for Moneybags and Wannabags!
Topmind
>
> >I am just saying that it should be *backed* by something
> >more imperical. IOW, one cannot determine benefits by
> >the philosophy alone. The philosophy gives you new ways
> >to look at things and maybe new ways to test, but
> >
> >Philosophy != Metric
>
> Right. We need both *and* more! But we do *need* them all in
> approaching and utilizing OO software engineering and the OO modelling
> abstraction paradigm generally.
>
> Philosophy is key, not the sole factor, to comprehending the "big
> picture". The "big picture", for the most part, should guide and lead
> us in virtually everything we do in life.
Perhaps there is NO big picture when modeling. It is how we put
the little pictures together that matters. I try to make the
relations between things formula-controlled, rather than hard-wired
into the larger-scale code structure. In my philosophy, this
makes things more change-friendly because relationship changes
don't disrupt the bigger picture.
>
> Elliott
> --
> XP: Gutter Programming for Moneybags and Wannabags!
>
> ______________________________________________________________________
> 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
>
>
-T-
@objectmentor.com Robert C. Martin
<pncam...@bigfoot.nospam.com> wrote:
>To me an object model is a local optimisation, an artifact,
>a convient way of viewing the entity for *that* system.
>
>Many of the relationships will only be of concern to that
>one system/application. No view is the "primary"
>one in some absolute sence.
>
>This is why object models do not make good enterprise wide
>data stores.
I agree with this view. Object models are local because they are tied
more to behavior than to data. The relationships between objects are
relationships supported by the behaviors of particular applications.
Thus each application requires a different set of relationships.
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
Paul Campbell
>
> "Paul Campbell" <pncam...@bigfoot.nospam.com> wrote in message
> news:a2u6ov$tlu$1...@news6.svr.pol.co.uk...
> >
> > "Shayne Wissler" <thal...@yahoo.com> wrote in message
> > news:F8M38.2359$bP1....@rwcrnsc51.ops.asp.att.net...
> > .
> > >
> > > 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.
> >
> > To me an object model is a local optimisation, an artifact,
> > a convient way of viewing the entity for *that* system.
> >
> > Many of the relationships will only be of concern to that
> > one system/application. No view is the "primary"
> > one in some absolute sence.
>
> Ah, but I'm not a modeler. For me, the main concern is the system I'm
> building.
Yes the but the concern of the business people funding your system
will be what else (outside your system) they can use that data for.
This is a natural thing for them to do because data is often a modern
businesses most valueable asset.
Objects might be a usefull abstraction for us but the wider business
will just want the data. And they want it in a form where they can just plug
some off the shelf reporting tools in (as a minimum usually). Often data
that starts out life "belonging" to a particular system, will end up being
adopted by other systems and so things like system specific containment
hierarchies will not be welcome.
Also to clarify I use the term "model" to mean a description using OO
terminology and not to imply say specific an analysis model.
Paul C.
Paul Campbell
> >
> > "Shayne Wissler" <thal...@yahoo.com> wrote in message
> > news:F8M38.2359$bP1....@rwcrnsc51.ops.asp.att.net...
> > .
> > >
> > > 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.
> >
> > To me an object model is a local optimisation, an artifact,
> > a convient way of viewing the entity for *that* system.
>
>
> What if a system needs two views? Do you partition
> your "system" by single views?
Possibly.
I know what your driving at here: that surely is infact no place at all
for object modelling (vs relational data modelling) were there is any
possibility
of multiple users (in terms of systems or even sub-systems) of the data.
However the "opposing force" is the sheer usefulness of a more
behavour oriented model in *some* types of application.
There are certainly a whole host of ways of cutting up the system
and making the inevitable compromises. I would say though that
where the tradeoffs are fairly balanced I usually err on the
relational side.
And hey youve aready got me favouring attribute tables over inheritance
for appropriate domain problems - your going to have to work harder
to get me to totally abandon OO :P.
Paul C.
Topmind
> <pncam...@bigfoot.nospam.com> wrote:
>
> >To me an object model is a local optimisation, an artifact,
> >a convient way of viewing the entity for *that* system.
> >
> >Many of the relationships will only be of concern to that
> >one system/application. No view is the "primary"
> >one in some absolute sence.
> >
> >This is why object models do not make good enterprise wide
> >data stores.
>
> I agree with this view. Object models are local because they are tied
> more to behavior than to data. The relationships between objects are
> relationships supported by the behaviors of particular applications.
> Thus each application requires a different set of relationships.
So you are suggesting that OO needs a middle-level division
known as an "application"?
>
>
> 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
>
-T-
Topmind
Well, I would just like more solid descriptions and examples and
analysis of when to use one over the other. Like I said,
the maintainers are going to have to be sufficiently versed
on both paradigms if you mix. Unless the benefits of mixing
are significant, it would be better to perfect the techniques
and tools for just one.
If one OOP fan says to use p/r on part A and OO on part B, but
another fan says the opposite, then it seems reasonable to
conclude that p/r would be just fine for either part.
IOW, the lack of concensus about when to use what
suggests that mixing is not getting you much.
Consistency also has rewards of its own. For example,
there may be a set of utilities that are geared to
work with the p/r stuff, but cannot be used (as-is)
for the OO stuff. Thus, you may either have to
re-invent the wheel for the OO side, or do without.
The image that comes to mind is a half-rotary
and a half-cylider car engine.
>
> Paul C.
>
-T-
Topmind
>
> 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?
http://geocities.com/tablizer/oopbad.htm
>
> > > > > > 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.
I guess I would have to see an example at this point.
>
> > 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?
Mixing of p/r design and OOP design. I didn't have a particular
language in mind.
As far as game programming, for speed and timing purposes, tables
may not be appropriate for the faster action games. However, I can
envision using tables for role-playing games. Tables seem ideal
for modeling and managing the "psychological parameters" of the
characters of the game, among other things.
>
> 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 don't know what you mean by the last one, but lets just
say that I have yet to see an instance of a custom business
application that was better than p/r for those.
> > > 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.
But then that language would not be optimized for
particular people and/or particular niches.
Businesses tend to have certain cultures, and tend to
pick organizational philosophies that fit these
cultures. IOW, one-size-fits-all has for the most
part been rejected. (Or, at least it comes and goes
in waves.)
If a biz can hire people who fit a certain profile,
then why not use a language/paradigm that fits that profile
also?
>
> 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.
I have also proposed my own pet language proposals,
but would rather not bring them up here, being
that I don't expect universal acceptance.
>
> --
> Helmut Leitner lei...@hls.via.at
> Graz, Austria www.hls-software.com
>
-T-
Topmind
>....
>
> > It's clear that you can do everything in OOP and PP, but PP is simpler and
> > more natural for the topmost abstractions.
>
> Yes, but it seems to me that we are talking about a level of abstraction
> that is more appropriate for describing requirements or engineering tasks.
> For the imlementation level it seems to lack structure. YMMV.
IMO this may be because in p/r you tend to define the structure
for a particular task. IOW, it is not a global structure, but
an as-needed structure. In practice this may take the form of
an SQL query that grabs and temporarily forms the relationships
that will be needed for a particular task.
IOW, ad-hoc or "virtual" structures.
The "big picture" structure may thus be flimsy because
it is assumed that a big-picture structure is over-design
and/or too specific a design.
OO seems to want to build structures, and then "automatically
ride" these structures; which I agree that it does relatively
well. Thus come sayings like "automatic dispatching".
However, the flaw in this is that structures are relative
to need. At least that is the working assumption I have,
based on obsveration and my experience.
>
> Regards, Ilja
>
>
-T-
Helmut Leitner
Topmind wrote:
> > > Well, we have a mutual agreement there. It is Summary Point
> > > Number 3 on my webpage IIRC.
> >
> > Could you give me the link?
>
> http://geocities.com/tablizer/oopbad.htm
Interesting. I have to study it a bit more, but I think
I agree on about 80% of your conclusions.
I dont't agree on chemistry. I once built an OO simulation
system for molecular simulations. It had 3 classes:
- (the whole) system (boundary conditions, temperature, ...)
- molecules (connected atoms)
- atoms (of all types)
No one in his right mind would ever construct an object
hierarchy for the chemical elements, even if they don't
change (as you argue).
I don't agree on your use of communism (not everything
that doesn't work can be meaningfully compared to it).
I don't agree on C (because if you are able to write good code
in C, then you will be able to write good code in any language).
> > > IMO, some consistency is important for grok-ability.
> >
> > Consistency is IMO not a philosophy but a necessity.
>
> I guess I would have to see an example at this point.
I said it is a necessity, not a reality.
Philosophy is most of the time a matter of taste or belief.
But to be inconsistent means to be unclear, means to be unprofessional.
> > > 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?
>
> Mixing of p/r design and OOP design. I didn't have a particular
> language in mind.
the refrain "OOP and tables don't fit, don't fit" :-) ?
> > > 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.
> >
> > There are many other areas that are not database-centric.
> > Any kind of text-processing, large parts of scientific computing,
> > game programming, ...
>
> As far as game programming, for speed and timing purposes, tables
> may not be appropriate for the faster action games. However, I can
> envision using tables for role-playing games. Tables seem ideal
> for modeling and managing the "psychological parameters" of the
> characters of the game, among other things.
But the tables don't need to be implemented as tables.
I think that what you mean by "tables" is what I call OOT (object
oriented thinking): Basically we think in objects and properties
of these objects, *but* that doesn't mean objects in the OOP sense.
There are many ways one can work with object:
- objects referenced by OIDs (pointers) (window.redraw() or WindowRedraw(w))
- objects in tables referenced by keys (CustomerByNameRetPhoneNumber("Topmind"))
- objects wherever referenced by names (FileByNameDelete("xy.txt"))
- objects with implicit references (SystemShutdown())
- ...
and most of these ways hurt if you use OOP because OOP enforces one
way to implement objects and one way to structure the namespace.
IMO the main point of attack to criticize OOP is to show that it
violates OO thinking and real world modelling in many, many ways.
I don't talk about programming languages. I talk about
consistency in thinking and naming procedures/methods.
> I have also proposed my own pet language proposals,
> but would rather not bring them up here, being
> that I don't expect universal acceptance.
Suppose, that would make a nice target :-)
Topmind
>
> Topmind wrote:
> > > > Well, we have a mutual agreement there. It is Summary Point
> > > > Number 3 on my webpage IIRC.
> > >
> > > Could you give me the link?
> >
> > http://geocities.com/tablizer/oopbad.htm
>
> Interesting. I have to study it a bit more, but I think
> I agree on about 80% of your conclusions.
>
> I dont't agree on chemistry. I once built an OO simulation
> system for molecular simulations. It had 3 classes:
> - (the whole) system (boundary conditions, temperature, ...)
> - molecules (connected atoms)
> - atoms (of all types)
> No one in his right mind would ever construct an object
> hierarchy for the chemical elements, even if they don't
> change (as you argue).
>
> I don't agree on your use of communism (not everything
> that doesn't work can be meaningfully compared to it).
I compare OOP to economic communism because both are
intellectually "catchy", but flounder under real
conditions. (Or at least don't beat alternatives.)
>
> I don't agree on C (because if you are able to write good code
> in C, then you will be able to write good code in any language).
But the other way around may not be true. C also lacks
named parameters and "nested" scope. Both of these
limitations can make life difficult.
>
> > > > IMO, some consistency is important for grok-ability.
> > >
> > > Consistency is IMO not a philosophy but a necessity.
> >
> > I guess I would have to see an example at this point.
>
> I said it is a necessity, not a reality.
> Philosophy is most of the time a matter of taste or belief.
> But to be inconsistent means to be unclear, means to be unprofessional.
Wouldn't that preclude mixing of too many paradigms?
>
> > > > 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?
> >
> > Mixing of p/r design and OOP design. I didn't have a particular
> > language in mind.
>
> the refrain "OOP and tables don't fit, don't fit" :-) ?
IMO, they don't. Their philosophy fights over too much
of the same territory. Two yins.
You don't need instantiation if you are adding records
instead, for example.
>
> > > > 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.
> > >
> > > There are many other areas that are not database-centric.
> > > Any kind of text-processing, large parts of scientific computing,
> > > game programming, ...
> >
> > As far as game programming, for speed and timing purposes, tables
> > may not be appropriate for the faster action games. However, I can
> > envision using tables for role-playing games. Tables seem ideal
> > for modeling and managing the "psychological parameters" of the
> > characters of the game, among other things.
>
> But the tables don't need to be implemented as tables.
Tabling is an *interface*, and not an implementation.
I have rarely seen the actual implementation.
>
> I think that what you mean by "tables" is what I call OOT (object
> oriented thinking): Basically we think in objects and properties
> of these objects, *but* that doesn't mean objects in the OOP sense.
But "OOT" is even harder to define than "OOP", which has proven to
be a bear.
>
> There are many ways one can work with object:
> - objects referenced by OIDs (pointers) (window.redraw() or WindowRedraw(w))
> - objects in tables referenced by keys (CustomerByNameRetPhoneNumber("Topmind"))
> - objects wherever referenced by names (FileByNameDelete("xy.txt"))
> - objects with implicit references (SystemShutdown())
> - ...
> and most of these ways hurt if you use OOP because OOP enforces one
> way to implement objects and one way to structure the namespace.
>
> IMO the main point of attack to criticize OOP is to show that it
> violates OO thinking and real world modelling in many, many ways.
But "matching the real world" is probably a minority opinion
WRT being the main goal.
Same difference IMO, just at a different scale.
>
> > I have also proposed my own pet language proposals,
> > but would rather not bring them up here, being
> > that I don't expect universal acceptance.
>
> Suppose, that would make a nice target :-)
Youch!
>
> --
> Helmut Leitner lei...@hls.via.at
> Graz, Austria www.hls-software.com
>
-T-
Helmut Leitner
Topmind wrote:
> > I don't agree on your use of communism (not everything
> > that doesn't work can be meaningfully compared to it).
>
> I compare OOP to economic communism because both are
> intellectually "catchy", but flounder under real
> conditions. (Or at least don't beat alternatives.)
You could improve your arguments by looking into the philosophy
of Karl Popper. He criticized communism, psychoanalysis, ...
very efficiently ("The open society and its enemies"). He showed,
that although consistent, they lack to make falsifiable predictions
about reality and thus immunize against critisism ("If XXX doesn't
work, you didn't apply it correctly").
> >
> > I don't agree on C (because if you are able to write good code
> > in C, then you will be able to write good code in any language).
>
> But the other way around may not be true. C also lacks
> named parameters and "nested" scope. Both of these
> limitations can make life difficult.
I don't argue that C is a competitive language (except in some niche).
But it would have been easy to extend it, hadn't C++ stopped all
development for a long time.
> > > > > IMO, some consistency is important for grok-ability.
> > > >
> > > > Consistency is IMO not a philosophy but a necessity.
> > >
> > > I guess I would have to see an example at this point.
> >
> > I said it is a necessity, not a reality.
> > Philosophy is most of the time a matter of taste or belief.
> > But to be inconsistent means to be unclear, means to be unprofessional.
>
> Wouldn't that preclude mixing of too many paradigms?
What is "too many"?
I know that I would like to have objects at hand - if I want them -
in procedural languages. I know, that I would like to have procedures
at hand in OO languages - without having to hide them somewhere.
> > > > > 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?
> > >
> > > Mixing of p/r design and OOP design. I didn't have a particular
> > > language in mind.
> >
> > the refrain "OOP and tables don't fit, don't fit" :-) ?
>
> IMO, they don't. Their philosophy fights over too much
> of the same territory. Two yins.
>
> You don't need instantiation if you are adding records
> instead, for example.
That's right.
> > > > > 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.
> > > >
> > > > There are many other areas that are not database-centric.
> > > > Any kind of text-processing, large parts of scientific computing,
> > > > game programming, ...
> > >
> > > As far as game programming, for speed and timing purposes, tables
> > > may not be appropriate for the faster action games. However, I can
> > > envision using tables for role-playing games. Tables seem ideal
> > > for modeling and managing the "psychological parameters" of the
> > > characters of the game, among other things.
> >
> > But the tables don't need to be implemented as tables.
>
> Tabling is an *interface*, and not an implementation.
> I have rarely seen the actual implementation.
Ok, but if you say "table" I hear "database" or "SQL". Is that wrong?
> > I think that what you mean by "tables" is what I call OOT (object
> > oriented thinking): Basically we think in objects and properties
> > of these objects, *but* that doesn't mean objects in the OOP sense.
>
> But "OOT" is even harder to define than "OOP", which has proven to
> be a bear.
I don't think the OO thinking is hard to define.
There is good OOP and bad OOP and the only way to separate this
is by learning to do OOT. This leads to a criticism of OOP systems.
> > There are many ways one can work with object:
> > - objects referenced by OIDs (pointers) (window.redraw() or WindowRedraw(w))
> > - objects in tables referenced by keys (CustomerByNameRetPhoneNumber("Topmind"))
> > - objects wherever referenced by names (FileByNameDelete("xy.txt"))
> > - objects with implicit references (SystemShutdown())
> > - ...
> > and most of these ways hurt if you use OOP because OOP enforces one
> > way to implement objects and one way to structure the namespace.
> >
> > IMO the main point of attack to criticize OOP is to show that it
> > violates OO thinking and real world modelling in many, many ways.
>
> But "matching the real world" is probably a minority opinion
> WRT being the main goal.
Programming is about "modelling the world" and interaction with that modell.
Everything else is just implementation detail, that should be avoided if possible.
Esp. in the topmost abstractions.
Topmind
>
> Topmind wrote:
> > > I don't agree on your use of communism (not everything
> > > that doesn't work can be meaningfully compared to it).
> >
> > I compare OOP to economic communism because both are
> > intellectually "catchy", but flounder under real
> > conditions. (Or at least don't beat alternatives.)
>
> You could improve your arguments by looking into the philosophy
> of Karl Popper. He criticized communism, psychoanalysis, ...
> very efficiently ("The open society and its enemies"). He showed,
> that although consistent, they lack to make falsifiable predictions
> about reality and thus immunize against critisism ("If XXX doesn't
> work, you didn't apply it correctly").
It is not so much how communism works (or doesn't), but how
and why so many intellectuals grasped on to it.
>
> > >
> > > I don't agree on C (because if you are able to write good code
> > > in C, then you will be able to write good code in any language).
> >
> > But the other way around may not be true. C also lacks
> > named parameters and "nested" scope. Both of these
> > limitations can make life difficult.
>
> I don't argue that C is a competitive language (except in some niche).
> But it would have been easy to extend it, hadn't C++ stopped all
> development for a long time.
Yeah, OOPL's froze p/r progress dead in it's tracks for the
most part.
>
> > > > > > IMO, some consistency is important for grok-ability.
> > > > >
> > > > > Consistency is IMO not a philosophy but a necessity.
> > > >
> > > > I guess I would have to see an example at this point.
> > >
> > > I said it is a necessity, not a reality.
> > > Philosophy is most of the time a matter of taste or belief.
> > > But to be inconsistent means to be unclear, means to be unprofessional.
> >
> > Wouldn't that preclude mixing of too many paradigms?
>
> What is "too many"?
>
> I know that I would like to have objects at hand - if I want them -
> in procedural languages. I know, that I would like to have procedures
> at hand in OO languages - without having to hide them somewhere.
I suppose it is too entrenched to exclude these days (like QWERTY).
I can only hope the hype dies down.
Well, close enough. But note that SQL is an interface. (And so
is ODBC.)
>
> > > I think that what you mean by "tables" is what I call OOT (object
> > > oriented thinking): Basically we think in objects and properties
> > > of these objects, *but* that doesn't mean objects in the OOP sense.
> >
> > But "OOT" is even harder to define than "OOP", which has proven to
> > be a bear.
>
> I don't think the OO thinking is hard to define.
> There is good OOP and bad OOP and the only way to separate this
> is by learning to do OOT. This leads to a criticism of OOP systems.
Well, agreement seems hard to come by in the OO community.
>
> > > There are many ways one can work with object:
> > > - objects referenced by OIDs (pointers) (window.redraw() or WindowRedraw(w))
> > > - objects in tables referenced by keys (CustomerByNameRetPhoneNumber("Topmind"))
> > > - objects wherever referenced by names (FileByNameDelete("xy.txt"))
> > > - objects with implicit references (SystemShutdown())
> > > - ...
> > > and most of these ways hurt if you use OOP because OOP enforces one
> > > way to implement objects and one way to structure the namespace.
> > >
> > > IMO the main point of attack to criticize OOP is to show that it
> > > violates OO thinking and real world modelling in many, many ways.
> >
> > But "matching the real world" is probably a minority opinion
> > WRT being the main goal.
>
> Programming is about "modelling the world" and interaction with that modell.
> Everything else is just implementation detail, that should be avoided if possible.
> Esp. in the topmost abstractions.
One can argue that software may transcend the real world, adding new
features to it to assist people in ways that manual processes could
not do so well due to their physical limitations. For example,
multiple indexes on a paper filing cabinet is not an easy thing
to do by hand.
>
> --
> Helmut Leitner lei...@hls.via.at
> Graz, Austria www.hls-software.com
>
-T-
Helmut Leitner
Topmind wrote:
> > Topmind wrote:
> > > > I don't agree on your use of communism (not everything
> > > > that doesn't work can be meaningfully compared to it).
> > >
> > > I compare OOP to economic communism because both are
> > > intellectually "catchy", but flounder under real
> > > conditions. (Or at least don't beat alternatives.)
> >
> > You could improve your arguments by looking into the philosophy
> > of Karl Popper. He criticized communism, psychoanalysis, ...
> > very efficiently ("The open society and its enemies"). He showed,
> > that although consistent, they lack to make falsifiable predictions
> > about reality and thus immunize against critisism ("If XXX doesn't
> > work, you didn't apply it correctly").
>
> It is not so much how communism works (or doesn't), but how
> and why so many intellectuals grasped on to it.
That's just was, what Popper talks about. He was himself a communist
at the age of 16 (in the vienna of 1918) for a short time and was
so shocked about his being intellectually trapped, that he started
to research and to develop his theories.
> > > > > > > IMO, some consistency is important for grok-ability.
> > > > > >
> > > > > > Consistency is IMO not a philosophy but a necessity.
> > > > >
> > > > > I guess I would have to see an example at this point.
> > > >
> > > > I said it is a necessity, not a reality.
> > > > Philosophy is most of the time a matter of taste or belief.
> > > > But to be inconsistent means to be unclear, means to be unprofessional.
> > >
> > > Wouldn't that preclude mixing of too many paradigms?
> >
> > What is "too many"?
> >
> > I know that I would like to have objects at hand - if I want them -
> > in procedural languages. I know, that I would like to have procedures
> > at hand in OO languages - without having to hide them somewhere.
>
> I suppose it is too entrenched to exclude these days (like QWERTY).
> I can only hope the hype dies down.
Amen.
> > > > > > > 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.
> > > > > >
> > > > > > There are many other areas that are not database-centric.
> > > > > > Any kind of text-processing, large parts of scientific computing,
> > > > > > game programming, ...
> > > > >
> > > > > As far as game programming, for speed and timing purposes, tables
> > > > > may not be appropriate for the faster action games. However, I can
> > > > > envision using tables for role-playing games. Tables seem ideal
> > > > > for modeling and managing the "psychological parameters" of the
> > > > > characters of the game, among other things.
> > > >
> > > > But the tables don't need to be implemented as tables.
> > >
> > > Tabling is an *interface*, and not an implementation.
> > > I have rarely seen the actual implementation.
> >
> > Ok, but if you say "table" I hear "database" or "SQL". Is that wrong?
>
> Well, close enough. But note that SQL is an interface. (And so
> is ODBC.)
Yes, but anything that could be transformed into a table may be seen
as a table just as well (e.g. a Windows registry, a hash table, a simple
array of structs ...).
> > > > I think that what you mean by "tables" is what I call OOT (object
> > > > oriented thinking): Basically we think in objects and properties
> > > > of these objects, *but* that doesn't mean objects in the OOP sense.
> > >
> > > But "OOT" is even harder to define than "OOP", which has proven to
> > > be a bear.
> >
> > I don't think the OO thinking is hard to define.
> > There is good OOP and bad OOP and the only way to separate this
> > is by learning to do OOT. This leads to a criticism of OOP systems.
>
> Well, agreement seems hard to come by in the OO community.
Who is seeking for agreement? :-)
> > > > There are many ways one can work with object:
> > > > - objects referenced by OIDs (pointers) (window.redraw() or WindowRedraw(w))
> > > > - objects in tables referenced by keys (CustomerByNameRetPhoneNumber("Topmind"))
> > > > - objects wherever referenced by names (FileByNameDelete("xy.txt"))
> > > > - objects with implicit references (SystemShutdown())
> > > > - ...
> > > > and most of these ways hurt if you use OOP because OOP enforces one
> > > > way to implement objects and one way to structure the namespace.
> > > >
> > > > IMO the main point of attack to criticize OOP is to show that it
> > > > violates OO thinking and real world modelling in many, many ways.
> > >
> > > But "matching the real world" is probably a minority opinion
> > > WRT being the main goal.
> >
> > Programming is about "modelling the world" and interaction with that modell.
> > Everything else is just implementation detail, that should be avoided if possible.
> > Esp. in the topmost abstractions.
>
> One can argue that software may transcend the real world, adding new
> features to it to assist people in ways that manual processes could
> not do so well due to their physical limitations. For example,
> multiple indexes on a paper filing cabinet is not an easy thing
> to do by hand.
You may use "filing cabinet" as a handy methaphor for the UI, but the software
doesn't model it.
The filing cabinet is already a model of the world. It may model employees.
These employees have many properties and only a few of them are put into the model.
The indexes are only an implementation detail providing faster access, they model nothing.
Helmut Leitner
Ilja Preuss wrote:
>
> > You could improve your arguments by looking into the philosophy
> > of Karl Popper. He criticized communism, psychoanalysis, ...
> > very efficiently ("The open society and its enemies"). He showed,
> > that although consistent, they lack to make falsifiable predictions
> > about reality and thus immunize against critisism ("If XXX doesn't
> > work, you didn't apply it correctly").
>
> How should falsifiable predicitions made by OOP look like?
>
> Which falsifiable predictions does PP make about reality?
These are interesting questions. If we aren't prepared to answer
them, this shows that we still have a long way to go.
My hint to Topmind was to improve his arguments by generalizing and
using a better framework (Popper instead of a communism analogy).
Helmut Leitner
Ilja Preuss wrote:
> > I know that I would like to have objects at hand - if I want them -
> > in procedural languages. I know, that I would like to have procedures
> > at hand in OO languages - without having to hide them somewhere.
>
> You don't have to hide them anywhere. C++ is a superset of C - you can write
> pure C programs in it.
IMHO C++ always was a unsound hybrid language. If we compare it to Java
we see how much low-level work has to be done in C++ to make objects work.
> And I have seen bunches of PP programs written in
> java - at least one of them written by myself. Hell, take a look at
> java.lang.Math, it's pure PP.
Yes, but isn't this the code rediculed by
"you can write FORTRAN in any language"
shamefully hidden as static procedures in a Math object?
And what mess if you have 5 projects extending Math in they own
private compartments of the namespace if you want to harvest
their reuseable code to grow a Math "extension library"
and refactor all projects accordingly!
I think that a lot of OO system (Java, Smalltalk, Lisp) are designed to
work as monolithical systems. They work extremely well for a single projects
in a static setting. But if you want to maximize reuse over multiple projects,
they are a step back compared to simple procedural libraries.
Graham Perkins
> IMHO C++ always was a unsound hybrid language.
Agreed.
> If we compare it to Java we see how much low-level work
> has to be done in C++ to make objects work.
I disagree. I've found that the only really important
thing missing in C++ is garbage collection. Bigger and
more standardised class libraries would help, but that's
not about making objects work in the first place.
With Java, we STILL have awkward separation between
primitive and class types. int/char/boolean etc. are
still not conformant with Object.
And we've LOST ability to control value/reference nature
of an object. Nor can we derive from more than one base
class or express a class generically, as we can in C++.
I find the C++ syntax a little opaque, but that is a
matter of practice and does not affect the level at which
one can work with objects.
> > And I have seen bunches of PP programs written in
> > java - at least one of them written by myself. Hell, take a look at
> > java.lang.Math, it's pure PP.
>
> Yes, but isn't this the code ridiculed by
> "you can write FORTRAN in any language"
> shamefully hidden as static procedures in a Math object?
Agreed. And snippety snip some other stuff which is entirely
reasonable and agreeable.
> I think that a lot of OO system (Java, Smalltalk, Lisp) are designed to
> work as monolithical systems. They work extremely well for a single projects
> in a static setting. But if you want to maximize reuse over multiple projects,
> they are a step back compared to simple procedural libraries.
I could argue the point here. But better still, perhaps you could
explain?
I can see how a lot of classes with loadsa statics and public
attributes would tend to limit the client languages you can use.
(since runtime object model would have to agree across client
and supplier). And this should be less of a problem with
procedural libraries since only primitive types and "handles"
are moved around.
But the situation can be reversed. A good class library can
encapsulate enough to remove need for compatible runtime object
model. And a bad procedural library will make many record
structures and language-specific types visible.
When you say multiple projects, do you mean with multiple
languages?
-------------+ http://www.gperkins.co.uk/
@objectmentor.com Robert C. Martin
<gper...@gperkins.co.uk> wrote:
>Helmut Leitner wrote:
>> IMHO C++ always was a unsound hybrid language.
>
>Agreed.
Oh, please! There is nothing unsound about C++. It's a perfectly
good langauge that has been put to a great deal of good use. The fact
that it has evolved over time does give it a kind of lumpy aspect. So
what? English is even lumpier.
C++ is no longer my language of choice. I have grown to be more
familiar with Java, and am happily exploring python and ruby. But my
most significant work was done in C++, and I was never sorry about
that choice.
Helmut Leitner
Ilja Preuss wrote:
>
> > I think that a lot of OO system (Java, Smalltalk, Lisp) are designed to
> > work as monolithical systems. They work extremely well for a single
> projects
> > in a static setting. But if you want to maximize reuse over multiple
> projects,
> > they are a step back compared to simple procedural libraries.
>
> I don't follow you. What is the key difference between a procedural library
> and a "pure static" class?
IMO there are two key differences with respect to reuse:
- granularity (procedure vs. class)
- namespace (none vs. package&class)
These differences create penalties for
- harvesting
- documenting
- learning
- using
reusable code within the OOP systems.
That does not mean that I prefer PP to OOP. I think that OO languages
are the better languages for software development in general.
But with respect to reuse they fall short.
My problem is that I am a reuse enthusiast.
Universe
> of Karl Popper. He criticized communism, psychoanalysis, ...
> very efficiently ("The open society and its enemies").
> He showed,
> that although consistent, they lack to make falsifiable predictions
> about reality and thus immunize against critisism ("If XXX doesn't
> work, you didn't apply it correctly").
That is *precisely* the defense many non-political people have very
well made about whatever.
Even more it does *not* make the focus non-falsifiable.
Non-falsifiability is about making Logically invalid propositions.
The primary basis of truth is correspondence with the facts of
experiment or long term practice. The truth about such facts may
stated in both validly or invalidly wrt Logic. Just as the untrue
things may spoken of validly or invalidly wrt Logic.
Elliott
--
XP: Can you say speedup for Mssr. Symantec MoneyBags?
Helmut Leitner
Graham Perkins wrote:
>
> Helmut Leitner wrote:
> > IMHO C++ always was a unsound hybrid language.
>
> Agreed.
>
> > If we compare it to Java we see how much low-level work
> > has to be done in C++ to make objects work.
>
> I disagree.
No problem, my "IMHO" should signal that I write
about personal opinion and preference.
> I've found that the only really important
> thing missing in C++ is garbage collection.
That's one big problem. Any modern language should have it.
> Bigger and
> more standardised class libraries would help
> but that's
> not about making objects work in the first place.
I agree, but this is not the language itself.
A bigger and better standard lib would help any language.
> With Java, we STILL have awkward separation between
> primitive and class types. int/char/boolean etc. are
> still not conformant with Object.
>
> And we've LOST ability to control value/reference nature
> of an object. Nor can we derive from more than one base
> class or express a class generically, as we can in C++.
I agree. Seems that C# has learned something from Java.
> I find the C++ syntax a little opaque, but that is a
> matter of practice and does not affect the level at which
> one can work with objects.
I can't count the C++ magazines and books about how to
use the language details correctly. In a way it seemed
as if programmers - after "centuries" of dull C/PP - liked
to go into complex puzzle solving.
> > I think that a lot of OO system (Java, Smalltalk, Lisp) are designed to
> > work as monolithical systems. They work extremely well for a single projects
> > in a static setting. But if you want to maximize reuse over multiple projects,
> > they are a step back compared to simple procedural libraries.
>
> I could argue the point here. But better still, perhaps you could
> explain?
I tried in an answer to Ilja yesterday.
Helmut Leitner
Universe wrote:
>
> > You could improve your arguments by looking into the philosophy
> > of Karl Popper. He criticized communism, psychoanalysis, ...
> > very efficiently ("The open society and its enemies").
>
> > He showed,
> > that although consistent, they lack to make falsifiable predictions
> > about reality and thus immunize against critisism ("If XXX doesn't
> > work, you didn't apply it correctly").
>
> That is *precisely* the defense many non-political people have very
> well made about whatever.
This is one of the easiest answers to critics.
> Even more it does *not* make the focus non-falsifiable.
> Non-falsifiability is about making Logically invalid propositions.
I don't know exactly what you mean...
I prefer "consistent" to "logically valid".
Inconsistent theories typically have little influence anyway.
> The primary basis of truth is correspondence with the facts of
> experiment or long term practice. The truth about such facts may
> stated in both validly or invalidly wrt Logic. Just as the untrue
> things may spoken of validly or invalidly wrt Logic.
I'm not sure that I understand you. One can arrive at some truth
just by guessing or by intuition if there are only a small number
of possibilities (greek philosophers about [not] atomic nature
of the world). But todays science and technology is so complex
and has to explain so many facts quantitatively (not by yes/no)
that only a consistent theory has a chance to do the job.
Helmut Leitner
"Robert C. Martin" wrote:
>
> On Wed, 30 Jan 2002 13:21:44 +0000, Graham Perkins
> <gper...@gperkins.co.uk> wrote:
>
> >Helmut Leitner wrote:
> >> IMHO C++ always was a unsound hybrid language.
> >
> >Agreed.
>
> Oh, please! There is nothing unsound about C++.
I surely don't want to argue with you about the word "unsound"
which I have put savely a short distance behind my "IMHO".
But:
I am often astonished that ...
"in our business complexity is not seen as a deficiency".
... I do.
IMO C++ is the group of complex languages (like PL/I and ADA)
and it will die very fast (within 20+ years) when C# hits.
The problem with OO languages is, that there is no real OO
or general programming language theory behind them. While the hype
goes "we are OO, the world is saved", in fact nothing has changed.
Languages are a pile of features and continue to develop
neither consistently nor towards an orthogonal goal.
Cagdas Ozgenc
> I surely don't want to argue with you about the word "unsound"
> which I have put savely a short distance behind my "IMHO".
>
> But:
> I am often astonished that ...
> "in our business complexity is not seen as a deficiency".
> ... I do.
>
> IMO C++ is the group of complex languages (like PL/I and ADA)
> and it will die very fast (within 20+ years) when C# hits.
>
> The problem with OO languages is, that there is no real OO
> or general programming language theory behind them. While the hype
> goes "we are OO, the world is saved", in fact nothing has changed.
> Languages are a pile of features and continue to develop
> neither consistently nor towards an orthogonal goal.
I presume, you are referring to C++ or Java per se. There are nice OO
languages in academia, which are based on solid theoretical work. To name
some, Haskell, O'Caml, Cecil are good examples. If you are looking for a
language that is full of BS, then C# is a good example. No one can claim
that, all those 70 something keywords they introduced to the language can be
explained through thoery. The aim was solely towards making everyone happy,
so they put together popular language constructs ending up similar to a
movie that I watched some time ago. The movie was originally in Russian.
Then they dubbed it into French to compete in Cannes movie fest, then it was
subtitled based on the French dub into Turkish when it hit the movies here
in Turkey.
Helmut Leitner
Ilja Preuss wrote:
>
> > > > You could improve your arguments by looking into the philosophy
> > > > of Karl Popper. He criticized communism, psychoanalysis, ...
> > > > very efficiently ("The open society and its enemies").
> > >
> > > > He showed,
> > > > that although consistent, they lack to make falsifiable predictions
> > > > about reality and thus immunize against critisism ("If XXX doesn't
> > > > work, you didn't apply it correctly").
> > >
> > > That is *precisely* the defense many non-political people have very
> > > well made about whatever.
> >
> > This is one of the easiest answers to critics.
>
> On the other hand, it may be the only one you know of, and it may
> nevertheless be correct.
>
> What can a cook say, confronted with a statement like "ligating sauces with
> butter doesn't work" except for "See, I have done this a thousand times, and
> it almost always worked. The times it didn't work I did something wrong. So
> with the time I learned to not do it wrong and what to do if I did it wrong
> again (and, of course, wich sauces not to apply it to). Cooks all over the
> world are doing this successfully. So I strongly suggest that it *will* work
> as soon as you learned how to do it right."
You are absolutely right,
"If XXX doesn't work, you didn't apply it correctly"
is not an invalid argument in itself.
To expand on the cook-example: it is not guaranteed, that a recipe tells
us everything we need to repeat it. Often there are details missing.
E. g. it took me 20 years of experience to repeat Austrian "Palatschinken" and to
refine the description of how to make them efficiently (they are a hybrid
between French "crepe" and US "pancakes"). The basic recipe is: mix eggs,
milk and flour and put it in the pan. The complete description I sent to
my son, who currently stays in NZ, is a full page of instructions.
When we immunize against criticism, we miss the chance to improve our
tools and our thinking.
Helmut Leitner
Cagdas Ozgenc wrote:
>
> > I surely don't want to argue with you about the word "unsound"
> > which I have put savely a short distance behind my "IMHO".
> >
> > But:
> > I am often astonished that ...
> > "in our business complexity is not seen as a deficiency".
> > ... I do.
> >
> > IMO C++ is the group of complex languages (like PL/I and ADA)
> > and it will die very fast (within 20+ years) when C# hits.
> >
> > The problem with OO languages is, that there is no real OO
> > or general programming language theory behind them. While the hype
> > goes "we are OO, the world is saved", in fact nothing has changed.
> > Languages are a pile of features and continue to develop
> > neither consistently nor towards an orthogonal goal.
>
> I presume, you are referring to C++ or Java per se.
They can serve as examples. But the "pile of features" fits
all other languages as well.
> There are nice OO languages in academia, which are based on solid
> theoretical work. To name some, Haskell, O'Caml, Cecil are good examples.
Maybe, but "solid theoretical work" is not the same as "a general theory".
Academical languages must typically concentrate on certain aspects of a
language to prove a point. So they are usually not fit for the market.
@objectmentor.com Robert C. Martin
<lei...@hls.via.at> wrote:
>IMO C++ is the group of complex languages (like PL/I and ADA)
>and it will die very fast (within 20+ years) when C# hits.
I think C# is just as complex as C++. It is just as irregular as C++,
if not moreso. That's not to say that I think C# is a bad language --
I don't. I just don't see it as a major improvement *linquistically*
over C++. *Environmentally* it is a huge improvement, but that has
little to do with the language itself.
Helmut Leitner
Ilja Preuss wrote:
>
> > > > I think that a lot of OO system (Java, Smalltalk, Lisp) are designed
> to
> > > > work as monolithical systems. They work extremely well for a single
> > > projects
> > > > in a static setting. But if you want to maximize reuse over multiple
> > > projects,
> > > > they are a step back compared to simple procedural libraries.
> > >
> > > I don't follow you. What is the key difference between a procedural
> library
> > > and a "pure static" class?
> >
> > IMO there are two key differences with respect to reuse:
> > - granularity (procedure vs. class)
>
> I don't see this difference: shouldn't it be either "procedure vs. static
> method" or "library vs. class"?
The smallest unit you can get out of a
- PP library is a procedure.
- OO library is a class.
If you add procedures to a PP library you will not automatically add them
to the footprint of all projects that use this libary.
If you add methods to a OO class you will automatically add them to the
footprint of all projects that use the class. And if any of the unused
methods of the class needs other (unneeded) procedures or classes they
will also add to the project.
So: in PP you can extend a library without adding it to all projects.
You can put a procedure to reuse without making others pay a penalty.
> On the other hand, granularity isn't the only quality influencing reuse.
> Some of the most usefull libraries will have dependencies between
> procedures.
A library may be "reuse", but typically a library is not "reuse".
Reuse starts when you write normal code that is general and useful
enough to be reused. How do you then make the reuse happen? How do you
develop a cultur of reuse? How does the code flow from the project
to the library? How is the refactoring done in the originating project
and in other projects?
> > These differences create penalties for
> > - harvesting
> What do you mean by this?
Constantly taking reusable code out of existing projects and adding
it to a "library repository" for reuse by current and future projects.
> > - learning
> Doesn't (for example) organizing in namespaces aid learning?
No. E.g. the 3500+ class-namespace of Java doesn't help learning.
@objectmentor.com Robert C. Martin
<lei...@hls.via.at> wrote:
>The problem with OO languages is, that there is no real OO
>or general programming language theory behind them.
I don't know what a general theory of programming languages would look
like.
>While the hype
>goes "we are OO, the world is saved", in fact nothing has changed.
I agree that the hype is nonsense. On the other hand, I think
something *has* changed. OO features are very useful for solving
problems that were nearly intractable in procedural languages.
For example, long long ago I had to break of a 35K 8080 program into
1K chunks because we burned that program onto thirty-five 2708
EEPROMS. We did not want to have to ship 35 eeproms every time we
changed the program, so I had to turn the program into 35 individually
compilable and deployable components.
I did this by using vector tables. Each component would register it's
functions in a vector table, and all functions were called through the
vector table. This was a giant pain in the neck to pull off; but was
incredibly valuable once complete.
An OO language would have done this automatically. None of the
slavish effort of building the vector tables, registering functions in
those tables, or calling functions through the tables would have been
necessary. The OO language would have built and managed the vector
tables for me.
>Languages are a pile of features and continue to develop
>neither consistently nor towards an orthogonal goal.
I think that's a pessimistic view. Rather I think that each new
programming language is an attempt to find a goal to move towards.
One or more of those attempts is going to find something.
@objectmentor.com Robert C. Martin
<helmut....@chello.at> wrote:
>
>The smallest unit you can get out of a
>- PP library is a procedure.
>- OO library is a class.
It is interesting to contemplate which of those two might be the
smaller. The smallest procedure you can have is one that does
nothing. However, even a procedure that does nothing has an
implementation. The smallest class you can have is an interface or
abstract class that has no implementation whatever.
>
>If you add procedures to a PP library you will not automatically add them
>to the footprint of all projects that use this libary.
>
>If you add methods to a OO class you will automatically add them to the
>footprint of all projects that use the class. And if any of the unused
>methods of the class needs other (unneeded) procedures or classes they
>will also add to the project.
Truth. This is why good OO designers dilligently practice dependency
management. Classes are not simply buckets for miscellaneous
functions, nor are they attractors for any and all marginally relevant
methods. Rather, a well designed class has only those methods needed
by the applications it lives in. Morevoer, good OO designers are
careful about transitive dependencies. They make use of interfaces
and abstract methods to ensure that applications do not haul in more
code than they need.
>
>So: in PP you can extend a library without adding it to all projects.
>You can put a procedure to reuse without making others pay a penalty.
This is true only of well designed procedures. A procedure of the
form:
if (app1) {do something specific for application1 1}
else if (app2) {do something specific for app 2}
...
*does* haul unwanted code into every application that uses it.
>
>Reuse starts when you write normal code that is general and useful
>enough to be reused.
Agreed.
>How do you then make the reuse happen? How do you
>develop a cultur of reuse? How does the code flow from the project
>to the library?
This does not happen automatically. Making something reusable is very
expensive. There must be a driving business need for the reuse,
otherwise it won't happen. If the drive is there, then the developers
will worth together to make it happen.
>How is the refactoring done in the originating project
>and in other projects?
Painfully. One of the costs of making reusable components is the
refactoring imposed upon the original users.
Topmind
> >So: in PP you can extend a library without adding it to all projects.
> >You can put a procedure to reuse without making others pay a penalty.
>
> This is true only of well designed procedures. A procedure of the
> form:
>
> if (app1) {do something specific for application1 1}
> else if (app2) {do something specific for app 2}
> ...
>
> *does* haul unwanted code into every application that uses it.
Dealing with things like this (above) is often messy in either
paradigm. If the differences are spotty, then subclassing
can get messy, especially if the granularity of the difference
does not match the granularity of the methods.
One good thing about the IF approach is that you can fairly
easily change the "actor" of the conditions. For example,
if you start shipping your app to
many companies and some clients want
branch 1 and others want branch 2, then it can be turned
into a configuration setting:
if (config.optionX) {do option X}
else {no option X}
Then if it later changes to being controlled by each
user setting:
if (user.optionX) {do option X}
else {no option X}
Changing the "rule conditions" to reference or use
a different entity(s) is fairly common.
I don't see how OOP pivots well on these. Especially
if multiple conditions are needed:
if (entity1.A or (entity2.B and entity3.C)) {do option X}
else {no option X}
Could somebody show me how OOP can be adaptable to such
without building a huge infrastructure to manage it?
-T-
Helmut Leitner
Ilja Preuss wrote:
>
> > Reuse starts when you write normal code that is general and useful
> > enough to be reused. How do you then make the reuse happen? How do you
> > develop a cultur of reuse? How does the code flow from the project
> > to the library? How is the refactoring done in the originating project
> > and in other projects?
>
> A recent example:
>
> There is a class JLabel in the Swing library of java (aka JFC). It's a gui
> component which just shows some text which can be changed programmatically
> (sp?). The problem is: Every time you change the text, the JLabel will
> adjust its preferred size, so that some LayoutManagers will adjust the
> layout of surrounding components to fit to it - which can lead to some
> fidgety design...
>
> The first time a colleague needed to fix this, she wrote a subclass of
> JLabel which simply reported a fixed (configurable) preferred size,
> independent of its content. Imagining that this class could be handy in
> other places, too, she moved it to the global util.swing package. Today,
> working on an other project, we again came across the annoying behaviour of
> JLabel - she remembered her class, we changed the instantiation of the label
> to use it and it worked instantly.
That's a good example how it may work in OOP.
But there important points:
- How much work was moving the class to the new package?
- If she hadn't remembered, would the class have been found?
> I don't have any experience with gui programming in PP languages. Perhaps
> you could explain how this would have worked out using PP?
You can't repair a broken OOP GUI using PP.
PP GUI frameworks usually mimic OOP GUI frameworks. A solution
may be similar or impossible.
> > > > These differences create penalties for
> > > > - harvesting
> > > What do you mean by this?
> >
> > Constantly taking reusable code out of existing projects and adding
> > it to a "library repository" for reuse by current and future projects.
>
> I still don't understand how PP makes this easier, sorry :-(
Typically you have 2-4 source changes for a procedure move in PP.
Typically you do the work across projects with
- a grep-like tool (search across projects)
- a normal text editor (you don't need a special refactoring tool)
> > > > - learning
> > > Doesn't (for example) organizing in namespaces aid learning?
> >
> > No. E.g. the 3500+ class-namespace of Java doesn't help learning.
>
> Perhaps I don't understand you here, again. Let me explain on an example why
> I think it does help:
>
> Say you want to sort some objects in a custom way. You already know of the
> collection api, so you look at java.util (or someone tells you to). There
> you find an interface with an interesting name: SortedSet. Might just be
> what you want - it has all the methods to put and get objects and so on. But
> how do they get sorted? The only implementation seems to be the TreeSet
> class; it has a constructor with a Comparator as parameter. Comparing is
> essentiell for sorting, so we probably have just to implement the compareTo
> method of this interface. If we would have read the API documentation, we
> would have known for sure...
>
> As I think of it, it defenitely makes communication simpler: "How do I sort
> my objects?" "Take a look at java.util.TreeSet." "Oh, right, thanx!" ;-)
If you have a common PP namespace, you might have a similar class and you
tell him: "Take a look at TreeSet", so you communicate 2 words instead of 4.
Helmut Leitner
"Robert C. Martin" wrote:
>
> On Thu, 31 Jan 2002 19:53:49 GMT, Helmut Leitner
> <helmut....@chello.at> wrote:
>
> >
> >The smallest unit you can get out of a
> >- PP library is a procedure.
> >- OO library is a class.
>
> It is interesting to contemplate which of those two might be the
> smaller. The smallest procedure you can have is one that does
> nothing. However, even a procedure that does nothing has an
> implementation. The smallest class you can have is an interface or
> abstract class that has no implementation whatever.
One could look at this statistically:
- The average procedure may be 3-10 lines (wild guess)
- The average class may be 10-20 methods (wild guess)
> >If you add procedures to a PP library you will not automatically add them
> >to the footprint of all projects that use this libary.
> >
> >If you add methods to a OO class you will automatically add them to the
> >footprint of all projects that use the class. And if any of the unused
> >methods of the class needs other (unneeded) procedures or classes they
> >will also add to the project.
>
> Truth. This is why good OO designers dilligently practice dependency
> management. Classes are not simply buckets for miscellaneous
> functions, nor are they attractors for any and all marginally relevant
> methods. Rather, a well designed class has only those methods needed
> by the applications it lives in.
>
> Morevoer, good OO designers are
> careful about transitive dependencies. They make use of interfaces
> and abstract methods to ensure that applications do not haul in more
> code than they need.
These are good principles that are rarely met.
> ...
> >Reuse starts when you write normal code that is general and useful
> >enough to be reused.
>
> Agreed.
>
> >How do you then make the reuse happen? How do you
> >develop a cultur of reuse? How does the code flow from the project
> >to the library?
>
> This does not happen automatically. Making something reusable is very
> expensive. There must be a driving business need for the reuse,
> otherwise it won't happen. If the drive is there, then the developers
> will worth together to make it happen.
>
> >How is the refactoring done in the originating project
> >and in other projects?
>
> Painfully. One of the costs of making reusable components is the
> refactoring imposed upon the original users.
Therefore it is critical to minimize the refactoring work and
the work surrounding the reuse situation.
There are a number of issues (assume multiple projects):
- Does a (similar) solution already exist? If yes, which
implementation is better? What can we learn?
- If it doesn't exist: Is the reusable code in a final
form or does it lack something? Must it be improved?
- Search for similar situations in other projects where
the reused code can be put to immediate use.
- Make the actual move, refactor your project
- Refactor the projects that can reuse the code.
- (it may be a bit more complicated because you may
have more places to put the reuse code, so you have
to decide on this too and handle situations where
you decide to move code from library_a to library_b)
In PP you can do this work with a decent editor and an
improved grep. You can't do the same with OOP because
method calls are not uniquely grep-searchable.
You would need special tools for OOP and I havn't yet
seen an OOP development system supporting such work
across multiple projects.
In PP a move from libary_a to library_b typically doesn't
involve refactoring at the project level. So there is
freedom in refactoring the libraries.
Helmut Leitner
"Robert C. Martin" wrote:
>
> On Thu, 31 Jan 2002 09:44:09 +0100, Helmut Leitner
> <lei...@hls.via.at> wrote:
>
> >The problem with OO languages is, that there is no real OO
> >or general programming language theory behind them.
>
> I don't know what a general theory of programming languages would look
> like.
It is interesting to me, that there seems to be none.
A general theory of programming language would have to unify our
language, what is
- a byte (C, rest of the world)
- a list (Lisp, Perl, Java)
- an array (C, Perl, Java, ...)
- many other ambiguous terms
It could unify our thinking about primitive types (similar to
what .NOT does) but including those types that make LISP or Perl
so outstanding useful in certain areas.
It could work towards modularizing language features.
- with or without GC
- with or without mutable objects
- with or without call by reference
- with or without goto
- with or without namespace
- with or without preprocessor
- with or without "flat" objects (detailed memory layout)
- away from the interpreter/p-code/JIT/native preselection
- ...
Why can't the project manager decide, that he wants
- Java
- without namespaces
- with call by reference
- without goto
- with preprocessor
- natively compiled
- ...
???
A theory could work towards reusable open source toolsets for language
implementation and the surrounding tools.
A theory could work towards "naming systems" to make libraries more
consistent and procedures/methods more reusable.
[This is where my heart is]
> >While the hype
> >goes "we are OO, the world is saved", in fact nothing has changed.
>
> I agree that the hype is nonsense. On the other hand, I think
> something *has* changed. OO features are very useful for solving
> problems that were nearly intractable in procedural languages.
I agree. I didn't mean that there where no improvements. OOP gave us
quite a number of definite improvements, but these improvements are not
without penalties. I see it as "7 steps forward, 3 steps back". YMMV.
> For example, long long ago I had to break of a 35K 8080 program into
> 1K chunks because we burned that program onto thirty-five 2708
> EEPROMS. We did not want to have to ship 35 eeproms every time we
> changed the program, so I had to turn the program into 35 individually
> compilable and deployable components.
>
> I did this by using vector tables. Each component would register it's
> functions in a vector table, and all functions were called through the
> vector table. This was a giant pain in the neck to pull off; but was
> incredibly valuable once complete.
>
> An OO language would have done this automatically.
You would get complete memory layout control by e. g. Java or C++ ?
BTW you would have needed a lot more than this 35 eeproms to hold
that increase in footprint. IMO it would have never worked.
> ...
> >Languages are a pile of features and continue to develop
> >neither consistently nor towards an orthogonal goal.
>
> I think that's a pessimistic view. Rather I think that each new
> programming language is an attempt to find a goal to move towards.
> One or more of those attempts is going to find something.
It may sound pessimistic, but it is not. I would have hoped that
languages would stabilize during my lifetime and that going from
C to C++ to Java meant going from 30% to 50% to 80% of an ideal
language. Now it seems more like going from 30% to 40% to 50%
with still a very long way to go.
@objectmentor.com Robert C. Martin
<helmut....@chello.at> wrote:
>> >How is the refactoring done in the originating project
>> >and in other projects?
>>
>> Painfully. One of the costs of making reusable components is the
>> refactoring imposed upon the original users.
>
>Therefore it is critical to minimize the refactoring work and
>the work surrounding the reuse situation.
A library will be reusable by others only to the extent that it can be
refactored to fit. If the original users put backpressure on that
refactoring, then the library will be less general.
We often hope that we can make a library generic by thinking it
through up front. Unfortunately this rarely works. The things that
make a library reusable are not nearly as foreseeable and plannable as
we might hope.