Cobol - Interesting take on Paradigms (OO vs Procedural)

Author

Interesting take on Paradigms (OO vs Procedural)

Rick Smith

2008-03-28, 6:55 pm

< http://www.cs.berkeley.edu/~jrs/4/lec/14 >
-----
Why did the originators of object orientation rename "structures" to
"objects"
and "procedures" to "methods"? Hubris and arrogance, in my opinion. Some
people believe object orientation is a completely new "paradigm" for
programming. The best known paradigms for computer languages are these.

- Procedural languages: Fortran, C, Pascal
- Functional languages: Lisp, Scheme, Haskell
- Logic languages: Prolog
- Object-oriented languages: Java, Smalltalk, C++

The first three of these really use very different ways of thinking about
how
to program a computer. Object-oriented languages are mostly a gloss on
procedural languages.

The one part of object-orientation that really stands out, and might give it
claim to being a separate "paradigm," is _polymorphism_.
-----

Howard Brazee

2008-03-28, 6:55 pm

On Fri, 28 Mar 2008 12:08:44 -0500, "Rick Smith" <ricksmith@mfi.net>
wrote:

>Why did the originators of object orientation rename "structures" to
>"objects"
>and "procedures" to "methods"? Hubris and arrogance, in my opinion. Some
>people believe object orientation is a completely new "paradigm" for
>programming. The best known paradigms for computer languages are these.

I believe it was to divorce their design from programming terms. Of
course, that didn't last.

Rick Smith

2008-03-28, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:jaaqu3hk4cuqm38cu7uv09elamk239nsi3@
4ax.com...
> On Fri, 28 Mar 2008 12:08:44 -0500, "Rick Smith" <ricksmith@mfi.net>
> wrote:

Well, no, I didn't write it!

Here is the missing attribution.
< http://www.cs.berkeley.edu/~jrs/4/lec/14 >
-----
Some[color=darkred]
-----
[color=darkred]
> I believe it was to divorce their design from programming terms. Of
> course, that didn't last.

Why is "to divorce their design from programming terms"
[used previously, assumed] not "[h]ubris and arrogance"?

Howard Brazee

2008-03-28, 6:55 pm

On Fri, 28 Mar 2008 13:10:05 -0500, "Rick Smith" <ricksmith@mfi.net>
wrote:

>
>Why is "to divorce their design from programming terms"
>[used previously, assumed] not "[h]ubris and arrogance"?

Because language can carry prejudice. They wanted a blank slate that
in the new analysis. Why should that be hubris and arrogance?

Sometimes starting over can give insight if we don't carry too much
baggage with us.

tlmfru

2008-03-28, 6:55 pm

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

Howard Brazee <howard@brazee.net> wrote in message
news:jaaqu3hk4cuqm38cu7uv09elamk239nsi3@
4ax.com...
> On Fri, 28 Mar 2008 12:08:44 -0500, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
Some[color=darkred]
>
> I believe it was to divorce their design from programming terms. Of
> course, that didn't last.

Rick Smith

2008-03-28, 6:55 pm

"Howard Brazee" <howard@brazee.net> wrote in message
news:v7equ3lkg1j5o37uo0hv76l7209kk82arm@
4ax.com...
> On Fri, 28 Mar 2008 13:10:05 -0500, "Rick Smith" <ricksmith@mfi.net>
> wrote:
>
>
> Because language can carry prejudice. They wanted a blank slate that
> in the new analysis. Why should that be hubris and arrogance?
>
> Sometimes starting over can give insight if we don't carry too much
> baggage with us.

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.

Rick Smith

2008-03-28, 6:55 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13uqi1couu5v915@corp.supernews.com...
[snip]
> 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.

An erroneous oversimplification on my part. Because methods
may refer to data outside their definition, any reuse of methods
would require a change in the means for accessing that data.
My appologies.

Howard Brazee

2008-03-28, 6:55 pm

On Fri, 28 Mar 2008 14:07:59 -0600, "tlmfru" <lacey@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".

I can't argue with that.

Richard

