can i learn OOD without any procedural 1st - Theory and Concepts

On Apr 1, 11:28 pm, "topmind" <topm...{}technologist.com> wrote:
> S Perryman wrote:

>> topmind wrote:

TM> What is an example of a good debunking of a given paradigm?

>> Providing a claim made by someone, preferably one documented in
>> some widely-known or available media, and then showing specifically
>> why that claim does not hold.

>> I asked you for a specific example of such actually being done.

My favourite one is by James Randi in the 1970s during the height of
Uri Gellers' fame. In response to the spoon bending phenomenon, Randi
set a bit of metal (comparable in tensile properties etc to an average
metal spoon) in a sealed tube. He may have also rigged the metal to
measuring devices etc in order to get some measure of any force
exerted if the metal bent.

Participants were allowed to influence the metal without physical
contact
with the metal. AFAIK, no one has ever done it.

Randi thus debunked the "psychic powers" claim in a precise,
controlled environment.

But it opened the science as to whether the combination of continual
rubbing of the spoon + human substances (sweat etc) could cause a
physical/chemical effect sufficient to weaken the specific form of
metal
(composition, shape etc) . Which in itself is an interesting
phenomenon
for science to investigate.


>If paradigms are subjective preferences, which I suspect they are, then
>nobody can supply objective proof that one is better than another
>because none is objectively better.

### (a marker for cross-reference)

You have obviously not realised the implications of what you have
written above.


TM> It is not my burden anyhow. If you claim OO is objectively better,
TM> YOU have to prove it, NOT ME. Deflecting the issue to me is a red
TM> herring. I see thru it.

TM> THE BURDEN IS ON THE CLAIMERS.

>> Please cite the references (see above) to where people have claimed
>> OO is "objectively better" (than "procedural" I guess) . If they have
>> been made on comp.object, I do not recall ever seeing them (but I
>> could be wrong) .

>If you don't think OO is objectively better, then simply say so and
>ignore topics that involve such.

1. I am on record in comp.object for years as stating that the
argument
cannot be shown one way or another. Stated frequently over the 7 yrs
of
your infestation on comp.object .

2. I am more interested in why you continue with your tedious
repetitive
rhetoric when 1 is so obvious to a vaguely-intelligent human.


>I've given references for Meyer's and Martin's pro-OO claims with page
>numbers.

1. Feel free to re-post them here.
2. Do these "claims" state that OO is "objectively better" than
"procedural" ??

If the answer to 2 is no, then either cite references to elsewhere
where
claims that OO is "objectively better" than "procedural" have been
made.
Or (yet again) *retract the statement that such claims have ever been
made* by protagonists in the OO field.


>I ignore a lot of stuff on comp.object that I am not interested in or
>don't disagree with. Thus, if you don't disagree that OO is not
>objectively better, why the fuss?

