Re: Is it possible to use the value of the PROGRAM ID within the source code?

From: Richard (riplin_at_Azonic.co.nz)
Date: 06/19/04 

Date: 18 Jun 2004 23:49:46 -0700

robert.deletethis@wagner.net (Robert Wagner) wrote

> But it has, at least once. When Structured Programming appeared in the late
> '60s, we already had a substantial body of work based on GO TO. Had this forum
> existed then, I can picture heated debates between the Old Guard defending GO TO
> and bright-eyed 'progressives' decrying GO TO. For once, the good guys won,
> although we still see backguard pockets of resistance some 35 years later.

There is nothing in 'structured programming' that prohibits the use of
GO TO, though it may restrict the scope of its use.

Personally I find that I never need GO TO and have a style in which it
can not be useful.
 
> What happened to that spirit of improvement? OO Cobol is roughly comparable to
> Structured Programming back then. Why has it been ignored by the Cobol
> community? Because we're now aged 50-60 rather than 20-30? Or is it because
> mainframe shops have Programming Standards prohibiting progress? (pardon
> alliteration)

No. That is not the case. Much of the OO features in C++, for
example, are to solve the problems of the C language. In many cases
Cobol never had those problems. Now OO does have some really useful
functionality, in many cases the types of applications that Cobol is
commonly used for does not need this functionality. In other cases,
such as in your demonstration, the OO is not only inappropriate but is
far slower when compared to conventional solutions.

If you had learnt other languages well enough then you would have seen
where the OO solutions were required and could evaluate whether these
could be applied to Cobol.

> I don't think pointers make Cobol C-like; I think they make it equally capable.

One of the reasons that C++ of the 80s is a step up from C is that it
replaced pointers with objects. Memory management was contained
within the objects. The reason that Java of the 90s is a step up
from C++ is that the objects themselves are garbage collected. These
two steps removed all the manual grubbiness from pointers that were
the bane of C.

Cobol never had this pointer problem because the applications
generally did not require them. C used them to build trees, lists and
other complex structures. Cobol just put this data into files and
arrays.

Introducing pointers to Cobol in the way you want them to be used just
takes the language back to the C of the 70s. There are reasons for
wanting pointers, such as interacting with the OS, but these should be
as restrained as possible. They are not an 'advanced feature', they
are taught in a 'C advanced course', because the programmer needs to
be better than a beginner.

> Before compilers 'extended the Standard' to support pointers, we did it with
> calls to assembly language programs that modified 'BLL cells'. Pointers are an
> essential tool. Their absence in Java and C# is a serious limitation to those
> cultures.

You simply show that you never went through the learning process that
led to the reason why they are not in Java or C#, and what has
replaced the need for them.

While trivial programs, such as your demos, may make pointer
management seem easy this is not the case in any substantial program.
C++ programmers who wrote large C applications with pointers know why
C++ introduced objects. Java programmers who did large systems in C++
know why garbage collection was added and pointers were removed.

You obviously did not go through that and so promote starting at step
1 in the 70s.

> Resisting progress is one thing, arguably good; ignoring and rejecting it is
> Bad. Cobol's strength doesn't come from immutability, it comes from
> extensibility. OO Cobol is a good demonstration of the language's vibrancy ..
> and its adherents' resistance to progress.

Pointers are _not_ progress. Your demo of doing anappropriate things
with collection classes and then concluding they are slow and poor is
not progress. If you want progress then do something _better_.

> I agree -- diletantes will not stick with Cobol. Good riddance.

So why do you care what they say about Cobol ?

Relevant Pages

  • Re: [SLE] Re: GNOME vs KDE Redoux
    ... I've found Java to be a tight and comfortable ... programming language. ... program COBOL have had our share of both of the others also... ... and C programmers need and *must* always and forever use pointers. ...
    (SuSE)
  • Re: Relevance of languages WAS: Re: Date Validation in COBOL
    ... Very good response from both you and Howard. ... COBOL replacing Assembler was one ... programming to the masses was a very bad move and there would have ... because COBOL controls everything and is not designed for responding ...
    (comp.lang.cobol)
  • Re: Is it possible to use the value of the PROGRAM ID within the source code?
    ... When Structured Programming appeared in the late ... Why has it been ignored by the Cobol ... >replaced pointers with objects. ... Memory management was contained ...
    (comp.lang.cobol)
  • Cobol and OO programming: the final chapter!
    ... The history of Cobol today is often modeled as an evolution in steps ... reflection of the OO programming influence, ... ideological fight for pimp standards has basically already been fought ... must assume it does give us the fittest ideology for the times. ...
    (comp.lang.cobol)
  • Layers, objects, and granularity
    ... working with classes and objects in COBOL and ... from the input and output and replace them with an interface. ... Presentation layer, Business layer, and Data access ... Leaving aside the debate about OO programming versus Procedural programming, ...
    (comp.lang.cobol)