2008-03-28, 6:55 pm

On Mar 29, 6:08 am, "Rick Smith" <ricksm...@mfi.net> wrote:
> <http://www.cs.berkeley.edu/~jrs/4/lec/14>
> -----
> Why did the originators of object orientation rename "structures" to
> "objects"
> and "procedures" to "methods"?

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.

> Hubris and arrogance, in my opinion.

Which seems to be inadequately informed.

> Some
> people believe object orientation is a completely new "paradigm" for
> programming.

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.

> The best known paradigms for computer languages are these.
> - Procedural languages: Fortran, C, Pascal
> - Functional languages: Lisp, Scheme, Haskell
> - Logic languages: Prolog
> - Object-oriented languages: Java, Smalltalk, C++

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.

> The first three of these really use very different ways of thinking about
> how
> to program a computer.

No. They are computerisations of the different disciplines that they
derived from. The "different ways of thinking" were well before there
were computers.

> Object-oriented languages are mostly a gloss on
> procedural languages.

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.

> The one part of object-orientation that really stands out, and might give it
> claim to being a separate "paradigm," is _polymorphism_.
> -----

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.

Pete Dashwood

2008-03-28, 6:56 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13uq9i0e2sfdd1a@corp.supernews.com...
>
> < http://www.cs.berkeley.edu/~jrs/4/lec/14 >
> -----
> Why did the originators of object orientation rename "structures" to
> "objects"
> and "procedures" to "methods"? Hubris and arrogance, in my opinion.

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.

Certainly the difference between a "procedure" and a "method" is less
tangible, nevertheless, there is a difference and to deny this simply
reveals lack of true understanding. You can "know" something intellectually,
but that doesn't mean you grasp it and understand it fully. Sometimes, it
isn't until you actually have to apply these things in real life situations
(rather than creating contrived math based exercises to demonstrate them)
that you come to a full conceptual understanding of them.

It is very often the subtleties and nuances of something (the "finer points"
if you like...) that are essential to the real understanding of it.

From reading this article it is obvious to me that that the writer comes
from a procedural background and has never really been exposed to OO
implementation in the real world. (That is not to diminish their knowledge
or capabability to teach the subject, just that some of the subtleties have
never been grasped.)

> Some
> people believe object orientation is a completely new "paradigm" for
> programming.

It was certainly "new" when it was introduced, and it had enough differences
fromm established procedural practice to alienate it from, at least, the
COBOL community...

> The best known paradigms for computer languages are these.
>
> - Procedural languages: Fortran, C, Pascal
> - Functional languages: Lisp, Scheme, Haskell
> - Logic languages: Prolog
> - Object-oriented languages: Java, Smalltalk, C++
>
> The first three of these really use very different ways of thinking about
> how
> to program a computer.

Yes, they all claim to be fundamentally different; the last one is less
dramatically different, but it IS different. Much of the importance of those
differences is in the subtleties.

I could make the same argument about Prolog and Lisp. You can certainly
argue that Lisp is a functional language, but it is also a Logic language in
the same sense as Prolog. It is only when you come to use these things for
real implementations that you start to "understand" the subtle difference.

>Object-oriented languages are mostly a gloss on
> procedural languages.
>

I disagree strongly. However, I would agree that you CAN perceive them that
way, and you are very likely to if your background is procedural.

> The one part of object-orientation that really stands out, and might give
> it
> claim to being a separate "paradigm," is _polymorphism_.

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

What did the Romans ever do for us...? :-)

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

Kellie Fitton

2008-03-28, 6:56 pm

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:

Kellie Fitton

2008-03-28, 6:56 pm

On Mar 28, 1:07=A0pm, "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. =A0So 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. =A0Then at least there will be n=
o
> overlap.
>
> PL
>

http://groups.google.com.au/group/c...d/thread/f8a2d=
c2eb7689d9d/f3c4430fa6dad4ec?lnk

Pete Dashwood

2008-03-28, 6:56 pm

--
"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."
>
>

Pete Dashwood

2008-03-28, 6:56 pm