Because you have spent *7 yrs* arguing the toss about something that
*BY YOUR OWN ADMISSION* (see ### ) cannot be shown one way or
another. So unless you can produce citeable references to the claims
about OO that you believe (wrongly) that you have debunked, all you
have
shown is that you have some serious mental problem that means you
have wasted reams of time over 7 yrs.

The pressure is well and truly on you now.

Either you can produce the references to these claims you continually
claim are made about OO, or you have condemned yourself with your
own verdict on 7 yrs of behaviour on comp.object (poor attempts at
debunking something that has never ever been claimed, and that
you have admitted can never be proved) ...


Regards,
Steven Perryman

On Apr 3, 6:38 am, "topmind" <topm...{}technologist.com> wrote:

On Apr 2, 6:43 pm, Patrick May <p...{}spe.com> wrote:

>> "topmind" <topm...{}technologist.com> writes:

>>> He also complained about the limiting dimensions of OO, dispatching
>>> off of mostly a single dimension/factor (type).

>> This is a limitation of some languages, not of OO in general.

> It is hard to tell without a clear, consensus definition of OO. One
> can put function pointers in associative arrays to get OO features out
> of a non-OO language. With a wide enough definition of OO, OO is
> everything.

Rubbish. Just another typical attempt to evade the truth.
Patrick May has explained Paul Grahams' critique precisely.


1. OO prog langs based on the Simula model (known in industry as
"single dispatch" ) are limited when an operation to be executed is
to be determined by both the object being invoked and the types
of the input parameters to that operation (known in industry as
"multiple dispatch" ) .

The grief attempting to emulate multiple dispatch even for just two
variables (object X parameter) with single dispatch is well-known
in industry (the "double dispatch" and Visitor patterns etc) .


2. There are a group of OO prog languages (CLOS etc) that support
multiple dispatch. Therefore the single dispatch problem is not
universal in OOP.

3. Paul Graham is more than aware of the facts stated in 1/2.
After all he is a Lisp programmer. He also *wrote a book* whose
contents *teach people how to use CLOS* . Which means Paul Graham
understands CLOS quite well.

He may well have actually written some of his successful business
s/w in CLOS.


Your attempt to use Paul Graham as an "appeal to authority" as support
for the failings of OO is shown as a fallacy.


Regards,
Steven Perryman

On Apr 2, 12:53 am, "Daniel Parker" <danielapar...{}> wrote:

>For what it's worth, Stepanov's C++ STL doesn't look that great, with
>the benefit of hindsight. Personally, for the collection classes, I
>would have preferred well thought out abstract classes for Bags, Sets,
>Lists, Arrays, Maps, etc., and implementations thereof. You know,
>basic OO, if you accept the notion that the substantative part of OO
>is ADTs.

The STL is IMHO worse than something that a CS101 student would come
up
with (I once wrote some additional simple infrastructure in the style
of
the STL that enhance the STL to make things more akin to something
like
the EiffelBase libraries - I was sick and tired of certain
restrictions
forced on my code etc) .

However, I state this in the full understanding of the issues/
pressures that the STL progenitors were under (providing the pre/post
increment/decrement syntax with iterators, not implementing iterator
traversal as virtual ops for performance reasons etc) , and having to
implement collection libraries myself in C++ . Without said things, I
have no doubt that the STL would be quite different.

The STL has been a good starting point for a std C++ collection
library, but I hope that someone will take it further and make it a
bit more friendly.


Regards,
Steven Perryman

In article <1175585668.425737.227860{}n76g2000hsh.googlegroups.com>,
ggroups{}bigfoot.com wrote:

> On Apr 3, 6:38 am, "topmind" <topm...{}technologist.com> wrote:
>
> On Apr 2, 6:43 pm, Patrick May <p...{}spe.com> wrote:
>
> >> "topmind" <topm...{}technologist.com> writes:
>
> >>> He also complained about the limiting dimensions of OO, dispatching
> >>> off of mostly a single dimension/factor (type).
>
> >> This is a limitation of some languages, not of OO in general.
>
> > It is hard to tell without a clear, consensus definition of OO. One
> > can put function pointers in associative arrays to get OO features out
> > of a non-OO language. With a wide enough definition of OO, OO is
> > everything.
>
> Rubbish. Just another typical attempt to evade the truth.
> Patrick May has explained Paul Grahams' critique precisely.
>
>
> 1. OO prog langs based on the Simula model (known in industry as
> "single dispatch" ) are limited when an operation to be executed is
> to be determined by both the object being invoked and the types
> of the input parameters to that operation (known in industry as
> "multiple dispatch" ) .
>
> The grief attempting to emulate multiple dispatch even for just two
> variables (object X parameter) with single dispatch is well-known
> in industry (the "double dispatch" and Visitor patterns etc) .
>
>
> 2. There are a group of OO prog languages (CLOS etc) that support
> multiple dispatch. Therefore the single dispatch problem is not
> universal in OOP.
>
> 3. Paul Graham is more than aware of the facts stated in 1/2.
> After all he is a Lisp programmer. He also *wrote a book* whose
> contents *teach people how to use CLOS* . Which means Paul Graham
> understands CLOS quite well.
>
> He may well have actually written some of his successful business
> s/w in CLOS.
>
>
> Your attempt to use Paul Graham as an "appeal to authority" as support
> for the failings of OO is shown as a fallacy.


Actually he is right here. Paul Graham is known to strong dislike
CLOS and Common Lisp (no joke). He does not use CLOS.
His Lisp books explain almost no CLOS at all.

He is developing a new Lisp-dialect called Arc which will
not be object-oriented. He develops Arc, because he
does not like Common Lisp.

See Paul about CLOS and OOP here:
http://www.paulgraham.com/noop.html

Well, one may not cite him as an authority about the problems
of CLOS, since he never used it (see the link).




>
>
> Regards,
> Steven Perryman

--
http://lispm.dyndns.org

On Apr 3, 9:21 am, Rainer Joswig <jos...{}lisp.de> wrote:

> ggro...{}bigfoot.com wrote:

TM> He also complained about the limiting dimensions of OO,
dispatching
TM> off of mostly a single dimension/factor (type).

PM> This is a limitation of some languages, not of OO in general.

TM> It is hard to tell without a clear, consensus definition of OO.
One
TM> can put function pointers in associative arrays to get OO features
out
TM> of a non-OO language. With a wide enough definition of OO, OO is
TM> everything.

>> Rubbish. Just another typical attempt to evade the truth.
>> Patrick May has explained Paul Grahams' critique precisely.

>> 1. OO prog langs based on the Simula model (known in industry as
>> "single dispatch" ) are limited when an operation to be executed is
>> to be determined by both the object being invoked and the types
>> of the input parameters to that operation (known in industry as
>> "multiple dispatch" ) .

>> The grief attempting to emulate multiple dispatch even for just two
>> variables (object X parameter) with single dispatch is well-known
>> in industry (the "double dispatch" and Visitor patterns etc) .

>> 2. There are a group of OO prog languages (CLOS etc) that support
>> multiple dispatch. Therefore the single dispatch problem is not
>> universal in OOP.

>> 3. Paul Graham is more than aware of the facts stated in 1/2.
>> After all he is a Lisp programmer. He also *wrote a book* whose
>> contents *teach people how to use CLOS* . Which means Paul
>> Graham understands CLOS quite well.

>> He may well have actually written some of his successful business
>> s/w in CLOS.

>> Your attempt to use Paul Graham as an "appeal to authority" as
>> support for the failings of OO is shown as a fallacy.

> Actually he is right here. Paul Graham is known to strong dislike
> CLOS and Common Lisp (no joke).

A dislike not based on ignorance or lack of experience.


> He does not use CLOS.

Hence "may well have" (I could not say for certain either way) .


> His Lisp books explain almost no CLOS at all.

Here is his book on Lisp that has two chapters on CLOS :

http://www.amazon.com/ANSI-Common-LI...5593004&sr=8-1

To write about CLOS implies an understanding (of things such as
multiple
dispatch) .

Contrast with Stepanov (of STL fame) , where a search on "Stepanov
multiple dispatch" reveals a couple of people questioning his
ignorance
of multiple dispatch for his arguments against OO.


> He is developing a new Lisp-dialect called Arc which will
> not be object-oriented. He develops Arc, because he
> does not like Common Lisp.

> See Paul about CLOS and OOP >here:http://www.paulgraham.com/noop.html

> Well, one may not cite him as an authority about the problems
> of CLOS, since he never used it (see the link).

I do not cite him as an "authority" at all in my argument.
He does however have reasonable knowledge of CLOS and multiple
dispatch (for reasons stated above) .


Regards,
Steven Perryman

In article <1175598436.722577.158480{}q75g2000hsh.googlegroups.com>,
ggroups{}bigfoot.com wrote:

> On Apr 3, 9:21 am, Rainer Joswig <jos...{}lisp.de> wrote:
>
> > ggro...{}bigfoot.com wrote:
>
> TM> He also complained about the limiting dimensions of OO,
> dispatching
> TM> off of mostly a single dimension/factor (type).
>
> PM> This is a limitation of some languages, not of OO in general.
>
> TM> It is hard to tell without a clear, consensus definition of OO.
> One
> TM> can put function pointers in associative arrays to get OO features
> out
> TM> of a non-OO language. With a wide enough definition of OO, OO is
> TM> everything.
>
> >> Rubbish. Just another typical attempt to evade the truth.
> >> Patrick May has explained Paul Grahams' critique precisely.
>
> >> 1. OO prog langs based on the Simula model (known in industry as
> >> "single dispatch" ) are limited when an operation to be executed is
> >> to be determined by both the object being invoked and the types
> >> of the input parameters to that operation (known in industry as
> >> "multiple dispatch" ) .
>
> >> The grief attempting to emulate multiple dispatch even for just two
> >> variables (object X parameter) with single dispatch is well-known
> >> in industry (the "double dispatch" and Visitor patterns etc) .
>
> >> 2. There are a group of OO prog languages (CLOS etc) that support
> >> multiple dispatch. Therefore the single dispatch problem is not
> >> universal in OOP.
>
> >> 3. Paul Graham is more than aware of the facts stated in 1/2.
> >> After all he is a Lisp programmer. He also *wrote a book* whose
> >> contents *teach people how to use CLOS* . Which means Paul
> >> Graham understands CLOS quite well.
>
> >> He may well have actually written some of his successful business
> >> s/w in CLOS.
>
> >> Your attempt to use Paul Graham as an "appeal to authority" as
> >> support for the failings of OO is shown as a fallacy.
>
> > Actually he is right here. Paul Graham is known to strong dislike
> > CLOS and Common Lisp (no joke).
>
> A dislike not based on ignorance or lack of experience.
>
>
> > He does not use CLOS.
>
> Hence "may well have" (I could not say for certain either way) .

But he hasn't. He hasn't written any CLOS-based software.

>
>
> > His Lisp books explain almost no CLOS at all.
>
> Here is his book on Lisp that has two chapters on CLOS :
>
> http://www.amazon.com/ANSI-Common-LI...5593004&sr=8-1

Have you read it? I have a copy. His book is mostly a few explanations of Common Lisp features,
some very short examples (almost all non-CLOS) and a some reference listing Common Lisp
constructs with short explanations. You can learn virtually nothing
substantial about CLOS from it.

> To write about CLOS implies an understanding (of things such as
> multiple
> dispatch) .

He sure understands it a bit and doesn't like it. Neither Common Lisp,
nor CLOS, not OOP. I heard it directly at a talk he gave
a few years back at the International Lisp conference in New York.
;-)

