Re: Relevance of languages WAS: Re: Date Validation in COBOL

Richard wrote:
On Jan 8, 3:17 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Hi Peter,

Very good response from both you and Howard. So I'm taking some time
out to reply, although some of what I originally wrote was not
entirely serious...:-)

tlmfru wrote:
You'll remember the scene of about 15-20 years ago when the PC
tsunami seemed to be about to take over the IT world, when even
mighty IBM was reeling under the assault, when the BUNCH
(Burrroughs, Univac, NCR, CDC, and Honeywell) were effectively
eliminated as mainframe companies (stipulating that
Burroughs/Univac still exist as Unisys, but with a vastly changed
business model). At that time there was much comment as to what IBM
should do. I remember a series of articles in Computerworld (I
think) expressing opinions; most of them suggested a radical change
of course, some going so far as to insist that IBM must implement
Windows on its machines and abandon its own o/s'es! None of which
they did.

I was working for CDC at the timeof the anti-trust suit and remember
these times very well. I later worked for IBM just after the dismay
at losing thier leadership (both market and corporate) was beginning
to be felt, and I think the only thing that saved them was the
appointment of a CEO who knew what was going on. It's hard to
believe that a company whose net profit was equivalent in one year
to the GNP of New Zealand, could, within a few years, be in danger
of losing it altogether.

(Some might say this is a lesson MicroSoft would do well to
remember...)

While some will hope that they don't learn from the past and will
repeat it themselves.


How does this relate to the questions expressed below?

Only this: that a great deal of the changes in this industry are
driven by sincere but not always well-informed enthusiasms.

Absolutely. Seen it many times. COBOL replacing Assembler was one
such... :-) Instead of developing high level languages which enabled
people who really weren't programmers to try their hand at it,
imagine if they had focused on improving the development facilities
available in Assembler, instead? Programming would have stayed with
the professionals, and the professionals would have been much more
productive.

"properly informed" people would have realised that bringing computer
programming to the masses was a very bad move and there would have
been no COBOL or PL/1. Platform transportability could have been
achieved by low-level code conversion software instead.

I

instance acouple of my younger colleagues who goggled with awe at
the successive announcements of a new chip with 10% more speed;
"jeez, I've got to have that", they would cry, then be utterly
unable to understand why I didn't follow suit; or the engineers who
were learning VB assuring me that they were using a new
"event-oriented" method of programming which I wouldn't understand,

Ah, the arrogance of youth... :-) There's usually no malice in it.
To be fair, getting COBOL programmers to understand and embrace the
interrupt driven model of programming is sometimes difficult, simply
because COBOL controls everything and is not designed for responding
to events. People get used to initiating processes and controlling
them. When something screams: "Attend to me, NOW!" it is a bit of a
paradigm shift...

People without the benefit of COBOL experience pick it up very
quickly.

then shamefacedly
admitting that my advice worked; one real enthusiast declared in
print that once C replaced Cobol, maintenance costs would
immediately come down.

Well, they did with the advent of C++. (The OO features mean reuse
and less maintenance.) I still wouldn't advocate C or C++ as a the
preferred choice for Business code development; especially not when
there is C# which combines the best of these worlds with the best of
the Java world as well, and even throws in a smattering of VB for
good measure... :-)

The issue of maintenance costs was the subject of an infamous
Datamation article in the mid 80s. They surveyed various development
departments and identified the language used and the time spent on
'new' and 'maintenace'. Of course most in-house and packaged business
software has 'maintenance' as developments needed to meet changing
business requirements, while non-business applications in C tended to
only refer to bug fixing as 'maintenance' and feature enhancement as
'new development'

The conclusion of the article that if C was used, rather than Cobol,
then costs would be slashed because maintenance would disappear was
grossly flawed. The maintenance requirement was a function of the
application type, not of the language.

Even your claim that OO reduces maintenance is flawed.

No, it isn't. I have figures and statistics collected over 3 years to back
it up. I was saving before that, but that is all I have documented.

I can't speak to other people's experience, but in my case, at least, moving
from procedural to OO COBOL was a major step in increasing overall ROI.
Moving to C# has increased it again because productivity is higher, and
using .NET means that "old" and "new" can play nicely together without
problem. This extends the life of the "old".

It may do so
because one does not change an existing class (maintenance) but one
writes a _new_ class that inherits from the old and has the
differences catered for. Claiming that this is therefore 'less
maintenance' fails to acknowledge that it arrives at the same result
after much the same effort (but can eventually lead to inheritance
hell).

