Interesting take on Paradigms (OO vs Procedural)

On 28 Mar, 21:11, Kellie Fitton <KELLIEFIT...@yahoo.com> wrote:
> On Mar 28, 12:33=A0pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> 
> 
> 
>
> Hi,
>
> You might find what my COBOL teacher said about OOP interesting:
>
> Begin quote:
>
> Well, as far as COBOL's concerned object oriented programming
> is like communism ------ it's only good on paper. =A0 It had such an
> attractive concepts and ideals, these ideals were very alluring
> and seductive (if not stimulating) when described on paper.
>
> However, the complexity and the dynamic aspects of human nature,
> real-world business applications, and the test of mainstream
> business rules and taxonomy, that deflated object oriented
> programming and proved it is not a practical paradigm.
>
> Object oriented is simply an oversold and overhyped programming
> concept, without any clear benefits that can be fathomed in the
> IT world of business applications. =A0 Nonetheless, object oriented
> design is mainly solutions to problems that COBOL does not have.
>
> End quote:

Don't let Pete Dashwood hear you saying that!

On 28 Mar, 21:16, "Pete Dashwood"

> "Structures" are NOT "objects" and there therefore is a good reason for no
t
> retaining the procedural nomenclature; neither are "procedures" "methods",
> just because on the surface they appear to be similar.
>
> A horse is not a camel, despite both of them having a leg at each corner a
nd
> being used for transport.
>

Technically, there is very little difference between an earthworm, a
frog and a human (except for what theBible has to say about morphology
and anatomy). Camels and horses are virtually identical.

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:65553nF2cjsrhU1@mid.individual.net...
>
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13uq9i0e2sfdd1a@corp.supernews.com... 
>
> This simply says that the writer has not really understood the essential
> differences. I read the full article and he/she does a good job of listing
> the differences, but identifying differences and actually understanding
the
> implications of those differences are two different things.
>
> The comment above implies that the commentator sees no difference between
a
> "structure" and an "object", yet anyone who has worked with these things
in
> the real world would understand the essential difference. This is the
> difference between Acadaemia and Reality.

H'm! Structure, in procedural, is accessed through a pointer.
Object, in object-based, is accessed through a reference.
Object, in object-oriented, is accessed through a reference;
but also holds a "vtable" to accommodate inheritance and
polymorphism.

The essential difference seems to be the extension of the
structure to add the "vtable" making the object a bigger
structure.

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13ur1alih0ug9ae@corp.supernews.com...
> 
> news:20701054-5cb5->4abb-b841-15b85c63b8f8@i12g2000prf.googlegroups.com...
>
> [snip]
> 
> 
>
> [snip]
> 
> 
>
> It is my understanding that, "in the IT world of business
> applications"; most data is representational, not object.
> The distinction is that the former has little or no behavior
> while the latter does.
>
> One problem with attempting to add behavior to
> representational data is that the process is potentially
> never-ending. One may add methods to the class to use
> the data in one way, then add more methods to use it
> another way, and so on. In formal OO design, this
> requires opening the class to add the methods--a no-no
> that violates the Open/Closed Principle. If inheritance is
> used to extend the class, then inheritance can not be used
> also for sub-classing, without creating "class spaghetti".
> To avoid this problem, one simply leaves the data as is
> and creates separate classes that have the required
> behavior. For business information, these classes use
> the paradigm "clerks performing procedures on or with
> data", which is pretty much what COBOL programs
> do now.
>
>

You can use the decorator pattern to add behavior to an object and the
object does not even know about the new behavior.

"Kellie Fitton" <KELLIEFITTON@yahoo.com> wrote in message
news:0af65c32-0960-4ba9-bf26-1769788c054d@i7g2000prf.googlegroups.com...
On Mar 28, 1:07 pm, "tlmfru" <la...@mts.net> wrote:
> While wanting to use different terms, to avoid confusion and baggage, was
> a
> good idea, their choice was singularly poor. So far as I can tell EVERY
> OO-oriented term carries unwanted meanings - e.g., my tiff last year with
> PD
> over "function".
>
> Having said this, I'm fully aware that nobody will ever be able to prevent
> newcomers to a field from trying to equate the new concepts to things
> they're familar with.
>
> So let's rename all object-oriented things as either completely new,
> artificial words - fomas and granfalloons, for instance, for objects and
> methods <wink> - or auto-oriented things. Then at least there will be no
> overlap.
>
> PL
>