> Contrast with Stepanov (of STL fame) , where a search on "Stepanov
> multiple dispatch" reveals a couple of people questioning his
> ignorance
> of multiple dispatch for his arguments against OO.
>
>
> > He is developing a new Lisp-dialect called Arc which will
> > not be object-oriented. He develops Arc, because he
> > does not like Common Lisp.
>
> > See Paul about CLOS and OOP >here:http://www.paulgraham.com/noop.html
>
> > Well, one may not cite him as an authority about the problems
> > of CLOS, since he never used it (see the link).
>
> I do not cite him as an "authority" at all in my argument.
> He does however have reasonable knowledge of CLOS and multiple
> dispatch (for reasons stated above) .

He has some knowledge, but no practical experience, as you can
see from the link I have posted: "Common Lisp has an enormously powerful
object system and I've never used it once".

>
>
> Regards,
> Steven Perryman

--
http://lispm.dyndns.org

ggroups{}bigfoot.com wrote:
> On Apr 1, 11:28 pm, "topmind" <topm...{}technologist.com> wrote:
> > S Perryman wrote:
>
> >> topmind wrote:
>
> TM> What is an example of a good debunking of a given paradigm?
>
> >> Providing a claim made by someone, preferably one documented in
> >> some widely-known or available media, and then showing specifically
> >> why that claim does not hold.
>
> >> I asked you for a specific example of such actually being done.
>
> My favourite one is by James Randi in the 1970s during the height of
> Uri Gellers' fame. In response to the spoon bending phenomenon, Randi
> set a bit of metal (comparable in tensile properties etc to an average
> metal spoon) in a sealed tube. He may have also rigged the metal to
> measuring devices etc in order to get some measure of any force
> exerted if the metal bent.
>
> Participants were allowed to influence the metal without physical
> contact
> with the metal. AFAIK, no one has ever done it.
>
> Randi thus debunked the "psychic powers" claim in a precise,
> controlled environment.
>
> But it opened the science as to whether the combination of continual
> rubbing of the spoon + human substances (sweat etc) could cause a
> physical/chemical effect sufficient to weaken the specific form of
> metal
> (composition, shape etc) . Which in itself is an interesting
> phenomenon
> for science to investigate.