"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."

Rick Smith

2008-03-28, 6:56 pm

"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>

Rick Smith

2008-03-28, 6:56 pm

>"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.

Rick Smith

2008-03-28, 9:56 pm

"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>

Rick Smith

2008-03-28, 9:56 pm

Alistair

2008-03-28, 9:56 pm

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!

Alistair

2008-03-28, 9:56 pm

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

> "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.
>

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.

Rick Smith

2008-03-28, 9:56 pm

"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.

2008-03-28, 9:56 pm

In article <6ee2259e-8acb-4822-b0fb-922006515356@s19g2000prg.googlegroups.com>,
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

Charles Hottel

2008-03-28, 9:56 pm

"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."
>

Charles Hottel

2008-03-28, 9:56 pm

"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.

Charles Hottel

2008-03-29, 3:55 am

"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".

Charles Hottel

2008-03-29, 3:55 am

"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).

Charles Hottel

2008-03-29, 3:55 am

"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.

Rick Smith

2008-03-29, 3:55 am

"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...[color=darkred]
>
> 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.

tim

2008-03-29, 3:55 am

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

tim

2008-03-29, 3:55 am

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

Richard

2008-03-29, 3:55 am

On Mar 29, 1:51 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
> "Richard" <rip...@azonic.co.nz> wrote in message
>
> news:c3525524-b3c3-451e-b747-69eea559fc18@s19g2000prg.googlegroups.com...
>
>
>
>
>
>
> 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.

Turning to my* copy of "Programming Languages. NATO Advanced Study
Institute, edited by F Genuys 1968" it has an article "Discrete Event
Simulation Languages" by Ole-Johan Dahl. This apparently was given as
a series of lectures around 1966. It discusses simulation in general
and how some computer simulation languages map onto the process.

In part 3, Basic Concepts:

"""... We think about a system as in terms of the objects that it
contains. The statis of the system is defined by the status of each
object and by the relations that hold between objects.

3.1.1 Classes of Objects

.... This conflict is resolved by the technique of classifying objects.
.... status descriptors called attributes. An attribute is a
variable, ...

The class concept vastly simplifies the description of a system. A
qualitative declaration of a class of objects serves as an en bloc
description of every member of that class.
"""

After a few pages of these concepts there is a section that indicates
the terminology of several programs and how the concepts relate to the
terminology used by the programs. The programs are GPSS, SOL,
SIMSCRIPT, CSL and SIMULA. For example in GPSS an 'attribute' is
called a 'parameter', an 'object' is called a 'transaction', GPSS
doesn't implement anything related to 'class'.

Later it discusses 'reference counting' and 'garbage collecting'

It seems that the point is clearly made that discrete simulation as a
discipline used the terms we see in modern OO languages whereas the
computer simulation languages of the time (mid 60s), including SIMULA
of 1966 (and GPSS), were implemented by computer programmers who used
the terms that they were used to.

* I say 'my copy' in spite of the "ICL Head Office Library" stamp on
the front page and 'date due' slip affixed to the last. If this wasn't
blank it would have some date in 1970 stamped on it.

Rick Smith

2008-03-29, 6:57 pm

"Richard" <riplin@azonic.co.nz> wrote in message
news:c1715df2-76a5-4502-bdd7-23e4ae8f7551@d4g2000prg.googlegroups.com...
> On Mar 29, 1:51 pm, "Rick Smith" <ricksm...@mfi.net> wrote:
[snip]
>
> Turning to my* copy of "Programming Languages. NATO Advanced Study
> Institute, edited by F Genuys 1968" it has an article "Discrete Event
> Simulation Languages" by Ole-Johan Dahl. This apparently was given as
> a series of lectures around 1966. It discusses simulation in general
> and how some computer simulation languages map onto the process.
[snip]
> After a few pages of these concepts there is a section that indicates
> the terminology of several programs and how the concepts relate to the
> terminology used by the programs. The programs are GPSS, SOL,
> SIMSCRIPT, CSL and SIMULA. For example in GPSS an 'attribute' is
> called a 'parameter', an 'object' is called a 'transaction', GPSS
> doesn't implement anything related to 'class'.

