Re: Is Micro Focus doomed?



James J. Gavan wrote:
> Judson McClendon wrote:
>
> Donald is lost to the COBOL cause. If they offered him a freebie set of
> CDs in a leopard covered case - it just wouldn't make sense for him to
> 'reverse convert'. From what he wrote, he is obviously talking M/F
> (runtime fees) and he was probably getting answers from the lowest
> person on the marketing team ladder in Toronto. Shame on you Donald. I
> thought you, as a Socialist were passionate about rights and fair play.
> Perhaps you are a lover rather than a fighter.
>

Completely irrelevant.

I like the Cobol language, and always have. I've worked in it for 40
years now, and find Cobol both easy to read and easy to write. However,
when choosing how to write code, my likes and dislikes are rather
irrelevant. What is relevant is costs, hassles, and the length of time
it takes to write the system, plus incremental costs that occur after
the fact, like marketing and upgrading/maintaining.

Cobol is wonderfull at handling fixed format data. The picture clause is
probably the most efficient (and oop oriented) method of specifying a
data format ever invented, and all by itself made programs far more
solid. Cobol was also one of the *only* languages that had some sort of
uniformity accross platforms, so in terms of product lifetime was one of
the best languages.

However, it is terrible at handling free-format data, and suits the
cosmetic part of programming poorly, at least in the modern world. In
addition, it is no longer uniform. Most of the Cobol code I have seen in
the last five years is easier to re-write than to convert. Because most
of the formating and I/O are now external, you are not only tied to the
Cobol compiler, but to three or four other tools that all are platform
dependant. Cobol has become *worse* to convert than other languages,
albeit largely for historical reasons.

About 90% of the Cobol code I replace, I replace not with new code I
wrote, but with new code that was generated automatically by a tool. For
example, I wrote 15 programs to convert data from Isam files yesterday.
Essentially, all I did was enter the copy books into a data dictionary,
and it produced all the conversion code, all the basic listings code,
and all the screen update code. What I spend my time on is refinements
and prettifying it.

Cobol has not caught up. At one time, I thought it could, and maybe it
still can, but I cannot afford to wait.

Now, in addition to that, they have added a huge cost factor. Commiting
financial suicide to remain faithfull to a concept as abstact as a
language ... well, maybe if I was French Canadian. It is no longer Cobol
anyway. It is now MF Cobol, Fujitsi Cobol, etc.

I see no reason to fight back. I'd no sooner fight for Cobol than I
would go to war for Ford. There are more important things in life. I
just try to adapt to the silly shit, and make a living. Ill send you
fiddle tunes instead of Cobol, maybe. You'd probably enjoy them more anyway.

Donald

.



Relevant Pages

  • Re: Theodore Adorno, a prophet of data systems design
    ... Hey, goose man. ... >> especially those who cling to outdated languages. ... Buddy of mine wrote an efficient chess program in Cobol to demonstrate ... Levine the Genius Tailor says, "no problem, just hold your arm like ...
    (comp.programming)
  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... with no mainframe COBOL at all, ... And general-purpose computers running general-purpose applications are a ... movement in general programming toward better ... But are these pockets of "old time languages" significant in a global ...
    (comp.lang.cobol)
  • Re: Could this save COBOL?
    ... I am personally of the opinion that any languages not supporting the OO ... paradigm will be gone within 10 years, and that includes COBOL, unless it is ... OO COBOL running in the Dot NET environment could have a real chance of ... If the lifeblood of COBOL is going to be 1960s code in a mainframe ...
    (comp.lang.cobol)
  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
  • Re: Cobol News - Microfocus and AcuCOBOL
    ... I think they are the languages of today. ... I disagree strongly about problems for the programmer. ... It is a hard concept for COBOL people to grasp.. ... functionality comes along, it inherits what is there already and extends it. ...
    (comp.lang.cobol)