Re: Structured Coding


"Frank Swarbrick" <Frank.Swarbrick@xxxxxxxxxxxxxx> wrote in message
news:45c6vsF5qmkpU1@xxxxxxxxxxxxxxxxx
Pete Dashwood<dashwood@xxxxxxxxxxxxxx> 02/10/06 6:37 PM >>>

It is amazing the diversity of ways in which people learn. (I did an adult

teaching course last year - that's a course for teaching adults - and was
very fascinated by the perceptual and psychological interactions that
occur

when we learn something. There is no "one size fits all". Some people are
more visual, some are more conceptual, some are more language oriented.
All

of us are different, and a good teacher will include material in his
course

that appeals to all types.

Unlike you, Frank, I AM convinced that OO is a good way to learn
programming
as a first language. (That doesn't mean I think you are "wrong" - your
statement is certainly true for many people.)

I had major problems struggling with OO COBOL when it was first released.
I

spent three months trying to get my head around the new concepts and
suffered from exactly what you outlined above - a lifetime of procedural
COBOL.

In the end, in despair, I thought: "*** it. Maybe I'll just learn
Java..."

So I invested in a couple of Java books (the best was "Java 2 in 24 Hours"

by Rogers Cadenhead - possibly one of the best books on learning a
programming language ever written; light hearted, witty, amusing,
entertaining, and VERY useful), and tried to clear my mind of everything I

knew and approach it as something not seen before, without making
judgements
based on other experience. Within 3 days I was hooked. It was so obvious.
Simple, elegant, and fun. By the time I had my first Java programs and
applets running, my mind was racing ahead exploring the implications of
this new freedom. I went back to OO COBOL and saw it in a new light. The
concepts I had previously struggled with were now an open book and
everything fell into place. I started writing components...

Later I had to run some courses in Java Web programming (servlets) and
JavaScript (for client). I found the "computer programmers (COBOL)" had
the

hardest time and were the last to pick it up. The people who had never
programmed in their life took to it like ducks to water.

I think that once we become competent in COBOL (for instance) it is very
easy to believe that is THE way to do things. To succeed with OO you
should

clear your mind, or at least agree with yourself to suspend criticism or
evaluation until you have written some samples and got them working. And
learn OO by means of a language that was OO from its inception, designed
to

be OO, not having had a bolt on of Object handling to make it "socially
acceptable", even if (as in the case of COBOL) that bolt on is superbly
and

cleverly engineered.

I recommend Java because it meets those criteria.

Actually, I only said that because I don't know anyone who learned OO
first,
so I had no data that would allow me to state that OO programming
languages
are good first languages to learn.

I take your point. I am managing Java people at the moment so they are very
facile with OO concepts. I can't imagine any of them now going to learn a
procedural language. There just isn't a requirement for it. It is as if the
OO paradigm subsumes the procedural one and renders it obsolete... but I'm
sounding like a zealot, and I'm really not :-) I do believe in the right
tools for the job and in things that work.

But you appear to have experience with
other people, if not yourself, learning an OO language first, and finding
it
"simple" (well, as simple as any programming paradigm might be), so you
can
state that, and I can as well if I use you as a reference <g>.

Yes, I can certainly attest that people with no previous experience have
much less difficulty with OO than people who have many years of say, COBOL.
But then, I've taught people COBOL too and they had little difficulty
learning it. (I am now curious to see what the reaction would be if some of
my Java people had to learn COBOL... :-))

Anyway, don't take my message as saying that I am not a fan of OO. I am
definitely a fan. I am constantly going crazy using procedural COBOL
because I know that so many of the things I have to do could be done so
much
simpler with an OO language. All I was getting at, and you apparently
agree, is that in order to learn OO you have to leave a lot of your
procedural thinking behind. It's often hard.

Yes, absolutely.

I have a general question... With COBOL, if you add a new field to a
group
that is passed between programs (program to sub-program, etc) you pretty
much have to recompile any programs that use that group in order for
things
to not break.

This is the problem with interfaces. Frequently they are used to pass
parameters and pointers to parameters, and if a new parameter has to be
added to the list, as you observed, everything has to be recompiled and
linkages must be checked for type and length and consistency. The same can
apply to OO methods if you write them to accept parameters; (that is one
reason why I don't personally do that). I use Properties instead, and GET
and SET them. This means extension classes can be used, or the factory for
the class can be used

(I favour the factory approach for COBOL and was surprised to see that some
OO COBOLlers here don't use it. It is very advantageous to set a factory
property one time (say at start of day) and know that all objects of that
class will have access to it without any further effort or changes to the
method interfaces.)

You don't have to do that with Java because the "group" is a
class, essentially, and when you instantiate the class it creates the new
object based on the current version of the class -- basically the class
itself has control over it's own instantiation.
The Class includes the Propertiesof the Class, yes.

As long as the
instantiating class does not attempt to access class variables directly
then
it doesn't matter if the changed class is larger, smaller, has variables
moved around in memory, etc.

That's right. Although I wouldn't want to maintain a Class once it is
written, and have covered that elsewhere... :-) The point is that in an OO
environment there are many more options for modifying the behaviour of a
class, without actually needing to recompile it or the programs that use it.
(I have Booleans in some Classes that allow the behaviour of Methods to
change so the behaviour of a Class can be changed just by flicking a few
switches. These switches are not in the interface (as they would be in a
procedural module) but in the properties of the Class, accessible with GET
and SET.


So the question, is, can this type of behavior be somehow simulated in a
procedural (non-OO) language? Seems to me not very easily. Perhaps you
could get your procedural code to "act" as if it's OO, but I'm sure that
wouldn't be worth it.

It's an interesting question and I gave it some thought. You are right that
a solution (at least the ones I can envision) all involve so much work that
you would simply give it up and use OO, but here are some "academic
exercise" suggestions:

1. Write a procedural module that has no interface. (Other than the main
entry point). So, no USING and no RETURNING. How do you get data in and out?
It has to be by means of a Transaction queue (a la CICS), or a terminal
dependent buffer (SPA as in IMS, or Comm Area as in CICS, or similar
mechanism on other platforms.) The problem now is that the module has no
control over its data (it cannot "OWN" it) and the data is no longer
encapsulated. (Buffers can be reclaimed by the system and queues can crash
at any time.) This process is analogous to the idea of GETting and SETting
properties within Method code. It also allows multiple "instances " of data
to be associated with one (reusable and possibly, re-entrant) piece of code.
Note that any "Methods" (called subprograms) using this data would have to
treat it as an "external global" resource. It isn't OO, but it is
analogous...(In some limited ways).

2. Use nested programs to place data and procedural code within one overall
"Class". The "Methods" would each be subprograms and would have their own
encapsulated data divisions. You would need to provide GET and SET "methods"
(in fact, these would be procedural entry points) for each of them to allow
access to the internal data.

There is a very faint relationship between this approach and the way that
Fujitsu PowerCOBOL handles the OO controls and event processing it has to
manage.

And that's where we come to the nub of the problem; none of the above deals
with handling events, the way a true OO component or Class can. Java code
can "listen" and be activated when certain events occur, PowerCOBOL handles
a wide diversity of interrupts and the events raised by them, so does C++
and even Visual Basic... Interrupt driven programming is the heart and soul
of OO and it would be very tedious to emulate that with procedural code.

Sorry if that question didn't really make sense. I'm having a hard time
phrasing it. Anyway...

Well, I had a shot at it... I'm sure others here could shed different
insights on it. For myself, I'll stick to OO... :-)

Pete.



.

Quantcast