Re: CoBOL moved to OO

From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 12/30/03 

Date: Tue, 30 Dec 2003 12:25:54 +1300

Good post, Ray.

I found your conclusions excellent and don't really mind you disagreeing
over recursion <G> (Please note that I never used the term in my original
post, as it is not what I was trying to demonstrate...it is the difficulty
of using OO "equivalents" to procedural processes, that really fails to sell
OO....- that was the point I was TRYING to make <G>)

I think you are right about the "mix" and I endorse 100% your indication
that we shopuld be considering how to help COBOL people bridge the gap.

Pete.

"RKRayhawk" <rkrayhawk@aol.com> wrote in message
news:20031228192321.19959.00001141@mb-m01.aol.com...
>
>
> In one of his many fine and generous posts
>
> "Peter E.C. Dashwood" dashwood@enternet.co.nz
> Date: 12/27/03 3:36 PM EST
> Message-id: <3fededd4_5@news.athenanews.com>
>
>
> offered an expression that I would like the privilege of disagreeing with
>
>
> snips infront
>
> <<
>
> If I use INVOKE, I can have any number of "copies" of the same
encapsulated
> code, all in different states (or not), and I can manage any or all of
them
> very simply and easily. Not only that, but it is efficient in machine
terms
> as well. To do this with CALL I would need to contrive different module
> names for the same duplicated source code. I can never process these
copies
> in parallel (I can with INVOKE), without writing special facilities to let
> my Operating System multi-task them.
>
>
> >>
>
> snips behind
>
>
> Actually, the single thing that distinguishes old old old COBOL from all
of the
> languages that descend from ALGOL is that COBOL resisted recursion until
very
> recently. But it is notable that RECURSIVE program ID syntax enters COBOL
with
> COBOL 85 (I think), and therefore before OO COBOL. In any event, you can
have
> recursive programs without having classes.
>
>
> Programming with any language that allows recursion is definitely a
paradigm
> shift when compared to old old old COBOL which did not allow a program to
CALL
> itself directly or indirectly. In RECURSIVE call sequences, each
occurence of
> a program recieves its own complete working storage (speaking in
COBOLese).
>
> That is one of the ways that you can have distinct copies of vast lists of
data
> items 'in parallel'. But there is not much literature out there
encouraging
> folks to go off and design differently with that new COBOL capability. Yet
lots
> of new things are possible with that alone (way short of use of the new
syntax
> infused into modern COBOL 2002 for object orientation).
>
> Recursive design of procedures in program design is distinct from object
> oriented programming. Bubble sort is a recursive algorithm. That is doable
with
> COBOL 85 and the RECURSIVE syntactic element. You would _not_
> '...need to contrive different module names for the same
> duplicated source code ...'
>
>
> Furthermore, with ordinary COBOL a single program can have multiple copies
of
> records and handle them in parallel, simultaneously, as we all do with
two-file
> match routines. The use of OF/IN phrases are not utterly unrelated to
object
> syntax, it is just coded a little in reverse (think about that for a
while).
>
>
> Object methods are recursive. Interestingly, Class methods are
procedurally
> recursive but the Class data (FACTORY data in COBOLese) is not recursive
in its
> deployment (that is, it ain't instance data, there is only one copy of the
> FACTORY). Yet Class methods and data are part of object orientation.
>
>
> The only way in COBOL to wake up a method is the syntax of INVOKE, simply
> because the language standards folks have not devined an easy way to allow
for
> referential activation. There are some experimental syntaxes that allow
for
> the specification of some methods with INVOKED AS syntax that approaches
that,
> but it is mounds of stuff ontop of big heaps of stuff. This is really a
shame,
> and I think relates to what this thread is all about (In a small way).
>
> The invocation of the method is exactly where most of us get that Aha!
> experience and the ease of seeing it is going to be denied to COBOLers
probably
> forever. INVOKE syntax is okay, but the new world would be a little
easier to
> see if things were more fluid on the surface of the language as they are
in the
> ALGOL descendants.
>
> Which brings me to my larger point. If I understand this thread, it is
as
> though we have two groups of people. One says I have been to the mountain
and
> seen it and it is a revelation. Others say they have been there but
didn't do
> that.
>
> These interactions are happening between honest people who are taking a
lot of
> time to explicate their ideas. I believe that we can now begin to make a
new
> kind of conclusion.
>
> First, the old conclusion that is available already. Object Orientation
works,
> and scales up to some level of development effort. Second, the new
conclusion
> that is arriving about now is that Object Orientation does not sell the
way
> previous development methodologies sold.
>
> Stating the matter in my own terms, I think the issue is the labor
markets.
> Flatlander COBOL has been used because it works with the very large and
very
> diverse programming community engaged in commercial information system
> development, and because many persons were trained in COBOL.
>
> We have a problem arising here. The future flow of programmers is going to
be
> heavily proportioned with Object Oriented professionals, and the supply of
> COBOLers is rather obviously declining.
>
> The intermediate future is probably one where most of the managers are
> Flatlanders and most of the programmers are mixed and then soon enough
> pretty much all Objectifiers by preference.
>
> The discussions occuring here are simply a prologue for what is going to
> continue for a while. Honesty. Detail. Agreement to disagree. No
resolution.
>
> The new methodology is not likely to displace the old in any wholesale
fashion.
> We will get mix, and probably the ability to mix is what current job
posting
> that list _both_ Java and COBOL are indicating.
>
> What we really should be talking about is how to mix. That is what will
sell,
> as job skills and as solutions.
>
>
> Best Wishses,
> Bob Rayhawk
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Relevant Pages

  • Re: CoBOL moved to OO
    ... the single thing that distinguishes old old old COBOL from all of the ... Programming with any language that allows recursion is definitely a paradigm ... of new things are possible with that alone (way short of use of the new syntax ... Yet Class methods and data are part of object orientation. ...
    (comp.lang.cobol)
  • Re: CoBOL moved to OO
    ... RECURSION was added in the 2002 Standard. ... support to it for COBOL was only ... Yet Class methods and data are part of object orientation. ...
    (comp.lang.cobol)
  • Re: Recursive Call
    ... both direct and indirect recursion is prohibited. ... >> an extension and it does whatever the implementor says it does. ... > COBOL, but I did find it extremely useful in writing a parts explosion ... pitfalls were and what the appropriate syntax was. ...
    (comp.lang.cobol)
  • Re: free implementation? factorial?
    ... >> Alain Reymond wrote: ... >>>Try to use the recursive posssibilities of modern Cobol. ... >> using recursion is preferable. ... the practical programmer/designer, a sort of "Ockham's Razor" approach ...
    (comp.lang.cobol)
  • Re: CoBOL moved to OO
    ... COBOL compilers were always code (not data, ... this is easier to do with stack ... The Burroughs/Unisys Large ... a 'stack' to handle the data recursion. ...
    (comp.lang.cobol)