I kind of had software development techniques in mind. I don't see the
applicability of this to software.

>
>
> >If paradigms are subjective preferences, which I suspect they are, then
> >nobody can supply objective proof that one is better than another
> >because none is objectively better.
>
> ### (a marker for cross-reference)
>
> You have obviously not realised the implications of what you have
> written above.

Oh, I have:

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

People have an inborn tendancy to mistake personal preferences for
universal truths.

>
> TM> It is not my burden anyhow. If you claim OO is objectively better,
> TM> YOU have to prove it, NOT ME. Deflecting the issue to me is a red
> TM> herring. I see thru it.
>
> TM> THE BURDEN IS ON THE CLAIMERS.
>
> >> Please cite the references (see above) to where people have claimed
> >> OO is "objectively better" (than "procedural" I guess) . If they have
> >> been made on comp.object, I do not recall ever seeing them (but I
> >> could be wrong) .
>
> >If you don't think OO is objectively better, then simply say so and
> >ignore topics that involve such.
>
> 1. I am on record in comp.object for years as stating that the
> argument
> cannot be shown one way or another. Stated frequently over the 7 yrs
> of
> your infestation on comp.object .

Then perhaps you should ignore any debates where one claims or
challenges issues of alleged superiority. I am not sure what your
complaint to me is. You are not forced to read debates that don't
interest you.

