(not entirely...) OT: OPINION... chicken entrails, runic stones, and crystal balls... WAS CoBOL moved to OO

From: Peter E.C. Dashwood (dashwood_at_enternet.co.nz)
Date: 01/01/04 

Date: Thu, 1 Jan 2004 21:29:37 +1300

"Richard" <riplin@Azonic.co.nz> wrote in message
news:217e491a.0312311900.7e1c2e1d@posting.google.com...
<snip>
>
> > The language wars were fought 15 - 20 years ago and C
> > (and it's derivatives) won.
>
> Nonsense. The areas in which C and C++ dominate (ie 'computer science'
> based arenas) are a continuous war that has moved from Algol through
> Pascal, Ada, Modula2, C and C++ and is now moving on to Java and C#.
> In another few years it will another few different or derived
> languages vying for attension.
>
> Meanwhile businesses will still use Cobol and scientists will use
> Fortran.

As you know, I disagree with this, but your post made me think.

I agree completely with your analysis of the "computer science" wars, so I
need to re-evaluate why I don't share your view regarding COBOL and Fortran.

After some consideration I have reached the following conclusions:

1. SOME businesses will continue to use COBOL (I believe it will be mainly
for Batch processing.). I also believe that there will not ALWAYS be a need
for Batch processing. (I know it's hard to believe in the current
"state-of-the-art"). As online transaction rates increase and online systems
become ever more efficient, there is no conceivable need for overnight
updates. Distributed systems through Client Server and the Corporate
Intranet will remove the need for Report runs off a central mainframe.

Some reasons why I believe that serious in-house development won't use
COBOL:

    (a) There are cheaper, better, faster alternatives becoming available.
"In-house development" is likely to be distributed back to individual
departments within the organisation and they will use standard tools to meet
their local needs. The Corporate systems will be based around standard
packages like SAP and Siebel, and the role of "bespoke software generation"
will decline to the point where it will simply involve plugging a few
standard components from the Corporate component repository into standard
desktop software. (OO, which COBOL seems to have missed the boat on, is one
of the major facilitators of this capability.)

    (b) Because (without OO) it is a closed system and cannot easily
communicate with all the "standard" desktop tools that users are coming more
and more to take for granted. (Like Spreadsheets, Word Processors,
Databases, etc.). When another report is required, most Businesses are not
going to accept that a COBOL programmer is required to write it. As skill
levels of users inevitably increase, they will simply use standard software
and do it themselves.

(By "standard software" I do not necessarily imply ONLY MS, although that is
certainly the de facto standard for most businesses at the moment. I think
we will see more businesses looking to remove their dependency on MS by
installing Linux and Unix (at least for trials...) and it will be
interesting to see what MS does to counter this. COBOL cannot (without OO)
be part of this, whether it goes Unix or MS, so that means that COBOL is
likely to be confined to the last bastions of procedural code, the
mainframes. I am not confident that mainframes will continue to be used for
any real length of time, UNLESS the WAY in which they are used changes. It
is interesting to see IBM advocating WEBSPHERE and Java and even component
use for mainframes. Again, without OO, COBOL will play what must be
essentially a "rearguard" action in this arena. Because of tradition, these
sites will support COBOL, but as the pressure comes on from cheaper
alternatives, they will slowly disappear (or transmute into something other
than what they are today...)

    (c) Fewer and fewer Businesses are going to invest in expensive in-house
IT development when they can cost-effectively outsource it, or use packages
that provide standard functionality and can be maintained (configured) by
users rather than programmers.

    (d) Many CEOs are wanting to get back to the Business they are in, and
resent the huge budgets we have seen for in-house IT departments. If your
business is Insurance (for instance...) you may resent spending 15% of your
turnover on maintaining in house IT facilities, when you could buy the same
service for 2%. (I know of one major Australian Insurer who did exactly this
some years ago; it was devasting to the COBOL staff, but it was a "right"
Business decision.)

    (e) None of the above even considers the impact and effect of "fashion"
which, whether we like it or not, DOES colour Board level decisions. COBOL
is perceived as being outmoded, old-fashioned, and, in some cases, downright
dangerous. Despite modern facilities being provided by vendors, the uptake
by the user base has simply tended to confirm the "conservative" perception
of COBOL and COBOLlers. I am persuaded that it is now too late to do
anything significant about this, but I hope I'm wrong.

2. Scientists will use FORTRAN.

This is not in quite the same category as COBOL because the users tend to be
a very small base within a given organization.It is not "visible" to the
organization at large. FORTRAN is easily learned and a very useful tool for
many scientific applications. (I remember meeting FORTRAN evangelists during
my time with CDC (in the 1970s), where we were dealing mainly with
Scientific applications. It was (is?) adequate to the task and nobody had
any problems with it. I think the "new" generation of laboratory people will
probably prefer VB, and I have seen some stunning scientific stuff written
in Java, but I have to admit, FORTRAN is likely to outlive COBOL.)

Pete.