[Info-vax] And another one bites the dust....

Dan Cross cross at spitfire.i.gajendra.net
Mon Feb 21 09:21:45 EST 2022


In article <j7dsr3Fqp7nU1 at mid.individual.net>,
Bill Gunshannon  <bill.gunshannon at gmail.com> wrote:
>On 2/19/22 21:07, Dan Cross wrote:
>> I don't know any academics who think that COBOL is dead.  But
>> I also don't know any academics who think about COBOL much at
>> all.
>
>Then you must not know many currently teaching at American
>Universities.

I assure you I do.  Please forgive me for saying so, but I am
getting the impression It seems to me that most of what you're
saying here is based on personal experience in a single location
several decades ago.

>> Everyone who's paying any attention knows there's oodles of
>> COBOL out there, much of which is quite important.
>
>Then why do you think colleges all removed COBOL from their curriculum?

They did that 25 years ago.

Academics, generally, aren't fools: they know that there's a lot
of COBOL out there.  I wager most understand that COBOL backs very
important applications.  That does not imply that they have, or
should feel, a moral obligation to study or teach COBOL.

>> But that begs the question: why should _COBOL_ be part of
>> the cirriculum?
>
>Because it is a skill needed badly in the real world

So, apparently, is driving a long-haul truck.

>and up until
>about two decades ago they had no problem filling that need.

Up to two decades ago they taught it because the state of the art
in programming languages hadn't advanced sufficiently that there
were interesting alternatives they felt were more valuable.  Now
there are.

Again, why does any of this mean COBOL should be part of a
university curriculum?  "Large companies need it and it used
to be taught" is not a sufficiently compelling argument.
Large companies also use Excel.

Should a course in COBOL be mandatory?  Elective?  If elective,
who would teach it?  What if no one is interested in teaching
an elective course on COBOL?  What if too few students are
interested in taking it?

>[snip]
>> I'd rather that a university education teach fundamentals;
>> specific skills can be learned in industry.
>
>They do teach fundamentals.  But unless you think that college
>grads have no need of getting a job when they graduate they will
>need to learn a lot more than just fundamentals and theory.

It seems to me that graduates in modern CS programs aren't
having that terrible of a time finding jobs without COBOL.

>> I know a lot of academics and I don't think I've ever heard them
>> discuss COBOL, either for or against.  I don't think there's some
>> cabal of Univeristy professors conspiring to keep COBOL down.
>
>All of academia is a cabal.  Just like a lot of the recent arguments
>(that most people think are just politics) about "science" Comp Sci
>goes the same way.  Once a decision is made no one who plans on his
>career as a professor continuing will buck them.  One bad review on
>a paper (or worse still refusal to even review your papers) and your
>career is over.  Publish or perish is alive and well.

That is a very dim, but inaccurate, view of academia and
academics.  Academic papers are rejected all the time due to
bad reviews; that's par for the course.  

I do agree that the publication-based tenure-track rat-race
creates a lot of disincentives, though.  In fact, I was just
having this conversation with an academic last week (though
we were talking about operating systems, not langauges): junior
faculty tend not to approach something unless they can get a
publishable paper out of it.  Senior faculty are often too
saddled with administrative duties to have the time.

>> Perhaps it would be appropriate to mention in a survey course on
>> programming language design; there's a lot of useful history there.
>
>Yeah, we had one of them.  Taught by one of the learned professors
>who was against COBOL.  The course called "Programming Languages"
>did not mention it at all.  It had the students look at and even
>write programs Smalltalk and Prolog, both long dead, but failed to
>even mention COBOL.

Acadecdotal evidence, I'm afraid.

>> For an undergraduate course on compilers, I'd tend towards something
>> that was easy to parse and had reasonable semantics, so as not to
>> muddy the topic with too much detail about particular languages.
>
>Sadly, compiler courses are becoming scarce as well.  My Department
>dumped their last compiler course almost as long ago as COBOL.

Again, acecdotal evidence.

It sure does seem like you're extrapolating from a singleton sample
set.

>[snip]
>A number of the professors when I was there had started as
>Math Profs and took part in the formation of the Comp Sci
>Dept.  Did you ever here of Harlan Herrick?  He was very
>big in the creation of Fortran.  He ended his career as a
>professor in my Department.  He's buried some where here
>in Scranton.