Thanks for the information. I was hoping to find in my
GPSS book a discussion of the OO terms in the context
of simulation; but I guess that ain't going to happen.

Alistair

2008-03-29, 6:58 pm

On 29 Mar, 06:18, tim <T...@internet.com> wrote:
> On Sat, 29 Mar 2008 01:15:20 +0000, docdwarf wrote:
>
>
>
> 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.
>

Well said Tim. Most DNA is in fact what is called 'Junk DNA' with no
discernable function and with sections repeated without rhyme or
reason.

Pete Dashwood

2008-03-29, 7:01 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:6ee2259e-8acb-4822-b0fb-922006515356@s19g2000prg.googlegroups.com...
> 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). Camels and horses are virtually identical.

However, "virtually" is NOT identical.

Try not watering a horse for 6 w

s and see how long it lasts.

Try riding a horse over sand dunes for w

s on end and see how long it
lasts or the distance it covers, compared to a camel.

Try making turkish delight out of camel hooves...

Differences are important, (sometimes even critical...)

And THAT was my point.

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

Pete Dashwood

2008-03-29, 7:02 pm

"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
news:69c88c59-3e42-484a-8321-67452c60d5fd@s12g2000prg.googlegroups.com...
> On 29 Mar, 06:18, tim <T...@internet.com> wrote:
>
> Well said Tim. Most DNA is in fact what is called 'Junk DNA' with no
> discernable function and with sections repeated without rhyme or
> reason.

I think you need to qualify that to "without rhyme or reason that we can
discern at this time."

While it may be that much of what is there is left over from previous failed
evolutionary attempts (much as some maintenance programmers don't remove
code that has become irrelevant "just in case it is ever needed again"), and
is not required for the organism to function in its present incarnation,
that certainly doesn't mean we can decisively state it is there without
rhyme or reason.

We know that people can function "normally" even when quite large pieces of
their brains are removed, but we don't advocate removing brain parts in the
interest of general efficiency...:-)

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

Pete Dashwood

2008-03-29, 7:03 pm

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13ur5tg3con5ja4@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:65553nF2cjsrhU1@mid.individual.net...
> the
> a
> in
>
> 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.
>
You are looking only at the mechanics of an implementation. The conceptual
use of objects is WAY more important. But you only come to appreciate that
when you start using them for systems in the real world, and not just to
describe some academic argument.

Whether objects implement inheritance through a vtable or not is completely
irrelevant to the use of objects. For you, an object is just a structure in
memory; for me, it is much more than that. I visualise objects as
representing a real world entity and having attributes and behaviours that a
structure alone can never have. Perhaps it comes down to imagination and
vision.

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

tim

2008-03-29, 7:05 pm

On Sat, 29 Mar 2008 12:01:10 -0700, Alistair wrote:

> On 29 Mar, 06:18, tim <T...@internet.com> wrote:
>
> Well said Tim. Most DNA is in fact what is called 'Junk DNA' with no
> discernable function and with sections repeated without rhyme or
> reason.

This remains true.. But as I understand it a fair amount of the DNA that
does not produce proteins and thus was classified as junk DNA does in fact
produce RNA, which has an important role in regulating cell functions. For
example, a lot of the mutations that separate humans from their relatives
seem to be for RNA that controls brain functions.

Tim

Rick Smith

2008-03-29, 7:05 pm

"Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
news:657mp4F2dooroU1@mid.individual.net...
>
>
> "Rick Smith" <ricksmith@mfi.net> wrote in message
> news:13ur5tg3con5ja4@corp.supernews.com...
essential[color=darkred]
between[color=darkred]
things[color=darkred]
> You are looking only at the mechanics of an implementation. The conceptual
> use of objects is WAY more important. But you only come to appreciate that
> when you start using them for systems in the real world, and not just to
> describe some academic argument.
>
> Whether objects implement inheritance through a vtable or not is
completely
> irrelevant to the use of objects. For you, an object is just a structure
in
> memory; for me, it is much more than that. I visualise objects as
> representing a real world entity and having attributes and behaviours that
a
> structure alone can never have. Perhaps it comes down to imagination and
> vision.

