Fortran - OO is "non-procedural"?

Author

OO is "non-procedural"?

jamesgiles@att.net

2008-03-20, 7:15 pm

On Mar 20, 1:54=A0am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
=2E..
> [...] Some people
> swear by object-oriented programming for everything
> instead of procedural style. [...]

This is unrelated to the rest of this thread, but in what way is OOP
not procedural? OOP tends to be *more* procedural than non-OO
imperative languages. If nothing else, then due to the common
recommendation that access to components of something should be done
through procedures (methods) rather than directly.

I looked up "procedural programming" in wikipedia and it's not much
help. The distinction seems to be made by the same folks that claim
that an OOP "object" corresponds to a non-OOP "module". This latter
is a sufficiently common mistake as to qualify as a FAQ here.

The wikipedia entry for "procedural programming" contains the
following: "The focus of procedural programming is to break down a
programming task into a collection of data structures and subroutines,
whereas in object oriented programming it is to break down a
programming task into objects." Except that an object is an instance
of a class which in turn is a collection of data structures and
methods (procedures). So the defining distinction isn't a distinction
at all. In particular, OOP still is procedural. The syntax is
different, but the semantics and pragmatics are the same. At least,
until inheritance is brought into the picture. But the above seems to
be an effort to define OOP without mentioning inheritance.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Craig Powers

2008-03-20, 7:15 pm

jamesgiles@att.net wrote:
> On Mar 20, 1:54 am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> ...
>
> This is unrelated to the rest of this thread, but in what way is OOP
> not procedural? OOP tends to be *more* procedural than non-OO
> imperative languages. If nothing else, then due to the common
> recommendation that access to components of something should be done
> through procedures (methods) rather than directly.
>
> I looked up "procedural programming" in wikipedia and it's not much
> help. The distinction seems to be made by the same folks that claim
> that an OOP "object" corresponds to a non-OOP "module". This latter
> is a sufficiently common mistake as to qualify as a FAQ here.
>
> The wikipedia entry for "procedural programming" contains the
> following: "The focus of procedural programming is to break down a
> programming task into a collection of data structures and subroutines,
> whereas in object oriented programming it is to break down a
> programming task into objects." Except that an object is an instance
> of a class which in turn is a collection of data structures and
> methods (procedures). So the defining distinction isn't a distinction
> at all. In particular, OOP still is procedural. The syntax is
> different, but the semantics and pragmatics are the same. At least,
> until inheritance is brought into the picture. But the above seems to
> be an effort to define OOP without mentioning inheritance.

Perhaps the choice of terminology is unfortunate, but the distinction
that I draw between a pure OO style and a pure "procedural" style is
that in the OO style, *everything* (all data and all procedures) is a
member of an object, whereas in the pure "procedural" style, *nothing*
is a member of an object. Obviously, there's some overlap in that
whatever serves as the "main" program will be written in a somewhat
procedural style even though it is a member of an object. At the same
time, I object to the attempt to force everything into objects (a la
Java) even in instances where I'm coding something that proceeds in a
linear "first do A, then do B, then do C" style with few or no
operations or data that would be logically grouped as "objects".

jamesgiles@att.net

2008-03-20, 7:15 pm

On Mar 20, 12:56=A0pm, Craig Powers <eni...@hal-pc.org> wrote:
=2E..
> Perhaps the choice of terminology is unfortunate, but the distinction
> that I draw between a pure OO style and a pure "procedural" style is
> that in the OO style, *everything* (all data and all procedures) is a
> member of an object, whereas in the pure "procedural" style, *nothing*
> is a member of an object. =A0[...]

So, the difference really is "merely" syntax? That's the only
difference there is between derived types plus procedures defined on
those types and derived types with type-bound procedures.
Semantically and pragmatically they are completely interchangeable,
identical, isomorphic, whatever. Their only difference is syntax.

Now, don't get me wrong. I think syntax is often the most important
aspect of language design. The phrase "merely syntax" always sets my
teeth on edge. But I don't think syntactic differences constitute a
sufficient distinction to qualify as an important programming
paradigm.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

glen herrmannsfeldt

2008-03-20, 7:15 pm

Craig Powers wrote:
(snip on OO programming)

> Perhaps the choice of terminology is unfortunate, but the distinction
> that I draw between a pure OO style and a pure "procedural" style is
> that in the OO style, *everything* (all data and all procedures) is a
> member of an object, whereas in the pure "procedural" style, *nothing*
> is a member of an object. Obviously, there's some overlap in that

Note that you can write OO style in a non-OO language, and
vice versa. In most cases a compromise is best. Especially
for scientific software with number crunching inner loops you
want to keep object creation/destruction out of that loop.

On the other hand, the get/set style of OO programming still
works even if there is global access to the data. It is really
what you do that counts (assuming the reader believes it).

> whatever serves as the "main" program will be written in a somewhat
> procedural style even though it is a member of an object. At the same
> time, I object to the attempt to force everything into objects (a la
> Java) even in instances where I'm coding something that proceeds in a
> linear "first do A, then do B, then do C" style with few or no
> operations or data that would be logically grouped as "objects".

My favorite example is used for UDP network data:
create UDP object, add data to object, send object. Three
calls to say what could be done in one, just to make it look OO.
(That is for Java with garbage collect.)

TCP is different, so OO might make more sense. If it
doesn't make programs more readable it seems a waste.

-- glen

Craig Powers

2008-03-20, 7:15 pm

