Interesting take on Paradigms (OO vs Procedural)

On Mar 28, 12:33=A0pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> "Howard Brazee" <how...@brazee.net> wrote in message
>
> 
>
> Starting over can hide fundamental truths behind superficial
> untruths!
>


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.   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.   Nonetheless, object oriented
design is mainly solutions to problems that COBOL does not have.

End quote:

On Mar 28, 1:07=A0pm, "tlmfru" <la...@mts.net> wrote:
> While wanting to use different terms, to avoid confusion and baggage, was =[/color
]
a
> good idea, their choice was singularly poor. =A0So far as I can tell EVERY=[/color
]

> OO-oriented term carries unwanted meanings - e.g., my tiff last year with =[/color
]
PD
> over "function".
>
> Having said this, I'm fully aware that nobody will ever be able to prevent=[/color
]

> 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. =A0Then at least there will be n=[/color
]
o
> overlap.
>
> PL
>


[url]http://groups.google.com.au/group/comp.lang.cobol/browse_thread/thread/f8a2d=[/url
]
c2eb7689d9d/f3c4430fa6dad4ec?lnk

--
"I used to write COBOL...now I can do anything."
"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13uqi1couu5v915@corp.supernews.com...
>
> "Howard Brazee" <howard@brazee.net> wrote in message
>  news:v7equ3lkg1j5o37uo0hv76l7209kk82arm@
4ax.com... 
>
> Starting over can hide fundamental truths behind superficial
> untruths!
>
> You might consider the comments in
> < http://en.wikipedia.org/wiki/Syntactic_sugar >.
> -----
> Syntactic sugar is a term coined by Peter J. Landin for additions
> to the syntax of a computer language that do not affect its
> functionality but make it "sweeter" for humans to use. Syntactic
> sugar gives the programmer (designer, in the case of specification
> computer languages) an alternative way of coding (specifying) that
> is often more practical, more conducive to a better programming
> style, or more natural to read. However, it does not typically affect
> the expressiveness of the formalism or permit the language to do
> something new.
> [...]
> Object-oriented programming
>
> The C programming language is fully capable of object-oriented
> programming using its facilities of function pointers, type casting,
> and structures. However, languages such as C++ make
> object-oriented programming more convenient by introducing
> syntax specific to this coding style. Moreover, the specialized
> syntax works to emphasize the object-oriented approach to new
> programmers. Features of the C# programming language, such as
> properties and interfaces, similarly do not enable new functionality
> but instead make specific programming practices more prominent
> and more natural.
> -----
>
> And consider, from COBOL, that there is no _fundamental_
> difference among program, function, and method definitions--
> they do the same things and may be reused in another context
> by changing the identifying text: "program", "method", or
> "function", to one of the others.
>
> Now, if one calls "structures" "objects" and calls "procedures"
> "methods", this is not truly a "new" paradigm; but is a new,
> or rather a different, way of thinking about the same paradigm:
> "performing procedures on data".
>
> Bottom line: If it reduces to, "they are called objects and
> methods, because we say so" ("we" referring to the "originators
> of object orientation"); then hubris and arrogance seem an
> appropriate observation.

Well written, Rick, but this is a fine example of ITSA when it should be
ITSLIKE. The subtleties here are everything.

"Structures" are NOT "objects" and there therefore is a good reason for not
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 and
being used for transport.

I see neither hubris nor arrogance in the selection of a different
nomenclature to describe something that IS different.

Pete.
--
"I used to write COBOL...now I can do anything."
>
>

