Interesting take on Paradigms (OO vs Procedural)

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

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.

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

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

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.

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 
>
> I believe it was to divorce their design from programming terms.   Of
> course, that didn't last.

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

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 P
D
>over "function".

I can't argue with that.

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.

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