>
> 2. I am more interested in why you continue with your tedious
> repetitive
> rhetoric when 1 is so obvious to a vaguely-intelligent human.
>
>
> >I've given references for Meyer's and Martin's pro-OO claims with page
> >numbers.
>
> 1. Feel free to re-post them here.

Maybe another day. I don't feel like digging for it right now.

> 2. Do these "claims" state that OO is "objectively better" than
> "procedural" ??

They strongly *imply* it if not outright state it.

>
> If the answer to 2 is no, then either cite references to elsewhere
> where
> claims that OO is "objectively better" than "procedural" have been
> made.
> Or (yet again) *retract the statement that such claims have ever been
> made* by protagonists in the OO field.
>
>
> >I ignore a lot of stuff on comp.object that I am not interested in or
> >don't disagree with. Thus, if you don't disagree that OO is not
> >objectively better, why the fuss?
>
> Because you have spent *7 yrs* arguing the toss about something that
> *BY YOUR OWN ADMISSION* (see ### ) cannot be shown one way or
> another.

You don't seem to understand the situatation. If Bob claims that
unicorns are faster than horses, then I can rightfully hold it to Bob
to show that unicorns are faster than horses. If Bob cannot produce
evidence of speedy unicorns, then I have a right to complain about the
claims and expect a retraction. Complaining about Bob's unicorn claims
does NOT obligate me to prove the *opposite*. See the difference? This
is where my detractors misunderstand the burden of evidence.


> So unless you can produce citeable references to the claims
> about OO that you believe (wrongly) that you have debunked, all you
> have
> shown is that you have some serious mental problem that means you
> have wasted reams of time over 7 yrs.

No, it means I don't want to be your personal manual Google.

>
> The pressure is well and truly on you now.

Not. I am like Smokey the Bear. I show up when bad OO claims are lit
and hold the claimers to the fire. I am not going to dig up all past
incidences of people making OO claims here.

>
> Either you can produce the references to these claims you continually
> claim are made about OO, or you have condemned yourself with your
> own verdict on 7 yrs of behaviour on comp.object (poor attempts at
> debunking something that has never ever been claimed, and that
> you have admitted can never be proved) ...
>
>
> Regards,
> Steven Perryman

-T-

On Apr 3, 12:34 am, ggro...{}bigfoot.com wrote:
> On Apr 3, 6:38 am, "topmind" <topm...{}technologist.com> wrote:
>
> On Apr 2, 6:43 pm, Patrick May <p...{}spe.com> wrote:
>
> >> "topmind" <topm...{}technologist.com> writes:
> >>> He also complained about the limiting dimensions of OO, dispatching
> >>> off of mostly a single dimension/factor (type).
> >> This is a limitation of some languages, not of OO in general.
> > It is hard to tell without a clear, consensus definition of OO. One
> > can put function pointers in associative arrays to get OO features out
> > of a non-OO language. With a wide enough definition of OO, OO is
> > everything.
>
> Rubbish. Just another typical attempt to evade the truth.
> Patrick May has explained Paul Grahams' critique precisely.

Paul Graham? The above is in reference to Stepanov's OO criticism, not
Pauls.

>
> 1. OO prog langs based on the Simula model (known in industry as
> "single dispatch" ) are limited when an operation to be executed is
> to be determined by both the object being invoked and the types
> of the input parameters to that operation (known in industry as
> "multiple dispatch" ) .

Smalltalk and other dynamic OO languages don't do that. Does that mean
they are not true OO?

I don't see any clear line. Dispatching off of parameter signatures is
a slight form of predicate-based dispatching. Such could be put into a
procedural language also without there ever being formal support for
polymorphism, inheritance, etc.

In other words, there is nothing to stop one from having a non-OO
language like this:

function foo(int a, long b) {.....}
function foo(char a, int b) {.....}
function foo(int a) {.....}

Which is used could depend on the caller signature.

foo(7); // runs 3rd one
foo('xyz', 8); // runs 2nd one

I don't see that is an OO feature. It is predicate-based dispatching,
roughly similar to what SQL and Prolog does.

An OO language may have feature X, but that does not by itself make X
"OO".


>
> The grief attempting to emulate multiple dispatch even for just two
> variables (object X parameter) with single dispatch is well-known
> in industry (the "double dispatch" and Visitor patterns etc) .

Can you back this up with examples etc?

>
> 2. There are a group of OO prog languages (CLOS etc) that support
> multiple dispatch. Therefore the single dispatch problem is not
> universal in OOP.
>
> 3. Paul Graham is more than aware of the facts stated in 1/2.
> After all he is a Lisp programmer. He also *wrote a book* whose
> contents *teach people how to use CLOS* . Which means Paul Graham
> understands CLOS quite well.

IIRC, Paul Graham said he does not use OOP techniques in Lisp very
often and was not very enthusiastic about OO additions to OOP. If
you have examples of Paul supporting OOP, please show it. You claim
it, you show it. (My IIRC is only side info, not a formal claim.)

>
> He may well have actually written some of his successful business
> s/w in CLOS.
>
> Your attempt to use Paul Graham as an "appeal to authority" as support
> for the failings of OO is shown as a fallacy.

You are doing it, not me. I gave examples of other people complaining
about OO because you implied I am a lone looney with regard to OO
criticism. If Graham supported OOP somewhere else, then its your
burden to show that. I did my part. It appears you are being
hypocritical.

I found a *concrete example* of Graham criticising OO. If you have the
opposite, please show it. Again, I did my part.

>
> Regards,
> Steven Perryman

-T-