I'm familiar with the name in passing.  It's always very sad
when another pioneer in the field dies.  :-(

>> What I mean specifically is the danger of "PERFORM ... THRU ..."
>> style statements.  In a large code base, this makes it very
>> difficult to determine what is invoked from where; in that
>> sort of environment (and I fully acknowledge that I'm
>> speculating here) it may be safer to simply copy a section
>> of code, and modify the copy to fit some new specification,
>> then branch at an earlier descision point to either the new
>> or old code.
>> 
>
>I guess I just don't get your point with the PERFORM -- THRU
>stuff.  Don't see how that would differ from begin-end or {}
>in other languages.  But then, I was taught structured COBOL
>from the beginning which stressed good program structure and
>design as opposed to the spaghetti code that was common in the
>day (and not just in COBOL or BASIC.  I  have seen some really
>scary Fortran as well.)

Suppose I would like to modify some procedure; it seems
reasonable that I'd like to inspect its call-sites to make
sure that I'm not introducing a change that violates some
unstated assumption somewhere.  But how do I find all of
those call sites?  With `THRU`, they're often hidden, and
require semantically aware tools to find (e.g., I can't
just `grep` for the procedure name).

You mention "spaghetti code that was common in the day",
but isn't part of the issue that much of that code is _still
in production_?  Perhaps part of the reason that there is
so much COBOL in the world is because, instead of wading
through the pasta, people just copy the bunch and modify
to suit.  That's my point with the copy-and-paste idea.

This is part of the issue when discussing langauges with such
longevity.  COBOL people seem to get offended when someone
describes their language as 60+ years old: "but COBOL today
isn't like the COBOL of 50 years ago!"  But look at FORTRAN:
we still see FORTRAN-77 (and earlier!) code in daily use.
It's true that successive revisions of COBOL are different,
and rather more modern, than earlier versions.  But that
only matters if code bases have been updated to the modern
versions; if they haven't, you're still saddled with the
problems of the older dialects.  Did all of that spaghetti
code get rewritten to be well-structured?

>>> Another meaningless industry buzzword.  Outsourced to who?  I mean
>> 
>> I suspect that even a lot of the fortune x*100 companies
>> outside to body shops in the BRIC countries.
>
>Funny thing about that is if you follow the COBOL world you would be
>amazed at how little the locations we usually associate wit "out
>sourcing" know of COBOL either.

Available evidence seems to suggest otherwise: others in this
thread pointed out job frequencies in, say, India compared to
the US.

>>> I mentioned GDIT handling a big DOD COBOL system.  Is that what you
>>> call "outsourced"?  I call it government contracting.  :-)  Most of
>>> the banks, insurance, financial and credit card companies who are
>>> all still COBOL shops don't outsource.  They keep their IT operations
>>> very close at hand.
>> 
>> If that's the case, it's a pretty insular world.  The average
>> age of COBOL programmers in the US is 55; that says something.
>
>Yeah, it says that replacements are hard to find and getting harder.
>Something that will have to change because the code is not going away.

That's why I started out participating in this thread by
highlighting that as a risk.

>> I don't think I've seen anyong actively discourage COBOL in 25
>> years.  
>
>I watched it for at least the last 15 years I worked at the University.

Again, that's a single data point at a single institution, and when
did you leave that university?

>>         For that matter, I don't know that I've seen anyone
>> actively discuss COBOL in 25 years, either.
>
>I used to do it all the time.  And got good comments from the students
>I talked with.  Given the opportunity I am sure many of them would have
>taken a COBOL course.  But again, without a lot of support from the
>faculty it would have been a non-starter.  When your intent is to get
>out of there in the four years allocated there is no room in your
>schedule for even one extra 3 credit course.

It's unclear to me what you'd like the desired outcome to be: should
that university require a course in COBOL, then?  If it were an elective
course and students, by your admission, don't have room for it in their
schedules, then unless it is required, why would students take it?

>> UCSD Pascal, and GW-BASIC.  I don't think that should be
>> discouraged; I've found that having breadth in technology gives
>> useful perspective.  I also briefly looked up COBOL jobs in my
>> area (greater Boston) and the salaries are not competitive.  I'm
>> pretty senior, but still; if people think it's oh-so-important
>> to attract COBOL programmers, then show me the money: it's not
>> there.
>
>Yeah, I keep hearing that.  But then I go out and find 6 figure
>COBOL jobs.  The one thing I notice the most about these jobs
>on places like Indeed and Monster (who pretty much have the
>exact same jobs cause all they really do is scrape other places
>websites) have "estimated pay" because most of the places that
>use COBOL are old school and don't make that kind of igformation
>public.  And their "estimatees" seem to always be low balled.  I
>know this from looking at other jobs in fields and with companies
>that I have first hand experience with.

So waitasec; the companies that need COBOL programemrs are not
avertising competitive salaries and somehow it's the academics'
fault that COBOL isn't in high demand?

The COBOL salaries I'm seeing would be competitive as entry-level
positions for the FAANG companries, which aren't looking for
COBOL qualifications.

