Re: Wang COBOL alive and well as Wang VS makes a comeback



tjunker@xxxxxxxxxxx wrote:
On Apr 15, 7:13 am, billg...@xxxxxxxxxxx (Bill Gunshannon) wrote:

...
I fought to the last to keep COBOL at least peripherally in the
program here. (Not as a specific subject, but used in courses
like File Processing. In the end, I lost out to Java and whatever
will be the next language du jour...

That last is a major but largely unrecognized and undiscussed problem
in IT today. The language du jour may not last even as long as a
project using it. In a stable mainframe environment we are accustomed
more to the language du décennie (of the decade) or du siècle (of the
century). This contributes to the stability of programming efforts
and the resulting applications.

I don't know of any projects that use Java and have been running longer than
the Java language has been around, or even that use Ruby, or C# and have
been running as long as those languages have been available. Can you cite
some instances? (or even one...)

Your comment is an interesting one. It seems to imply that application
stability depends on platform stability and this is demonstrably not the
case. The mainframe environment has been "unstable" throughout the decades
it has been around. There are always new releases of system software that
impact applications. Even new releases of COBOL have unsettling effects on
applications written in the "old" dialect. Sometimes converting from one
level of COBOL to another can be as big a deal as migrating across platforms
altogether.

Certainly, if you were a mainframe COBOL shop, there was a CONSISTENT
approach to the programming, despite upheavals imposed by IBM changing the
technical environment every couple of years, but that was more to do with
the paradigm the language was based on, than with the platforms where it was
run.

There is a very fine line between the "stability" you commend, and the
failure to recognise when change was needed, and adapt and evolve.

As the network expanded, the idea of a centralised processor driving
everything became obsolete. The procedural paradigm that COBOL was created
for became less and less relevant. Object oriented programming changed the
face of the IT world. COBOL picked it up, but too little too late.

The "Language du jour" is a myth. Unlike the days when there was only COBOL,
(and it WAS a "language du jour") modern environments use a number of
different programming and scripting languages, selecting the best tools for
the job, rather than manipulating the job to fit the only tool available.


The instability that is rampant in IT
today works to undermine the companies involved, in ways their
management evidently doesn't see or understand.

I'm wondering exactly what you mean by "instability". I don't look around
IT and see "rampant instability"; I do see people using different tools to
solve different problems but the solutions are no more or less "unstable"
than they have always been. How long can a production system stay in
production if it is truly "unstable"?


When I was a young smartass I used to look down my nose at ordinary
programming and thought that the world needed more superprogrammers,
and the truly significant things were only done by the brightest and
the best.

Yes, that was a popular misconception in many places for many years. "We
don't write that kind of software; it gets written by experts in Detroit or
Poughkeepskie, or Dayton..." (The "modern" equivalent might be Redmond or
Seattle), and then one day you need something so badly you simply can't wait
for the vendor to do it, so you sit down and disassemble the compiler and
find out how it works and bend it to your will...or, you come in contact
with someone who has never bought into the "superprogrammer" idea and just
inspires you by example.... the kind of guy who picks up an assembler manual
for a machine he has never seen, works nights, and produces a new Operating
System that is far better than the one the vendor gave you... It comes down
to attitude.



Later in life I came to realize that really good and useful
work is mostly done by small, stable groups of ordinary but
constructive programmers, groups with very low turnover.

That is often the case, mainly because they understand the business, having
worked there most of their lives. It isn't exclsively so though. I've seen
teams assmbled for a particular purpose achieve amazing things. It comes
down to motivation, management, the quality of the people and corporate
culture.

This was
really brought home to me by my acquaintance with a civil service
group of about six, who had personally written most of their
repository of 50,000 programs, 37K of which were in current use by
actual audit. They were being displaced by a trend toward
outsourcing, and at one meeting with an outside firm about some new
requirements were told by the outside rep that it might take about six
months to do the work. After the meeeting the in-house guys put their
heads together in the hallway and figured out that with boilerplate
from their repository they could complete the work in a few days.
When the outside rep caught wind of that she said two interesting
things: "That's impossible!" and "They're lying!" Both were
reasonable conclusions from her point of view, in her reality, but
both were sadly wrong. These guys had no need to lie, and would be
put on the spot to deliver (which they had been going, thank you very
much, for the last 15 or so years). Nor was it impossible in the
reality of a small and cohesive group that had been writing that kind
of software for a couple of decades.

