Re: Java is becoming the new Cobol

On Thu, 3 Jan 2008 11:11:02 +1300, "Pete Dashwood" <dashwood@xxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:28b05ca0-c7a7-4ad5-b307-644da0ffc5fa@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

The article is not making the point that Java is becoming the
corporate language of choice, as Cobol is/once was (choose one), but
that is is becoming obsolete as it is being replaced by newer
languages such as "Ruby, PHP, AJAX [sic]", and even C#.

http://www.infoworld.com/article/07/12/28/52FE-underreported-java_1.html

"""If you're a Java developer, now's the time to invest in new
skills."""

It's true. It is even truer for COBOL developers.


There was a quote from a quarter century ago or more that went "10
years ago there were 3000 languages and COBOL, today there are 300 and
COBOL. In 10 years time I expect there will be 30 and COBOL."

The question then is: Is Java just another fad language in the range:
Algol, Pascal, Modula2, Ada, C++, that will be replaced by the next
fad languages Ruby, PHP, C# which will then be replaced by the
next ...

Bad Question.

Algol, Pascal,Modula2 and Ada were NOT "fad languages", and neither are
Ruby, PHP, and C#.

They simply addressed different paradigms.

Or will Java really become the next Cobol and will continue for
decades more ?

Java will not become the new COBOL and neither will anything else.

I believe SQL is becoming the new Cobol, for these reasons:

... It has been largely unchanged in 20+ years.
... It faces little competition, because database servers cannot easily be altered
to accept another language.
... It successfully ignored OO additions in the '90s, analogous to Cobol.
... Long running batch programs are being written in PL/SQL. There are whole shops,
mostly in data warehousing, that do 100% of development in PL/SQL, SQR and database
utilities.
... A recent survey of job ads found PL/SQL is second highest skill in demand by big
companies, after Java. It is higher than C++, C#, PERL, Ruby, et al.
... Attempts to replace the two dimensional relational model have not been successful in
the commercial marketplace.

COBOL belongs to an era when there was no Network and a centralised
mainframe only needed one or two high level languages to program it.

A network INCREASES the need for interoperability. When mainframes were islands and data
was passed via flat files, it didn't matter what language the other shop was using. Now
that we pass data by setting a DbLink to the other shop's database, we must talk to it in
SQL. XML doesn't change that much because it is hierarchical rather than object model and
its schemas usually map closely with underlying database schemas.

Those days are gone and COBOL is hanging on currently purely because of its
legacy applications. Even these are being slowly replaced. The only new
development in COBOL of any significance is probably on less than 1% of
sites Worldwide, and most of this will be mainframe, and procedural batch
processing.

Generally true, but a non-trivial portion, maybe 30%. of Cobol runs on Big Unix. For
instance PeopleSoft and Lawson.

The trend is to replace COBOL.

Initially that will be with Java (for the most part), but the important
thing here is not the language, but the paradigm.

Java is an OO language and OO is the basis for future development. COBOL
missed this boat (not through any fault of the language or the vendors of
it, but through the shortsightedness and arrogance of the COBOL community)
and there is no way of catching up.

Once something has been refactored into objects, the languages used to
access the objects are irrelevant; it is the paradigm that is important.
Languages like Java, Ruby, PHP, and C# are designed around OO and are
therefore relevant. It isn't a fad; it is here to stay.

Agreed. But isn't it contradictory to say language doesn't matter while pronouncing Cobol
dead? Cobol can talk OO as fluently as other languages.

Certainly, the
technology may move on from OO (it is already doing so with component based
systems), but the underlying base for the perceivable future will be OO, and
commercial sites will use whatever langiuages support this.

Sometimes it appears they'll use whatever the Fad Language Of The Month Club sent last
month..

.

Relevant Pages

  • Re: Cobol2Java: a Cobol to Java source code converter is available for evaluation
    ... If you were suggesting to use a C/C++ to Java tool that I may agree ... better because of being translated to a different language. ... Cobol is far from OO. ... many printers and page format as need at any time. ...
    (comp.lang.cobol)
  • Re: COBOL to Java conversion
    ... but also to change the language to be Java. ... I would be interested in knowing if anyone has seen a successful ... A significant size would be more than one million lines of COBOL code. ... "COBOL to Java is like a dog raised up on its hinder legs. ...
    (comp.lang.cobol)
  • Re: Cobol2Java: a Cobol to Java source code converter is available for evaluation
    ... If you were suggesting to use a C/C++ to Java tool that I may agree ... better because of being translated to a different language. ... Cobol programs in the Java syntax. ... It is also a way to keep Cobol programming if you like it. ...
    (comp.lang.cobol)
  • Re: Structured Coding
    ... more visual, some are more conceptual, some are more language oriented. ... I had major problems struggling with OO COBOL when it was first released. ... programming language ever written; light hearted, witty, amusing, ... Later I had to run some courses in Java Web programming and ...
    (comp.lang.cobol)
  • Re: COBOL to Java conversion
    ... Using the same programming language and keeping the code intact is a ... but also to change the language to be Java. ... A significant size would be more than one million lines of COBOL code. ... In the company I work for they put java in their multi platform COBOL ...
    (comp.lang.cobol)