Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> comp.databases.theory -> Re: Bob's 'Self-aggrandizing ignorant' Count: Was: What databases have taught me

Re: Bob's 'Self-aggrandizing ignorant' Count: Was: What databases have taught me

From: George <george99may_at_gmail.com>
Date: 27 Jun 2006 20:25:01 -0700
Message-ID: <1151465101.706527.146830@y41g2000cwy.googlegroups.com>

Bob Badour wrote:

> George wrote:
>
> > Marshall wrote>
> >
> >>Love Bob or hate him, "OO is a computational model and not
> >>a paradigm unless by 'paradigm' one means an example of
> >>a computational model" is an awesome sentence.
> >
> >>>That's the
> >>>worst definition of OOP I've ever seen "Large unpredictable state
> >>>machines", yeah right.
> >>
> >>Okay, so is "yeah right" supposed to be an example of a
> >>substantive refutation? Why don't you look of the definition
> >>of "state machine" and tell me what aspect of is not met
> >>by an object.
> >
> > The definition was:
> >
> >>>Bob Badour wrote:
> >>>
> >>>>OO is a computational model and not a paradigm unless by 'paradigm' one
> >>>>means an example of a computational model. Idiot. Further, it is a
> >>>>computational model comprising a collection of features useful for
> >>>>constructing large unpredictable state machines from small predictable
> >>>>state machines or otherwise picked arbitrarily in the mid to late 1960's
> >>>>for what seemed expedient at the time.
> >
> > You can represent a state machine with VB version 1, a UNIX shell
> > script, DOS batch job or rows and tables in a relational db - are these
> > examples of OOP?
>
> Are you trying to make a point? I don't recall redefining OOP as "any
> device or technology useful for constructing state machines." One can
> construct state machines with nothing more than inverting amplifiers.
> Computers, themselves, are nothing more or less than huge state machines.
>

I gave you the benefit of doubt and stuck to programming but nothing in your definition actually defines the type of programming. You mainly talk about state machines, which of course can be implemented using "OOP" and many other ways. Your definition is devoid of any useful differentiation yet you call the other guy an idiot, so what does that make you?

> I will respond to your argument above by analogy: That "a lever is a
> simple machine useful for amplifying force" in no way diminishes or
> contradicts the statement that "a ramp is a simple machine useful for
> amplifying force."
>

Can we just stick to "large unpredictable state machines comprised of smaller predictable ones".

>
> > "Large" is a relative term what does it mean 3 or 3million? Sloppy but
> > I won't pursue it.
>
> It has been argued that there are only three useful numbers in
> computing: zero, one and some arbitrarily large power of two. Others
> have stated essentially the same point as: zero, one and infinity.
>
> Whatever "large" is, it is larger than zero or one. Given that the
> purpose of relative terms is to compare things and given that the
> original statement compared the sizes of two state machines, I find your
> inability to understand a relative term relating sizes quite remarkable.
>

What part of "I won't pursue it" is confusing you?

> Do you have anything to offer resembling a substantive or relevant
> rebuttal to my description of the inclusion criteria for features of the
> OO computational model?
>

I have argued using reductio ad absurdum (proof by contradiction), I just started with your definition and applied allowed for and reasonable absurdities, from there the conclusions are obvious?

Implementing "large unpredictable state machines" using DOS batch jobs may not be what you indended but nothing in your definition disallows it, can't you see that? And OO programs do not have to be unpredictable, can't you see that?

Man I cannot think for you.

>
> > "Unpredictable"? Every object I've instantiated behaves in a completely
> > predictable fashion, specifically as defined by its class, there is no
> > mystery, no unpredictability. Actually I'm not sure how you'd implement
> > unpredictability, perhaps you can use reflection then you can invoke
> > methods at random?
>
> Given your inability to parse my statement in any accurate or useful
> manner, I have to conclude you are either totally ignorant of the
> origins of the OO computational model or you lack the intellect to
> comprehend written english or both. I am not sure exactly how the source
> of your inability breaks down, though.
>

Or you could conclude your definition is stupid.

> OO was invented for simulation and was first expressed in a language
> called Simula. Stroustrop later invented C++ as a variant of C for
> exactly the same purpose: simulation. Stroustrop used the same inclusion
> criteria when transforming the C computational model into OO and in fact
> borrowed the features from Simula.
>

Yes but things have moved on and there are other big influences like Smalltalk and Minsky's frames and what has any of that to do with your definition?

> The whole purpose of a simulation is to create a large unpredictable
> state machine to discover what would happen in various conditions. If
> the simulations were predictable, there would be no need for them in the
> first place.
>

That may be valid for simulations but not all simulations need to be written using OOP. Furthermore not all OO programs are simulations, so the terms are not synonymous. Equating the two is one of your gross errors.

> That an individual object class defines a template for a relatively
> simple predictable state machine agrees entirely with my description of
> the inclusion criterion for features of the OO computational model. The
> computational model is, after all, useful for piecing together large
> unpredictable state machines from small predictable state machines.
>

You haven't used "class" or "template" until now and you haven't defined them so I don't know what you mean by them.

> Oh the irony, when people using the computational model to piece
> together predictable state machines with the intent to create larger
> predictable state machines discover the result is unpredictable after all.
>
>

Oh the even greater irony of sloppy operators calling other people idiots. I'm not even sure you can see how useless your definition is, that doesn't make you so bright does it? And why are you still defending it?

> > Yet in this great definition the original recipient is suppose to be
> > the idiot? That's just truly amazing isn't it.
>
> I am not sure what part you find amazing. The part where I can identify
> idiots by their apparent ignorance and profound inability to accurately
> describe what they vociferously advocate? The part where I can identify
> idiots by their habit of substituting meaningless buzzwords where one
> would ordinarily expect to find intelligence and reason? The part where
> I have a demonstrably better grasp of both OO and written english than
> the OO proponents I encounter? The part where I am unafraid to give
> voice to these observations?

The part where you fail to identify yourself as the chief idiot is the most amazing part.

You have wrongly equated OOP with "simulations" making the terms virtually synonymous, they are not. And you have wrongly equated "state machine" and "object" again the terms are not synonymous. If you fail to grasp this I can't help you.

Until you demonstrate a mildly valid understanding of OOP your critiques of it are worthless. And your insults seem to best apply to yourself. Received on Tue Jun 27 2006 - 22:25:01 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US