I used to see objects as real world entities. Now I associate
real world entites with classes, because the methods in the
classes repesent behavior. If one is to "simulate" anything,
it is the behavior that is to be simulated.

To simulate a business, the behavior occurs in employees,
customers, orders, accounts, etc.; but to simulate the
financial systems of a business the behavior is in clerks, and
the employees, customers, orders, accounts, etc., become
just data structures devoid of behavior. This is not much
different than a card game, where the dealer and players
have behavior but the cards don't; even though the cards
are real world entities.

2008-03-30, 3:59 am

In article <657lo7F2e5vr4U1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
>
>"Alistair" <alistair@ld50macca.demon.co.uk> wrote in message
>news:69c88c59-3e42-484a-8321-67452c60d5fd@s12g2000prg.googlegroups.com...
>
>I think you need to qualify that to "without rhyme or reason that we can
>discern at this time."

I agree, Mr Dashwood... now, how often in my postings does one read
*that*? The 'junk DNA' stuff is something that strikes me as just plain
odd; energy is required to create and maintain it. A left-over here or
there I can understand - the little toe or the vermiform appendix - but so
much... *stuff* in each and every cell?

It just doesn't make sense to me, now... but I will not say 'it will never
make sense to anyone, ever.'

DD

Robert

2008-03-30, 3:59 am

On Sat, 29 Mar 2008 12:01:10 -0700 (PDT), Alistair <alistair@ld50macca.demon.co.uk> wrote:

>On 29 Mar, 06:18, tim <T...@internet.com> wrote:
>
>Well said Tim. Most DNA is in fact what is called 'Junk DNA' with no
>discernable function and with sections repeated without rhyme or
>reason.

Orgel and Crick called it "Selfish DNA: The Ultimate Parasite" in this article:

http://profiles.nlm.nih.gov/SC/B/C/D/G/_/scbcdg.pdf

DNA does not make protein directly. It encodes mRNA, which goes to a ribosome, where the
protein is actually made. Most DNA doesn't make only one mRNA, it is like a macro that can
make many different RNAs depending on parameters. It often makes short temporary RNA
(stRNA), which in turn makes more stRNA, which eventually makes 'real' mRNA. There are
layers of abstraction and overloading much like programming languages. DNA isn't a simple
protein template, it's a meta language.

Amoeba dubia have 200 times the DNA of humans. The marbled lungfish and a plant named
Fritillaria assyriaca have 40 times as much. It is hard to believe the excess contributes
to the host's survival or complexity. You could regard them as old companies burdened with
parasitic unionized employees who cost and contribute little, or as cultures with an
unusually complex grammar. Why is Mandarin and Russian so much more complex than Spanish?
The message is the same. The answer is historic accident.

tlmfru

2008-03-31, 6:58 pm

A challenge to this point of view - not disputing the real world fact to
which it applies!

What percentage of the people that have so "voted", Pete, are actually
qualified? I.e., what percentage of them have complete familiarity with
BOTH procedural and OO concepts? You have, as do other people that comment
in this group; therefore your and their opinions must be taken seriously.
But judging by comments about the putative behaviour of Java and other
programmers should they be required to soil themselves with Cobol - they are
acting strictly from their own prejudices, not in any reasoned manner.
After all, most of them have as their first language Java or C++. All of us
are canalized to a certain extent by what we learn first; so this is not
suprising. But it isn't and should not be taken to be a rational thing.
(Remember the "arguments" for using goto-less programs - and I don't want to
start a debate on that: "GOTO's suck". "Don't use GOTO's - ever". QED.
Such a standard of debate would be sneered off the planet if rationality
were to rule). Put another way: how far would you trust the conclusions of
a hardware consultant who states that the only thing he's familiar with is
Solaris? So why should one accept the opinion of somebody whose ONLY
experience is in Java?

