Re: Interesting take on Paradigms (OO vs Procedural)
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 29 Mar 2008 10:42:50 +1300
"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:c3525524-b3c3-451e-b747-69eea559fc18@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Mar 29, 6:08 am, "Rick Smith" <ricksm...@xxxxxxx> 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.
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."
.
- Follow-Ups:
- Re: Interesting take on Paradigms (OO vs Procedural)
- From: tlmfru
- Re: Interesting take on Paradigms (OO vs Procedural)
- From: Rick Smith
- Re: Interesting take on Paradigms (OO vs Procedural)
- References:
- Interesting take on Paradigms (OO vs Procedural)
- From: Rick Smith
- Re: Interesting take on Paradigms (OO vs Procedural)
- From: Richard
- Interesting take on Paradigms (OO vs Procedural)
- Prev by Date: Re: Interesting take on Paradigms (OO vs Procedural)
- Next by Date: Re: Confessions of a CoBOL programmer
- Previous by thread: Re: Interesting take on Paradigms (OO vs Procedural)
- Next by thread: Re: Interesting take on Paradigms (OO vs Procedural)
- Index(es):
Relevant Pages
|