>> Active job listings in my area.  
>
>Where you live can have a large effect on that.  Where I live
>the majority of computer jobs are low level Windows jobs.  Sadly,
>I have watched most of the better computer stuff get moved away.
>A number of years ago Mellon Bank bought the biggest local bank.
>First action was to move all Data Processing to Pittsburgh.  Didn't
>even offer the current employees here transfer opportunities.
>Procter and Gamble has a large facility here.  Mostly an HPUX
>shop.  While they are constantly hiring factory floor workers
>from the local community they have never advertised for people
>here to work with the real computers.  All of those people are
>hired in Cincinatti at HQ.  They do have PC monkeys locally but
>even the company with that contract is not local.

It sounds like you're saying that COBOL jobs are sparse in your
market.  I'm a New Yorker, but I live in the greater Boston area
now.  I don't recall seeing competitive COBOL jobs in NYC, and
they're aren't a lot here.  If the demand is there, the corproations
are doing a poor job of advertising and filling them.

Correct me if I'm wrong, but earlier you talked about a 3 credit
course for COBOL: that's a fairly light load.  That seems like
something a CS graduate should be able to do with a month or two
of self-study: if that's the case, it sure seems like something
a recent grad could do over the summer before starting a job.  So
why aren't they?

It's starting to sound more and more like the problem may be with
the organizations that are using COBOL not adequating adertising
and recruiting.

>>                                 Availability of training
>
>That's the big problem.  All the local colleges (and we have a good
>dozen) used to teach COBOL.  None of them do today.

There are languages that have been invented since I graduated:
currently, most of what I write is in Rust.  Courses for that
could not have existed when I was in college because the
language did not yet exist, and I had to pick it up on my own.
Fortunately, I had enough experience to be able to do so: I
don't see how COBOL is any different.  It seems like a fairly
straight-forward imperative language: a competent programmer
with a good reference should be able to largely aborb the syntax
in a couple of days or a week, and working with experienced
practioners, should be able to write competent code in a month
or two.  Is lack of academic training, by faculty you readily
admit are not pracitioners,  _really_ the issue?

By your own admission, the corporations that are seeking these
positions are "old school" and don't even advertise very well;
they don't even post job listings with salaries!  Perhaps the
problem isn't just with the academia no longer teaching the
material.  Perhaps the jobs just aren't attractive to new grads
with other options.

>> environments, materials, and high-quality open source implementations
>> and tools.
>
>Open Source?  Take a look at GnuCOBOL.  Full featured.  Very stable.

Who runs their production systems on it?  What do I use in lieu of
VTAM, CICS, ISAM, etc?  What sort of debugging support, semantic
analysis tools, etc?

>Interfaces well to database systems (including Oracle the last I heard).
>Has COBOL specific IDE's but others like Eclipse can handle COBOL as
>well.

Is Eclipse used for anything other than being a glorified editor
with COBOL?

>> Why is that a loss?  In my opinion, we're practically forcing
>> too many kids to go to 4 year colleges when they're not really
>> all that interested in doing so, and then we're saddling them
>> with crippling debt after they get out.  Part of this is a
>> level of social contempt for trades; that's very sad.  When I
>> was in the Marine Corps, I worked with a lot of folks who went
>> into the trades and they were intelligent, motivated, hard-working,
>> genuinely wonderful people.  They shouldn't be penalized or
>> disrespected for not having a burning desire to deconstruct
>> Baudrillard.
>
>There is a value to the liberal arts side of education which
>one does not get in a trade school.  The students loss.
>There is money to be made teaching COBOL.  The University's
>loss.  :-)

I think perhaps there may not be as much money there as perhaps
you may believe.

>Like Georgetown, Columbia's primary function seemed to be turning out
>white collar workers.

Funny, the president of the university told us the goal was to
teach us how to learn and think when I graduated.  I was a
non-traditional student (work after high school, a stint in the
military, etc) and I took that very seriously: I was there to
learn how to approach and wrestle with really hard problems and
ideas, not learn a trade.

>Used to have quite the Comp Sci program there.

AFAIK, they still do, but again, I wasn't a computer scientist.
I think I took one CS course: compilers from Aho.

>I had quite a bit of contact because of the Kermit project.
>Some of the Kermit binaries were actually built on system's
>in my house by Frank DaCruz.

The kermit project was only tangentially related to the university
afer a few years.

>When I lived up at West Point I used to see football
>from Columbia on Saturday mornings. Sometimes I was the only one
>watching them play.  :-)

We were quite proud of our record in the Ivy League: the most
consecutive loses of any football team. :-)

	- Dan C.




More information about the Info-vax mailing list