Thoughts on teaching OO concepts to COBOL programmers

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.

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. Of course, that includes what was not helpful as
well. We often learn more from our mistakes than our successes.

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.

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

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.

Thanks in advance to all who respond. Either via newsgroup or to
zberger at knology.net. I really appreciate your thoughts.

Regards,

Joe Zitzelberger
.

Relevant Pages

  • Re: GoTo in Java
    ... were a year or two down the track and everybody was very happy with OCaml. ... > language switch would pay off in faster development (due in part to ... COBOL as a scripting language for .NET. ... Compare this with COBOL programmers discussing Java... ...
    (comp.lang.cobol)
  • Re: Infinite Loops and Explicit Exits
    ... but C programmers know not to do it that way. ... not what Cobol programmers want. ... null-terminated memory format is unsuited to storage in a file. ... What kind of programming language doesn't natively support ...
    (comp.lang.cobol)
  • Re: Declining Cobol job market
    ... pursuing Cobol jobs. ... server side programming in PL/SQ. ... A lot of COBOL programmers (and RPG programmers, and Assembler ...
    (comp.lang.cobol)
  • Re: How proprietary is the "COBOL file system"
    ... like RDB, for the same reason. ... COBOL was left behind. ... businesses to keep their old language, or to go to a new language: ... they have mainframe programmers and web programmers. ...
    (comp.lang.cobol)
  • Re: OT: Religion in CLC posts WAS: Re: MF Collection Class speed
    ... possible that Cobol programmers see themselves as defenders of an intellectual lost cause?The last hangers-on of an idea whose time has passed. ... The absolute power was a corrupting influence, just as it has been in certain other religions. ...
    (comp.lang.cobol)