http://groups.google.com.au/group/c...30fa6dad4ec?lnk

I have seen multi-page two column lists comparing oo terminology with what
came before. It was easy to see the parallels and I though I understood oo
programmming.  I was wrong.  I don't think I truly understood the power and
advantages of it until I read the book "Head First Design Patterns".

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13uqu7i6r4oqh87@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:6555ibF2e9upbU1@mid.individual.net...
>
> [snip]
> 
> not 
>
> I am sure you have that reversed. I agree that structures
> are not objects, because objects have a "vtable" or vector
> table to redirect procedure calls ... oops ... method
> invocations to the correct code. If 'class object' inherits
> from 'class structure', then an object is a structure! <g>
>
>

Objects have a 'structure' but it is not a COBOL structure (level
hierarchy).

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13ur3032ivqhu44@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:65572qF2devk5U1@mid.individual.net...
>
> [snip]
> 
> its 
> using 
> just 
>
> What is, and ought to be, central to the discussion is
> the use of OO for core business applications, such as
> accounting. IBM created the San Francisco Project,
> as I understand it, as a means for VARs to implement
> core business applications using Java. The project was
> cancelled. It is not clear to me why it was cancelled,
> but the thousands of VARs that might have benefited
> from this free software apparently saw no reason to
> use it.
>
> But, hey, if you are not using OO for core business
> applications, then you may not be able to appreciate
> the problems. <g>
>
>

Nobody doubts that COBOL was great for business applications of the past.
While it is possible to use COBOL for internet  based business applications
most people have chosen to go with OO.

"Charles Hottel" <chottel@earthlink.net> wrote in message
news:13urbjoss3fk4bf@corp.supernews.com...
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13ur1alih0ug9ae@corp.supernews.com... 
news:20701054-5cb5->4abb-b841-15b85c63b8f8@i12g2000prf.googlegroups.com... 
>
> You can use the decorator pattern to add behavior to an object and the
> object does not even know about the new behavior.

The distinction here is that Decorator adds to an
individual object, whereas the addition I was referring
to was to the class and thus to all objects instantiated
from that class.

Choosing Decorator, when the addition is needed for
all, adds overhead and complexity that would not
otherwise occur since every access to every object is
indirect. Stacking Decorator for each change would
seem to make things much worse, much faster.

Using a "Clerk pattern" for each behavior is as simple
as it gets.

On Sat, 29 Mar 2008 01:15:20 +0000, docdwarf wrote:

>
> 'Technically' there is even less difference between what you cite and
> between A-negative and B-positive human blood... now I'd appreciate it if
> you'd keep away from dealing with transfusions.
>
> DD

Ditto. No more than one bit might separate a program that works correctly
and one that fails catastrophically. This is a relevant analogy, because
DNA is code.

Tim

On Fri, 28 Mar 2008 19:51:12 -0500, Rick Smith wrote:

> The book "Simulation Using GPSS", Thomas J. Schriber,
> 1974, covers the use of General Purpose Simulation System
> to accomplish discrete event simulation. I find no mention of
> "class", "object", or "method" in this book; thus, apparently,
> these terms are not in the jargon of GPSS users. The author
> uses procedural languages as a model for explaining the use
> of GPSS.

And I thought I hoarded too much old stuff!

Simula and GPSS were two different things. Simula defintely had OO
concepts - I programmed it in the late 1970s. They are appropriate for the
kinds of problems Simula aimed to solve (discrete simulations).

They are just not appropriate for each and every problem. The OO paradigm
works badly when pushed too far in any of several directions. For example -
for continuous simulations and for modelling continuous functions; when
the interactions between objects are more important than the objects
themselves; when there is only one object (the "singleton" pattern); or
when the actions are more important and complex than the objects
themselves.

Tim