No, you have failed to realise that with a component based approach things
are much more configurable. It isn't just about extending existing classes
(although that certainly figures in it). Behaviour can be changed by
configuration, by the order that components are activated in, by adding or
configuring Framework Classes that require no maintenance at all, or by
minor changes in the "glue" that holds everything together.It doesn't ALWAYS
require a Class extension. The reason I say that OO component based
approaches require less maintenance is because of granularity, not becase of
the innate mechanics of this architecture.

As for ".dll Hell" I've not personally experienced it. I have good
inventories of the components I use and the .NET framework is very well
documented, publicly, so the components available from there are easily
recognized. Provided proper design is done, there should be no need to
descend into "inheritance (or any other kind of) hell".


<snip>.

I'd almost agree here. Unfortunately, it isn't just about "business
problems", it is also about how solutions should be deployed and how
responsive these solutions are to a rapidly changing business
environment. If I need some "intelligence" at the Ulan Bator end of
the corporate network so the boys can keep us updated on the price
of mare's milk and spot emerging market opportunites, I need a
different solution than the one I use when I'm talking to Farmer
Brown about the price of cheese, for local distibution. And if the
Mongolians suddenly decide they might go for cows instead of horses,
I need to be able to amend my solution very quickly.

There was a time when a computer sat in the middle of the office and
did its thing. Both problems and solutions were simple and
relatively static. People communicated wth it by means of green
screens which it drove by timeslicing the power of its processor.
(And this was considered a very lucky break, after having to provide
punch cards and receive information printed on screeds of green
lineflo...)

Actually many computers still do that, except the screens are multi-
coloured, and they may be in the middle of some other office.


I haven't seen anything recently driving a 3270 screen in 32K of Foreground
1, but I'll take your word for it. :-)

That (slightly gentler) time is gone and we are living with a "now"
generation who have the attention span of a flea, the
self-discipline of a ferret, and who have been exposed to television
advertising since the day they were born. OF COURSE, they love
what's new. OF COURSE they love technology (even though they have no
desire to know how or why it works; the very few that actually do
have some remnant of the curiousity which stimulated the Human Race
to evolve the way it has, are described as "nerds" and "geeks" and
prevented from contributing to the gene pool by social mores that
will ensure no self-respecting member of the opposite sex goes near
them ...)

So, given this scenario, I can't actually agree that solutions can be
provided by the mainline languages of yesteryear, to TODAY's
problems. Sure you can implement an algorithm in almost any
language, but that, in and of itself, does not necessarily represent
a SOLUTION.

All languages have calling facilities, after all, so
the lack of intrinsic facilities to handle everything - e.g.,
(pending corrections) I don't think any "high-level" language can
directly manipulate I/O gear or handle interrupts, etc. - is no
impediment to its use.

So, you are advocating using these languages as "glue" or a
"Framework" where they can simply call out for assistance in the
areas they are not good at? I think there is something in that. I
used COBOL in this capacity for a number of years, but now there are
simply better tools available. (See response to Howard, below.)

There will come a time when so many such
calls must be made to get the job done as to make it sensible to
start using something else, of course; whether we've reached that
point with (for instance) OO or not seems to be highly up in the
air.

My opinions, then: while Cobol is indeed old-fashioned, none of the
reasons for its creation have changed; much of the replacement urge
is clamour; and that Cobol still exists and is still being used for
new development (and I'm NOT going to debate that) is proof enough
of its continued vitality.

OK, let's look at those one by one...

1."none of the reasons for its creation have changed". COBOL arose
out of a fear by customers that they were spending large amounts of
money to develop computer systems which locked them in to a
particular vendor's platform. Developing lines of code in Assembler
is just as expensive as it is in COBOL, and knowing that if you ever
have a disagreement with your hardware vendor, there is nothing you
can do about it, doesn't help the situation. The idea of "platform
independence" gained very rapid acceptance and by the early 1960s it
was like the "Holy Grail" of computing.
Vendors realised that providing a "high-level" language, was going
to be a major sales clincher and they were all working flat-out to
be first. The CODASYL formalised it and got the major players to sit
around a table (Grace Hopper and the DOD deserve some credit for
driving this) and even contribute various ideas and existing
software. It didn't take vendors long to realise that they could
still make "migration" away from their hardware very difficult by
providing and encouraging the use of "extensions" to the early
standards, and they vied with each other to provide the most
"useful" extensions. COBOL was NEVER about a language for
implementing algorithms (Algol and Jovial were already around for
that...); it's primary purpose was to provide platform independence,
then to remove the mystery attached to Assembler programming, and
improve productivity and ease of maintenance (hopefully...)

Is that like today? I don't think so. Platform independence is not a
problem; we use networks with protocols recognised by all the
attached hardware.

'Platform independence' _is_ still a problem, mainly because Microsoft
regards it as meaning 'both Windows XP _and_ Windows Vista' and make
subtle undocumented changes to attempt to lock in their products and
lock out every one else's, as well as their older products.

No comment to blatant troll, Richard... tsk, tsk, you really should know
better... :-)