Good example. The lady concerned betrayed a lack of experience.

I think there is a parallel in the instability found in IT today.

What "instability"? Are you saying that anything NOT written in COBOL is
"unstable"? That would be a very difficult position to defend.

No
language du jour offers benefits in more than the very short term that
even begin to compare with what can be done with stable tools and
platforms, even if the latter are not sexy.

Sorry, I disagree. In fact the converse is true, at least for me. Since
moving away from the "stability" of COBOL, I have more than doubled my
productivity. The new languages and scripts are more powerful, take less
time to write, and component based development means high level of re-use of
code and minimal maintenance.

And the work product of
the stable tools, on a stable platform, is lasting, witness the
millions or billions of lines of COBOL still doing useful work today.

And being rapidly outnumbered by even more billions of lines of other
languages, every day. The "stability" you keep mentioning is NOT about
languages it is about functionality. If you can isolate functionality and
encapsulate it (and we know a lot more about how to do that now, than we did
in days of yore), it really doesn't matter WHAT language you write it in. I
have recently posted some code that I wrote in COBOL for a mainframe 35
years ago. It is running today as a .Net COM component on a web site,
controlled by server side pre-compiled C# code-behind.
(http://primacomputing.co.nz/cobol21/S2NTestServer.aspx) You can interact
with it through a web page today, just as you would have through a green
screen 35 years ago. A tribute to the "stability" of COBOL? Maybe. A
tribute to the longevity of encapsulated functionality? Definitely. It could
have been written in Fortran, Pascal, Algol, Assembler or Jovial and it
would have been just as useful.

The work product of the language and platform du jour is fairly likely
to be discarded next year or the year after, when the next fashion
trend strikes.

Oddly enough, it is only the peope who HAVEN'T embraced the new technology
who see it that way. People using these languages to create objects and
components that encapsulate functionality in a platform independent manner,
are really not concerned about what is "fashionable". If a new language
arrives that makes the job easier, or maybe the new language has a better
innate implementation of the new paradigms, like Java implementing object
oriented programming, then they will move to it. That isn't "wrong" or
"unstable", it is effective computer programming. People observing it from
"outside" see a "fashion change". Swapping an axe for a chainsaw, isn't a
"fashion change", it is an evolution. But if all you know is axes, you may
well see it as "fashion".

Personally I prefer to work with stable tools on stable platforms and
solve challenges once, not the same challenge again and again on
shifting ground.

Where's the fun in that? :-)

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


.



Relevant Pages

  • Re: 7E7 Flight Controls Electronics
    ... was just good thing that that localization was not too easy - it would ... Please don't confuse abstraction skills of typical COBOL programmer (that ... I pointed at the current programming "biblioware" for commercial data ... > language was because I learned all the workarounds. ...
    (comp.lang.ada)
  • 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: New Cobol compiler written in Cobol
    ... It didn't have a visible operating system. ... > If I were writing a Cobol compiler, I wouldn't look at today's market. ... > What will a programming language need to be successful in that world? ... They'll use a language they can understand at a glance. ...
    (comp.lang.cobol)
  • Re: C Programmer Needed
    ... >> from modern platforms to those platforms anyway. ... >> characteristics of their programming primitives. ... Throw in full language support for all basic ... Adding in full threading would be *hard*. ...
    (comp.programming)
  • Re: Gartner on Assessing the Age of Software Languages and Tools
    ... It's doing some Romero-level twitching, ... We have a lot of customers with no mainframe COBOL at all, ... COBOL.NET does everything that any other .NET language does. ... And of course the whole *point* of the CLI/CLR is that it simplifies mixed-language programming, so it's trivial to use one .NET language for the bulk of an application, and drop into another if it is better suited for some particular aspect. ...
    (comp.lang.cobol)