PL

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

>
> 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

2008-04-01, 3:55 am

"tlmfru" <lacey@mts.net> wrote in message
news:h59Ij.101602$Ft5.46083@newsfe15.lga...
>A challenge to this point of view - not disputing the real world fact to
> which it applies!
>
> What percentage of the people that have so "voted", Pete, are actually
> qualified?

As you agree that this is the reality, it really doesn't matter, does it?

However, I'll respond to your point...

I said "the World" has voted with its feet and embraced OO. So the key
things here are what I mean by "the World", and what you mean by
"qualified"...

You defined what you meant in the next sentence.

So maybe I need to expand a little on what I was talking about.

"The World" in this context is the world of in house development. That isn't
just programmers. It is analysts, managers, and everyone who is affected by
the paradigm in use (even including the Business...). (So often (in CLC) the
bigger picture is lost sight of...)

The fact is that the introduction of an Object based paradigm has caused
complete re-thinks in HOW systems are developed, and was one of the primary
things which led to the death of the Waterfall as a static development
process. (I'm not claiming that Waterfall development is dead; it is alive
and well on many sites, but most of them have not embraced Object
technology...sites that have, for the most part, are using Object based
development methodologies that involve OOD, Object modelling, RAD, and
Active style interactive development.) They are more responsive, more
flexible, and less expensive, than their procedural counterparts. They have
no trouble getting staff because the universities are churning out people at
all levels who have been taught the Object paradigm. Object modelling, joint
development, prototyping, distributed components and architectures like SOA,
Web based applications, are all "the norm" for these people, many of whom
have no intention of being programmers.

(in fact, with the advent of really smart visual tools, programming skill
requirements are actually becoming moot... I was evaluating a new
development tool last w

and it just left me gasping... I produced a
database-driven web based application, with three tiers of C# code,
annotated stubs for "tailoring " if required, complete DB connection,
access, and update, and click once deployment to a web server, in 6 hours.

This included the DB design. (OK, it wasn't difficult and I've had a lot of
practice at it, but neither was it completely trivial...6 tables, 7
referential integrity constraints, 3 inverted relationships...)

The code produced by the tool is incredible, clear and efficient. The user
interface is stunning, with toolbars and menu options all generated and
driven from the database. I checked out the presentation layer and all the
C# code behind pages, master pages, CSS images, icons, toolbars, etc. I
reckon to write it all manually would have been at least 2 months work. I
will need to do some tailoring for some of the trickier stuff with one or
two complex multiple table joins, and some tweaking of the User Interface
(although this will be really minimal), but I estimate it to be about a
w

's work. The finished application would normally take three months to
produce. It would not be feasible without Object technology. I was able to
produce a working DB model and application prototype, in support of a
proposal which is being put together by a client. If this goes ahead and
they get the funding they are looking for, I'll post links to the finished
application here and you can check it out for yourselves.)

The point is that the Object paradigm has benefits not just for programmers.
If it were up to programmers only, the results might be different than they
observably are. It is no good saying that choices were made by people
"unqualified" to choose; "the World" is larger than just the programming
bullpen...and adopting the Object based model is not JUST about programming.

Programmers generally don't get to vote on what language will be used on the
sites where they work. Instead, the site mandates certain languages and
approaches, and then recruits people with those skills. And that is
reasonable, because programmers are generally not concerned with the welfare
of a given site (apart from the fact that if it goes broke they are faced
wth the inconvenience of getting another job); rather, they are concerned
primarily with making a living.

You might think that would make them aware of changing technology and eager
to embrace new ideas.

Paradoxically, it doesn't. Having invested years in gaining proficiency with
a given language, they then s

to protect their investment by resisting
change and trying to persuade others that it is unnecessary and inefficient.

Only when the site management actually insist that the new stuff be
implemented, and when many other sites have adopted it and thereby changed
the market place for programming skills, will you find some of them getting
down to coming to grips with it.

>I.e., what percentage of them have complete familiarity with
> BOTH procedural and OO concepts?