I have no problem with communicating across platforms using a commonly
acepted protocol (and even, occasionally, some that are NOT so commonly
accepted... TCP/IP is not the ONLY internet protocol...). If you want stuff
to be platform independent, develop Web based systems. They'll run on XP
Vista, Linux, Unix, MacOS and any other OS that recognises the protocol and
has a browser... Sure there can be browser inconsistencies, but they are
minor and comparatively easily rectified, as we have seen here recently.
That was simply inconceivable at the time COBOL was developed.

This is the reason they introduce new .doc formats with almost every
release, they want to force everyone to buy the new versions and to
eliminate non-microsoft products.

Aren't you even a little bit tired of banging this old hackneyed drum? The
doc formats are now public, anyone can download a FREE viewer for any MS
document, and people ARE using alternative products (I get offered Open
Office for free every time my system updates Java...) Sure, MS would like
us to buy their products. I don't know any business currently trading where
that ISN'T the case...Personally, I use MS products because they work
extremely well (for the most part), and on the occasions when they don't,
Help is a couple of mouse clicks away. Mainly, I use them because that's
what most of my customers (existing and potential) use, but I'm aware there
are alternatives and I have a choice. Given that such is the case, I cannot
share your vitriol for MicroSoft (although, of course, I respect your right
to your opinion).


This is why they introduced IE incompatibilities and made Frontpage
and IIS generate IE-only http.

IIS doesn't generate anything. FrontPage has fallen into disfavour and I
believe is now replaced.(I don't know a single professional web developer
who ever used it, anyway. I tried it myself and found it to be a poor shadow
of DreamWeaver so haven't used it since - that was around 10 years ago...)
IE extensions were introduced because the standard stuff (at the time)
couldn't cut it. Most of what were extensions are now standard (or there is
equivalent standard functionality), so that is academic. I could argue that
MS did the community a favour by providing the functionality that people
wanted and thereby urging W3C to consider these features.

You may be a bit out of date on web development, or at least web development
using MS tools.

Networking with SMB only remains cross platform because the Samba team
can reverse engineer all the changes that MS introduce.

Well, that's a good thing.

Removal of mystery? Today's generation accept computers as easily
as they do cell phones. (I was amused yesterday when a friend who is
in her sixties was looking for GOOGLE on a computer that didn't
belong to her. Her 19 month old grand-daughter obligingly picked up
the mouse and opened the Browser for her...) Ease of maintenance?
What maintenance? Write components and reuse them. Productivity? I
can write C# at approximately 6 times the rate I could write COBOL
(NOT based on lines of code, but on results achieved. Powerful, more
compact languages with highly intelligent IDEs are simply quicker
and easier to write...)

2."much of the replacement urge is...

read more

No, I don't think so... :-)

Pete.
--
"I used to write COBOL...now I can do anything."


.

Relevant Pages

  • Re: Relevance of languages WAS: Re: Date Validation in COBOL
    ... COBOL replacing Assembler was one such... ... print that once C replaced Cobol, maintenance costs would immediately ... application type, not of the language. ... The idea of "platform independence" gained very rapid acceptance and by the ...
    (comp.lang.cobol)
  • Re: PowerCOBOL conversion to DotNET
    ... COBOL from the seventies, which have been converted and migrated across ... Presentation layer. ... comes to platform change. ... Moving to C# is not really about the language; ...
    (comp.lang.cobol)
  • Re: PowerCOBOL conversion to DotNET
    ... COBOL from the seventies, which have been converted and migrated across ... Presentation layer. ... comes to platform change. ... Moving to C# is not really about the language; ...
    (comp.lang.cobol)
  • Re: DRAFT COBOL revision
    ... GOOD EXAMPLE since this is a weak typed language, so a variable, could ... so why not OO Cobol? ... I do programming in Java in a daily basis, ... You could reasonably expect that maintenance due to business ...
    (comp.lang.cobol)
  • Re: Cobol for Visual sutdio
    ... People interested in using COBOL with Visual studio might do well to look ... Studio as part of a migration away from the mainframe platform. ... It is a problem with the COBOL language so neither of them can implement it ...
    (comp.lang.cobol)