jamesgiles@att.net wrote:
> On Mar 20, 12:56 pm, Craig Powers <eni...@hal-pc.org> wrote:
> ...
>
> So, the difference really is "merely" syntax? That's the only
> difference there is between derived types plus procedures defined on
> those types and derived types with type-bound procedures.
> Semantically and pragmatically they are completely interchangeable,
> identical, isomorphic, whatever. Their only difference is syntax.
>
> Now, don't get me wrong. I think syntax is often the most important
> aspect of language design. The phrase "merely syntax" always sets my
> teeth on edge. But I don't think syntactic differences constitute a
> sufficient distinction to qualify as an important programming
> paradigm.

I think there's more to it than syntax. Fundamentally, I agree that OO
amounts to a system whereby a bunch of stuff that's tedious in a non-OO
language gets done under-the-hood (although taken to extremes, it forces
the under-the-hood stuff even on operations where it's not appropriate),
so it's basically just a distinction in syntax when one looks at solving
the same problem in both an OO and non-OO imperative language.

I agree that it's possible to write the same thing in both syntaxes, but
I think that the strict OO syntax tends to go hand-in-hand with a
different approach to designing the program -- though I couldn't say
whether that's because OO leads to the same people designing
differently, or whether it's because OO draws different people who
already have a predilection for designing that way.

That's just my personal impression, I have no evidence to back it up and
it might very well be wrong.

Arjen Markus

2008-03-21, 8:13 am

On 20 mrt, 17:52, "jamesgi...@att.net" <jamesgi...@att.net> wrote:
> On Mar 20, 1:54=A0am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> ...
>
>
> This is unrelated to the rest of this thread, but in what way is OOP
> not procedural? =A0OOP tends to be *more* procedural than non-OO
> imperative languages. =A0If nothing else, then due to the common
> recommendation that access to components of something should be done
> through procedures (methods) rather than directly.
>

Perhaps "imperative" is the correct term and not "procedural".
But my remark/rant was not so much geared to the difference
in programming paradigm as to those zealots that say that OOP
is a good thing and anything else is bad.

I agree, though, that OOP as seen in most C++ or Java programs
is very procedural, even though lots of things are going on
under the hood.

Regards,

Arjen

GaryScott

2008-03-21, 7:20 pm

On Mar 20, 3:51=A0pm, Craig Powers <eni...@hal-pc.org> wrote:
> jamesgi...@att.net wrote:
>
>
>
> I think there's more to it than syntax. =A0Fundamentally, I agree that OO
> amounts to a system whereby a bunch of stuff that's tedious in a non-OO
> language gets done under-the-hood (although taken to extremes, it forces
> the under-the-hood stuff even on operations where it's not appropriate),
> so it's basically just a distinction in syntax when one looks at solving
> the same problem in both an OO and non-OO imperative language.
>
<snip>

My problem with gaining a thorough understanding of OO is the
terminology is too imprecise and varies in significant ways depending
on programming language and domain. For example, the term CLASS is
confusing to me. If it were called "OBJECT TEMPLATE", I could
remember it better. I also generally don't like using the exact same
key word to define a template and to declare an instance of that
template (possibly using a slightly different syntax). The same
problem occurs with derived types. I would have preferred something
like a "TYPEDEF" or "TYPE TEMPLATE" to declare a template, and "TYPE"
or "TYPE INSTANCE" to declare a data type instance.

jamesgiles@att.net

2008-03-21, 7:20 pm

On Mar 21, 4:24=A0am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
=2E..
> Perhaps "imperative" is the correct term and not "procedural".
> But my remark/rant was not so much geared to the difference
> in programming paradigm as to those zealots that say that OOP
> is a good thing and anything else is bad.

Well my remark/rant was more geared to find out what people think OO
*is* anymore. Now that the proponents of the paradigm are trying to
distance themselves from inheritance, what's left? Without
inheritance, there's nothing going on "under the hood" that's not
identical to the internal workings of conventional imperative
languages. The syntax is different.

About a year ago someone posted here a long list of definitions of OOP
terms. I thought the thing most significant about the list was that
OOP itself was only defined implicitly. An "Object Oriented Program"
was one designed according to an "Object Oriented Design", the latter
was a design created by "Object Oriented Analysis" of the problem, the
latter was an analysis consistent with "Object Oriented Principles",
etc. I used to know what OOP was back in the days when the proponents
freely admitted that inheritance was the main innovation. I have no
idea any more.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare

Arjen Markus

2008-03-21, 7:20 pm

On 21 mrt, 16:17, "jamesgi...@att.net" <jamesgi...@att.net> wrote:
> On Mar 21, 4:24=A0am, Arjen Markus <arjen.mar...@wldelft.nl> wrote:
> ...
>
> Well my remark/rant was more geared to find out what people think OO
> *is* anymore. =A0Now that the proponents of the paradigm are trying to
> distance themselves from inheritance, what's left? =A0Without
> inheritance, there's nothing going on "under the hood" that's not
> identical to the internal workings of conventional imperative
> languages. =A0The syntax is different.
>
> About a year ago someone posted here a long list of definitions of OOP
> terms. =A0I thought the thing most significant about the list was that
> OOP itself was only defined implicitly. =A0An "Object Oriented Program"
> was one designed according to an "Object Oriented Design", the latter
> was a design created by "Object Oriented Analysis" of the problem, the
> latter was an analysis consistent with "Object Oriented Principles",
> etc. =A0I used to know what OOP was back in the days when the proponents
> freely admitted that inheritance was the main innovation. =A0I have no
> idea any more.
>

With polymorphism having gone too (note the pun!), yes, I agree:
OOP has made a U turn.

All that is left is something like: methods and data should be
closely together. And that is nothing really distinguishing.

Regards,

Arjen

Sponsored Links