Do you need to have full understanding of both concepts to see that one of
them has more benefits for the installation as a whole, than the other?

The financial bottom lines cannot be denied; Object based development is
demonstrably cheaper than maintaining code line by line. It is inescapable,
whether it is palatable or not.

You might need understandding of both concepts if you are a programmer. But
it isn't just about programming. If site management can see that things get
done quicker and more easily in places where Objects and components are the
norm, they are going to want a slice of the action. Managers, analysts,
business people... they all talk, Acadaemia is already sold. Soon, "the
buzz" becomes a rumble and the landslide starts...the pebbles don't get to
vote, so they bounce over to CLC and post their frustration here... :-)

The Object paradigm could not have enjoyed the success it has if it was as
flawed as some people here would like to think, or if it were simply a
"re-invention" of existing technology. Yes, there have been disasters; but
there were and are with the procedural approach too...

>You have, as do other people that comment
> in this group; therefore your and their opinions must be taken seriously.

Well, thank you, Peter, but I honestly don't think it is down to programming
experience alone. I believe it is bigger than that.

> But judging by comments about the putative behaviour of Java and other
> programmers should they be required to soil themselves with Cobol - they
> are
> acting strictly from their own prejudices, not in any reasoned manner.

I have worked with Java people, when I was a contract COBOL programmer, and
more recently as a Project Manager. I don't think they are any more
prejudiced or unreasonable than some of the people who post here. In my
experience MOST programmers are pretty fiercely loyal to their language of
choice. (The real secret, is not to have a language of choice and therefore
not get emotional about programming languages; so far, I have not
personallly been able to achieve this...I love C# and am liking it more as I
use it more... but I love COBOL too and am sorry to see its decline, even
though I understand the reasons for it.)

> After all, most of them have as their first language Java or C++. All of
> us
> are canalized to a certain extent by what we learn first; so this is not
> suprising. But it isn't and should not be taken to be a rational thing.
> (Remember the "arguments" for using goto-less programs - and I don't want
> to
> start a debate on that: "GOTO's suck". "Don't use GOTO's - ever". QED.
> Such a standard of debate would be sneered off the planet if rationality
> were to rule). Put another way: how far would you trust the conclusions
> of
> a hardware consultant who states that the only thing he's familiar with is
> Solaris? So why should one accept the opinion of somebody whose ONLY
> experience is in Java?

Well, you shouldn't, unless his statements are qualified to that context. If
it is understood that his background is Java or whatever, then his comments
have as much weight as anybody else's from a similar background.

For me it comes down to results.

The Object paradigm is not better because Java or C++ programmers say so,
any more than you can say that the Procedural paradigm is better because
COBOL, PL/I, or Pascal programmers say so...

Programming is simply ONE aspect of a paradigm. It is an important one, but
it is NOT the ONLY one...

Object and component technology has been embraced by "the World" not just
because component based systems are cheaper and easier to develop and
maintain; it is because the whole approach works better for all of the
stakeholders, NOT just the programmers.

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

Pete Dashwood

2008-04-01, 3:55 am

"Rick Smith" <ricksmith@mfi.net> wrote in message
news:13utjs3674qjr8f@corp.supernews.com...
>
> "Pete Dashwood" <dashwood@removethis.enternet.co.nz> wrote in message
> news:657mp4F2dooroU1@mid.individual.net...
> essential
> between
> things
> completely
> in
> a
>
> I used to see objects as real world entities. Now I associate
> real world entites with classes, because the methods in the
> classes repesent behavior.

Yes, that is fair comment. I used "object" (an instance of a Class) where I
should probably have used "Class".

Certainly the Class has methods which constitute the behaviour of the Class
but until it is instantiated there is no behaviour anyway, so perhaps
"object" is not really so wrong.

> If one is to "simulate" anything,
> it is the behavior that is to be simulated.