"Richard" <riplin@azonic.co.nz> wrote in message
news:c3525524-b3c3-451e-b747-69eea559fc18@s19g2000prg.googlegroups.com...
> On Mar 29, 6:08 am, "Rick Smith" <ricksm...@mfi.net> wrote: 
>
> Because they weren't 'programmers', they were simulation modellers.
> Simula was/is a language for writing computer based simulations. For
> example a petrol (gas) station will have a number of pumps, staff and
> cars will arrive at various rates wanting various products and
> services.  Queuing theory will show some features, such as average
> wait times, but simulation will give more information.
>
> What is required in a simulation language is the ability to specify
> different behaviours in the various objects being simulated. Some
> drivers will bypass a gas station if the queue looks too long, or will
> wait a variable time in the queue before giving up. 'classes',
> 'objects' and 'methods' is the language (jargon) of this activity, and
> has been since before there were computers.
> 
>
> Which seems to be inadequately informed.
> 
>
> The first was Simula 68 which is now 40 years ago. Smalltalk was soon
> after. 'C with classes' (later called C++) was 1981. But the paradigm
> comes pre-computer simulation modeling.
>
> 
>
> These are different because they originated in different disciplines.
> Cobol from accounting, Fortran from engineering, APL from mathematics.
> Each brought their own terminology and methodology which had been
> developed independently for many decades before computers existed.
> 
>
> No. They are computerisations of the different disciplines that they
> derived from. The "different ways of thinking" were well before there
> were computers.
> 
>
> It happens that OO features were grafted on to existing computer
> languages when these features were an advantage. For example C with
> Classes was originally implemented via a translator, cfront, that
> generated C code. Later this was added directly into the compiler.
>
> Because of the cfront translator then every OO feature had to map to
> an existing C mechanism. Thus class data is a struct, overloading is
> done with name mangling. At the C level it looks like a 'gloss', yes.
> 
>
> C++ solves many problems that exist in C.  For example name space
> pollution. C also is difficult to extend. If, for example, you want a
> new numeric type, eg complex, then you have to do it with function.
> You need to have a set of functions that will implement all the
> mechanisms that are required for each of the data types that could be
> used:
> 'struct complex complex_add_real(struct complex a, real b)'
> 'struct complex complex_add_long(struct complex a, long b)'
> ...
> ...
>
> By creating a class for complex then the operations can be overloaded
> and type complex can be used as if it were a built-in type. Instead of
> having to change the compiler to include complex as a type that can
> take part in expressions so that it can replace, or supplement,
> Fortran the same thing can be achieved with a general mechanism that
> allows many other types to be added.
>
> The main advantage (IMHO) that OO adds to Cobol (or indeed any
> language) is the ability to have multiple instances. Cobol has had the
> ability to CALL routines to modularise programs. For example the
> printer handling can be a CALLed program that deals with all the needs
> of the printer. Different modules could be called dynamically by just
> changing the program name variable so that different characteristics
> of the particular printers could be dealt with appropriately
> (polymorphism). The different modules can, in the end, call a base
> module that does the common stuff (emulating inheritance).  The
> problem has been when the program wants to use two printers at the
> same time and these may be the same type. The code has to be
> duplicated, or the called programs enhanced to allow the relevant data
> to be held in a array or some such.
>
> With OO, one can create a second (or third) printer object and just
> use that.
>

Very interesting post, Richard. I didn't know the terms came from
Simulation. I liked your examples.

I think the whole debate over OO is pointless. The world has voted with its
feet. Trying to pretend there is nothing different or advantageous in using
OO, over standard COBOL, is like trying to pretend that a car is really just
a horse...

That is not to say there are not some things for which a horse is better
suited than a car, but saying that, in no way diminishes cars...or horses
:-)

Pete.
--
"I used to write COBOL...now I can do anything."

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:6555ibF2e9upbU1@mid.individual.net...

[snip]

> "Structures" are NOT "objects" and there therefore is a good reason for
not
> retaining the procedural nomenclature; neither are "procedures" "methods",
> just because on the surface they appear to be similar.

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>

>"Kellie Fitton" <KELLIEFITTON@yahoo.com> wrote in message
news:20701054-5cb5->4abb-b841-15b85c63b8f8@i12g2000prf.googlegroups.com...

[snip]

>You might find what my COBOL teacher said about OOP interesting:

>Begin quote:

[snip]

>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.   Nonetheless, object oriented
>design is mainly solutions to problems that COBOL does not have.

>End quote:

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.

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:65572qF2devk5U1@mid.individual.net...

[snip]

> I think the whole debate over OO is pointless. The world has voted with
its
> feet. Trying to pretend there is nothing different or advantageous in
using
> OO, over standard COBOL, is like trying to pretend that a car is really
just
> a horse...

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>

"Richard" <riplin@azonic.co.nz> wrote in message
news:c3525524-b3c3-451e-b747-69eea559fc18@s19g2000prg.googlegroups.com...
> On Mar 29, 6:08 am, "Rick Smith" <ricksm...@mfi.net> wrote: 
>
> Because they weren't 'programmers', they were simulation modellers.
> Simula was/is a language for writing computer based simulations. For
> example a petrol (gas) station will have a number of pumps, staff and
> cars will arrive at various rates wanting various products and
> services.  Queuing theory will show some features, such as average
> wait times, but simulation will give more information.
>
> What is required in a simulation language is the ability to specify
> different behaviours in the various objects being simulated. Some
> drivers will bypass a gas station if the queue looks too long, or will
> wait a variable time in the queue before giving up. 'classes',
> 'objects' and 'methods' is the language (jargon) of this activity, and
> has been since before there were computers.

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.

In article <6ee2259e-8acb-4822-b0fb-922006515356@s19g2000prg.googlegroups.co
m>,
Alistair  <alistair@ld50macca.demon.co.uk> wrote:
>On 28 Mar, 21:16, "Pete Dashwood"
> 
>
>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).

'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

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:65553nF2cjsrhU1@mid.individual.net...
>
<snip>

> And then he/she goes on to "mention" inheritance... and other things that
> are available in OO :-)
>

I am surprised that while inheritance is usually mentioned composition is
frequently left out.  Composition is as powerful as  inheritance but is
often more flexible.


> What did the Romans ever do for us...? :-)
>
> Pete.
> --
> "I used to write COBOL...now I can do anything."
>