Re: Thoughts on teaching OO concepts to COBOL programmers
- From: "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 12 Apr 2008 19:42:14 +1200
"Joe Zitzelberger" <zberger@xxxxxxxxxxx> wrote in message
news:zberger-C6D5FC.01023211042008@xxxxxxxxxxxxxxxxxxxxxxxxxxx
I've recently found myself tasked with teaching a few dozen IBM
mainframe COBOL programmers the concepts of object oriented programming.
No specific language syntax, just the concepts. These lucky few dinos
will find themselves mixing their COBOL back-ends with standard Java
apps, J2EE apps, C# apps, or Ruby apps.
To have a company actually offer to teach them this is a fortunate
opportunity. Full credit to the organisation concerned.
My specific goal is not to teach any language specific thing (though I
might use Java for the examples and kill the J2SE, J2EE and C# syntax
with a single invocation of the stone.throw() method). My purpose is to
teach the simple "what is an object", "what is inheritance", "what is an
interface", "what is encapsulation", et al, so that they have the proper
frame of mind to accept the language specific training that will be
offered.
I was hoping that some of you that have COBOL experience AND Object
Oriented experience might share your thoughts on what was helpful in the
learning process.
Having done precisely this exercise in a couple of places, but with smaller
groups than yours, I can tell you that it CAN be hard work. Some people can
suspend belief and look at something anew, others can't. There is a natural
tendency to simply decide that a new concept, sharing certain points with a
familiar one, IS the familiar one being re-invented. (I call this "ITSA").
Once they decide ITSA they will never realise that, in fact, it has very
important differences from the familiar concept. (I call this "ITSLIKE"). It
is important to let them know right at the start some ground rules:
1. What you are going to learn is not in competition with what you already
know, any more than an apple is superior to a fish.
2. Some of what you will encounter will strike chords with you and will
appear similar to things you already know. Please try not to conclude it is
a re-invention of what you know already. There are very important,but subtle
differences that only become apparent as you come to grips with the subject
for real.
3. Any new field has new jargon. Object based development is no exception.
Don't be intimidated by new terms, we'll cover and explain each one as we
come to it.
4. If you could possibly "forget" what you already know about programming,
or put it on hold for the duration of this course, you will make much better
progress than if you keep trying to relate what you are learning to what you
know already. An apple is not a fish, but both can provide sustenance.
Of course, that includes what was not helpful as
well. We often learn more from our mistakes than our successes.
Introduce OO concepts to COBOL programmers by means of OO COBOL. Big
mistake. It is too complex and unfamiliar to be a primer.
Introduce OO concepts by means of an OO language. (I used Java for myself,
but C# would have been better; it is simpler and more subtle, yet retains
the essentials of Java. When I taught myself this stuff it simply wasn't
available.)
For example: I've ruled out the traditional "shape" example to explain
polymorphism -- you know, the one where you have a "shape" base class
with a virtual "draw()" method -- and a "square", "triangle" and
"circle" subclass. I ruled it out because some practicing COBOL
programmers (for decades even) have never put a graphic onto a screen,
only text.
You are SO right to do this, Joe. They have enough to get their heads around
without giving them contrived examples that are outside their experience.
(So my simple example went from "shapes" to the "animal" class with the
speak() method -- you know the dog subclass says "bark" and the pig
subclass says "oink" and the sheep subclass says "baa means no".)
Yes, that is much better.
But I would really appreciate hearing about your experiences going from
COBOL to any OO style of programming. What were your pitfalls, what was
helpful, etc.
One thing I would really love is if you have good textbook
recommendations. If "The Idiots Guide to OO for Cobol Dummies" was the
best thing since sliced bread, please let me know, I might go buy a few
cases and make the author a slightly happier person.
I used "Teach yourself Java 2 in 24 hours" by Rogers Cadenhead. (ISBN
0-672-31630-7) This is the best textbook for self teaching I have ever
encountered. The concepts (including OO) are taught beautifully with wit and
humour. After completing this, I went back to OO COBOL and it all fell into
place effortlessly. (I had spent over 6 weeeks getting nowhere with it
before that...)
At around that time Wilson Price very generously sent me a copy of his book:
Elements of Object Oriented COBOL (ISBN 0-9655945-7-2) which is also
excellent. I could unhesitatingly recommend either or both of these books
for such a course. In fact, you could build a course of 24 classes using
Cadenhead's book alone, then use Wil's book for additional examples,
exercises, and relating the concepts to what happens in COBOL Land.
Pete.
--
"I used to write COBOL...now I can do anything."
.
- References:
- Thoughts on teaching OO concepts to COBOL programmers
- From: Joe Zitzelberger
- Thoughts on teaching OO concepts to COBOL programmers
- Prev by Date: Re: Interesting take on Paradigms (OO vs Procedural)
- Next by Date: Re: Opcodes of RM-COBOL 85
- Previous by thread: Re: Thoughts on teaching OO concepts to COBOL programmers
- Index(es):
Relevant Pages
|