Technically that is true. The data isn't simulated. But conceptually it is
the synergy derived from the COMBINATION of behaviours AND data (as a single
encapsulated whole) that makes Objects so powerful.
>
> To simulate a business, the behavior occurs in employees,
> customers, orders, accounts, etc.; but to simulate the
> financial systems of a business the behavior is in clerks, and
> the employees, customers, orders, accounts, etc., become
> just data structures devoid of behavior.

Only if you see it like that. :-)

At this point, I think we diverge.

> This is not much
> different than a card game, where the dealer and players
> have behavior but the cards don't; even though the cards
> are real world entities.

The cards certainly DO exhibit behaviour. If they behave well you go home
rich. :-)

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

2008-04-01, 3:55 am

In article <65dbahF2fprkhU1@mid.individual.net>,
Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:

[snip]

>Programmers generally don't get to vote on what language will be used on the
>sites where they work. Instead, the site mandates certain languages and
>approaches, and then recruits people with those skills. And that is
>reasonable, because programmers are generally not concerned with the welfare
>of a given site (apart from the fact that if it goes broke they are faced
>wth the inconvenience of getting another job); rather, they are concerned
>primarily with making a living.
>
>You might think that would make them aware of changing technology and eager
>to embrace new ideas.
>
>Paradoxically, it doesn't. Having invested years in gaining proficiency with
>a given language, they then s

to protect their investment by resisting
>change and trying to persuade others that it is unnecessary and inefficient.
>
>Only when the site management actually insist that the new stuff be
>implemented, and when many other sites have adopted it and thereby changed
>the market place for programming skills, will you find some of them getting
>down to coming to grips with it.

Thanks very much, Mr Dashwood... I'd call that quite mirth-inspiring, as
sweeping generalisations about 'programmers' offer me about as much
amusement as sweeping generalisations about 'mainframers'.

DD

Alistair

2008-04-01, 6:56 pm

On 29 Mar, 21:47, tim <T...@internet.com> wrote:
> On Sat, 29 Mar 2008 12:01:10 -0700, Alistair wrote:
>
>
>
>
>
> This remains true.. But as I understand it a fair amount of the DNA that
> does not produce proteins and thus was classified as junk DNA does in fact
> produce RNA,

Some would be for RNA encoding but the majority of 'junk' has no known
function with much appearing to be 'blank' encoding.

> which has an important role in regulating cell functions. For
> example, a lot of the mutations that separate humans from their relatives
> seem to be for RNA that controls brain functions.
>
> Tim- Hide quoted text -
>
> - Show quoted text -

Pete Dashwood

2008-04-01, 6:56 pm

<docdwarf@panix.com> wrote in message news:fsru19$pag$1@reader2.panix.com...
> In article <65dbahF2fprkhU1@mid.individual.net>,
> Pete Dashwood <dashwood@removethis.enternet.co.nz> wrote:
>
> [snip]
>
>
> Thanks very much, Mr Dashwood... I'd call that quite mirth-inspiring, as
> sweeping generalisations about 'programmers' offer me about as much
> amusement as sweeping generalisations about 'mainframers'.
>
> DD
>
Glad it made you smile, Doc. As Sir Arthur Wing Pinero reminded us: "There
is no harm in laughter".

I was aware of the general nature of my comments; as such, I wouldn't want
them taken too seriously.

Nevertheless, SOME of the generalization would be true for SOME programmers.

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

Richard

2008-04-01, 6:56 pm

On Apr 2, 10:50=A0am, "Pete Dashwood"
>
> Nevertheless, SOME of the generalization would be true for SOME programmer=
s.
>

With these conditions applied then in what way would they still be
'generalizations' ?

Pete Dashwood

2008-04-01, 9:56 pm

"Richard" <riplin@azonic.co.nz> wrote in message
news:67e3cd1d-9034-4d40-8fe7-18bcc1b9cfa3@b5g2000pri.googlegroups.com...
On Apr 2, 10:50 am, "Pete Dashwood"
>
> Nevertheless, SOME of the generalization would be true for SOME
> programmers.
>

With these conditions applied then in what way would they still be
'generalizations' ?

[Pete]

They wouldn't be, that's why I didn't qualify them, originally :-)

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

Sponsored Links