can i learn OOD without any procedural 1st
pandit
this is my very 1st post here. i don't know anything expect some Lisp,
one of my friends taught me Lisp.
i need to learn OOA-D 1st. so the question now is:
Can i learn OOA-D without learning Proecdural/Modular design 1st?
will that not handicap me?
( i am interested in C++, OOD & Templates and i do not want to learn C
1st, which is procedural. one of my friends, advised me to learn OOD
1st & then C++ but he has no idea on whether to learn procedural or
modular 1st as a solid-base of programming or OOD)
thanks
-- pandit
arnuld
you can read my post titled "struggling with design-paradigms".
BTW, i have also discussed the same with someone on my email. if you
want, i can send you the relevant email-communication.
pandit
yes, i read that one but it is ambiguous.
> BTW, i have also discussed the same with someone on my email. if you
> want, i can send you the relevant email-communication.
sure, if you can.
H. S. Lahman
> this is my very 1st post here. i don't know anything expect some Lisp,
> one of my friends taught me Lisp.
>
> i need to learn OOA-D 1st. so the question now is:
>
> Can i learn OOA-D without learning Proecdural/Modular design 1st?
>
> will that not handicap me?
It will not handicap you. In fact, it is a distinct advantage. The OO
paradigm is fundamentally different than the traditional procedural
approaches. One cannot mix & match the two. A major problem that
procedural developers have when they convert to the OO paradigm is that
they essentially need to forget everything they learned about procedural
development.
> ( i am interested in C++, OOD & Templates and i do not want to learn C
> 1st, which is procedural. one of my friends, advised me to learn OOD
> 1st & then C++ but he has no idea on whether to learn procedural or
> modular 1st as a solid-base of programming or OOD)
Your friend is correct. All of the OOPLs are 3GLs so they make
substantial compromises with the hardware computational models for
things like procedural block structuring, stack-based scope, and
procedural message passing. (That is especially true for C++.) As a
result it is very tempting to overlay procedural thinking on the OOPLs
because syntactically they are procedural languages with added abstract
constructs on top.
In addition, the procedural approaches are much more intuitive for
algorithmic processing on computers because they grew up in academia
solving scientific problems. The OO paradigm works from the opposite end
of the spectrum by abstracting customer problem spaces rather than
hardware computational models. So it is not very intuitive if one has
already learned procedural development.
So get a good OOA/D book and learn the fundamentals of the OO paradigm
first. (The Books category of my blog has some guidelines for selecting
a good book.)
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
arnuld
> algorithmic processing on computers because they grew up in academia
> solving scientific problems. The OO paradigm works from the opposite end
> of the spectrum by abstracting customer problem spaces rather than
> hardware computational models. So it is not very intuitive if one has
> already learned procedural development.
Lahman, doesn't that mean: "a programmer will learn more about
programming from algorithms and procedural approach rather than from
OOD"
?
> So get a good OOA/D book and learn the fundamentals of the OO paradigm
> first. (The Books category of my blog has some guidelines for selecting
> a good book.)
personally, i found OOSC by Bertrand Meyer better. you agree here with
me, Lahman
;-)
thanks
arnuld
H. S. Lahman
>>In addition, the procedural approaches are much more intuitive for
>>algorithmic processing on computers because they grew up in academia
>>solving scientific problems. The OO paradigm works from the opposite end
>>of the spectrum by abstracting customer problem spaces rather than
>>hardware computational models. So it is not very intuitive if one has
>>already learned procedural development.
>
>
> Lahman, doesn't that mean: "a programmer will learn more about
> programming from algorithms and procedural approach rather than from
> OOD"
>
> ?
Not quite. What it means is that OO development requires a different
mental approach to problem solving that procedural development. My point
here is that there is a substantial learning curve in adopting OO
techniques, more than for applying procedural techniques in a computing
environment. That's because the OO paradigm is focused on problem space
abstraction rather than hardware computational models. Most customer
problem spaces are not highly algorithmic.
For example, IT is characterized by applying lots of quite trivial
individual algorithms to mountains of data. In a General Ledger
application a heavy duty algorithm is a long division in an allocation.
The real problems lie in managing the data and organizing a gazillion
small algorithms that need to be cobbled together in complex ways.
(That's why it was called Data Processing for two decades before
Information Technology became fashionable.)
Corollary: if you need to solve an atmospheric diffusion problem, the OO
paradigm is probably not the way to do that. B-) One doesn't use OO
techniques to implement a Quicksort algorithm even if one can identify
objects like Pivot and Partition. That's because the goal of the OO
paradigm is maintainability in the face of volatile requirements over
time. The Quicksort algorithm isn't going to change over time so one
gets no benefit for using OO techniques while procedural techniques are
quite intuitive for the problem.
[OTOH, OO techniques are good for gluing together different algorithms
and dealing with the peripheral stuff like organizing data, UIs, and
persistence. So even complex algorithmic problems can benefit from using
OO techniques at the next level up from the pure mathematical
algorithms. IOW, use the right tool for the problem.]
H. S. Lahman
> just changed the subject, to make it more clear
I have to strongly disagree. The paradigms are almost diametrically
opposed. Procedural techniques are based on functional decomposition
with its hierarchical dependencies. One can argue that the whole point
of the OO paradigm is to eliminate hierarchical dependency structures.
All that good OO stuff -- encapsulation, separation of message and
method, decoupling, implementation hiding, flexible logical
indivisibility, problem space abstraction of intrinsic properties,
capturing business rules in static structure, etc., etc. -- plays
together expressly to eliminate hierarchical dependencies.
Dmitry A. Kazakov
decomposition is procedural. However some types of decomposition are
automated (upon inheritance or delegation). Further, for meta programming,
OOPLs provide new types of procedures to deal with classes.
There is no way to get rid of this sort of decomposition when the number of
states is any large. What any procedure does is in fact an abstraction of a
set of state transitions. You describe a bunch of transitions like 1->2,
2->3, 3->4, etc by a function inc:N->N. The difference is like between
finger counting and arithmetic. Now what OO does (on this basis) is
identifying N, the set of natural numbers for which arithmetic works.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
topmind
> Responding to Arnuld...
>
> >>In addition, the procedural approaches are much more intuitive for
> >>algorithmic processing on computers because they grew up in academia
> >>solving scientific problems. The OO paradigm works from the opposite end
> >>of the spectrum by abstracting customer problem spaces rather than
> >>hardware computational models. So it is not very intuitive if one has
> >>already learned procedural development.
>
> > Lahman, doesn't that mean: "a programmer will learn more about
> > programming from algorithms and procedural approach rather than from
> > OOD"
>
> > ?
>
> Not quite. What it means is that OO development requires a different
> mental approach to problem solving that procedural development. My point
> here is that there is a substantial learning curve in adopting OO
> techniques, more than for applying procedural techniques in a computing
> environment. That's because the OO paradigm is focused on problem space
> abstraction rather than hardware computational models.
I have to intervene here. This is highly unproven, at least for the
business domain. Subroutines and SQL queries are hardly "hardware
compuational models".
> Most customer
> problem spaces are not highly algorithmic.
>
> For example, IT is characterized by applying lots of quite trivial
> individual algorithms to mountains of data. In a General Ledger
> application a heavy duty algorithm is a long division in an allocation.
> The real problems lie in managing the data and organizing a gazillion
> small algorithms that need to be cobbled together in complex ways.
> (That's why it was called Data Processing for two decades before
> Information Technology became fashionable.)
>
> Corollary: if you need to solve an atmospheric diffusion problem, the OO
> paradigm is probably not the way to do that. B-) One doesn't use OO
> techniques to implement a Quicksort algorithm even if one can identify
> objects like Pivot and Partition. That's because the goal of the OO
> paradigm is maintainability in the face of volatile requirements over
> time.
They used to sell it primarily for "reuse". But they change the
alleged benefits/goal every decade as people realize the claims are
unproven or subjective. The OO claim is now shifting from "reducing
maintenance" to "reducing maintenance for large teams". I'd bet money
that next decade it will be different as the large team claim proves
elusive to reality. (OO makes you *need* large teams because it so
verbose in practice now.)
> The Quicksort algorithm isn't going to change over time so one
> gets no benefit for using OO techniques while procedural techniques are
> quite intuitive for the problem.
>
> [OTOH, OO techniques are good for gluing together different algorithms
> and dealing with the peripheral stuff like organizing data, UIs, and
> persistence. So even complex algorithmic problems can benefit from using
> OO techniques at the next level up from the pure mathematical
> algorithms. IOW, use the right tool for the problem.]
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
topmind
> Responding to Arnuld...
>
> > just changed the subject, to make it more clear
>
> I have to strongly disagree. The paradigms are almost diametrically
> opposed. Procedural techniques are based on functional decomposition
> with its hierarchical dependencies. One can argue that the whole point
> of the OO paradigm is to eliminate hierarchical dependency structures.
> All that good OO stuff -- encapsulation, separation of message and
> method, decoupling, implementation hiding, flexible logical
> indivisibility, problem space abstraction of intrinsic properties,
> capturing business rules in static structure, etc., etc. -- plays
> together expressly to eliminate hierarchical dependencies.
OO eliminate trees? You a funny man. Inheritence and to a slightly
lessor extent polymorphism have all the tree problems: mutual
exclusive category coupling. You would be trading one kind of tree for
another IF your claim about procedural being tree-oriented was true.
But, it is not. Modern procedural systems are far more event-driven
than the 70's style, such as being driven by menus stored in database
tables. A module can be as independent as you want to make it. (It is
not always the best option, but it is an option.)
As far as the crap about "problem space abstraction", put your proof
where your mouth is.
>
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
>
> H. S. Lahman
> h...@pathfindermda.com
> Pathfinder Solutionshttp://www.pathfindermda.com
> blog:http://pathfinderpeople.blogs.com/hslahman
> "Model-Based Translation: The Next Step in Agile Development". Email
> i...@pathfindermda.com for your copy.
topmind
> On Feb 21, 8:44 am, "H. S. Lahman" <h.lah...@verizon.net> wrote:
> As far as the crap about "problem space abstraction", put your proof
> where your mouth is.
Okay, I admit, that was a bit rude on my part. I should have simply
mentioned my objections without mentioning body parts etc.
I apologize.
>
> -T-
> oop.ismad.com
>
>
>
>
>
> > *************
> > There is nothing wrong with me that could
> > not be cured by a capful of Drano.
>
> > H. S. Lahman
-T-
topmind
arnuld wrote:
> > So get a good OOA/D book and learn the fundamentals of the OO paradigm
> > first. (The Books category of my blog has some guidelines for selecting
> > a good book.)
>
> personally, i found OOSC by Bertrand Meyer better. you agree here with
> me, Lahman
And don't forget to visit a critique of OOSC:
http://www.geocities.com/tablizer/meyer1.htm
-t-
H. S. Lahman
I'm not going to feed the troll. This response is for the OP's benefit...
>>>just changed the subject, to make it more clear
>>
>>I have to strongly disagree. The paradigms are almost diametrically
>>opposed. Procedural techniques are based on functional decomposition
>>with its hierarchical dependencies. One can argue that the whole point
>>of the OO paradigm is to eliminate hierarchical dependency structures.
>>All that good OO stuff -- encapsulation, separation of message and
>>method, decoupling, implementation hiding, flexible logical
>>indivisibility, problem space abstraction of intrinsic properties,
>>capturing business rules in static structure, etc., etc. -- plays
>>together expressly to eliminate hierarchical dependencies.
>
>
> OO eliminate trees? You a funny man. Inheritence and to a slightly
> lessor extent polymorphism have all the tree problems: mutual
> exclusive category coupling. You would be trading one kind of tree for
> another IF your claim about procedural being tree-oriented was true.
OO generalization is, indeed, a tree representation but there are no
hierarchical dependencies. The entire generalization tree resolves to a
single object with a single set of self-contained, logically indivisible
behavior responsibilities. It is simply a Venn Diagram in tree form that
happens to be a convenient way to enumerate the relevant property sets
that define subclass membership of the object in the root set.
> But, it is not. Modern procedural systems are far more event-driven
> than the 70's style, such as being driven by menus stored in database
> tables. A module can be as independent as you want to make it. (It is
> not always the best option, but it is an option.)
If they are truly event driven (i.e., with an event queue and
asynchronous communication model), then they are more OO than
procedural. Events separate message from response while synchronous
procedure calls do not. More important, the assumed delays in the
asynchronous model force the developer to view messages as announcements
(I'm Done) rather than hierarchical procedural imperatives (Do This).
> As far as the crap about "problem space abstraction", put your proof
> where your mouth is.
Aha, a new forensic ploy! You want me to to prove a conjecture that is
specified only in terms of vituperation. So I'm supposed to guess what
you want proved and whatever it is will then be attacked as the wrong
issue. It's nice to see you have some fresh material fro your trolling.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Mark Nicholls
> just changed the subject, to make it more clear
yes.....
it is trivial to consider procedural programming as a special case of
OO, OO gives you some extra bells and whistles that make life easier
(or more complex depending on what hat you've got on).
topmind
> >>I have to strongly disagree. The paradigms are almost diametrically
> >>opposed. Procedural techniques are based on functional decomposition
> >>with its hierarchical dependencies. One can argue that the whole point
> >>of the OO paradigm is to eliminate hierarchical dependency structures.
> >>All that good OO stuff -- encapsulation, separation of message and
> >>method, decoupling, implementation hiding, flexible logical
> >>indivisibility, problem space abstraction of intrinsic properties,
> >>capturing business rules in static structure, etc., etc. -- plays
> >>together expressly to eliminate hierarchical dependencies.
>
> > OO eliminate trees? You a funny man. Inheritence and to a slightly
> > lessor extent polymorphism have all the tree problems: mutual
> > exclusive category coupling. You would be trading one kind of tree for
> > another IF your claim about procedural being tree-oriented was true.
>
> OO generalization is, indeed, a tree representation but there are no
> hierarchical dependencies. The entire generalization tree resolves to a
> single object with a single set of self-contained, logically indivisible
> behavior responsibilities. It is simply a Venn Diagram in tree form that
> happens to be a convenient way to enumerate the relevant property sets
> that define subclass membership of the object in the root set.
Inheritance forces one to classify differences as a tree. In real
life, differences usually are not tree-shaped (or not enough to
warrent modeling differences as trees). It thus has less difference
management capability than sets unless you duplicate information.
Trees are simply not powerful enough to represent delta management.
Plus, the granularity of differences will often be smaller than your
original class divisions such that refactoring requires changing much
of the tree. You cannot override 1/3 of a method. IF statements are
more change-friendly in this regard because they are like calipers
that can open wide or small without having to rearrange your class
nesting and interfaces.
>
> > But, it is not. Modern procedural systems are far more event-driven
> > than the 70's style, such as being driven by menus stored in database
> > tables. A module can be as independent as you want to make it. (It is
> > not always the best option, but it is an option.)
>
> If they are truly event driven (i.e., with an event queue and
> asynchronous communication model), then they are more OO than
> procedural. Events separate message from response while synchronous
> procedure calls do not. More important, the assumed delays in the
> asynchronous model force the developer to view messages as announcements
> (I'm Done) rather than hierarchical procedural imperatives (Do This).
Here is an example. Think of a table with menu description and a URL.
When you click on a menu item, a lookup of this table can be done to
find out which webpage to run. Concurrency is generally handled via
the database.
>
> > As far as the crap about "problem space abstraction", put your proof
> > where your mouth is.
>
> Aha, a new forensic ploy! You want me to to prove a conjecture that is
> specified only in terms of vituperation. So I'm supposed to guess what
> you want proved and whatever it is will then be attacked as the wrong
> issue. It's nice to see you have some fresh material fro your trolling.
Prove that "OO is better problem space abstraction" in an objective
way, not something that assumes your personal psychology is a
universal model for all humans.
>
> *************
>
> H. S. Lahman
-T-
topmind
So does relational. Or functional, or logical programming, etc. You
seem to be arguing for paradigm potpurri.
Many of the things that people do with OO are better done in
relational in my opinion. For example, managing "instance features"
with sets instead of graphs of pointers or trees. OO is navigational
structures, which were discredited in the 70's and should have stayed
that way if the OO hypsters didn't zombie it up from the grave of Bad
Ideas.
-T-
arnuld
> it is trivial to consider procedural programming as a special case of
> OO, OO gives you some extra bells and whistles that make life easier
> (or more complex depending on what hat you've got on).
you mean one can learn OOD without learning procedural paradigm
?
-- arnuld
http://arnuld.blogspot.com
pandit
i can not comment anything on it but i have decided to learn OOD
without any procedural paradigm first.
may i have any advice whether C++ is a good vehicle for learning OOA-
D ?
thanks
- pandit
Mark Nicholls
technically yes....
it would be equivalent to learning to run without first learning to
walk though, once you'd learnt to run someone could tell you that
walking was just running slowly.
Mark Nicholls
The relevance of your response to the question that I was asked
elludes me.
Who said anything about the relational?
Mark Nicholls
Frankly no.
You can learn OO without explicitly learning procedural programming,
you'll just end up doing it by accident.
C++ is definitately not a good language to learn it in, I would use
C#, java or vb.net....I'm sure there are many others but I would use
something that was as simple as possible, but gave you a basic feel
for OOP.C++ is far too unconstrained.....I wouldn't suggest doing
anything in C++ except writing C.
arnuld
> On 23 Feb, 13:22, "arnuld" <geek.arn...@gmail.com> wrote:
>
> > > On Feb 22, 10:53 pm, "Mark Nicholls" <Nicholls.M...@mtvne.com> wrote:
> > > it is trivial to consider procedural programming as a special case of
> > > OO, OO gives you some extra bells and whistles that make life easier
> > > (or more complex depending on what hat you've got on).
>
> > you mean one can learn OOD without learning procedural paradigm
>
> > ?
> technically yes....
>
> it would be equivalent to learning to run without first learning to
> walk though, once you'd learnt to run someone could tell you that
> walking was just running slowly.
i did not get whether that was a +ve comment or -ve one. i mean, i did
not get whether you recommend precedural 1st or not. really sorry but
your reply is ambiguous to me :-(
thanks
-- arnuld
http://arnuld.blogspot.com
pandit
i think he is saying: You can learn OO paradigm without learning
procedural paradigm as basis.
but i am just guessing
-- pandit
Thomas Gagne
> <snip>
>
> i can not comment anything on it but i have decided to learn OOD
> without any procedural paradigm first.
>
> may i have any advice whether C++ is a good vehicle for learning OOA-
> D ?
>
features, like Smalltalk, Python, or Ruby. What you learn about OO
programming in those languages will serve you well when working with
"multi-paradigm" languages like Java and C++.
--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.
Dmitry A. Kazakov
During running at some time points the feet are off the ground.
Sorry, I just could not resist... (:-))
pandit
> On 1 Mar 2007 08:48:25 -0800, Mark Nicholls wrote:
>
> > On 23 Feb, 13:22, "arnuld" <geek.arn...@gmail.com> wrote:
> >>> On Feb 22, 10:53 pm, "Mark Nicholls" <Nicholls.M...@mtvne.com> wrote:
> >>> it is trivial to consider procedural programming as a special case of
> >>> OO, OO gives you some extra bells and whistles that make life easier
> >>> (or more complex depending on what hat you've got on).
>
> >> you mean one can learn OOD without learning procedural paradigm
>
> >> ?
>
> > technically yes....
>
> > it would be equivalent to learning to run without first learning to
> > walk though, once you'd learnt to run someone could tell you that
> > walking was just running slowly.
>
> During running at some time points the feet are off the ground.
>
what does this mean in context to: learning OOD before learning
procedural paradigm
Dmitry A. Kazakov
Honestly I don't know what is taught in technical colleges nowadays and in
which order. I only see the results. The students we get have very poor
software design and programming skills. OK, it would be silly to expect
that, but they don't know the foundations either. The most alarming thing
is lack of skeptical look and curiosity.
arnuld
> Honestly I don't know what is taught in technical colleges nowadays and in
> which order. I only see the results. The students we get have very poor
> software design and programming skills. OK, it would be silly to expect
> that, but they don't know the foundations either. The most alarming thing
> is lack of skeptical look and curiosity.
Dmitry, what does this has to do with the OP's question ?
Mark Nicholls
>
> - Show quoted text -
I think I was sitting on the fence, it's the way I did it, but that's
mainly historical the point being that you probably don't need to
explicitly learn it, but procedural decomposition is an important
element of OOP.
To me it's just better to have a go.....preferably with something that
is simple, well supported, well documented and with a wealth of people
using it.....so C#, vb.net or java.......have a go...mess about get it
wrong and learn from the mistakes.....I would do this well before
picking up some tome of design from whatever paradigm.
Mark Nicholls
>
> - Show quoted text -
I think you may be taking it too literally.
Lets turn it on it's head.
Do you have access to any compilers/programming tools?
If so which ones do you currently have access to?
You need to mess about to get a basic feel of how that tool works,
write simple programs (< 100 lines)....master the use of the tool, use
google to find samples, find groups that specialise in that tool to
answer your specific questions....
Now personally I would suggest finding something about procedural
decomposition at this point....master that.
Then I would pick up a nice simple OOP book (not something like Booch
or Meyer)......master that.
Matthieu Villeneuve
> this is my very 1st post here. i don't know anything expect some Lisp,
> one of my friends taught me Lisp.
>
> i need to learn OOA-D 1st. so the question now is:
>
> Can i learn OOA-D without learning Proecdural/Modular design 1st?
>
> will that not handicap me?
>
>
> ( i am interested in C++, OOD & Templates and i do not want to learn C
> 1st, which is procedural. one of my friends, advised me to learn OOD
> 1st & then C++ but he has no idea on whether to learn procedural or
> modular 1st as a solid-base of programming or OOD)
Out of curiosity, which Lisp do you know? Lisp isn't a language, it is
a family of language containing Common Lisp, Emacs Lisp, Scheme, etc.
You can write OO programs in Common Lisp (which was the first OO
language to get an ANSI standard, IIRC), so you may be able to start
with OO without having to take time to learn C++ or another language...
--
Matthieu Villeneuve
topmind
It was used an example to illustrate a point. You are basically using
a variation of the age-old Turing Equivalency argument to claim OO is
a superset of procedural.
But for the heck of it, here is a language-specific evidence that this
may not be true. In Java one cannot have a "global" function "print"
to make it C-like. Instead one has to do something like:
someArbitraryRedTapeSystemCrap.print(...);
It would probably have to abandon OOP to acheive such (or invent a
hidden "global" class, which is cheating).
-T-
Mark Nicholls
> Mark Nicholls wrote:
> > On 22 Feb, 18:27, "topmind" <topm...@technologist.com> wrote:
> > > On Feb 22, 9:53 am, "Mark Nicholls" <Nicholls.M...@mtvne.com> wrote:
>
> > > > On 21 Feb, 16:03, "arnuld" <geek.arn...@gmail.com> wrote:
>
> > > > > just changed the subject, to make it more clear
>
> > > > yes.....
>
> > > > it is trivial to consider procedural programming as a special case of
> > > > OO, OO gives you some extra bells and whistles that make life easier
> > > > (or more complex depending on what hat you've got on).
>
> > > So does relational. Or functional, or logical programming, etc. You
> > > seem to be arguing for paradigm potpurri.
>
> > > Many of the things that people do with OO are better done in
> > > relational in my opinion. For example, managing "instance features"
> > > with sets instead of graphs of pointers or trees. OO is navigational
> > > structures, which were discredited in the 70's and should have stayed
> > > that way if the OO hypsters didn't zombie it up from the grave of Bad
> > > Ideas.
>
> > > -T-
>
> > The relevance of your response to the question that I was asked
> > elludes me.
>
> > Who said anything about the relational?
>
> It was used an example to illustrate a point.
not by me it wasn't
> You are basically using
> a variation of the age-old Turing Equivalency argument to claim OO is
> a superset of procedural.
>
no I am not, I never mentioned it, and I don't see how it applies.
you seem to be making up flawed arguments in your head and then
claiming I said them.
I have not claimed anything about the semantics of execution.
> But for the heck of it, here is a language-specific evidence that this
> may not be true. In Java one cannot have a "global" function "print"
> to make it C-like. Instead one has to do something like:
>
> someArbitraryRedTapeSystemCrap.print(...);
>
> It would probably have to abandon OOP to acheive such (or invent a
> hidden "global" class, which is cheating).
>
> -T-- Hide quoted text -
>
> - Show quoted text -
Mathematicians 'cheat' all the time in the manner you reject......who
said anything about 'objects'....your mapping is to and from spaces of
strings, and yet the little '.' seems to have upset you....is the set
of even numbers smaller than the set of integers....because the
classic construction that shows their equivalence 'cheats' by creating
a correspondence between elements with different
labels?....no....would the proof be invalid if we using strings with a
'.' in them that may or may not have an interpretation in some model
you disaprove of?.....no....the interpretation is irrelevant.
Is there really any point us continuing this thread?......no....
topmind
Me, myself, and I used it as an example. Just because somebody uses a
car engine as an *analogy* does not mean they are changing the subject
to car engines.
>
> > You are basically using
> > a variation of the age-old Turing Equivalency argument to claim OO is
> > a superset of procedural.
> >
>
> no I am not, I never mentioned it, and I don't see how it applies.
>
> you seem to be making up flawed arguments in your head and then
> claiming I said them.
Dude, grow some diplomacy skills. Why not simply say, "There seems to
be a misunderstanding between us" rather than a form of "your head is
probably broken". I suspect sinister/dumb behavior from at least half
of everyone I talk to in a given day. However, I don't suggest that
beleif to their face.
Sometimes I think the problem with the 'net is that in real life being
overly frank risks getting you a new set of teeth. There is no such
check on behavior on the 'net. (Sometimes that is good, but has big
downsides also.)
>
> I have not claimed anything about the semantics of execution.
>
> > But for the heck of it, here is a language-specific evidence that this
> > may not be true. In Java one cannot have a "global" function "print"
> > to make it C-like. Instead one has to do something like:
> >
> > someArbitraryRedTapeSystemCrap.print(...);
> >
> > It would probably have to abandon OOP to acheive such (or invent a
> > hidden "global" class, which is cheating).
> >
> > -T--
>
> Mathematicians 'cheat' all the time in the manner you reject......who
> said anything about 'objects'....your mapping is to and from spaces of
> strings, and yet the little '.' seems to have upset you....is the set
> of even numbers smaller than the set of integers....because the
> classic construction that shows their equivalence 'cheats' by creating
> a correspondence between elements with different
> labels?....no....would the proof be invalid if we using strings with a
> '.' in them that may or may not have an interpretation in some model
> you disaprove of?.....no....the interpretation is irrelevant.
It would probably require a solid and consensus definition of OOP to
settle this. It is hard to use formal logic and reasoning on fuzz.
>
> Is there really any point us continuing this thread?......no....
Probably not. One or both of us is probably gonna hafta bust our
rump(s) to add enough precision to avoid miscommunication.
-T-
Nick Malik [Microsoft]
news:0G_Ch.3910$tQ.1391@trndny07...
> Responding to Arnuld...
>
>> just changed the subject, to make it more clear
>
> opposed. Procedural techniques are based on functional decomposition with
> its hierarchical dependencies. One can argue that the whole point of the
> OO paradigm is to eliminate hierarchical dependency structures. All that
> good OO stuff -- encapsulation, separation of message and method,
> decoupling, implementation hiding, flexible logical indivisibility,
> problem space abstraction of intrinsic properties, capturing business
> rules in static structure, etc., etc. -- plays together expressly to
> eliminate hierarchical dependencies.
>
I think that I can safely argue that OO fixes problems that are visible in
procedural languages.
Would you agree?
The is another twist, though. If you don't use procedural languages, is it
possible that you won't see those problems at all?
In other words, is OO a refinement of the Procedural line of thought?
If so, and there are other lines of thought, would OO apply equally well to
them?
If not, then how do you learn Object Oriented programming without learning
Procedural programming along the way?
In my mind, they are linked. OO solves Procedural's problems. To
understand the solution, you should understand the problem.
Respectfully,
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
topmind
Nick Malik [Microsoft] wrote:
> "H. S. Lahman" <h.la...@verizon.net> wrote in message
> news:0G_Ch.3910$tQ.1391@trndny07...
> > Responding to Arnuld...
> >
> >> just changed the subject, to make it more clear
> >
> > I have to strongly disagree. The paradigms are almost diametrically
> > opposed. Procedural techniques are based on functional decomposition with
> > its hierarchical dependencies. One can argue that the whole point of the
> > OO paradigm is to eliminate hierarchical dependency structures. All that
> > good OO stuff -- encapsulation, separation of message and method,
> > decoupling, implementation hiding, flexible logical indivisibility,
> > problem space abstraction of intrinsic properties, capturing business
> > rules in static structure, etc., etc. -- plays together expressly to
> > eliminate hierarchical dependencies.
> >
>
> I think that I can safely argue that OO fixes problems that are visible in
> procedural languages.
I think I can safely say that the chances of seeing an example of this
are nil. (Except for maybe animal, shape, or device driver examples.)
>
> Would you agree?
>
> The is another twist, though. If you don't use procedural languages, is it
> possible that you won't see those problems at all?
>
> In other words, is OO a refinement of the Procedural line of thought?
>
> If so, and there are other lines of thought, would OO apply equally well to
> them?
>
> If not, then how do you learn Object Oriented programming without learning
> Procedural programming along the way?
>
> In my mind, they are linked.
Psychology? Not allowed! If I can't do psych, nor can you.
> OO solves Procedural's problems. To
> understand the solution, you should understand the problem.
'sample pwease.
>
> Respectfully,
>
> --
> --- Nick Malik [Microsoft]
> MCSD, CFPS, Certified Scrummaster
> http://blogs.msdn.com/nickmalik
>
-T-
H. S. Lahman
>>>just changed the subject, to make it more clear
>>
>>I have to strongly disagree. The paradigms are almost diametrically
>>opposed. Procedural techniques are based on functional decomposition with
>>its hierarchical dependencies. One can argue that the whole point of the
>>OO paradigm is to eliminate hierarchical dependency structures. All that
>>good OO stuff -- encapsulation, separation of message and method,
>>decoupling, implementation hiding, flexible logical indivisibility,
>>problem space abstraction of intrinsic properties, capturing business
>>rules in static structure, etc., etc. -- plays together expressly to
>>eliminate hierarchical dependencies.
>>
>
>
> I think that I can safely argue that OO fixes problems that are visible in
> procedural languages.
>
> Would you agree?
Alas, not really. The real issue with hierarchical dependencies is the
way the software is designed. The 3GL just provides an implementation
technology for an existing design. One can take a procedural design and
implement it in an OOPL and one can take an OO design and implement it
in a procedural 3GL.
Thus, translation transformation engines routinely target procedural
languages when compiling OOA models for performance reasons and most
Eiffel compilers generate C as a "bytecode". Conversely, one can develop
a program in a language like C that is just as decoupled as a good
Smalltalk program. (The Michael Jackson's JSD was touted as a Structured
Design approach long before OOA/D methodologies but JSD applications
looked a whole lot more like OO applications that other procedural
approaches.)
The OOPLs just provide abstractions that encourage decoupling while the
procedural 3GLs provide structures that encourage hierarchical
organization. So...
> The is another twist, though. If you don't use procedural languages, is it
> possible that you won't see those problems at all?
There are a lot of "OO" applications out there that are just C or
FORTRAN programs with strong typing because the developers converted to
OO from procedural development and mapped their procedural design
techniques onto the OOPL. Such applications tend to be the worst of both
worlds.
> In other words, is OO a refinement of the Procedural line of thought?
>
> If so, and there are other lines of thought, would OO apply equally well to
> them?
I would say it is an evolution from procedural thought. Weaknesses of
procedural applications were recognized and the OO Deep Thinkers sought
ways to solve them. But those ways resulted in a fundamentally very
different approach to software design.
> If not, then how do you learn Object Oriented programming without learning
> Procedural programming along the way?
One learns OO development by starting with OOA/D. If the student has no
knowledge of procedural development, that is actually a great advantage
because the student doesn't need to unlearn anything. Most bad OO
programs are a direct result of converts from procedural development
overlaying familiar design techniques onto the OOPLs.
Unfortunately OOA/D is not nearly as intuitive as Structured Design in a
computing space dominated by hardware computational models. Worse, the
OOPLs are inherently 3GLS despite their added abstractions so the
languages still look procedural because of procedural block structuring,
stack-based scope, procedural message passing, etc.. That invites a
mapping of procedural design techniques onto the OOPLs is one hasn't
been properly taught OOA/D.
Once one figures out how computers work, one can program procedurally
and one has a lot of self-taught programmers. (Through the '80s almost
all programmers were self-taught because all the CS departments taught
were sort algorithms and data structures.) But one needs to be taught to
program properly in an OO fashion.
> In my mind, they are linked. OO solves Procedural's problems. To
> understand the solution, you should understand the problem.
I agree up to a point. A pet peeve of mine is that most OOA/D books are
written in Sermon On The Mount mode. They define a methodology without
telling one why the methodology is useful.
<flame ON>
FWIW, I think that is why we keep seeing these ill-fated hybrids with
functional programming showing up (functions as first class objects,
composition via generalization in layered model infrastructures, etc.).
The CS departments love functional programming because it is ideally
suited to scientific programming. So students come away seeing it and
OOA/D as two neat but different ways of doing things. Since they are not
taught why each paradigm does things the way it does, it becomes
tempting to start playing mix & match with individual features as a way
of "mapping" one paradigm into the other. But if one looks at the
fundamentals of what the paradigms are doing it becomes clear they are
fundamentally incompatible and one can't mix & match without producing a
hybrid that is inferior to both.
<flame OFF>
topmind
H. S. Lahman wrote:
>
> I would say it is an evolution from procedural thought. Weaknesses of
> procedural applications were recognized and the OO Deep Thinkers sought
> ways to solve them. But those ways resulted in a fundamentally very
> different approach to software design.
The "weakness" of procedural back when OO was invented was largely
that RDBMS did not exist yet. OO was only a half-fix.
-T-
Mark Nicholls
I was answering a specific question about OO and procedural
programming, I miss your point about pot pouri and any connection to
the relational model.
I am guilty of prejudging the line of your argument based on your
other posts.....i.e. linking every reference to OO as to some
reference to 'relational'.
>
>
> > I have not claimed anything about the semantics of execution.
>
> > > But for the heck of it, here is a language-specific evidence that this
> > > may not be true. In Java one cannot have a "global" function "print"
> > > to make it C-like. Instead one has to do something like:
>
> > > someArbitraryRedTapeSystemCrap.print(...);
>
> > > It would probably have to abandon OOP to acheive such (or invent a
> > > hidden "global" class, which is cheating).
>
> > > -T--
>
> > Mathematicians 'cheat' all the time in the manner you reject......who
> > said anything about 'objects'....your mapping is to and from spaces of
> > strings, and yet the little '.' seems to have upset you....is the set
> > of even numbers smaller than the set of integers....because the
> > classic construction that shows their equivalence 'cheats' by creating
> > a correspondence between elements with different
> > labels?....no....would the proof be invalid if we using strings with a
> > '.' in them that may or may not have an interpretation in some model
> > you disaprove of?.....no....the interpretation is irrelevant.
>
> It would probably require a solid and consensus definition of OOP to
> settle this. It is hard to use formal logic and reasoning on fuzz.
That is exactly my point....your argument as it stands says nothing
about OOP, it is simply the observation about a mapping between two
sets of strings....we simply prepend another string that happens to
have a '.' on the end of it.....you seem to be rejecting the argument
based on a specific interpretation that you reject....The observation
is cardinality of A is less than or equal to the cardinality of B.
Yes this argument can be used to construct an injective mapping from a
OO program into a procedural....we need to do some work to show that
semantics are preserved....(but they trivially are)....and so we show
that OO is a generalisation (as a construction mechanism, nothing to
do with the semantics of execution...they are both trivially by turing
completeness which tells us nothing about the relationship).
You can choose to reject the extension of the argument, but the
construction on strings is a pretty 'standard' counting argument used
all over the place.....the extension seems pretty unexceptional as
well.
>
>
>
> > Is there really any point us continuing this thread?......no....
>
> Probably not. One or both of us is probably gonna hafta bust our
> rump(s) to add enough precision to avoid miscommunication.
I apologise for prejudjing....
But to be fair though you did seem to jump in and construct an
argument I did not make and then reject it in a seeming attempt to
entice me into an argument about something I didn't comment on.
topmind
Mark Nicholls wrote:
> > > > You are basically using
> > > > a variation of the age-old Turing Equivalency argument to claim OO is
> > > > a superset of procedural.
> >
> > > no I am not, I never mentioned it, and I don't see how it applies.
> >
> > > you seem to be making up flawed arguments in your head and then
> > > claiming I said them.
> >
> > Dude, grow some diplomacy skills. Why not simply say, "There seems to
> > be a misunderstanding between us" rather than a form of "your head is
> > probably broken". I suspect sinister/dumb behavior from at least half
> > of everyone I talk to in a given day. However, I don't suggest that
> > beleif to their face.
> >
> > Sometimes I think the problem with the 'net is that in real life being
> > overly frank risks getting you a new set of teeth. There is no such
> > check on behavior on the 'net. (Sometimes that is good, but has big
> > downsides also.)
> >
> >
>
> I was answering a specific question about OO and procedural
> programming, I miss your point about pot pouri and any connection to
> the relational model.
Here is the quote again:
> > > > > > it is trivial to consider procedural programming as a special case of
> > > > > > OO, OO gives you some extra bells and whistles that make life easier
> > > > > > (or more complex depending on what hat you've got on).
> > > > > So does relational. Or functional, or logical programming, etc. You
> > > > > seem to be arguing for paradigm potpurri.
You seem to be implying that *some extra* paradigms or language
features are good over not having them. Thus, I am testing the logical
extension of this by looking at the addition of other paradigms/
features. If more X is good, then more Y should also be good, if your
rule holds up. If I do so, OO is not the only addon game in town, AND
we do seem to be risking paradigm pot pouri, which is not universally
accepted as "good".
>
> I am guilty of prejudging the line of your argument based on your
> other posts.....i.e. linking every reference to OO as to some
> reference to 'relational'.
If it works as an example, then it works as an example. Obviously it
is better to select a very familiar example on my part rather than
rotate them so that you don't get bored. Your boredom is not my
concern, to be frank.
I tend to view programming languages as data structures, not as
strings. I don't want to get into a syntax battle because there are
many ways to slice the syntax cat and skin the duck. A strict
interpretation of OO says that "every method must be part of an object/
class". Thus, self-standing functions like "print()" cannot exist, at
least not without zarking up the language.
>
> Yes this argument can be used to construct an injective mapping from a
> OO program into a procedural....we need to do some work to show that
> semantics are preserved....(but they trivially are)....and so we show
> that OO is a generalisation (as a construction mechanism, nothing to
> do with the semantics of execution...they are both trivially by turing
> completeness which tells us nothing about the relationship).
We could fudge it by having a "default class" such that any function
that cannot be mapped to a local method is assumed part of the default
class. But this is a kludge. We could kludge up procedural to make it
OOP also. Thus, if you want to play the kludge card....
>
> You can choose to reject the extension of the argument, but the
> construction on strings is a pretty 'standard' counting argument used
> all over the place.....the extension seems pretty unexceptional as
> well.
>
> >
> >
> >
> > > Is there really any point us continuing this thread?......no....
> >
> > Probably not. One or both of us is probably gonna hafta bust our
> > rump(s) to add enough precision to avoid miscommunication.
>
> I apologise for prejudjing....
>
> But to be fair though you did seem to jump in and construct an
> argument I did not make and then reject it in a seeming attempt to
> entice me into an argument about something I didn't comment on.
If I misinterpret what you say, then simply restate or clarify your
point. It is that simple. Constructing conspiracy theories about an
evil manipulative troll will only trigger another shout-war.
-T-
Mark Nicholls
appearing.
"or more complex depending on what hat you've got on".....
does this not imply that the extra features are of debatable value?
> Thus, I am testing the logical
> extension of this by looking at the addition of other paradigms/
> features. If more X is good, then more Y should also be good, if your
> rule holds up. If I do so, OO is not the only addon game in town, AND
> we do seem to be risking paradigm pot pouri, which is not universally
> accepted as "good".
>
Again you imply something I did not say.
"or more complex depending on what hat you've got on".....
>
>
> > I am guilty of prejudging the line of your argument based on your
> > other posts.....i.e. linking every reference to OO as to some
> > reference to 'relational'.
>
> If it works as an example, then it works as an example. Obviously it
> is better to select a very familiar example on my part rather than
> rotate them so that you don't get bored. Your boredom is not my
> concern, to be frank.
>
>
boredom? I did not say that either.
I still fail to see the point you are making....I answer a specific
question about OO and procedural yet you link it to being some sort of
sales pitch for OO, and then onto some sort of slur on other
paradigms.
The OP was about procedural programming being a stepping stone to OO.
Then you are including more than is required to construct the counting
argument.....the counting argument doesn't care whether they are car
registrations, data structures, programs, addresses....it is
irrelevant.
> I don't want to get into a syntax battle because there are
> many ways to slice the syntax cat and skin the duck. A strict
> interpretation of OO says that "every method must be part of an object/
> class". Thus, self-standing functions like "print()" cannot exist, at
> least not without zarking up the language.
Is there an injective mapping from the integers into the reals?
Does the syntactical representation of each domain have any effect on
the validity of the above conclusion?
representation is irrelevant.
>
>
>
> > Yes this argument can be used to construct an injective mapping from a
> > OO program into a procedural....we need to do some work to show that
> > semantics are preserved....(but they trivially are)....and so we show
> > that OO is a generalisation (as a construction mechanism, nothing to
> > do with the semantics of execution...they are both trivially by turing
> > completeness which tells us nothing about the relationship).
>
> We could fudge it by having a "default class" such that any function
> that cannot be mapped to a local method is assumed part of the default
> class. But this is a kludge. We could kludge up procedural to make it
> OOP also. Thus, if you want to play the kludge card....
Feel free to demonstrate polymorphism of a *fixed* program P using
only procedural code (no function pointers), that works under
extension.
Until you do that I will believe such a construction does not exist.
The construction the other way is trivial.
>
> > You can choose to reject the extension of the argument, but the
> > construction on strings is a pretty 'standard' counting argument used
> > all over the place.....the extension seems pretty unexceptional as
> > well.
>
> > > > Is there really any point us continuing this thread?......no....
>
> > > Probably not. One or both of us is probably gonna hafta bust our
> > > rump(s) to add enough precision to avoid miscommunication.
>
> > I apologise for prejudjing....
>
> > But to be fair though you did seem to jump in and construct an
> > argument I did not make and then reject it in a seeming attempt to
> > entice me into an argument about something I didn't comment on.
>
> If I misinterpret what you say, then simply restate or clarify your
> point. It is that simple. Constructing conspiracy theories about an
> evil manipulative troll will only trigger another shout-war.
In the context of a question about learning OO, is it useful to
procedural programming first.
topmind
But that is so wishy washy as to mean just about anything you want.
>
> does this not imply that the extra features are of debatable value?
Okay, I probably should have asked for clarification on the "hat"
comment first. I apologize for not taking such course of action.
Again, if we are allowed to play parsing pre-process fiddle games,
then anything can be anything such that the argument says nothing of
value.
>
> > I don't want to get into a syntax battle because there are
> > many ways to slice the syntax cat and skin the duck. A strict
> > interpretation of OO says that "every method must be part of an object/
> > class". Thus, self-standing functions like "print()" cannot exist, at
> > least not without zarking up the language.
>
> Is there an injective mapping from the integers into the reals?
Arguments about integers being a subtype of numbers usually do not
extrapolate to domain entities such as employees or invoices.
>
> Does the syntactical representation of each domain have any effect on
> the validity of the above conclusion?
>
> representation is irrelevant.
See the "anything can be anything" statement above.
> > > Yes this argument can be used to construct an injective mapping from a
> > > OO program into a procedural....we need to do some work to show that
> > > semantics are preserved....(but they trivially are)....and so we show
> > > that OO is a generalisation (as a construction mechanism, nothing to
> > > do with the semantics of execution...they are both trivially by turing
> > > completeness which tells us nothing about the relationship).
> >
> > We could fudge it by having a "default class" such that any function
> > that cannot be mapped to a local method is assumed part of the default
> > class. But this is a kludge. We could kludge up procedural to make it
> > OOP also. Thus, if you want to play the kludge card....
>
> Feel free to demonstrate polymorphism of a *fixed* program P using
> only procedural code (no function pointers), that works under
> extension.
Please explain "fixed" and "under extension".
>
> Until you do that I will believe such a construction does not exist.
>
> The construction the other way is trivial.
>
> >
> > > You can choose to reject the extension of the argument, but the
> > > construction on strings is a pretty 'standard' counting argument used
> > > all over the place.....the extension seems pretty unexceptional as
> > > well.
> >
> > > > > Is there really any point us continuing this thread?......no....
> >
> > > > Probably not. One or both of us is probably gonna hafta bust our
> > > > rump(s) to add enough precision to avoid miscommunication.
> >
> > > I apologise for prejudjing....
> >
> > > But to be fair though you did seem to jump in and construct an
> > > argument I did not make and then reject it in a seeming attempt to
> > > entice me into an argument about something I didn't comment on.
> >
> > If I misinterpret what you say, then simply restate or clarify your
> > point. It is that simple. Constructing conspiracy theories about an
> > evil manipulative troll will only trigger another shout-war.
>
> In the context of a question about learning OO, is it useful to
> procedural programming first.
>
> "it is trivial to consider procedural programming as a special case of
> OO, OO gives you some extra bells and whistles that make life easier
> (or more complex depending on what hat you've got on)."
Again, if we take into account your disclaimer at the end, it is one
big "it depends" without any details.
-T-
Mark Nicholls
that is not the case....the counting argument is a formal method.
>
>
>
> > > I don't want to get into a syntax battle because there are
> > > many ways to slice the syntax cat and skin the duck. A strict
> > > interpretation of OO says that "every method must be part of an object/
> > > class". Thus, self-standing functions like "print()" cannot exist, at
> > > least not without zarking up the language.
>
> > Is there an injective mapping from the integers into the reals?
>
> Arguments about integers being a subtype of numbers usually do not
> extrapolate to domain entities such as employees or invoices.
again your filling in gaps I have not specified, on the basis that you
want to have a pop at OO....the counting argument is a formal part of
set theory....it can be applied to several domains.....but it has
absolutely nothing to do with OO.
As a mathematical construct "Is there an injective mapping from the
integers into the reals"?
The relevance of the question is to your rejection of the application
to OO.....if you reject the OO application, then it only seems fair
that you reject the set theory application.
>
>
>
> > Does the syntactical representation of each domain have any effect on
> > the validity of the above conclusion?
>
> > representation is irrelevant.
>
> See the "anything can be anything" statement above.
No it cannot be.....specific representation is irrelevant.....it is
the basis of mathematical analysis.....it has absolutely nothing to do
with OO.....your are suffering from post de facto reasoning.
>
> > > > Yes this argument can be used to construct an injective mapping from a
> > > > OO program into a procedural....we need to do some work to show that
> > > > semantics are preserved....(but they trivially are)....and so we show
> > > > that OO is a generalisation (as a construction mechanism, nothing to
> > > > do with the semantics of execution...they are both trivially by turing
> > > > completeness which tells us nothing about the relationship).
>
> > > We could fudge it by having a "default class" such that any function
> > > that cannot be mapped to a local method is assumed part of the default
> > > class. But this is a kludge. We could kludge up procedural to make it
> > > OOP also. Thus, if you want to play the kludge card....
>
> > Feel free to demonstrate polymorphism of a *fixed* program P using
> > only procedural code (no function pointers), that works under
> > extension.
>
> Please explain "fixed" and "under extension".
>
>
Fixed....you cannot change any existing code...i.e. no tweaking 'if'
statements and claiming that the if statement is fixed....no adding
elements to look up tables, and claiming that they are fixed.....
extension (expansion really)....you are allowed to add new data
structures, and new 'procedures'.....
>
>
>
>
> > Until you do that I will believe such a construction does not exist.
>
> > The construction the other way is trivial.
>
> > > > You can choose to reject the extension of the argument, but the
> > > > construction on strings is a pretty 'standard' counting argument used
> > > > all over the place.....the extension seems pretty unexceptional as
> > > > well.
>
> > > > > > Is there really any point us continuing this thread?......no....
>
> > > > > Probably not. One or both of us is probably gonna hafta bust our
> > > > > rump(s) to add enough precision to avoid miscommunication.
>
> > > > I apologise for prejudjing....
>
> > > > But to be fair though you did seem to jump in and construct an
> > > > argument I did not make and then reject it in a seeming attempt to
> > > > entice me into an argument about something I didn't comment on.
>
> > > If I misinterpret what you say, then simply restate or clarify your
> > > point. It is that simple. Constructing conspiracy theories about an
> > > evil manipulative troll will only trigger another shout-war.
>
> > In the context of a question about learning OO, is it useful to
> > procedural programming first.
>
> > "it is trivial to consider procedural programming as a special case of
> > OO, OO gives you some extra bells and whistles that make life easier
> > (or more complex depending on what hat you've got on)."
>
> Again, if we take into account your disclaimer at the end, it is one
> big "it depends" without any details.
Correct!
So whatever you are complaining about.......I didn't say.....
>
> -T-- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
Daniel Parker
>
> As a mathematical construct "Is there an injective mapping from the
> integers into the reals"?
>
> The relevance of the question is to your rejection of the application
> to OO.....if you reject the OO application, then it only seems fair
> that you reject the set theory application.
>
not quite sure what the point is.
Daniel
topmind
> > > Then you are including more than is required to construct the counting
> > > argument.....the counting argument doesn't care whether they are car
> > > registrations, data structures, programs, addresses....it is
> > > irrelevant.
> >
> > Again, if we are allowed to play parsing pre-process fiddle games,
> > then anything can be anything such that the argument says nothing of
> > value.
>
> that is not the case....the counting argument is a formal method.
>
> >
> >
> > > > I don't want to get into a syntax battle because there are
> > > > many ways to slice the syntax cat and skin the duck. A strict
> > > > interpretation of OO says that "every method must be part of an object/
> > > > class". Thus, self-standing functions like "print()" cannot exist, at
> > > > least not without zarking up the language.
> >
> > > Is there an injective mapping from the integers into the reals?
> >
> > Arguments about integers being a subtype of numbers usually do not
> > extrapolate to domain entities such as employees or invoices.
>
> again your filling in gaps I have not specified, on the basis that you
> want to have a pop at OO....the counting argument is a formal part of
> set theory....it can be applied to several domains.....but it has
> absolutely nothing to do with OO.
>
> As a mathematical construct "Is there an injective mapping from the
> integers into the reals"?
Can you turn that into something about employees, invoices, products,
etc?
>
> The relevance of the question is to your rejection of the application
> to OO.....if you reject the OO application, then it only seems fair
> that you reject the set theory application.
Do you have a link to this "counting theory" described more carefully?
You are growing too kryptic for my tastes.
Thanks
-T-
Mark Nicholls
?
lets label the integers .....,Z0,Z1,Z2,Z3....etc
and label (some of) the reals R0,R1,R2,R3....etc
the mapping
...
Z0->R0
Z1->R1
Z2->R2
Z3->R3
etc
seems to fit the bill.
The point being that it doesn't matter how I 'label' the
domains....the mapping is preserved....the argument holds.
Mark Nicholls
I replied to this one as well and it didn't appear....hmmm....oh well.
?
Is there a injective mapping from the domain of heights of employees
to the nearest inch into the domain of precise heights of employees
(i.e. expressed as reals).
>
>
> > The relevance of the question is to your rejection of the application
> > to OO.....if you reject the OO application, then it only seems fair
> > that you reject the set theory application.
>
> Do you have a link to this "counting theory" described more carefully?
> You are growing too kryptic for my tastes.
>
http://en.wikipedia.org/wiki/Cardinality
> Thanks
Daniel Parker
> On 7 Mar, 20:58, "Daniel Parker" <danielapar...@gmail.com> wrote:
>
> > On Mar 7, 12:21 pm, "Mark Nicholls" <Nicholls.M...@mtvne.com> wrote:
>
> > > As a mathematical construct "Is there an injective mapping from the
> > > integers into the reals"?
>
> > not quite sure what the point is.
>
> ?
>
> lets label the integers .....,Z0,Z1,Z2,Z3....etc
>
> and label (some of) the reals R0,R1,R2,R3....etc
>
> the mapping
> ...
> Z0->R0
> Z1->R1
> Z2->R2
> Z3->R3
> etc
>
> seems to fit the bill.
>
Daniel
topmind
Call me dense, but I don't see how this applies to procedural
allegedly being a subset of OO or "naked methods" such "print". In
procedural, functions don't have to belong to any object/class
whatsoever. However, OO generally requires this, so it is not a
superset. If it was a super-set, then it would allow free-floating
functions. Now a given language may allow for such, but language X
allowing Y is not nec. the same as paradigm A allowing Y. Such a
language would simply be a multi-paradigm language.
>
>
>
> > Thanks
>
-T-
Mark Nicholls
You may be being dense....or I may be being dense...or we may be
talking about different things.
"functions don't have to belong to any object/class.....However, OO
generally requires this, so it is not a superset."
Z80 Assembly program
'ret'
Z80 Machine code program
'C9'
are these programs 'equivalent'?
topmind
I don't know machine code so I cannot be sure. However, saying two
programming statements/snippets produce the same results has nothing
to do with paradigm difference or paradigm subset-ness. It is simply a
statement of Turing Equivalency.
(I encountered an error why trying to post this, so I apologize if it
doubles up.)
-T-
topmind
My surgeon did the same during my brain surgery. That is why I spail
bad :-)
>
> Daniel
Mark Nicholls
But it is saying that the a specific program under a specific mapping
and specific conditions, creates a program that behaves identically
(Turing or whatever model you wish...that is a semantic issue and
irrelevant...a program is a black box that has a result on applying a
funcion 'execute')....'paradigm' is not what I said, I'm talking about
programming constructs.....so on one hand a string of
characters....and on the other an execution 'result'....who can say
how the programs were created...they may be created by random, or by a
room of monkeys with type writers or by OO'ites....it is not the
issue.
If programmer A produces a program in assembler and programmer B
produces a program in machine that is in the image of the obvious
mapping from assembler to machine code....and both programs
unsuprisingly produce exactly the same result, then are the constructs
equivalent? to me they are.
It would be the same to ask, are mathematical sentences written in
roman numerals equivalent to mathematical sentences written in arabic
numeral under evaluation. i.e. can you construct a sentence in one
that under the obvious mapping is not true in the other?
The proof is relatively trivial....you simply take the inverse mapping
and that all atomic terms true in arabic have to be true in
roman....and then inductively thus all sentences true/false in arabic
have to be true/false in roman.....do that both ways and your
done....if 2+2=4....then 'ii' + 'ii' = 'iv'....I don't need to sit
there with an abacus and work it out, I simply map the numerals and
hey presto I know the result.
Thus 'arabic mathematics' is isomorphic i.e. indisinguishable except
for the strings of characters that you label the number with, to
'roman mathematics'.
The construct for machine code and assembler would be roughly the
same....they are isomorphic....indistinguishable except for labels.
The construct for OO constructs against procedural ones, again would
be basically the same.....indistinguishable except for labels.
Maybe your objection is a more fundamental philosophical one about
such mathematics constructs rather than a specific objection to OO, if
so, we will simply have to agree to disagree.....I 'believe' in these
constructions....but it is only a belief......but then how would you
work out.....xviii + xv + xxxxix = ?....time for the abacus? or would
you simply map them to arabic numerals?
topmind
> On 13 Mar, 05:22, "topmind" <topm...@technologist.com> wrote:
If procedural syntax can be mapped to an OO engine and OO syntax can
be mapped to a procedural engine, that does *not* tell us anything
*useful* in a practical sense other than a mapping/translation can be
made. It may perhaps be useful to a compiler/interpreter writer in
search of reuse, but not for the language user (app developer).
-T-
Mark Nicholls
So you accept the mapping?
topmind
Yes, but it probably works both ways such that one is not "greater"
than the other.
-T-
Mark Nicholls
I agree.
they are equivalent for fixed universes of types.
basically I can create an OO program for every procedural one, and a
procedural one for every OO one....but for a procedural program to
handle polymorphism it will contain lots of.....
if param.type == 'dog'
{
.....'woof'
}
else
{
if param.type == 'cat'
{
.....'meow'
}
}
I have no implicit problem with this, others may complain but the
point isn't a value judgement about styles of code.
But I observe that if I expand the universe of types the procedural
one can only do an 'else unknown type' behaviour....it's call graph is
closed.
The OO one can polymorphically dispatch to the new behaviour supplied
with the type....i.e. the call graph is open.
i.e. under expansion of types they are not equivalent....i.e. OO '>'
procedural (in this context).
topmind
>
> - Show quoted text -
That greatly depends on the language. If you are allowed to
syntactically jury-rig "print(x)" into being "object.print(x)" under
the covers, then under-the-covers dynamic case-statement additions (or
whatever technique is used) should also be permitted. If you can jury-
rig to prove equivalency, then so can I.
(Such is probably far easier under say Lisp than C, I would note.)
-T-
frebe
> procedural one for every OO one....but for a procedural program to
> handle polymorphism it will contain lots of.....
>
> if param.type == 'dog'
> {
> .....'woof'}
>
> else
> {
> if param.type == 'cat'
> {
> .....'meow'
> }
>
> }
Not if you are using function pointers and functional pattern
matching. OO is not the only mechanism that are good at handling
polymorphism.
I would also like to add that every OO application I have seen had a
lot of "if (a instanceof A)". Trying to classify functionality into
trees of subtypes is not powerful enough for a lot of business logic.
A multi-dimensional approach is more suitable.
> The OO one can polymorphically dispatch to the new behaviour supplied
> with the type....i.e. the call graph is open.
Function pointers would do the same job.
/Fredrik
Mark Nicholls
it's a bog standard mathematical construct.
and you *explicitly* accepted it.
> the covers, then under-the-covers dynamic case-statement additions (or
> whatever technique is used) should also be permitted.
Can you give me an example of run time "dynamic case-statement
additions".....sounds like a function pointer or an OO method to me.
I did say about 10 posts ago
"Feel free to demonstrate polymorphism of a *fixed* program P using
only procedural code (no function pointers), that works under
extension."
You didn't respond at the time, and now your trying to move the goal
posts.
I have explicitly excluded changing the program ...I have said nothing
more about the semantics of execution or construction technique, I've
just if the string of characters that constitute the program is fixed
and we expand the domain of types then they are not equivalent.
You can claim that I am just constucting an arbritrary scenario.
Fine....but it is a specific identifiable difference (and happens to
be very useful when extending an existing system.....but that is a
secondary issue).
> If you can jury-
> rig to prove equivalency, then so can I.
>
Your 'rig' has already been excluded.
Is it time to end it? Personally I think I've demonstrated my point
and you're unwilling to accept it....you may be right, you may be
wrong, shall we just leave it?
Mark Nicholls
> > basically I can create an OO program for every procedural one, and a
> > procedural one for every OO one....but for a procedural program to
> > handle polymorphism it will contain lots of.....
>
> > if param.type == 'dog'
> > {
> > .....'woof'}
>
> > else
> > {
> > if param.type == 'cat'
> > {
> > .....'meow'
> > }
>
> > }
>
> Not if you are using function pointers and functional pattern
> matching. OO is not the only mechanism that are good at handling
> polymorphism.
I agree, procedural decomposition with function pointers is
equivalent.
But I excluded function pointers in a previous post.
Without function pointers though they are not equivalent...so my
original statement stands.
As far as pattern matching is concerned I plead ignorance, it's not
something that I believe is part of classic procedural
decomposition....I believe it used largely in functional languages,
which is another kettle of fish again.
>
> I would also like to add that every OO application I have seen had a
> lot of "if (a instanceof A)".
To be able to write a bad book does not discredit the language it is
written in....I don't see the relevance.
If as I claim OO is a generalasation of pure procedural programming
then the fact one sees elements in OO that one would see in a
procedural language seems to underline the point.
> Trying to classify functionality into
> trees of subtypes is not powerful enough for a lot of business logic.
> A multi-dimensional approach is more suitable.
>
I do not understand in what sense it is 'multi-demensional'? Can I
assume you mean that OO constructions are single dimensional in some
sense?
Can you explain?
> > The OO one can polymorphically dispatch to the new behaviour supplied
> > with the type....i.e. the call graph is open.
>
> Function pointers would do the same job.
I agree....but I explicitly excluded them in a previous post....the
question was about the procedural decomposition.
topmind
Wait a second here. Are we comparing programming language features, or
software design techniques?
OO is just a narrow technique where function pointers and/or code
snippets are put into a specific type of data structure, generally a
"map", with some syntactic sugar to bind it closer to the language. I
don't find maps the "magic structure" that OO'ers seem to. I have
nothing against putting function pointers and/or code snippets into
data structures, I would just rather have relational structures for
such instead of maps of maps. Maps of maps are messier than relational
in my opinion. I find consistency and logical organization with
relational, but maps of maps have no discipline to them: they are the
Go To of data/link structures.
Maybe someday someone will find "map math", the Dr. Codd of maps.
Until that day, relational is cleaner.
-T-
Mark Nicholls
language features.....that....I've constantly said the paradigm by
which the program is designed may be random.
>
> OO is just a narrow technique where function pointers and/or code
> snippets are put into a specific type of data structure,
yes......this is why I excluded them from a discussion of procedural
constructions, because learning classic procedural decomposition does
not involve them.
> generally a
> "map", with some syntactic sugar to bind it closer to the language. I
> don't find maps the "magic structure" that OO'ers seem to.
it's not magic, it's a semantic feature of the OO model.
> I have
> nothing against putting function pointers and/or code snippets into
> data structures,
neither have I but I excluded them in a previous post, as not part of
a classic procedural toolkit.
> I would just rather have relational structures for
> such instead of maps of maps. Maps of maps are messier than relational
> in my opinion.
discusions on the relation model are irrelevant, you took exception to
a statement comparing OO language features and procedural ones, and
are now trying to include things that were explicitly excluded rather
than simply saying.
"yes you're right, if you consider procedural constructions to be WXY
(and explicitly not WXY plus Z), then they are not equivalent in the
scenario you have demonstrated, lets move on".
> I find consistency and logical organization with
> relational, but maps of maps have no discipline to them: they are the
> Go To of data/link structures.
>
Fine....but it is not relevant....you have a relatively formal
demonstration of the statement you objected to, and seemingly have no
formal objection.
All I have is tangental comments about constructions that are not in
scope.
> Maybe someday someone will find "map math", the Dr. Codd of maps.
> Until that day, relational is cleaner.
It is still irrelevant.
Is OO > procedural in the context I have given?
If not then please demonstrate by counter example.
(your opinions on the relational model are for another day, and I
have, as yet, not disputed them).
I have accepted 'frege's comments, and pointed out that they have been
excluded by a previous post, but that I agree with his comments non
the less.
I am at the point where I think you have demonstrated that you are not
willing to discuss the matter with any sense of open mindedness, is
there any point in continuing?
frebe
> > trees of subtypes is not powerful enough for a lot of business logic.
> > A multi-dimensional approach is more suitable.
>
> I do not understand in what sense it is 'multi-demensional'? Can I
> assume you mean that OO constructions are single dimensional in some
> sense?
When you choose to subclass a class, you are subtyping according to a
given dimension. When you try to subclass by multiple dimensions, you
have a problem.
> > > The OO one can polymorphically dispatch to the new behaviour supplied
> > > with the type....i.e. the call graph is open.
>
> > Function pointers would do the same job.
>
> I agree....but I explicitly excluded them in a previous post....the
> question was about the procedural decomposition.
Functions and functions pointers have been supported in many
procedural languages since long time ago. The main difference is that
in traditional development, you just use function pointers when you
really need them. The common OO argument "I need to extend my
application without recompiling the existing sources", is not that
important in real life.
/Fredrik
topmind
But "procedural decomposition" is a technique, not a language feature.
>
> >
> > OO is just a narrow technique where function pointers and/or code
> > snippets are put into a specific type of data structure,
>
> yes......this is why I excluded them from a discussion of procedural
> constructions, because learning classic procedural decomposition does
> not involve them.
>
> > generally a
> > "map", with some syntactic sugar to bind it closer to the language. I
> > don't find maps the "magic structure" that OO'ers seem to.
>
> it's not magic, it's a semantic feature of the OO model.
Again, we would probably need a more precise definition of "OO" in
order to dig into this deeper.
>
> > I have
> > nothing against putting function pointers and/or code snippets into
> > data structures,
>
>
> neither have I but I excluded them in a previous post, as not part of
> a classic procedural toolkit.
>
> > I would just rather have relational structures for
> > such instead of maps of maps. Maps of maps are messier than relational
> > in my opinion.
>
> discusions on the relation model are irrelevant, you took exception to
> a statement comparing OO language features and procedural ones, and
> are now trying to include things that were explicitly excluded rather
> than simply saying.
Procedural does not exclude relational. Oracle's engine is built in C,
for example. But again this is right smack back to Turing Equivalency.
I will agree that OO languages make certain design approaches (OO)
*more convenient*, at least out-of-the-box, but that is not the same
as being a super-set.
Or are you excluding paradigms-via-libraries? For relational for the
moment, procedural does not forbid putting function pointers and/or
code snippets into data structures.
>
> "yes you're right, if you consider procedural constructions to be WXY
> (and explicitly not WXY plus Z), then they are not equivalent in the
> scenario you have demonstrated, lets move on".
>
> > I find consistency and logical organization with
> > relational, but maps of maps have no discipline to them: they are the
> > Go To of data/link structures.
> >
>
> Fine....but it is not relevant....you have a relatively formal
> demonstration of the statement you objected to, and seemingly have no
> formal objection.
>
> All I have is tangental comments about constructions that are not in
> scope.
>
> > Maybe someday someone will find "map math", the Dr. Codd of maps.
> > Until that day, relational is cleaner.
>
> It is still irrelevant.
>
> Is OO > procedural in the context I have given?
>
> If not then please demonstrate by counter example.
>
> (your opinions on the relational model are for another day, and I
> have, as yet, not disputed them).
No they are not, per Oracle-C example.
>
> I have accepted 'frege's comments, and pointed out that they have been
> excluded by a previous post, but that I agree with his comments non
> the less.
>
> I am at the point where I think you have demonstrated that you are not
> willing to discuss the matter with any sense of open mindedness, is
> there any point in continuing?
You have not demonstrated clear superset-ness of OO over procedural.
If you have, I missed it. It is not my job to be open-minded for this
particular issue, but to evaluate your superset claims. I honestly see
no power to them. You seem to keep running into the Turing Complete
wall. Again, I will agree that OO makes certain techniques easier out-
of-the-box, but that is not the same as being a superset. Rather than
call me "closed minded", perhaps you need to refactor your evidence.
-T-
topmind
Mark Nicholls wrote:
> > Trying to classify functionality into
> > trees of subtypes is not powerful enough for a lot of business logic.
> > A multi-dimensional approach is more suitable.
> >
>
> I do not understand in what sense it is 'multi-demensional'? Can I
> assume you mean that OO constructions are single dimensional in some
> sense?
Just try to build a sub-type-based classification system for people.
Not just employees, but *people*. (The same issues happen for
"employees", but under "people" it is more obvious.)
-T-
Mark Nicholls
it is dependent on language features.
if you have no procedures you can't do it, you can do it without
function pointers.
so you take the minimal set of language features to support it and
then construct the program.
>
>
> > > OO is just a narrow technique where function pointers and/or code
> > > snippets are put into a specific type of data structure,
>
> > yes......this is why I excluded them from a discussion of procedural
> > constructions, because learning classic procedural decomposition does
> > not involve them.
>
> > > generally a
> > > "map", with some syntactic sugar to bind it closer to the language. I
> > > don't find maps the "magic structure" that OO'ers seem to.
>
> > it's not magic, it's a semantic feature of the OO model.
>
> Again, we would probably need a more precise definition of "OO" in
> order to dig into this deeper.
you've got more than enough already....
> > > I have
> > > nothing against putting function pointers and/or code snippets into
> > > data structures,
>
> > neither have I but I excluded them in a previous post, as not part of
> > a classic procedural toolkit.
>
> > > I would just rather have relational structures for
> > > such instead of maps of maps. Maps of maps are messier than relational
> > > in my opinion.
>
> > discusions on the relation model are irrelevant, you took exception to
> > a statement comparing OO language features and procedural ones, and
> > are now trying to include things that were explicitly excluded rather
> > than simply saying.
>
> Procedural does not exclude relational.
no but it does not include it (see below).....
> Oracle's engine is built in C,
> for example.
It is irrelevant on 3 counts
i) The engine exists *inside* the program....C is the meta langauge
*not* the language of oracle.
ii) you still need to show that it is possible to construct a
'relational program' that can be expanded under extension of types.
iii) C is not a pure procural programming language, if function
pointers are used (very likely) in Oracles construction then it falls
outside the scope of the discussion.
> But again this is right smack back to Turing Equivalency.
you may be....I'm not.
my distinction is *not* based on the closure of the set of semantics
(Turing equivalence) but on invariance of the program.
> I will agree that OO languages make certain design approaches (OO)
> *more convenient*, at least out-of-the-box, but that is not the same
> as being a super-set.
firstly even if I accepted they were 'equivalent' for the scenario
given, which I don't...(you have not given a counter example or
refuted the sketch proof), that is not to say that the constructs of
one are not a subset of the construct of another.
e.g.
consider a set of vectors that span a 2 dimensional vector space.
we can use set A i.e. just 2 {<1,0>, <0,1>}....but I could add another
so the set {<1,0>, <0,1>,<1,1>}
A is a strict subset of B...the span of both sets are
equivalent....but B is a *superset* of A.
their spans are equivent, but one set of 'constructions' is a subset
of the other.
>
> Or are you excluding paradigms-via-libraries? For relational for the
> moment, procedural does not forbid putting function pointers and/or
> code snippets into data structures.
see above.
>
> > "yes you're right, if you consider procedural constructions to be WXY
> > (and explicitly not WXY plus Z), then they are not equivalent in the
> > scenario you have demonstrated, lets move on".
>
> > > I find consistency and logical organization with
> > > relational, but maps of maps have no discipline to them: they are the
> > > Go To of data/link structures.
>
> > Fine....but it is not relevant....you have a relatively formal
> > demonstration of the statement you objected to, and seemingly have no
> > formal objection.
>
> > All I have is tangental comments about constructions that are not in
> > scope.
>
> > > Maybe someday someone will find "map math", the Dr. Codd of maps.
> > > Until that day, relational is cleaner.
>
> > It is still irrelevant.
>
> > Is OO > procedural in the context I have given?
>
> > If not then please demonstrate by counter example.
>
> > (your opinions on the relational model are for another day, and I
> > have, as yet, not disputed them).
>
> No they are not, per Oracle-C example.
see above....it is irrelevant on 3 counts.
>
> > I have accepted 'frege's comments, and pointed out that they have been
> > excluded by a previous post, but that I agree with his comments non
> > the less.
>
> > I am at the point where I think you have demonstrated that you are not
> > willing to discuss the matter with any sense of open mindedness, is
> > there any point in continuing?
>
> You have not demonstrated clear superset-ness of OO over procedural.
I have on 2 counts,
i) as a set of construction
ii) as not being equivalent under expansion of types.
You have given me a counter example? no.
> If you have, I missed it. It is not my job to be open-minded for this
> particular issue, but to evaluate your superset claims.
honest debate relies on both parties engaging in that debate open
mindedly.
> I honestly see
> no power to them. You seem to keep running into the Turing Complete
> wall.
you keep trawling the same agument that I have never used, and is not
part of either demonstration....it is *irrelevant*.
> Again, I will agree that OO makes certain techniques easier out-
> of-the-box, but that is not the same as being a superset.
so at least you should accept demonstation 2?
> Rather than
> call me "closed minded", perhaps you need to refactor your evidence.
>
I have never engaged in conversations with you before because on
reading your posts you never seem to ever accept things that are
plainly demonstrated to you, (like many other, including me at times),
this does not make you wrong, just extremely difficult to have
constructive debate with, you have many points that are valid about
the over hyping and the 'magical' nature of OO that is expounded here,
but don't throw the baby out with the bath water.
you give me no counter examples, you simply extend the debate to areas
you feel happier with in some hope that they can be shown to be in
scope, or are not obviously out of scope.
You have not disputed the sketch proof, you have no counter examples
that are not simply out of scope.
Please show a simple procedural program that behaves in the manner I
have asked for, if you are right you should not need to have to invoke
the magic of 'relational' or 'oracle'.
I'm done though....I don't think there's much point.....you may be
right, but I don't believe you have enough evidence to demonstrate I
am wrong, let alone that you are right.
Mark Nicholls
> > > Trying to classify functionality into
> > > trees of subtypes is not powerful enough for a lot of business logic.
> > > A multi-dimensional approach is more suitable.
>
> > I do not understand in what sense it is 'multi-demensional'? Can I
> > assume you mean that OO constructions are single dimensional in some
> > sense?
>
> When you choose to subclass a class, you are subtyping according to a
> given dimension. When you try to subclass by multiple dimensions, you
> have a problem.
I think you need to give me an example....the penny hasn't dropped.
>
> > > > The OO one can polymorphically dispatch to the new behaviour supplied
> > > > with the type....i.e. the call graph is open.
>
> > > Function pointers would do the same job.
>
> > I agree....but I explicitly excluded them in a previous post....the
> > question was about the procedural decomposition.
>
> Functions and functions pointers have been supported in many
> procedural languages since long time ago.
I agree, but procedural decomposition e.g. things like Jackson
structures programming, and the study of simply algorithms doesn't use
them, the context of the OP was, "is it worth learning procedural
decomposition before OO", my answer was based basically the set of
construction required to support this sort of decomposition....so not
function pointers.
> The main difference is that
> in traditional development, you just use function pointers when you
> really need them. The common OO argument "I need to extend my
> application without recompiling the existing sources", is not that
> important in real life.
Quite possibly, I was a C programmer and used function pointers
liberally in addition to basically doing procedural decomposition....I
then migrated to a more explicit X windows/Rumbaugh style of C that is
effectively OO.....the sanity of this is open to debate.
My demonstration was of "I need to extend my application without
recompiling the existing sources", I did caveat by saying that the
value of this was irrelevant to the demonstration.....but I take the
point.
But the "I need to extend my application without recompiling the
existing sources" property of OO is distinctive from simple procedural
constructions.....even if it's value is debatable.
topmind
But if we are only allowed to compare *minimal*, then OOP does not
support "print(foo)" because "print" is not tied to an object. Either
additions/fudges are allowed for both sides or additions/fudges are
not allowed for both sides. Otherwise you have a double standard.
>
> >
> >
> > > > OO is just a narrow technique where function pointers and/or code
> > > > snippets are put into a specific type of data structure,
> >
> > > yes......this is why I excluded them from a discussion of procedural
> > > constructions, because learning classic procedural decomposition does
> > > not involve them.
> >
> > > > generally a
> > > > "map", with some syntactic sugar to bind it closer to the language. I
> > > > don't find maps the "magic structure" that OO'ers seem to.
> >
> > > it's not magic, it's a semantic feature of the OO model.
> >
> > Again, we would probably need a more precise definition of "OO" in
> > order to dig into this deeper.
>
> you've got more than enough already....
There is rarely a substitute for precision in this biz.
>
> > > > I have
> > > > nothing against putting function pointers and/or code snippets into
> > > > data structures,
> >
> > > neither have I but I excluded them in a previous post, as not part of
> > > a classic procedural toolkit.
> >
> > > > I would just rather have relational structures for
> > > > such instead of maps of maps. Maps of maps are messier than relational
> > > > in my opinion.
> >
> > > discusions on the relation model are irrelevant, you took exception to
> > > a statement comparing OO language features and procedural ones, and
> > > are now trying to include things that were explicitly excluded rather
> > > than simply saying.
> >
> > Procedural does not exclude relational.
>
> no but it does not include it (see below).....
See minimal double-standard issue above.
>
> > Oracle's engine is built in C,
> > for example.
>
> It is irrelevant on 3 counts
>
> i) The engine exists *inside* the program....C is the meta langauge
> *not* the language of oracle.
I don't see how that disqualifies it.
> ii) you still need to show that it is possible to construct a
> 'relational program' that can be expanded under extension of types.
Why? "Types" is not part of the analogy.
> iii) C is not a pure procural programming language, if function
> pointers are used (very likely) in Oracles construction then it falls
> outside the scope of the discussion.
Where does this concept of "pure procedural" come from? You are being
loosy goosy with the definition of OO, but super-narrow with
"procedural". Almost every dynamic procedural language I've used had
some form of dynamic execution such that one could store function
names and/or expressions in arrays or other structures and execute
them if needed. At the very least they let you choose which script
file to run. Thus, one could store the script file names in an array
and determine which to execute at run-time. This is a very rudimentary
form of "function pointers" that is common in scriptish languages.
> > Rather than
> > call me "closed minded", perhaps you need to refactor your evidence.
> >
>
> I have never engaged in conversations with you before because on
> reading your posts you never seem to ever accept things that are
> plainly demonstrated to you, (like many other, including me at times),
> this does not make you wrong, just extremely difficult to have
> constructive debate with, you have many points that are valid about
> the over hyping and the 'magical' nature of OO that is expounded here,
> but don't throw the baby out with the bath water.
>
> you give me no counter examples, you simply extend the debate to areas
> you feel happier with in some hope that they can be shown to be in
> scope, or are not obviously out of scope.
Of course I would rather deal with my fuzz instead of your fuzz. If
you want to avoid that, then provide a precise definition of OO and
procedural that can be tested with formal logic.
>
> I'm done though....I don't think there's much point.....you may be
> right, but I don't believe you have enough evidence to demonstrate I
> am wrong, let alone that you are right.
Without a hard, precise, and agreed-upon definition of OOP and
procedural, I don't think we can continue. "Notion math" will not
settle this.
-T-
adaw...@sbcglobal.net
"topmind" <top...@technologist.com> wrote in message
>
> That greatly depends on the language.
>
does not mean it _should_ be done that way.
Object-oriented programming is intended to create specializable
(extensible) types, called classes, so that addition of those
types to an existing design requires no modification of the
existing code.
I have done a lot of procedural coding over my many decades
of programming and I have also done object-oriented programming.
I have programmed in functional languages, scripting languages,
and domain-specific languages.
As I follow the arguments presented in this forum from time to time,
it is increasingly clear that those who think they are making cogent
arguments against OOP simply have no idea what they are talking
about. Apparently, they have never designed an OOP software
system, or if they have tried, they have failed at doing so. Their
failure is not the fault of the paradigm, but a shortcoming in their
own abilities.
The concept of type is quite fundamental. Even in functional languages
one encounters it, even when it is under-the-hood. OOP classes are
nothing more than extensible abstract-data-types (ADT) that provide
a stronger model of encapsulation, dynamic-binding, and polymorphism,
message management, and non-invasive specialization than that found
in other styles of design. By non-invasive, I mean that, with correct
application of OOP, there is no need to perform open-heart surgery
on existing modules when new features need to be added to an
existing design.
While function pointers can be used as a technique for emulating sonme
aspects of OOP, this approach is not sufficient for satisfying everything.
That being said, OOP is not the correct solution for every set of programming
problems. It is often a bit of overkill. Some problems benefit from a simple
procedural, table-driven, or application-specific tools and languages approach.
Stand alone objects such as executable components are also a good technique.
Even so, when the problem does call for an OOP approach, there is not good
substitute for a development environment that directly supports OOP. Attempts
to do OOP in languages that don't support it are usually doomed to failure. Not
all OOP languages are created equal. Smalltalk is probably the gold-standard.
C++ should always be the choice of last resort. In fact, I believe (though I
have
no statistics to support this) that the choice of C++ for OOP projects is one of
the reasons there are so many bad OOP horror stories. Eiffel, on the other
hand, provides an OOP model that makes sense.
There is nothing fundamentally wrong with the OOP paradigm. There is a lot
wrong with some of the tools used to implement it, as noted in the previous
paragraph. The on-going progress in software architecture and patterns
has benefitted from the concepts of object technology.
I realize that nothing I have said will persuade those naysayers who insist on
digging in their feet and declaiming against OOP. "He convinced against his
will, is of the same opinion still," continues to ring true, even in this kind
of
an argument. However, my observation regarding their contributions, so far,
is that they have quite limited experience actually building systems with OOP,
or limited experience doing so using good tools and languages (C++ doesn't
count since it is inherently error-prone).
Richard Riehle
topmind
adaw...@sbcglobal.net wrote:
> "topmind" <top...@technologist.com> wrote in message
> >
> > That greatly depends on the language.
> >
> The fact that something _can_ be done in a given manner
> does not mean it _should_ be done that way.
This sub-topic is really about characterising what OOP *is*, not about
whether it is "better". But I am flexible and will reply anyhow.
>
> Object-oriented programming is intended to create specializable
> (extensible) types, called classes, so that addition of those
> types to an existing design requires no modification of the
> existing code.
>
> I have done a lot of procedural coding over my many decades
> of programming and I have also done object-oriented programming.
> I have programmed in functional languages, scripting languages,
> and domain-specific languages.
>
> As I follow the arguments presented in this forum from time to time,
> it is increasingly clear that those who think they are making cogent
> arguments against OOP simply have no idea what they are talking
> about. Apparently, they have never designed an OOP software
> system, or if they have tried, they have failed at doing so. Their
> failure is not the fault of the paradigm, but a shortcoming in their
> own abilities.
Everybody on the web claims or implies they are Einstein's superior.
You have to *show* OOP being better, not merely claim you are smart
and experienced. Use code and realistic change scenarios applied to
it, for example. If you don't want to do it, then just say so. We
don't need yet more unverifiable anecdotes, they are a cheap commodity
on the web, to be frank. People come to see evidence, not read resumes
from people who have very positive views of themselves.
>
> The concept of type is quite fundamental. Even in functional languages
> one encounters it, even when it is under-the-hood. OOP classes are
> nothing more than extensible abstract-data-types (ADT) that provide
> a stronger model of encapsulation, dynamic-binding, and polymorphism,
> message management, and non-invasive specialization than that found
> in other styles of design. By non-invasive, I mean that, with correct
> application of OOP, there is no need to perform open-heart surgery
> on existing modules when new features need to be added to an
> existing design.
I find at least two problems with OO's approach to "extension without
modification".
The first is that most changes in the real world are *not* tree-
shaped. Overriding subtypes generally assumes a tree-shaped extension
pattern. (OO does not have to use trees, but it is far messier than
the competition, at least not better, when it does such.) I find sets
a better way to manage variations/features than trees and believe this
to be an inharent advantage of sets. They are far more flexible and
don't force you to commit to one dimension/factor being artificially
dominant. Trees may be okay in the short-term, but as more features
are piled on, they cannot handle it.
The second is granularity. Real-world changes often don't always fit
the grain of one's code granularity. Thus, in practice one has to do
things like figure out how to override one-third of a method. It can
be a lot of code-rework to do such. And IF statement is like a
calliper that can reach over any range in any part of the code, and
this is less subject to granularity problems and less code re-work.
(If there is a pattern to many of the IF statements, then often such
can be tablized to make it easier to see and manage.)
I've pointed this out before, and don't remember you responding.
ADT are a nice concept on paper, but often just don't work in the real
world. They cannot handle reality very well.
>
>
> While function pointers can be used as a technique for emulating sonme
> aspects of OOP, this approach is not sufficient for satisfying everything.
Again, the issue there was about classification and characteristics of
OOP, not advantages in usage.
>
> That being said, OOP is not the correct solution for every set of programming
> problems. It is often a bit of overkill. Some problems benefit from a simple
> procedural, table-driven, or application-specific tools and languages approach.
> Stand alone objects such as executable components are also a good technique.
>
> Even so, when the problem does call for an OOP approach, there is not good
> substitute for a development environment that directly supports OOP. Attempts
> to do OOP in languages that don't support it are usually doomed to failure. Not
> all OOP languages are created equal. Smalltalk is probably the gold-standard.
> C++ should always be the choice of last resort. In fact, I believe (though I
> have
> no statistics to support this) that the choice of C++ for OOP projects is one of
> the reasons there are so many bad OOP horror stories. Eiffel, on the other
> hand, provides an OOP model that makes sense.
>
> There is nothing fundamentally wrong with the OOP paradigm. There is a lot
> wrong with some of the tools used to implement it, as noted in the previous
> paragraph. The on-going progress in software architecture and patterns
> has benefitted from the concepts of object technology.
I would like to see an example of patterns making a custom business
application better than the competitors. I've seen possibly okay
systems software examples, but not good biz examples.
>
> I realize that nothing I have said will persuade those naysayers who insist on
> digging in their feet and declaiming against OOP. "He convinced against his
> will, is of the same opinion still," continues to ring true, even in this kind
> of
> an argument. However, my observation regarding their contributions, so far,
> is that they have quite limited experience actually building systems with OOP,
> or limited experience doing so using good tools and languages (C++ doesn't
> count since it is inherently error-prone).
>
> Richard Riehle
-T-
adaw...@sbcglobal.net
>
> adaw...@sbcglobal.net wrote:
>> "topmind" <top...@technologist.com> wrote in message
>> >
>> > That greatly depends on the language.
>> >
>> The fact that something _can_ be done in a given manner
>> does not mean it _should_ be done that way.
>
> You have to *show* OOP being better, not merely claim you are smart
> and experienced. Use code and realistic change scenarios applied to
> it, for example. If you don't want to do it, then just say so. We
> don't need yet more unverifiable anecdotes, they are a cheap commodity
> on the web, to be frank. People come to see evidence, not read resumes
> from people who have very positive views of themselves.
>
data processing systems that have been developed successfully
using OOP. Of course, there are also a lot of such systems
where OOP was used badly.
>>
>
> I find at least two problems with OO's approach to "extension without
> modification".
>
> The first is that most changes in the real world are *not* tree-
> shaped. Overriding subtypes generally assumes a tree-shaped extension
> pattern. (OO does not have to use trees, but it is far messier than
> the competition, at least not better, when it does such.) I find sets
> a better way to manage variations/features than trees and believe this
> to be an inharent advantage of sets. They are far more flexible and
> don't force you to commit to one dimension/factor being artificially
> dominant. Trees may be okay in the short-term, but as more features
> are piled on, they cannot handle it.
>
Eiffel, one is not restricted to the usual tree approach. Even so, levels
of abstraction do work well in real life. In Ada, a language that I
have found useful, the object model is augmented with a feature of
child library units that are a lightweight form of programming by
extension that does not require the standard model of inheritance.
Object components are not restricted to tree structures. And, message
passing via delegation does not depend on inheritance. Another powerful
variation is genericity. While this is not found in every OOP language,
it is an essential feature of Eiffel, Ada, Java, and C++ (as templates). I
admit that the template model of C++, while quite powerful, is also
full of potential for making a horrid mess of things. But this same feature
in Eiffel and Ada is a stable and effective adjunct to the object model.
There are a lot of variations for design in OOP that go beyond
inheritance alone.
> The second is granularity. Real-world changes often don't always fit
> the grain of one's code granularity. Thus, in practice one has to do
> things like figure out how to override one-third of a method. It can
> be a lot of code-rework to do such. And IF statement is like a
> calliper that can reach over any range in any part of the code, and
> this is less subject to granularity problems and less code re-work.
> (If there is a pattern to many of the IF statements, then often such
> can be tablized to make it easier to see and manage.)
>
Overriding, done correctly, does not require the code rework you
speak of. The principle is "open to extension but close to modification."
It works quite well in practice. It works for systems programming,
applications programming, and other kinds of programming. The one
exception, in my experience, is scientific programming where it seems
to have more limited application (limited is not the same as none).
>
> I've pointed this out before, and don't remember you responding.
>
Tables are a good technique for software development. I have used
decision-table languages and I'm quite fond of the EVALUATE statement
in COBOL. I wish more languages had a statement similar to the
EVALUATE statement. I also use tables in other parts of my designs.
>
An IF statement, when doing extensible designs, requires one to revisit
existing implementation code, open it up (like cracking open a chest for
open-heart surgery), and modify it. This is not necessary in a correctly
designed OOP system. It violates the principle of "open to extension,
while closed to modification." I breaks the principles of information
hiding and encapsulation.
>
Further, an IF statement with the kind of global range you suggest is in
violation of the principles of coupling and cohesion. OOP has the
virtue of providing a stronger model of encapsulation, greater opportunity
for cohesion, and limiting the need for excessive coupling.
>
> ADT are a nice concept on paper, but often just don't work in the real
> world. They cannot handle reality very well.
>
This statement, by itself, flies in the face of a reality that has existed
since the early 1970's. It demonstrates a sad lack of understanding
of the central tenets of software development that have worked for
over thirty years. I recommed you read John Guttag's PhD dissertation
for a more comprehensive understanding of the concepts of data
and procedural abstraction.
>>
Richard Riehle
topmind
Only to a point. Types hard-ware taxonomies/classifications into code.
Designs are more flexible if taxon/classif assigments are data-driven
instead of hard-wired because sets are simply more flexible than type
systems. It's that simple: sets are better than types for biz apps.
(At least not objectively worse.)
> In Ada, a language that I
> have found useful, the object model is augmented with a feature of
> child library units that are a lightweight form of programming by
> extension that does not require the standard model of inheritance.
How about a demo of it being better than other techniques.
>
> Object components are not restricted to tree structures. And, message
> passing via delegation does not depend on inheritance. Another powerful
> variation is genericity. While this is not found in every OOP language,
> it is an essential feature of Eiffel, Ada, Java, and C++ (as templates). I
> admit that the template model of C++, while quite powerful, is also
> full of potential for making a horrid mess of things. But this same feature
> in Eiffel and Ada is a stable and effective adjunct to the object model.
> There are a lot of variations for design in OOP that go beyond
> inheritance alone.
And they tend to get messier and messier the more they drive away from
the basics of OO. Work-arounds like multiple-inheritance and mixins
are bandages to compensate for lack of respect for set theory. Set
theory kicks ADT's ass in my opinion.
>
> > The second is granularity. Real-world changes often don't always fit
> > the grain of one's code granularity. Thus, in practice one has to do
> > things like figure out how to override one-third of a method. It can
> > be a lot of code-rework to do such. And IF statement is like a
> > calliper that can reach over any range in any part of the code, and
> > this is less subject to granularity problems and less code re-work.
> > (If there is a pattern to many of the IF statements, then often such
> > can be tablized to make it easier to see and manage.)
> >
> Overriding, done correctly, does not require the code rework you
> speak of.
Then how do you override 1/3 of a method without lots of rework?
> The principle is "open to extension but close to modification."
> It works quite well in practice.
I haven't seen it. OO'ers just say, "just refactor, get used to
refactoring". They don't avoid change, they embrace change and give it
a job title. That is selling out to the Job Security Gods. OO'ers like
200 lines of code to print Hello World because it is job security.
KISS is murdered in modern OO frameworks. Modern OO is Beurocracy
Oriented Programming.
> It works for systems programming,
> applications programming, and other kinds of programming. The one
> exception, in my experience, is scientific programming where it seems
> to have more limited application (limited is not the same as none).
> >
> > I've pointed this out before, and don't remember you responding.
> >
> Tables are a good technique for software development. I have used
> decision-table languages and I'm quite fond of the EVALUATE statement
> in COBOL. I wish more languages had a statement similar to the
> EVALUATE statement. I also use tables in other parts of my designs.
I am not necessarily suggesting code-in-tables as the only solution
here.
> >
> An IF statement, when doing extensible designs, requires one to revisit
> existing implementation code, open it up (like cracking open a chest for
> open-heart surgery), and modify it. This is not necessary in a correctly
> designed OOP system.
Most IF statements add *features*. Tree-based subtyping cannot handle
non-tree additions, and non-tree subtyping is messy and shanty-town
looking (and probably subject to other code rework anyhow.)
Note that in change management, "cracking open a routine" is not
necessarily the worse sin. OO'ers exaggerate the risk of such. A more
important metric is reducing the *total* code rework. It is often
safer to bust into a function to change 2 lines of code rather than
alter 15 to pay offerings to the "encapsuation gods". This is another
OO book myth that needs to be killed or at least put in perspective.
> It violates the principle of "open to extension,
> while closed to modification." I breaks the principles of information
> hiding and encapsulation.
> >
> Further, an IF statement with the kind of global range you suggest is in
> violation of the principles of coupling and cohesion.
I didn't necessary suggest a global range. The vast majority are
local.
> OOP has the
> virtue of providing a stronger model of encapsulation, greater opportunity
> for cohesion, and limiting the need for excessive coupling.
Show me with a realistic biz example. I've grown weary of brochure-
like claims.
> >
> > ADT are a nice concept on paper, but often just don't work in the real
> > world. They cannot handle reality very well.
> >
> This statement, by itself, flies in the face of a reality that has existed
> since the early 1970's. It demonstrates a sad lack of understanding
> of the central tenets of software development that have worked for
> over thirty years. I recommed you read John Guttag's PhD dissertation
> for a more comprehensive understanding of the concepts of data
> and procedural abstraction.
I think YOU are the unlearned one here, not me. Sets are powerful and
OO does not natively do them. Outside of inheritance trees, OO is
shanty-town-like graphs. Sets usually have more discipline and meta-
ability than graphs. We tossed graphs when we went away from Goto's,
but OO is trying to bring the data-structure equivalence of them back.
Graphs are messy to change. It is easier to study the *change impact*
with sets because query techniques for sets are better understood at
this point in history. Sets are more "mathable" than graphs. Graphs
run, but they are ugly to work with, change, and manage. Non-trivial
OO usually turns into messy navigational graphs. If you are the only
one on earth to avoid that fate, congratulations. But, most OO out
there cannot and creates crap in the end. I'll take procedural/
relational messes over OO messes any day.
If you know the magic to taming the wild shanty-town structure graphs
of OO, then please document it so others don't repeat the messes.
Otherwise I will use the database for the big picture and routines to
execute individual relatively self-contained tasks. It is cleaner,
more consistent, and better understood. At least not objectively
worse than OO.
OO has not found a disciplined way to manage LINKS between objects. An
individual object may be fairly simple and intuitive, but for non-
trivial apps one must be able to get their head around the LINKS
between objects in order to manage, understand, repair, and add
features to them. There is no consensus method to clean and normalize
them, and what exists sure looks shanty-town to me.
> >>
> Richard Riehle
-T-
Mark Nicholls
> I find at least two problems with OO's approach to "extension without
> modification".
>
> The first is that most changes in the real world are *not* tree-
> shaped. Overriding subtypes generally assumes a tree-shaped extension
> pattern. (OO does not have to use trees, but it is far messier than
> the competition, at least not better, when it does such.) I find sets
> a better way to manage variations/features than trees and believe this
> to be an inharent advantage of sets. They are far more flexible and
> don't force you to commit to one dimension/factor being artificially
> dominant. Trees may be okay in the short-term, but as more features
> are piled on, they cannot handle it.
>
> The second is granularity. Real-world changes often don't always fit
> the grain of one's code granularity. Thus, in practice one has to do
> things like figure out how to override one-third of a method. It can
> be a lot of code-rework to do such. And IF statement is like a
> calliper that can reach over any range in any part of the code, and
> this is less subject to granularity problems and less code re-work.
> (If there is a pattern to many of the IF statements, then often such
> can be tablized to make it easier to see and manage.)
>
Oh right!....so you've been disputing it even as a distinctive example
of OOP up to now, but all of a sudden you've forgotted that fact and
given a reasoned answer on the basis that it is a distinctive aspect
of OOP.
Thanks for completely wasting my time.
topmind
I apologize, but I am not understanding your complaint here. What is
"it" in "disputing it"? Note that by "tablized" I don't necessarily
mean putting code in tables, but rather usually making it declarative
rather than repeating the code in the app.
-t-
Mark Nicholls
>
> - Show quoted text -
I spent 10+ posts trying to convince you, relatively formally that OO
was distinctive in the ability to "extension without modification"....
you constantly nit picked and hopped around the issue, invoking
Oracle, relational and all sorts of other tangental
objections.....someone else talks about it and then you cite the
practicality of the OO approach, implicitly accepting the truth of the
claim.
Whats the point?
topmind
I am sorry, but I still don't know what you are talking about. I've
been in a lot of OO debates such that I mix my detractors all up. I
would suggest you label your evidence. Here is a sketchy example:
Code Example: "Lisa"
Description: asdfasdf asd asdf as df asdf...
OOP:
good.shiney(foo);
nice.good.friendly();
rab = new rainbows.and.butterflies();
etc...
Procedural/Relational:
bad(bloaty);
bloaty(bad + no_good);
if (bad) {hardToChange()};
etc...
Scenario 1:
User wants a new product with green lights that beeps every third
Friday.
OOP Changes:
foo.bar()....
P/R Changes:
asdfas().....
case(99)...
Scenario 2:
(etc.....)
To me, this is how you document superiority related to change
scenarios. At least give your evidence labels, and/or a date to search
by. (A wiki such as C2.com may be better for such.)
-T-
Mark Nicholls
>
> - Show quoted text -
Your example code is nonsensical...and all of a sudden includes
relational...which is irrelevant (again).
OOP
void ProductActivate(Product product)
{
product.go();
}
procedural
void ProductActivate(Product product)
{
switch case (product.Name)
{
case "Foo1":
{
product.Beep();
}
case "Foo2":
{
product.Buzz();
}
....
....
..
}
}
etc
"User wants a new product with green lights that beeps every third
Friday."
OOP changes.....*none*!
procudural changes
switch case (product.Name)
{
case "Foo1":
{
product.Beep();
}
case "Foo2":
{
product.Buzz();
}
....
....
..
// ADDITIONAL code.
case "BeepEvery2ndFriday"
{
product.whateveritsawasteoftime();
}
}
ggr...@bigfoot.com
> > Mark Nicholls wrote:
> > > Whats the point?
> > Code Example: "Lisa"
> > OOP:
> > Procedural/Relational:
> > Scenario 1:
> > OOP Changes:
> > foo.bar()....
> > P/R Changes:
> > asdfas().....
> > case(99)...
> > Scenario 2:
> > (etc.....)
> Your example code is nonsensical...and all of a sudden includes
> relational...which is irrelevant (again).
> OOP
> void ProductActivate(Product product)
> {
> product.go();
>
> }
> procedural
> }
> etc
There is an issue that you missed here : the Product type itself.
In a procedural programming language (C, Modula-2, old Ada etc) , the
Product
type will have to be the *union of all the data properties of all the
product
types* (variant records etc) .
Variant records are the most appalling form of stamp coupling known to
programming. Changing one data property of one product variant affects
everything that uses the Product type.
Regards,
Steven Perryman
Mark Nicholls
>
> - Show quoted text -
I completely agree.
I was just trying to give a like for like version of topminds
example...i.e. the point being there is no change to the client
code....
topmind
>
> - Show quoted text -
In the real world you don't model products as sub-types (is-a). It
does not scale. You model them as having a SET of features. You assume
the features can be independent of one another such that you can add
new ones or remove old ones without affecting other features
(validation is used to flag non-permitted feature combo's). OO's
techniques tend to overcouple features. The actual tracking of which
product has which features is done in tables. This allows one to
decouple the code from domain classifications/taxonomies. Entity
taxonomies in code is BAD DESIGN.
Then the code tends to resemble:
doSomething(p) {
if (p.hasFeatureX) {.....}
if (p.hasFeatureY) {
....
if (p.hasFeatureZ Or p.hasFeatureR) {
....
}
}
....
}
This is an oversimplification, but my code does tend to look this way.
I will agree that all the interweaving feature conditionals can be
messy. But, I've never ever seen an OO'er successfully make it cleaner
without making unrealistic assumptions. Issues to consider:
1. Each routine/task tends to use different features because different
features tend to affect them. In other words, the pattern of which
task uses which feature tends to be somewhat random.
2. Feature selection may involve features of multiple entities. For
example, discounts may not only be affected by the product category,
but also by the nature (attributes of) the purchaser. Thus, we cannot
focus on just one entity when formulating a solution.
If you have the magic OO pattern to solve this, here is your chance to
be a herOO...
-T-
S Perryman
news:1174997454.4...@p77g2000hsh.googlegroups.com...
> I completely agree.
> I was just trying to give a like for like version of topminds
> example...i.e. the point being there is no change to the client code.
And I have added the other known major problem with the
procedural paradigm for this scenario : stamp coupling due to variant
records.
Regards,
Steven Perryman
Mark Nicholls
what if it doesn't need to scale?
> You model them as having a SET of features.
so you implement this in OO....you still *don't* need to change the
source code, you just iterate through the features (that implement a
common supertype) and invoke the behaviour on that.
This is just another cop out, you don't like the example so move the
goal posts.
> You assume
> the features can be independent of one another such that you can add
> new ones or remove old ones without affecting other features
> (validation is used to flag non-permitted feature combo's). OO's
> techniques tend to overcouple features. The actual tracking of which
> product has which features is done in tables. This allows one to
> decouple the code from domain classifications/taxonomies. Entity
> taxonomies in code is BAD DESIGN.
depends on context....
It another example of 'nay saying'.
>
> Then the code tends to resemble:
>
> doSomething(p) {
> if (p.hasFeatureX) {.....}
> if (p.hasFeatureY) {
> ....
> if (p.hasFeatureZ Or p.hasFeatureR) {
> ....
> }
> }
> ....
>
> }
how about
foreach feature in a.features
{
feature.Foo();
}
!
look still no client changes!
>
> This is an oversimplification, but my code does tend to look this way.
mines a simplification too...but much of my code looks like that.
>
> I will agree that all the interweaving feature conditionals can be
> messy. But, I've never ever seen an OO'er successfully make it cleaner
> without making unrealistic assumptions. Issues to consider:
see above, OO is not inconsistent with 'set' based approaches, being
able to have 2 ways to skin the cat is better than 1.
>
> 1. Each routine/task tends to use different features because different
> features tend to affect them. In other words, the pattern of which
> task uses which feature tends to be somewhat random.
>
> 2. Feature selection may involve features of multiple entities. For
> example, discounts may not only be affected by the product category,
> but also by the nature (attributes of) the purchaser. Thus, we cannot
> focus on just one entity when formulating a solution.
>
> If you have the magic OO pattern to solve this, here is your chance to
> be a herOO...
it can only be so simple, and no simpler.....there is no magic
anywhere.
I still don't change the client code on extension, which is the only
'magic' I claimed, you disputed, I gave up, you accepted, I come back,
you move the goal posts again.
>
> -T-- Hide quoted text -
topmind
If it will stay small and *not* change, then the difference between OO
and procedural will not matter much: no new conditions nor new method/
classes. OO'ers brags about handling new requirements and "large
applications". If you are changing what OO allegedly helps, then
please state so.
>
> > You model them as having a SET of features.
>
> so you implement this in OO....you still *don't* need to change the
> source code, you just iterate through the features (that implement a
> common supertype) and invoke the behaviour on that.
I would like to see a fuller example which assumes that product info
is stored in a RDBMS, because even if you use OOP for the app-side,
most of the product info will be stored in a RDBMS in the real world.
Thus, you have to translate feature tablized lists into instantiated
objects. Showing the just post-instantiated objects is not showing a
lot of RDB-to-OO translation issues.
>
> This is just another cop out, you don't like the example so move the
> goal posts.
I don't know what you are talking about. What moved? Your example was
not realistic, so I made it more realistic. If being more real is a
"copout", then I am indeed guilty. OO is better for toy examples?
woopee doo. I won't even dispute that. (The "green light gizmo"
example was not meant to be an exactual scenario of mine, but to
illustrate a PRESENTATION of evidence. If that is what you are fussing
about.)
>
> > You assume
> > the features can be independent of one another such that you can add
> > new ones or remove old ones without affecting other features
> > (validation is used to flag non-permitted feature combo's). OO's
> > techniques tend to overcouple features. The actual tracking of which
> > product has which features is done in tables. This allows one to
> > decouple the code from domain classifications/taxonomies. Entity
> > taxonomies in code is BAD DESIGN.
>
> depends on context....
>
> It another example of 'nay saying'.
As a general rule, I find it to be true. Code is complex enough
without sticking noun taxonomies into code. And databases handle
managing those better because you can search, sort, edit, and report
on them easier. Code is too stiff and hard-to-read for such.
>
> >
> > Then the code tends to resemble:
> >
> > doSomething(p) {
> > if (p.hasFeatureX) {.....}
> > if (p.hasFeatureY) {
> > ....
> > if (p.hasFeatureZ Or p.hasFeatureR) {
> > ....
> > }
> > }
> > ....
> >
> > }
>
> how about
>
> foreach feature in a.features
> {
> feature.Foo();
> }
How are these related to products? You didn't show that. If there was
a nice clean pattern, I would use a Control Table something like:
table: featureProcesses
---------
featureRef // foreign key to Feature table
taskRef // foreign key to Task table
function // function name or actual code snippet to execute
However, this usually doesn't work well in practice because there is
usually not enough regularity for this to work nicely, and it is hard
to factor commonailities together. Thus, the pattern I showed works
better in practice.
>
> !
>
> look still no client changes!
If there is the regularly you falsely assume, then the above table
would be an even nicer solution than your objects. Plus, you didn't
show the mapping of DB info into your objects. You seem to be assuming
Bubble Memory or the like (an OODBMS of sorts).
>
> >
> > This is an oversimplification, but my code does tend to look this way.
>
> mines a simplification too...but much of my code looks like that.
>
> >
> > I will agree that all the interweaving feature conditionals can be
> > messy. But, I've never ever seen an OO'er successfully make it cleaner
> > without making unrealistic assumptions. Issues to consider:
>
> see above, OO is not inconsistent with 'set' based approaches, being
> able to have 2 ways to skin the cat is better than 1.
OO does not do sets better than relational. It just makes you have to
reinvent a lot of wheels because OO does not do it natively. And there
are off-the-shelf tools to query, report, edit, etc. tables. There is
more standardization between RDBMS than OOP languages.
>
> >
> > 1. Each routine/task tends to use different features because different
> > features tend to affect them. In other words, the pattern of which
> > task uses which feature tends to be somewhat random.
> >
> > 2. Feature selection may involve features of multiple entities. For
> > example, discounts may not only be affected by the product category,
> > but also by the nature (attributes of) the purchaser. Thus, we cannot
> > focus on just one entity when formulating a solution.
> >
> > If you have the magic OO pattern to solve this, here is your chance to
> > be a herOO...
>
> it can only be so simple, and no simpler.....there is no magic
> anywhere.
>
> I still don't change the client code on extension, which is the only
> 'magic' I claimed, you disputed, I gave up, you accepted, I come back,
> you move the goal posts again.
>
See above about "moving goal posts". Note that in the real world they
*do* move. It is called "handling changes in requirements gracefully".
That is a key issue here.
-T-
Mark Nicholls
So you do accept it?...there is an implication that if there is a
change there is a difference.
> no new conditions nor new method/
> classes. OO'ers brags about handling new requirements and "large
> applications". If you are changing what OO allegedly helps, then
> please state so.
Again you insert others arguments......all this thread was about was
you objected(!) to me claiming OOP to be a generalisation of
procedural programming, I demonstrated it, you rejected, I
demonstrated it again, you still rejected it, I give up and go away,
you have a conversation with someone else and implicitly accept the
fact, but reject it's value on practical grounds...
thats fine, I have no issue with you rejecting it on practicality as
long as you accept the premise.
>
>
>
> > > You model them as having a SET of features.
>
> > so you implement this in OO....you still *don't* need to change the
> > source code, you just iterate through the features (that implement a
> > common supertype) and invoke the behaviour on that.
>
> I would like to see a fuller example which assumes that product info
> is stored in a RDBMS, because even if you use OOP for the app-side,
> most of the product info will be stored in a RDBMS in the real world.
> Thus, you have to translate feature tablized lists into instantiated
> objects. Showing the just post-instantiated objects is not showing a
> lot of RDB-to-OO translation issues.
Again it's a tangental aside....if you accept the original statement,
which you now seem to be doing implicitly, the OO + relational is a
generalisation of procedural + relational.
You can reject the value of the extension, that fine....it's a
different issue.
>
>
>
> > This is just another cop out, you don't like the example so move the
> > goal posts.
>
> I don't know what you are talking about. What moved? Your example was
> not realistic, so I made it more realistic. If being more real is a
> "copout", then I am indeed guilty. OO is better for toy examples?
> woopee doo. I won't even dispute that. (The "green light gizmo"
> example was not meant to be an exactual scenario of mine, but to
> illustrate a PRESENTATION of evidence. If that is what you are fussing
> about.)
>
see above....you are now implicitly accepting the premise and
rejecting it's value....fine.....I never claimed to any value, I
*explicitly* caveated the original statement with a clause sayings
it's value was not universally accepted.
>
>
> > > You assume
> > > the features can be independent of one another such that you can add
> > > new ones or remove old ones without affecting other features
> > > (validation is used to flag non-permitted feature combo's). OO's
> > > techniques tend to overcouple features. The actual tracking of which
> > > product has which features is done in tables. This allows one to
> > > decouple the code from domain classifications/taxonomies. Entity
> > > taxonomies in code is BAD DESIGN.
>
> > depends on context....
>
> > It another example of 'nay saying'.
>
> As a general rule, I find it to be true. Code is complex enough
> without sticking noun taxonomies into code. And databases handle
> managing those better because you can search, sort, edit, and report
> on them easier. Code is too stiff and hard-to-read for such.
>
You are arguing with someone who isn't here.....you are (again)
inserting arguments that I have not postulated and then reject
them.....
procedural + relational > OO?.....quite possibly so.....I will happily
discuss it further, if you explicitly accept my original statement
posted 2 weeks ago.
>
> > > Then the code tends to resemble:
>
> > > doSomething(p) {
> > > if (p.hasFeatureX) {.....}
> > > if (p.hasFeatureY) {
> > > ....
> > > if (p.hasFeatureZ Or p.hasFeatureR) {
> > > ....
> > > }
> > > }
> > > ....
>
> > > }
>
> > how about
>
> > foreach feature in a.features
> > {
> > feature.Foo();
> > }
>
> How are these related to products? You didn't show that. If there was
> a nice clean pattern, I would use a Control Table something like:
>
> table: featureProcesses
> ---------
> featureRef // foreign key to Feature table
> taskRef // foreign key to Task table
> function // function name or actual code snippet to execute
>
> However, this usually doesn't work well in practice because there is
> usually not enough regularity for this to work nicely, and it is hard
> to factor commonailities together. Thus, the pattern I showed works
> better in practice.
>
accept the premise explicitly, and we can discuss the value or
'extensibility'.....though you now seem to have moved on to arguing
about polymorphism in general.....a tangent of a tangent...which yet
again I claimed no value for.
>
>
> > !
>
> > look still no client changes!
>
> If there is the regularly you falsely assume, then the above table
> would be an even nicer solution than your objects. Plus, you didn't
> show the mapping of DB info into your objects. You seem to be assuming
> Bubble Memory or the like (an OODBMS of sorts).
>
The point I am still trying to get across is about invariance under
extension.
You are talking to ghosts of previous OO'ers....there not
here....there's only me.
>
>
> > > This is an oversimplification, but my code does tend to look this way.
>
> > mines a simplification too...but much of my code looks like that.
>
> > > I will agree that all the interweaving feature conditionals can be
> > > messy. But, I've never ever seen an OO'er successfully make it cleaner
> > > without making unrealistic assumptions. Issues to consider:
>
> > see above, OO is not inconsistent with 'set' based approaches, being
> > able to have 2 ways to skin the cat is better than 1.
>
> OO does not do sets better than relational. It just makes you have to
> reinvent a lot of wheels because OO does not do it natively. And there
> are off-the-shelf tools to query, report, edit, etc. tables. There is
> more standardization between RDBMS than OOP languages.
>
>
quite possibly....but it is irrelevant.
>
>
>
>
>
> > > 1. Each routine/task tends to use different features because different
> > > features tend to affect them. In other words, the pattern of which
> > > task uses which feature tends to be somewhat random.
>
> > > 2. Feature selection may involve features of multiple entities. For
> > > example, discounts may not only be affected by the product category,
> > > but also by the nature (attributes of) the purchaser. Thus, we cannot
> > > focus on just one entity when formulating a solution.
>
> > > If you have the magic OO pattern to solve this, here is your chance to
> > > be a herOO...
>
> > it can only be so simple, and no simpler.....there is no magic
> > anywhere.
>
> > I still don't change the client code on extension, which is the only
> > 'magic' I claimed, you disputed, I gave up, you accepted, I come back,
> > you move the goal posts again.
>
> See above about "moving goal posts". Note that in the real world they
> *do* move.
I claimed nothing about practicality....you are moving the goal posts.
> It is called "handling changes in requirements gracefully".
> That is a key issue here.
no the only issue is you disputed a factual statement, rejected the
demonstration, and then implicitly accepted it when talking to someone
else.....you now reject the value....thats fine...I claimed no
value....just the property.
Do you accept the property?
>
> -T-- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -
Is there a point?.....do you ever get the feeling that you
(specifically) constantly have these sorts of threads.....you
constantly reject everything in order to postulate your arguments even
when they are not pertinent, these arguments may have value, but why
should I give credence to them if you insist on 'nay saying' and
denial of others, it becomes a destructive debate.
topmind
What is "it"? Please cut down on pronouns.
>
> > no new conditions nor new method/
> > classes. OO'ers brags about handling new requirements and "large
> > applications". If you are changing what OO allegedly helps, then
> > please state so.
>
> Again you insert others arguments......all this thread was about was
> you objected(!) to me claiming OOP to be a generalisation of
> procedural programming,
No, somebody else came and started a new sub-topic about OO allegedly
better handling change and variations. See the topic title. That is
the title change I made to keep track of the new topic separate from
the old one. You are the confused one, not me. In case your newsreader
is supressing it for some reason, here it is again:
"Re: OO and Extending (Was: Is Procedural Paradigm a basis of OO
Paradigm?)"
> I demonstrated it, you rejected, I
> demonstrated it again, you still rejected it, I give up and go away,
Because you were wrong. It's that simple. You used a tight definition
of procedural (which I reject) and a loose OO definition. It is easy
to win a "subset" argument doing that.
-T-
Mark Nicholls
it is the statement that OO was a generalisation of procedural under
extension.
>
>
> > > no new conditions nor new method/
> > > classes. OO'ers brags about handling new requirements and "large
> > > applications". If you are changing what OO allegedly helps, then
> > > please state so.
>
> > Again you insert others arguments......all this thread was about was
> > you objected(!) to me claiming OOP to be a generalisation of
> > procedural programming,
>
> No, somebody else came and started a new sub-topic about OO allegedly
> better handling change and variations. See the topic title. That is
> the title change I made to keep track of the new topic separate from
> the old one. You are the confused one, not me. In case your newsreader
> is supressing it for some reason, here it is again:
>
> "Re: OO and Extending (Was: Is Procedural Paradigm a basis of OO
> Paradigm?)"
seems that the new subtopic is probably a better title for what we
were talking about....
I'm sorry if you are not able to admit your mistake due to the
incorrect title being displayed...
>
> > I demonstrated it, you rejected, I
> > demonstrated it again, you still rejected it, I give up and go away,
>
> Because you were wrong. It's that simple. You used a tight definition
> of procedural (which I reject) and a loose OO definition. It is easy
> to win a "subset" argument doing that.
but then you implicitly accept the argument when talking to someone
else.....you then object on practical grounds...the original premise
is accepted and ignored.
>
> -T-- Hide quoted text -
>
> - Show quoted text -
Forget it...there's no point wasting any more time on it....if I told
you the sky was blue, you'd point out that at night it was
black.....so I wasn't technically correct.
topmind
> > > Again you insert others arguments......all this thread was about was
> > > you objected(!) to me claiming OOP to be a generalisation of
> > > procedural programming,
> >
> > No, somebody else came and started a new sub-topic about OO allegedly
> > better handling change and variations. See the topic title. That is
> > the title change I made to keep track of the new topic separate from
> > the old one. You are the confused one, not me. In case your newsreader
> > is supressing it for some reason, here it is again:
> >
> > "Re: OO and Extending (Was: Is Procedural Paradigm a basis of OO
> > Paradigm?)"
>
> seems that the new subtopic is probably a better title for what we
> were talking about....
>
> I'm sorry if you are not able to admit your mistake due to the
> incorrect title being displayed...
*My* mistake???? *sigh*
"Incorrect"? Oh boy. Enron Lawyer flashback...
You could perhaps argue that the person changing the topic to
extendability (not me) should have created a full new topic from
scratch, but if they don't, then go with the flow rather than create a
conspiracy out it. Forks happen, no need to be a drama queen.
>
> >
> > > I demonstrated it, you rejected, I
> > > demonstrated it again, you still rejected it, I give up and go away,
> >
> > Because you were wrong. It's that simple. You used a tight definition
> > of procedural (which I reject) and a loose OO definition. It is easy
> > to win a "subset" argument doing that.
>
> but then you implicitly accept the argument when talking to someone
> else.....you then object on practical grounds...the original premise
> is accepted and ignored.
I suggest you reply to my last reply on the "subset" topic if you wish
to continue that issue.
>
> >
> > -T-- Hide quoted text -
> >
> > - Show quoted text -
>
> Forget it...there's no point wasting any more time on it....if I told
> you the sky was blue, you'd point out that at night it was
> black.....so I wasn't technically correct.
Of course the problem is me, and you are a perfect sparkling rainbow
angel.
Mark Nicholls
quite possibly....it seems to be a common theme.
> -T-
> oop.ismad.com- Hide quoted text -
topmind
Mark Nicholls wrote:
> > > Forget it...there's no point wasting any more time on it....if I told
> > > you the sky was blue, you'd point out that at night it was
> > > black.....so I wasn't technically correct.
> >
> > Of course the problem is me, and you are a perfect sparkling rainbow
> > angel.
> >
>
> quite possibly....it seems to be a common theme.
A legend in your own mind.
adaw...@sbcglobal.net
>
> adaw...@sbcglobal.net wrote:
>
> I think YOU are the unlearned one here, not me. Sets are powerful and
> OO does not natively do them. Outside of inheritance trees, OO is
> shanty-town-like graphs. Sets usually have more discipline and meta-
> ability than graphs. We tossed graphs when we went away from Goto's,
> but OO is trying to bring the data-structure equivalence of them back.
> Graphs are messy to change. It is easier to study the *change impact*
> with sets because query techniques for sets are better understood at
> this point in history. Sets are more "mathable" than graphs. Graphs
> run, but they are ugly to work with, change, and manage. Non-trivial
> OO usually turns into messy navigational graphs. If you are the only
> one on earth to avoid that fate, congratulations. But, most OO out
> there cannot and creates crap in the end. I'll take procedural/
> relational messes over OO messes any day.
>
been in this field for over forty years and have watched fad after
fad come and go. OO is not the perfect solution to every
software problem and, when done badly, as it usually is, it can
be more of a mess than simple procedural or even ad hoc
approaches.
Further, as I have noted often before as a paraphrase to Newton's
Third Law of Motion, every new set of software solutions results
in an equal opposite of new problems. OO does introduce a whole
host of interesting problems, and most people seem to get the
wrong answers to them
That being said, there is no need for magic, as you imply in the
paragraph below. There is a need for deeper understanding of
both the benefits and the potential pitfalls of OO -- just as there
is with any other software practice.
>
> If you know the magic to taming the wild shanty-town structure graphs
> of OO, then please document it so others don't repeat the messes.
> Otherwise I will use the database for the big picture and routines to
> execute individual relatively self-contained tasks. It is cleaner,
> more consistent, and better understood. At least not objectively
> worse than OO.
>
What a strange tangle of misconceptions we find in that paragraph. While
I admit that many naive OO practitioners lack the competence to get
it right, those same practitioners will likely get it wrong regardless of
what process the choose. However, those who do understand the
challenges, including the dangers, have a record of creating excellent
software using object technology, including OOP.
In my own practice, I have seen such excellence. I have also seen some
dismal attempts. The fact that there are failures (and there are) seems to
be more important that the fact that there are successes. We rarely talk
about the successes since there is nothing spectacular about them. They
simply work.
The focus on the failures seems to be just another form of "yellow
journalism." Those who spend their time ranting about those failures
instead of recognizing the successes are just as bad as those silly
tabloids one sees in the supermarket check-out lines that proclaim
things about the sex lives of humans with inter-galactic demons.
Your own rantings, clearly not grounded in the experience of success with
OOP, border on that same kind of silliness. You look for failures. Insist
that OOP is a failure. Then you keep insisting that OOP projects are
failures. Why do you think people use OOP if it is such a failure?
As you know, I am one of those people who believes that C and C++
are horrid languages because they are error-prone and require excessive
time debugging software instead of developing it. Yet, I am willing to
acknowledge that, used carefully and intelligently, a lot of good software
has been developed using those languages. Perhaps you see OOP in
this same light: it is possible to use it well, but success is only due to
the heroic efforts of people with special talent.
>
> OO has not found a disciplined way to manage LINKS between objects. An
> individual object may be fairly simple and intuitive, but for non-
> trivial apps one must be able to get their head around the LINKS
> between objects in order to manage, understand, repair, and add
> features to them. There is no consensus method to clean and normalize
> them, and what exists sure looks shanty-town to me.
>
It is sad, then, that you have been so sloppy in your own attempts to
use OOP; or that you have only seen people use it inefffectively. But
your experience notwithstanding to the contrary (I like that phrase
but it is also rather silly, isn't it), really good OOP software systems
are being developed and deployed all the time. I know of many
such systems written in both Ada and Eiffel. I also know of some
outstanding systems written in C++ (in spite of its being error-prone).
A friend of mine makes a very good living traveling around to COBOL
sites doing training in ObjectCOBOL. There is a huge inventory of
Java software already deployed using the Java libraries, and those
libraries are designed around the concepts of OOP.
You can deny the usefulness of OOP, rant about its alleged deficiencies,
and tout your equally flawed alternatives, but you cannot refute the
fact that a growing body of OOP software is being deployed that
effectively solves a wide range of business and business data processing
problems. Such an assertion is either the result of deliberate biases,
blatant ignorance, or raw stupidity. I am sure you are not stupid, so
I can only conclude that you are ignorant since I would not want to
suggest that you are deliberately biased. Ignorance is not a bad
thing, but one ought to know when a lack of knowledge gives the
appearance of bias. If you really understood OOP, you would also
understand when it is useful and when it is not rather than make these
silly pronouncements about it.
Perhaps, once you are willing to examine it in the light of well-formed
knowledge, you will be able to bring a more balanced perpective to
your contribution. Oh. Sorry. The other possibility, not mentioned
above, is that you simply like to argue about such things and facts
are not of any importance in your argument.
Richard Riehle
adaw...@sbcglobal.net
Arguing with this person about OOP is like having a
conversation with the Mad Hatter. No reasonable
demonstration of your point will make any impact.
He is determined to simply waltz around in circles with
anyone who takes the trouble to engage him. His mind
is made up and made up out of either the eagerness to
simply contend with anyone who takes the trouble to
discuss the the topic, or his eagerness to demonstrate
his own monumental ignorance of the topic.
I don't know why he bothers to frequent this forum since
he makes no useful contribution to it. Rather, he takes
up a lot of bandwidth that could be better spent, by all
of us, discussing solutions to problems. Topmind is
not a problem worth dealing with and I am done with
him.
Oh. I will not reply to any of his nonsensical responses
to this assessment.
Richard Riehle
"Mark Nicholls" <Nichol...@mtvne.com> wrote in message
news:1174472478.8...@y66g2000hsf.googlegroups.com...
Mark Nicholls
> Mark,
>
> Arguing with this person about OOP is like having a
> conversation with the Mad Hatter. No reasonable
> demonstration of your point will make any impact.
>
> He is determined to simply waltz around in circles with
> anyone who takes the trouble to engage him. His mind
> is made up and made up out of either the eagerness to
> simply contend with anyone who takes the trouble to
> discuss the the topic, or his eagerness to demonstrate
> his own monumental ignorance of the topic.
>
> I don't know why he bothers to frequent this forum since
> he makes no useful contribution to it. Rather, he takes
> up a lot of bandwidth that could be better spent, by all
> of us, discussing solutions to problems. Topmind is
> not a problem worth dealing with and I am done with
> him.
>
> Oh. I will not reply to any of his nonsensical responses
> to this assessment.
>
> Richard Riehle
>
Point taken,
I naively engaged.....
it was a big mistake.
> "Mark Nicholls" <Nicholls.M...@mtvne.com> wrote in message
Leslie Sanford
<adaw...@sbcglobal.net> wrote:
> Mark,
>
> Arguing with this person about OOP is like having a
> conversation with the Mad Hatter. No reasonable
> demonstration of your point will make any impact.
>
> He is determined to simply waltz around in circles with
> anyone who takes the trouble to engage him. His mind
> is made up and made up out of either the eagerness to
> simply contend with anyone who takes the trouble to
> discuss the the topic, or his eagerness to demonstrate
> his own monumental ignorance of the topic.
>
> I don't know why he bothers to frequent this forum since
> he makes no useful contribution to it. Rather, he takes
> up a lot of bandwidth that could be better spent, by all
> of us, discussing solutions to problems. Topmind is
> not a problem worth dealing with and I am done with
> him.
I was curious about the activity on comp.object a few days ago, so I
looked up the group's statistics on google:
http://groups.google.com/group/comp.object/about?hl=en
The aforementioned poster is listed as comp.object's all time poster.
I make no comment on this other than I think that it is... interesting.
P.S. Robert C. Martin is listed several times (under different email
accounts). Combining his total puts him in first place by only one post
at the time that I'm posting this.
topmind
That could be said about any paradigm/technique.
> >
> > If you know the magic to taming the wild shanty-town structure graphs
> > of OO, then please document it so others don't repeat the messes.
> > Otherwise I will use the database for the big picture and routines to
> > execute individual relatively self-contained tasks. It is cleaner,
> > more consistent, and better understood. At least not objectively
> > worse than OO.
> >
> What a strange tangle of misconceptions we find in that paragraph. While
> I admit that many naive OO practitioners lack the competence to get
> it right, those same practitioners will likely get it wrong regardless of
> what process the choose. However, those who do understand the
> challenges, including the dangers, have a record of creating excellent
> software using object technology, including OOP.
Until it has been documented, such claims should be treated no
different than Bigfoot sightings.
>
> In my own practice, I have seen such excellence. I have also seen some
> dismal attempts. The fact that there are failures (and there are) seems to
> be more important that the fact that there are successes. We rarely talk
> about the successes since there is nothing spectacular about them. They
> simply work.
Assembler and COBOL have plenty of working apps also.
>
> The focus on the failures seems to be just another form of "yellow
> journalism." Those who spend their time ranting about those failures
> instead of recognizing the successes are just as bad as those silly
> tabloids one sees in the supermarket check-out lines that proclaim
> things about the sex lives of humans with inter-galactic demons.
I'll recognize success when I see it and can study it. Same with
Bigfoot.
>
> Your own rantings, clearly not grounded in the experience of success with
> OOP, border on that same kind of silliness. You look for failures. Insist
> that OOP is a failure. Then you keep insisting that OOP projects are
> failures. Why do you think people use OOP if it is such a failure?
Job security and fad-chasing. Some CIO reads an airline magizine with
all the cute shape and animal OO examples and requires his shop to use
OOP. OO makes a mess, but as long as companies pay people to work with
the OO messes, they will. They are told by the fadsters that if they
stick with it, the benefits will eventually show up. Eventually they
are locked in and stop caring; same way they got married to Microsoft
for life.
>
> As you know, I am one of those people who believes that C and C++
> are horrid languages because they are error-prone and require excessive
> time debugging software instead of developing it. Yet, I am willing to
> acknowledge that, used carefully and intelligently, a lot of good software
> has been developed using those languages. Perhaps you see OOP in
> this same light: it is possible to use it well, but success is only due to
> the heroic efforts of people with special talent.
Perhaps the same is true of whatever the OO proponents abandoned to
switch to OO. This underscores my belief that paradigm preference may
be subjective: we gravitate towards those techniques that best model
the way we think. Software is not really about the external world,
but the heads of the maintainers.
Plus, I think it is fair to say that if only a handful of people are
capable of getting OO right (something you don't seem to dispute),
THAT ALONE is reason to toss it. Appearently OO is hard to get right
and hard to show being good and hard to document being good in
realistic settings.
Houston, we have a prOOblem.
If I think better with sets than graphs, why the hell force me to
think in graphs??? Bend the damned machine to fit the way I think, not
the other way around. The box should be our slave, not the other way
around.
> >
> > OO has not found a disciplined way to manage LINKS between objects. An
> > individual object may be fairly simple and intuitive, but for non-
> > trivial apps one must be able to get their head around the LINKS
> > between objects in order to manage, understand, repair, and add
> > features to them. There is no consensus method to clean and normalize
> > them, and what exists sure looks shanty-town to me.
> >
> It is sad, then, that you have been so sloppy in your own attempts to
> use OOP; or that you have only seen people use it inefffectively. But
> your experience notwithstanding to the contrary (I like that phrase
> but it is also rather silly, isn't it), really good OOP software systems
> are being developed and deployed all the time. I know of many
> such systems written in both Ada and Eiffel. I also know of some
> outstanding systems written in C++ (in spite of its being error-prone).
>
> A friend of mine makes a very good living traveling around to COBOL
> sites doing training in ObjectCOBOL. There is a huge inventory of
> Java software already deployed using the Java libraries, and those
> libraries are designed around the concepts of OOP.
>
> You can deny the usefulness of OOP, rant about its alleged deficiencies,
> and tout your equally flawed alternatives, but you cannot refute the
> fact that a growing body of OOP software is being deployed that
> effectively solves a wide range of business and business data processing
> problems.
That is like claiming that since COBOL sales far surpassed Algol, that
COBOL is better than Algol. (The Algol model eventually won via other
languages. It just took a while for the industry to wake up.)
> Such an assertion is either the result of deliberate biases,
> blatant ignorance, or raw stupidity. I am sure you are not stupid, so
> I can only conclude that you are ignorant since I would not want to
> suggest that you are deliberately biased. Ignorance is not a bad
> thing, but one ought to know when a lack of knowledge gives the
> appearance of bias. If you really understood OOP, you would also
> understand when it is useful and when it is not rather than make these
> silly pronouncements about it.
It is about evidence. There is no publicly inspected evidence that OO
is objectively better.
>
> Perhaps, once you are willing to examine it in the light of well-formed
> knowledge,
Yes, it is called "evidence" and open inquirey. AKA, "the scientific
method". "X is good because I say so and I am experienced and smart"
is not real evidence.
> you will be able to bring a more balanced perpective to
> your contribution. Oh. Sorry. The other possibility, not mentioned
> above, is that you simply like to argue about such things and facts
> are not of any importance in your argument.
Claims != Facts
The only fact you offered is that "some OO works well". I won't
dispute that, but it is also true of technologies that now most agree
are uglier than the south side of a north-walking baboon.
>
> Richard Riehle
-t-
topmind
adaw...@sbcglobal.net wrote:
> Mark,
>
> Arguing with this person about OOP is like having a
> conversation with the Mad Hatter. No reasonable
> demonstration of your point will make any impact.
There has NOT been a "reasonable demonstration". If you had such, you
would ram it down my throat every day I come here to discredit me. Why
do OO'ers make so much love with anecdotal evidence? Anecdotal
evidence is crack cocain to OO'ers. OOers: "We don't need no stinkin'
science". "I'm too smart for open evidence."
>
> He is determined to simply waltz around in circles with
> anyone who takes the trouble to engage him. His mind
> is made up and made up out of either the eagerness to
> simply contend with anyone who takes the trouble to
> discuss the the topic, or his eagerness to demonstrate
> his own monumental ignorance of the topic.
>
> I don't know why he bothers to frequent this forum since
> he makes no useful contribution to it. Rather, he takes
> up a lot of bandwidth that could be better spent, by all
> of us, discussing solutions to problems. Topmind is
> not a problem worth dealing with and I am done with
> him.
>
> Oh. I will not reply to any of his nonsensical responses
> to this assessment.
That's right, I am bad and evil and you are good and shiney and have
beautifully laminated OOP evidence in scientific journals.
And then we all wake up....
>
> Richard Riehle
>
-T-
topmind
wrote:
> <adawo...@sbcglobal.net> wrote:
> > Mark,
>
> > Arguing with this person about OOP is like having a
> > conversation with the Mad Hatter. No reasonable
> > demonstration of your point will make any impact.
>
> > He is determined to simply waltz around in circles with
> > anyone who takes the trouble to engage him. His mind
> > is made up and made up out of either the eagerness to
> > simply contend with anyone who takes the trouble to
> > discuss the the topic, or his eagerness to demonstrate
> > his own monumental ignorance of the topic.
>
> > I don't know why he bothers to frequent this forum since
> > he makes no useful contribution to it. Rather, he takes
> > up a lot of bandwidth that could be better spent, by all
> > of us, discussing solutions to problems. Topmind is
> > not a problem worth dealing with and I am done with
> > him.
>
> I was curious about the activity on comp.object a few days ago, so I
> looked up the group's statistics on google:
>
> http://groups.google.com/group/comp.object/about?hl=en
>
> The aforementioned poster is listed as comp.object's all time poster.
>
> I make no comment on this other than I think that it is... interesting.
It is my use of non-OO technologies that allow me to be so
productive :-)
>
> P.S. Robert C. Martin is listed several times (under different email
> accounts). Combining his total puts him in first place by only one post
> at the time that I'm posting this.
>
-T-
S Perryman
> On Mar 30, 5:41 am, "Leslie Sanford" <jabberdab...@BiteMeHotmail.com>
> wrote:
>><adawo...@sbcglobal.net> wrote:
>>>I don't know why he bothers to frequent this forum since
>>>he makes no useful contribution to it. Rather, he takes
>>>up a lot of bandwidth that could be better spent, by all
>>>of us, discussing solutions to problems. Topmind is
>>>not a problem worth dealing with and I am done with
>>>him.
>>I was curious about the activity on comp.object a few days ago, so I
>>looked up the group's statistics on google:
>>http://groups.google.com/group/comp.object/about?hl=en
>>The aforementioned poster is listed as comp.object's all time poster.
>>I make no comment on this other than I think that it is... interesting.
> It is my use of non-OO technologies that allow me to be so
> productive :-)
No, more supporting evidence IMHO of the mental problems that I have often
claimed you seem to be afflicted with (delusion etc). Another quick
analysis of the stats has your infestation of comp.object around the
2000 time-frame.
Given that Robert Martin has been posting on comp.object since the
early 1990s, you have managed to post as much as he has over 15+ yrs
in half the time. Yet I have yet to see anything from you (has anyone ?? )
that can even vaguely be deemed to be beneficial to comp.object as
intended by its Usenet charter.
Regards,
Steven Perryman
topmind
Debunking OO fanatics is my hobby. Some bowl, some keep gardens, some
sail boats, and some of us debunk OO.
As far as "beneficial", you only consider preaching from fellow OO
zealots "beneficial". In that sense, I could never pass your test. I
am like an evolutionist in a creationist forum.
You have no objective evidence that OOP is better. Until you get some,
I will defend non-OO technologies when I see them being trashed.
You attack me personally BECAUSE you have no evidence.
Bashing people is for those without evidence.
Bashing people is for those without evidence.
Bashing people is for those without evidence.
Bashing people is for those without evidence.
>
>
> Regards,
> Steven Perryman