On 18/02/2022 16:07, Arne Vajhøj wrote:
> On 2/18/2022 10:59 AM, Dan Cross wrote:
>> In article <620fb853$0$693$14726298@news.sunsite.dk>,
>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>> On 2/18/2022 10:12 AM, Dan Cross wrote:
>>>> In article <620e5870$0$701$14726298@news.sunsite.dk>,
>>>> Arne Vajhøj  <arne@vajhoej.dk> wrote:
>>>>> On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
>>>>>> In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
>>>>>> "dthi...@gmail.com" <dthittner@gmail.com> writes:
>>>>>>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>>>>>>> standard, and not a complete implementation of it either). Later
>>>>>>> FORTRAN
>>>>>>> standards (2003, 2008, 2108) have fully embraced object oriented
>>>>>>> code
>>>>>>> practices and C interoperability.
>>>>>>
>>>>>> Isn't there supposed to be a much more modern, FLANG-based Fortran
>>>>>> compiler from VSI (presumably only) on x86?
>>>>>>
>>>>>> If so, when?
>>>>>
>>>>> VSI has stated their intention to go with flang. Which is really
>>>>> saying
>>>>> that they have no intention of shoehorning the newer Fortran standards
>>>>> into the old compiler. Which makes sense.
>>>>
>>>> Not really. The old DEC GEM compilers were super cool.
>>>
>>> The cost.
>>
>> Which cost?  Bolting on a backend for x86_64 wouldn't be that
>> hard: they already have backends for VAX, MIPS, Alpha, and
>> Itanium.
>
> ????
>
> VSI is already doing that by utilizing LLVM.
>
> But the topic was "shoehorning the newer Fortran standards
> into the old compiler".
>
>> Keeping up with evolving language standards?  Yeah, that's an
>> issue.
>
> Yes.
>
>>>>> And since it will be LLVM based then it must be x86-64 only.
>>>>
>>>> Why do you say that? Just in the sense that they won't
>>>> backport to OpenVMS/Itanium or Alpha?  LLVM has backends
>>>> for non-x86 architectures.  (If I were VSI, I'd be
>>>> getting a jump on ports to ARM and RISC-V now.)
>>>
>>> I don't see flang/LLVM support Itanium or Alpha.
>>
>> Alpha support was dropped back in 2011:
>> https://github.com/llvm/llvm-project/commit/4c9fca99c9a6734bb33c34aeaf40b71c4002757e
>>
>>
>> IA-64 was removed back in 2009.
>>
>> Bringing either back would probably be a pretty big lift,
>> but with commercial support, I imagine the LLVM folks would
>> be fine with it.  There's an MC68k backend, afterall.
>
> I don't expect that to happen.
>
>> But if VSI is cool with GEM on Alpha/Itanium, and LLVM on
>> x86_64, I guess that's their business.
>
> That is what they say.
>

It doesn't really matter what they "say", what is important is source
code compatibility. From what I can see the LLVM compiler does not fully
support the DEC extensions there may be issues.

If you need to make changes to stay on VMS then it becomes much harder
to justify it.

>>> Maybe ARM or RISC-V some day in the future.
>>
>> It seems clear that there's an architectural shift away
>> from x86 happening.  Best to lay the groundwork now to
>> avoid being caught out.
>
> Maybe, but even if it does happen then it will take many years.
>

> Arne
>
>

Dave

On 2/18/2022 12:41 PM, David Wade wrote:
> On 18/02/2022 16:07, Arne Vajhøj wrote:
>> On 2/18/2022 10:59 AM, Dan Cross wrote:
>>> But if VSI is cool with GEM on Alpha/Itanium, and LLVM on
>>> x86_64, I guess that's their business.
>>
>> That is what they say.
>
> It doesn't really matter what they "say", what is important is source
> code compatibility. From what I can see the LLVM compiler does not fully
> support the DEC extensions there may be issues.
>
> If you need to make changes to stay on VMS then it becomes much harder
> to justify it.

I think I got that one worded wrong.

VSI use LLVM backend on x86-64.

They use their traditional frontend accepting DEC extensions.

I don't think they have announced what they will do for Fortran/flang
but based on their general direction, then my guess is two compilers:
- Traditional Fortran support Fortran 95 with all DEC extensions aka
100% copmpatible
- flang with uptodate Fortran support and whatever DEC extensions
John Reagan can easily put in aka 98% compatible

Arne

On 2022-02-18, Dan Cross <cross@spitfire.i.gajendra.net> wrote:
> In article <620e5870$0$701$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>
>>VSI has stated their intention to go with flang. Which is really saying
>>that they have no intention of shoehorning the newer Fortran standards
>>into the old compiler. Which makes sense.
>
> Not really. The old DEC GEM compilers were super cool.
>

And GEM was unfortunately the only part of MICA to survive.

However, times move on and the VMS language support is massively behind
the times these days. By moving to LLVM, VSI gets the best of both
worlds, with the GEM to LLVM interface to support the existing GEM
compiler frontends and VMS also gets access to the native LLVM frontends
(clang, etc).

Moving to LLVM is the logical thing for VSI to do.

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.

On 2/18/22 10:49, Dan Cross wrote:
> In article <j7844nFnlqeU1@mid.individual.net>,
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 2/17/22 17:15, Dan Cross wrote:
>>> True, but kids grow up dreaming about being astronauts.
>>> I don't know anyone who yearns to be a COBOL programmer.
>>
>> I still do.... :-)
>
> Ha! I meant to write, "I don't know any kids...", but perhaps
> I should just cite you as the exception to the rule. :-)
>
>>>
>>> The issue isn't that you can't train people to do it; it's
>>> that almost no one _wants_ to be trained to do it.
>>
>> No, that's not quite accurate. It's because the people who should
>> be teaching them COBOL refuse to for reasons with no basis in fact.
>
> Who are those people? University professors?

Yes.

> What are their
> reasons and, more importantly, why aren't those reasons factual?

Because the reason usually given is that COBOL is dead and that
what little COBOL code is left is rapidly being re-written in
Java. A statement totally unfounded. Two recent independent
surveys of companies using COBOL pegged the number of lines of
of existing COBOL code in production running every day at about
800 billion. And also contrary to popular belief among academics
more new code is being written every day.

>
>>> Then there's the matter of training materials, educational
>>> venues, etc. Universities used to teach COBOL.
>>
>> And they are the root of the problem.
>
> This is turning into a much deeper discussion. My opinion is
> that universities should not exist solely to provide vocational
> training. At this point, teaching COBOL is entirely vocational.

Yes, but when one learns COBOL in University that is not the only
thing e=they learn. (Well, at least not in a decent University.
I once new a grad from RPI who bragged that he never took any
course other than his engineering and math to get his degree!)
My degree has three concentrations. Comp Sci, Theology and
German. And, believe it or not my Comp Sci concentration
included more Comp Sci course than a Comp Sci Major.

On a side note to your comment above. Congratulations. You are
carrying on an argument that has been going quite steady since at
least 1850. With the backing of people like John Henry Newman
college education was opened up the common man and not just the
gentleman. But the argument still rages on. I worked for
nearly 30 years at a Jesuit University. We went thru a "Self
Examination" where other Jesuits came in to evaluate our work
to see if we were meeting the Jesuit goals for education. We
had one of our examiners (makes me think of the Inquest) who
came right out and said, "Computer Science is a trade and Jesuit
Schools should not be teaching it." Interestingly enough he
was from Georgetown which is famous for turning out lawyers.
Like that's not a trade.

>
>>> High
>>> quality textbooks were produced.
>>
>> Well, can't say I agree with that. The textbook business is mostly
>> snake oil. One of the most popular COBOL textbooks was written by
>> a pair of professional textbook writers, not by practitioners of the
>> art. When I took COBOL in school I bought two additional books to
>> accompany the chosen textbook. It contributed greatly to how well
>> I learned the subject.
>
> Who wrote those books?

Who wrote which? The original was by Shelly & Cashman. that
was 40 years ago. They are still at it but now it's mostly
Windows Applications like MSOffice. there used to be a Wiki
that even said they were professional textbook writers but I
can't find it at the moment. :-) The others I bought on my
own were references written bu current (at the time) practitioners
of the art. I could find their names as I still have the books.

> At any rate, perhaps I should have said
> that there have been high quality texts on COBOL, regardless of
> whether those texts fit a prescribed textbook format.

That is true. The Murach series are very good although they
are primarily targeted at IBM Mainframe programming. But they
still make excellent desktop references.

>
>>
>>> These days, not so much.
>>> Most training materials will be second hand books describing
>>> old version of the language, or vendor-supplied materials
>>> of varying levels of quality and erudition.
>>
>> There are very good books on COBOL available today. And they
>> cover the language as is currently in use. (That means the
>> EVALUATE verb rather than 20 level deep IF-THEN-ELSE peices.)
>> They also cover Database access from COBOL as well as the
>> old fashioned flat file stuff. I have even considered writing
>> a COBOL text myself targeted at the use of OpenSource tools.
>
> Go for it! That would be a useful addition to the canon.

I may, but I have learned from experience that it is a lot
more work than most people probably think. And in the
current atmosphere there is very little chance of actually
getting a publisher. O'Reilly seems to be gone.

>
>>> And who does the training? I guess the vendors provide
>>> courses, or its OJT'ed?
>>
>> Right now probably the vendor. GDIT, who has a very large
>> COBOL IS supporting the DOD used to advertise for interns.
>> Wanted first or second year students who had taken the
>> usual two course intro to programming and said they would
>> provide the COBOL training.
>>
>> But that is a very limited solution to the problem. Universities
>> have abdicated their responsibility to prepare students for their
>> future careers. I think it is time to get the Tech Schools
>> involved. Many of them are now degree granting institutions
>> (locally you can get degrees in things like diesel mechanic!)
>> and have taught low level CIS classes already. This could be
>> a boon for them.
>
> I suppose there's a much larger debate to be had about the role
> of universities in professional computing. I wouldn't say that
> they have "abdicated their responsibility to prepare students
> for their future careers", though; certainly not by abandoning
> COBOL in their curricula.

It goes much deeper than just abandoning curricula. In most
places (at least on my side of the pond) they very vocally
attack it and put in a lot of effort steering students away
from even looking at it.

>
> In my view, universities exist to for two things: education and
> research. The educational mission usually means imparting the
> basics and equipping students with the tools necessary to absorb
> other information. This naturally means learning things that
> are mostly agnostic of any particular technology; in CS, that's
> data structures and algorithms, basic coding skills, highlights
> of major topics in the field, etc. Particular programming
> languages are not among them.

I agree up to a point. Other than in a compiler or computer languages
course I agree one could forego actually teaching COBOL in depth. But
then, our last course to use COBOL (and the only one to teach it) was
not really about "programming" at all. It was called File Processing
and COBOL was by far the right language for the job.

>
> The research side should be pushing the limits of the field ever
> outward. If there's any interesting research to do on COBOL, I
> imagine it would be some semantic analysis, but mostly automatic
> conversion to other languages.

But you have only addressed Comp Sci. There is another side to the
practice. And, like most schools that teach Comp Sci we also had a
degree program called Computer Information Systems. And the specific
target of this is the use of computers in business. Exactly where the
teaching of COBOL as one of the primary languages would have remained.
But it didn't. I once spoke with the IT director for a Fortune 100
Insurance company and told him one of our most distinguished and
experienced professors was telling his students that this company
was re-writing all their COBOL into Java. He was rolling on the
floor laughing. But that is the reality of the situation.

>
>>>> And that is true for just about anything on the planet. Yes, we train for
>>>> required jobs. But the Cobol (and Basic,Fortran, (hock, spit, gag) C, and
>>>> others will define the needs, based upon the entities with those needs.
>>>
>>> Well, good luck finding them.
>>>
>>>> I have my doubts about the training defining the needs.
>>>
>>> It's not a, "mommy, where do COBOL programmers come from?"
>>> question.
>>
>> True. the real question that people in the industry should be
>> asking is just why Universities refuse to meet this particular
>> need.
>
> Probably because the need appears less pressing than reality
> might indicate, but again, universities aren't vocational
> training schools;

On 2/18/2022 10:12 AM, Dan Cross wrote:
> In article <620e5870$0$701$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/17/2022 5:28 AM, Phillip Helbig (undress to reply) wrote:
>>> In article <919fe330-a0dc-4784-bd2e-edea99790dc0n@googlegroups.com>,
>>> "dthi...@gmail.com" <dthittner@gmail.com> writes:
>>>> VSI Fortran is pretty much just rebranded HPE Fortran (FORTRAN-95
>>>> standard, and not a complete implementation of it either). Later FORTRAN
>>>> standards (2003, 2008, 2108) have fully embraced object oriented code
>>>> practices and C interoperability.
>>>
>>> Isn't there supposed to be a much more modern, FLANG-based Fortran
>>> compiler from VSI (presumably only) on x86?
>>>
>>> If so, when?
>>
>> VSI has stated their intention to go with flang. Which is really saying
>> that they have no intention of shoehorning the newer Fortran standards
>> into the old compiler. Which makes sense.
>
> Not really. The old DEC GEM compilers were super cool.
>
>> And since it will be LLVM based then it must be x86-64 only.
>
> Why do you say that?

VAX, Alpha, and itanic are not VSI's future.

> Just in the sense that they won't
> backport to OpenVMS/Itanium or Alpha? LLVM has backends
> for non-x86 architectures. (If I were VSI, I'd be
> getting a jump on ports to ARM and RISC-V now.)
>
> - Dan C.
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <620fc42f$0$701$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/18/2022 10:59 AM, Dan Cross wrote:
>>>> Not really. The old DEC GEM compilers were super cool.
>>>
>>> The cost.
>>
>> Which cost? Bolting on a backend for x86_64 wouldn't be that
>> hard: they already have backends for VAX, MIPS, Alpha, and
>> Itanium.
>
>????
>
>VSI is already doing that by utilizing LLVM.

....at the hidden cost of maintain two separate toolchains
for different architectures, and maintaining common code in
a least-common-denominator dialect of the language, at
least until they cut Alpha and Itanium loose completely.

>[snip]
>>> Maybe ARM or RISC-V some day in the future.
>>
>> It seems clear that there's an architectural shift away
>> from x86 happening. Best to lay the groundwork now to
>> avoid being caught out.
>
>Maybe, but even if it does happen then it will take many years.

Which is why they should get a jump on things now. :-)

- Dan C.

In article <620fdedb$0$704$14726298@news.sunsite.dk>,
Arne Vajhøj <arne@vajhoej.dk> wrote:
>On 2/18/2022 12:41 PM, David Wade wrote:
>> On 18/02/2022 16:07, Arne Vajhøj wrote:
>>> On 2/18/2022 10:59 AM, Dan Cross wrote:
>>>> But if VSI is cool with GEM on Alpha/Itanium, and LLVM on
>>>> x86_64, I guess that's their business.
>>>
>>> That is what they say.
>>
>> It doesn't really matter what they "say", what is important is source
>> code compatibility. From what I can see the LLVM compiler does not fully
>> support the DEC extensions there may be issues.
>>
>> If you need to make changes to stay on VMS then it becomes much harder
>> to justify it.
>
>I think I got that one worded wrong.
>
>VSI use LLVM backend on x86-64.

Ah, that's rather differnet, and makes a lot more sense.

- Dan C.

In article <suot6g$uus$1@dont-email.me>,
Dave Froble <davef@tsoft-inc.com> wrote:
>On 2/18/2022 10:12 AM, Dan Cross wrote:
>> In article <620e5870$0$701$14726298@news.sunsite.dk>,
>> Arne Vajhøj <arne@vajhoej.dk> wrote:
>>> And since it will be LLVM based then it must be x86-64 only.
>>
>> Why do you say that?
>
>VAX, Alpha, and itanic are not VSI's future.

Undoubtedly, but I wasn't suggesting that it was.
My comment was motivated by an apparent statement
that LLVM == x86. It does not.

- Dan C.

On 2/18/2022 7:07 PM, Dan Cross wrote:
> In article <620fc42f$0$701$14726298@news.sunsite.dk>,
> Arne Vajhøj <arne@vajhoej.dk> wrote:
>> On 2/18/2022 10:59 AM, Dan Cross wrote:
>>>>> Not really. The old DEC GEM compilers were super cool.
>>>>
>>>> The cost.
>>>
>>> Which cost? Bolting on a backend for x86_64 wouldn't be that
>>> hard: they already have backends for VAX, MIPS, Alpha, and
>>> Itanium.
>>
>> ????
>>
>> VSI is already doing that by utilizing LLVM.
>
> ...at the hidden cost of maintain two separate toolchains
> for different architectures, and maintaining common code in
> a least-common-denominator dialect of the language, at
> least until they cut Alpha and Itanium loose completely.

I think they are reusing what they can.

Based on presentations the model for existing compilers are:

(source)--common frontend--(GEM IR)--GEM--(Alpha/Itanium code)

(source)--common frontend--(GEM IR)--G2L--(LLVM IR)--LLVM--(x86-64 code)

>>>> Maybe ARM or RISC-V some day in the future.
>>>
>>> It seems clear that there's an architectural shift away
>>> from x86 happening. Best to lay the groundwork now to
>>> avoid being caught out.
>>
>> Maybe, but even if it does happen then it will take many years.
>
> Which is why they should get a jump on things now. :-)

If they had enough resources, but VSI is a relative small company.

Arne

In article <j7a9d8F5tfpU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>On 2/18/22 10:49, Dan Cross wrote:
>>> No, that's not quite accurate. It's because the people who should
>>> be teaching them COBOL refuse to for reasons with no basis in fact.
>>
>> Who are those people? University professors?
>
>Yes.

Well, that's an opinion.

>> What are their
>> reasons and, more importantly, why aren't those reasons factual?
>
>Because the reason usually given is that COBOL is dead and that
>what little COBOL code is left is rapidly being re-written in
>Java. A statement totally unfounded. Two recent independent
>surveys of companies using COBOL pegged the number of lines of
>of existing COBOL code in production running every day at about
>800 billion. And also contrary to popular belief among academics
>more new code is being written every day.

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.

Everyone who's paying any attention knows there's oodles of
COBOL out there, much of which is quite important.

>>>> Then there's the matter of training materials, educational
>>>> venues, etc. Universities used to teach COBOL.
>>>
>>> And they are the root of the problem.
>>
>> This is turning into a much deeper discussion. My opinion is
>> that universities should not exist solely to provide vocational
>> training. At this point, teaching COBOL is entirely vocational.
>
>Yes, but when one learns COBOL in University that is not the only
>thing e=they learn. (Well, at least not in a decent University.
>I once new a grad from RPI who bragged that he never took any
>course other than his engineering and math to get his degree!)
>My degree has three concentrations. Comp Sci, Theology and
>German. And, believe it or not my Comp Sci concentration
>included more Comp Sci course than a Comp Sci Major.

But that begs the question: why should _COBOL_ be part of
the cirriculum?

>On a side note to your comment above. Congratulations. You are
>carrying on an argument that has been going quite steady since at
>least 1850. With the backing of people like John Henry Newman
>college education was opened up the common man and not just the
>gentleman. But the argument still rages on.

Incorrect; that's an argument over _who_ should be elligible
for higher education, which I made no statement about. What
we're discussing here is _what_ should be taught in a college
education. You evidently feel that COBOL should be taught.
I can't see much of an argument for that. There's a lot of
COBOL out there, sure; so what? There's a lot of Visual Basic,
and a lot of JavaScript. Probably more HTML is generated on
a daily basis than all COBOL in the world combined. Should
HTML feature in a college education? How about CSS? Etc.
Should universities teach carpentry, plumbing or iron work?
These are all important things; what is the domain of a
university and what is not?

I'd rather that a university education teach fundamentals;
specific skills can be learned in industry.

>I worked for
>nearly 30 years at a Jesuit University. We went thru a "Self
>Examination" where other Jesuits came in to evaluate our work
>to see if we were meeting the Jesuit goals for education. We
>had one of our examiners (makes me think of the Inquest) who
>came right out and said, "Computer Science is a trade and Jesuit
>Schools should not be teaching it." Interestingly enough he
>was from Georgetown which is famous for turning out lawyers.
>Like that's not a trade.

I'm sure I must have heard something about knife fights
with Jesuits somehwere along the way.

>>> Well, can't say I agree with that. The textbook business is mostly
>>> snake oil. One of the most popular COBOL textbooks was written by
>>> a pair of professional textbook writers, not by practitioners of the
>>> art. When I took COBOL in school I bought two additional books to
>>> accompany the chosen textbook. It contributed greatly to how well
>>> I learned the subject.
>>
>> Who wrote those books?
>
>Who wrote which? The original was by Shelly & Cashman. that
>was 40 years ago. They are still at it but now it's mostly
>Windows Applications like MSOffice. there used to be a Wiki
>that even said they were professional textbook writers but I
>can't find it at the moment. :-) The others I bought on my
>own were references written bu current (at the time) practitioners
>of the art. I could find their names as I still have the books.

It's funny, but I've used "textbooks" written by practitioners.
But at this level, we're arguing semantics about what it means
to be a textbook, which is not useful. The point was whether
high quality texts exist suitable for use in a university (or
other) course.

>> At any rate, perhaps I should have said
>> that there have been high quality texts on COBOL, regardless of
>> whether those texts fit a prescribed textbook format.
>
>That is true. The Murach series are very good although they
>are primarily targeted at IBM Mainframe programming. But they
>still make excellent desktop references.

Good to go, then. We're in that venerable state of "violent
agreement" on this point.

>>>> These days, not so much.
>>>> Most training materials will be second hand books describing
>>>> old version of the language, or vendor-supplied materials
>>>> of varying levels of quality and erudition.
>>>
>>> There are very good books on COBOL available today. And they
>>> cover the language as is currently in use. (That means the
>>> EVALUATE verb rather than 20 level deep IF-THEN-ELSE peices.)
>>> They also cover Database access from COBOL as well as the
>>> old fashioned flat file stuff. I have even considered writing
>>> a COBOL text myself targeted at the use of OpenSource tools.
>>
>> Go for it! That would be a useful addition to the canon.
>
>I may, but I have learned from experience that it is a lot
>more work than most people probably think. And in the
>current atmosphere there is very little chance of actually
>getting a publisher. O'Reilly seems to be gone.

I don't know; if there's a market, then someone will publish.
O'Reilly does indeed seem to be out to lunch, but the Rust book
was amazingly good. Like, early-90s O'Reilly quality.

>> I suppose there's a much larger debate to be had about the role
>> of universities in professional computing. I wouldn't say that
>> they have "abdicated their responsibility to prepare students
>> for their future careers", though; certainly not by abandoning
>> COBOL in their curricula.
>
>It goes much deeper than just abandoning curricula. In most
>places (at least on my side of the pond) they very vocally
>attack it and put in a lot of effort steering students away
>from even looking at it.

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.

>> In my view, universities exist to for two things: education and
>> research. The educational mission usually means imparting the
>> basics and equipping students with the tools necessary to absorb
>> other information. This naturally means learning things that
>> are mostly agnostic of any particular technology; in CS, that's
>> data structures and algorithms, basic coding skills, highlights
>> of major topics in the field, etc. Particular programming
>> languages are not among them.
>
>I agree up to a point. Other than in a compiler or computer languages
>course I agree one could forego actually teaching COBOL in depth. But
>then, our last course to use COBOL (and the only one to teach it) was
>not really about "programming" at all. It was called File Processing
>and COBOL was by far the right language for the job.

Perhaps it would be appropriate to mention in a survey course on
programming language design; there's a lot of useful history there.
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.

>> The research side should be pushing the limits of the field ever
>> outward. If there's any interesting research to do on COBOL, I
>> imagine it would be some semantic analysis, but mostly automatic
>> conversion to other languages.
>
>But you have only addressed Comp Sci. There is another side to the
>practice. And, like most schools that teach Comp Sci we also had a
>degree program called Computer Information Systems. And the specific
>target of this is the use of computers in business. Exactly where the
>teaching of COBOL as one of the primary languages would have remained.
>But it didn't. I once spoke with the IT director for a Fortune 100
>Insurance company and told him one of our most distinguished and
>experienced professors was telling his students that this company
>was re-writing all their COBOL into Java. He was rolling on the
>floor laughing. But that is the reality of the situation.

On 2/19/22 21:07, Dan Cross wrote:
> In article <j7a9d8F5tfpU1@mid.individual.net>,
> Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> On 2/18/22 10:49, Dan Cross wrote:
>>>> No, that's not quite accurate. It's because the people who should
>>>> be teaching them COBOL refuse to for reasons with no basis in fact.
>>>
>>> Who are those people? University professors?
>>
>> Yes.
>
> Well, that's an opinion.

Maybe, but an opinion based on almost 30 years in academia right thru
the time when all this happened.

>
>>> What are their
>>> reasons and, more importantly, why aren't those reasons factual?
>>
>> Because the reason usually given is that COBOL is dead and that
>> what little COBOL code is left is rapidly being re-written in
>> Java. A statement totally unfounded. Two recent independent
>> surveys of companies using COBOL pegged the number of lines of
>> of existing COBOL code in production running every day at about
>> 800 billion. And also contrary to popular belief among academics
>> more new code is being written every day.
>
> 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.

>
> 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?

>
>>>>> Then there's the matter of training materials, educational
>>>>> venues, etc. Universities used to teach COBOL.
>>>>
>>>> And they are the root of the problem.
>>>
>>> This is turning into a much deeper discussion. My opinion is
>>> that universities should not exist solely to provide vocational
>>> training. At this point, teaching COBOL is entirely vocational.
>>
>> Yes, but when one learns COBOL in University that is not the only
>> thing e=they learn. (Well, at least not in a decent University.
>> I once new a grad from RPI who bragged that he never took any
>> course other than his engineering and math to get his degree!)
>> My degree has three concentrations. Comp Sci, Theology and
>> German. And, believe it or not my Comp Sci concentration
>> included more Comp Sci course than a Comp Sci Major.
>
> But that begs the question: why should _COBOL_ be part of
> the cirriculum?

Because it is a skill needed badly in the real world and up until
about two decades ago they had no problem filling that need.

>
>> On a side note to your comment above. Congratulations. You are
>> carrying on an argument that has been going quite steady since at
>> least 1850. With the backing of people like John Henry Newman
>> college education was opened up the common man and not just the
>> gentleman. But the argument still rages on.
>
> Incorrect; that's an argument over _who_ should be elligible
> for higher education, which I made no statement about. What
> we're discussing here is _what_ should be taught in a college
> education. You evidently feel that COBOL should be taught.
> I can't see much of an argument for that. There's a lot of
> COBOL out there, sure; so what? There's a lot of Visual Basic,
> and a lot of JavaScript. Probably more HTML is generated on
> a daily basis than all COBOL in the world combined. Should
> HTML feature in a college education? How about CSS? Etc.

Well, they do teach CSS and HTML and PHP and JavaScript.
Visual Basic not so much any more, but they did teach that,
too.

> Should universities teach carpentry, plumbing or iron work?

Some colleges do, believe it or not. We have at least one locally.
Used to be a trade school. Now it's a college. In a few years if
it grows any more it will likely be a University.

> These are all important things; what is the domain of a
> university and what is not?

Primarily, since at least the early 1900's it has been to
educate white collar workers as well as the educated wealthy
who have no intention of getting a job anyway. (One of my
high school classmates started college right after high school.
He got an undergrad engineering degree. then he got an undergrad
Math degree. Then he got an undergrad English degree. If he
had not been killed in an accident he would probably still be
acquiring undergrad degrees. :-)

>
> 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.

>
>> I worked for
>> nearly 30 years at a Jesuit University. We went thru a "Self
>> Examination" where other Jesuits came in to evaluate our work
>> to see if we were meeting the Jesuit goals for education. We
>> had one of our examiners (makes me think of the Inquest) who
>> came right out and said, "Computer Science is a trade and Jesuit
>> Schools should not be teaching it." Interestingly enough he
>> was from Georgetown which is famous for turning out lawyers.
>> Like that's not a trade.
>
> I'm sure I must have heard something about knife fights
> with Jesuits somehwere along the way.
>
>>>> Well, can't say I agree with that. The textbook business is mostly
>>>> snake oil. One of the most popular COBOL textbooks was written by
>>>> a pair of professional textbook writers, not by practitioners of the
>>>> art. When I took COBOL in school I bought two additional books to
>>>> accompany the chosen textbook. It contributed greatly to how well
>>>> I learned the subject.
>>>
>>> Who wrote those books?
>>
>> Who wrote which? The original was by Shelly & Cashman. that
>> was 40 years ago. They are still at it but now it's mostly
>> Windows Applications like MSOffice. there used to be a Wiki
>> that even said they were professional textbook writers but I
>> can't find it at the moment. :-) The others I bought on my
>> own were references written bu current (at the time) practitioners
>> of the art. I could find their names as I still have the books.
>
> It's funny, but I've used "textbooks" written by practitioners.

There are some. But the majority are written by professional
textbook writers or professors who have never held a real world
job. Neither of which I consider practitioners.

> But at this level, we're arguing semantics about what it means
> to be a textbook, which is not useful. The point was whether
> high quality texts exist suitable for use in a university (or
> other) course.

They do.

>
>>> At any rate, perhaps I should have said
>>> that there have been high quality texts on COBOL, regardless of
>>> whether those texts fit a prescribed textbook format.
>>
>> That is true. The Murach series are very good although they
>> are primarily targeted at IBM Mainframe programming. But they
>> still make excellent desktop references.
>
> Good to go, then. We're in that venerable state of "violent
> agreement" on this point.
>
>>>>> These days, not so much.
>>>>> Most training materials will be second hand books describing
>>>>> old version of the language, or vendor-supplied materials
>>>>> of varying levels of quality and erudition.
>>>>
>>>> There are very good books on COBOL available today. And they
>>>> cover the language as is currently in use. (That means the
>>>> EVALUATE verb rather than 20 level deep IF-THEN-ELSE peices.)
>>>> They also cover Database access from COBOL as well as the
>>>> old fashioned flat file stuff. I have even considered writing
>>>> a COBOL text myself targeted at the use of OpenSource tools.
>>>
>>> Go for it! That would be a useful addition to the canon.
>>
>> I may, but I have learned from experience that it is a lot
>> more work than most people probably think. And in the
>> current atmosphere there is very little chance of actually
>> getting a publisher. O'Reilly seems to be gone.
>
> I don't know; if there's a market, then someone will publish.
> O'Reilly does indeed seem to be out to lunch, but the Rust book
> was amazingly good. Like, early-90s O'Reilly quality.
>
>>> I suppose there's a much larger debate to be had about the role
>>> of universities in professional computing. I wouldn't say that
>>> they have "abdicated their responsibility to prepare students
>>> for their future careers", though; certainly not by abandoning
>>> COBOL in their curricula.
>>
>> It goes much deeper than just abandoning curricula. In most
>> places (at least on my side of the pond) they very vocally
>> attack it and put in a lot of effort steering students away
>>from even looking at it.
>
> 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.

On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
> On 2/19/22 21:07, Dan Cross wrote:

Bit of a trim of the old stuff needed ...

To me, a university is there to teach a person how to think and learn.

When my son started school, he asked "what type of job should I learn to do?".
My reply was "You aren't going to learn a job. You're going there to learn how
to learn, and think, and to learn about the world that you haven't seen yet."

As to teaching Cobol, learning computer languages should be a part of
university, if the student chooses. I had a semester of Cobol when I was in
school, maybe 50 some years ago.

What I would not agree with is misinformation. If a professor is misleading
students based upon his/her own bias about how the world should be run, well,
that's dishonest, and it should be "former professor".

As for skills, to me is seems it always comes down to OJT. No school is going
to teach exactly what a particular employer needs. Some basics, and how to
learn, yes. Details, no.

As an example, I was taught about linked lists. I wasn't taught about what I
needed them for, that came later on the job. The school taught the concept, the
job taught the need and design.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

On Sunday, February 20, 2022 at 12:17:22 AM UTC-5, Dave Froble wrote:
> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
> > On 2/19/22 21:07, Dan Cross wrote:
> Bit of a trim of the old stuff needed ...
>
> To me, a university is there to teach a person how to think and learn.
>
> When my son started school, he asked "what type of job should I learn to do?".
> My reply was "You aren't going to learn a job. You're going there to learn how
> to learn, and think, and to learn about the world that you haven't seen yet."
>
> As to teaching Cobol, learning computer languages should be a part of
> university, if the student chooses. I had a semester of Cobol when I was in
> school, maybe 50 some years ago.
>
> What I would not agree with is misinformation. If a professor is misleading
> students based upon his/her own bias about how the world should be run, well,
> that's dishonest, and it should be "former professor".
>
> As for skills, to me is seems it always comes down to OJT. No school is going
> to teach exactly what a particular employer needs. Some basics, and how to
> learn, yes. Details, no.
>
> As an example, I was taught about linked lists. I wasn't taught about what I
> needed them for, that came later on the job. The school taught the concept, the
> job taught the need and design.
> --
> David Froble Tel: 724-529-0450
> Dave Froble Enterprises, Inc. E-Mail: da...@tsoft-inc.com
> DFE Ultralights, Inc.
> 170 Grimplin Road
> Vanderbilt, PA 15486

David,

David,

An refreshing perspective that I share and rarely see. I got in "trouble" with the established professors when I was teaching at the college level years ago. I taught both FORTRAN and assembly language (Macro32 at the time) and my exams were not the usual "write a code segment to do this" type of test. My thoughts at the time were that nowhere in industry would you be given a directive like that. You would be given a task and the reference material available to assist in accomplishing that task. I concentrated more on how to resolve a problem by breaking it down into logical steps. In other words, how to think. In this fashion, the language syntax specifics were more details on how to make it happen rather than problem solving. I had many students return to tell me that their current employment used a different language but that they had no problems adapting to that language because syntax was easy to reference and use. The thought process was more important.

While I believe that languages such as Cobol should be offered and available, concentrating on how to solve a problem and exposing students to MANY language syntax variants is valuable too. Perhaps a course in language similarities and differences would be a good one. Show examples of the advantages of each language and the disadvantages too. Lets face it, some languages are not appropriate for some tasks.

Dan

On 2/20/22 00:17, Dave Froble wrote:
> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>> On 2/19/22 21:07, Dan Cross wrote:
>
> Bit of a trim of the old stuff needed ...
>
> To me, a university is there to teach a person how to think and learn.

That's definitely part of it. BUt, based on observing life around us
today, they appear to have abdicated the part about learning to think
as well as COBOL. :-) They do not teach yo how to learn. It is
pretty much assumed you got that in the schools before you got to
University.

>
> When my son started school, he asked "what type of job should I learn to
> do?".

Bad question. But then, that's probably why so many students end out
taking 5 to 6 years to get that degree because they really don;t know
why they are even there.

> My reply was "You aren't going to learn a job.  You're going there
> to learn how to learn, and think, and to learn about the world that you
> haven't seen yet."

And partly a wrong answer. Colleges are trade schools. They are
trade schools for the white collar class. Bankers, CPA's, chemists,
lawyers, future CEO's and yes, systems analysts (which is actually
a higher level programmer than today's buzzword, "coder".) You are
certainly not going to learn any of that in the local Vo/Tech or even
Community College.

>
> As to teaching Cobol, learning computer languages should be a part of
> university, if the student chooses.  I had a semester of Cobol when I
> was in school, maybe 50 some years ago.

50 years ago? What school and what degree program? Computers were in
their infancy in the University system in those days with only a couple
major colleges offering degrees in it.

>
> What I would not agree with is misinformation.  If a professor is
> misleading students based upon his/her own bias about how the world
> should be run, well, that's dishonest, and it should be "former professor".

But that is what too much of college has become, and especially in CS.
They are no longer satisfied with merely driving the bus they now want
to even tell the riders where they want to go.

>
> As for skills, to me is seems it always comes down to OJT.  No school is
> going to teach exactly what a particular employer needs.  Some basics,
> and how to learn, yes.  Details, no.

That's true up to a point. A new entry level job always includes OJT.
But there is an expectation that the candidate has basic skills for
the tasks they are expected to do. You don't start in the construction
business as a master carpenter but your boss expects you to know which
end of the hammer should strike the nail.

Again, we really come down to the CS/CIS difference. If one is going
for a CIS degree it is expected that they will come arrive at that
first job with the basic knowledge required by the job. That means
COBOL, Databases, including SQL programming, web concepts and probably
HTML, JavaScript and PHP and even UI concepts. They won't design and
code a shopping cart the first day, but they should understand what it
entails. Sadly, all of that is there except for the language needed
for the backend. For some, as yet never explained, reason that part
was dropped. And, the most interesting thing about it is how close
to each other they all dropped it. That is the stuff conspiracy
theories are built on. :-)

>
> As an example, I was taught about linked lists.  I wasn't taught about
> what I needed them for, that came later on the job.  The school taught
> the concept, the job taught the need and design.

Very true. I had been in the business for over 40 years before I
started taking classes for a degree (which I got 4 years before my
somewhat forced retirement!) I got to observe a lot of our upcoming
students in these classes. It was funny listening to chatter among
the Discrete Math students. "Why are we learning about nodes?
What is this Venn Diagram crap? Who cares about Linked Lists? I
just want to learn how to be a programmer." Of course, having done
this for 40 years I knew exactly how all this stuff fit in. Like
it or not, COBOL fits in the same way. It uses a paradigm not quite
the same as the procedural paradigm of Pascal or Ada. And the
students who plan to do this for a living should at least have the
basics under their belt before they hit that first job. At least
a 3 credit course although 6 credits would do them much better in
the real world.

Will it happen again? Who knows. But I am betting it won't happen
at the University level. Another major truism about the academic
world is they never admit to making a mistake. That would be a sign
of weakness.

bill

On 2/20/2022 9:49 AM, Bill Gunshannon wrote:
> On 2/20/22 00:17, Dave Froble wrote:
>> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>>> On 2/19/22 21:07, Dan Cross wrote:
>>
>> Bit of a trim of the old stuff needed ...
>>
>> To me, a university is there to teach a person how to think and learn.
>
> That's definitely part of it. BUt, based on observing life around us
> today, they appear to have abdicated the part about learning to think
> as well as COBOL. :-) They do not teach yo how to learn. It is
> pretty much assumed you got that in the schools before you got to
> University.

Bad assumption. In secondary schools, and grade schools, one is taught facts.
One isn't taught to think much about the facts. After all, onme would need the
facts before being able to think about them. But at some time some more
abstract thought about the world around us is needed, and that should happen at
university. At least, that's how I see it.

>> When my son started school, he asked "what type of job should I learn to do?".
>
> Bad question.

I always say, there is no such thing as a bad question. If someone has a
question, that indicates he/she "doesn't know", and is trying to find out.
However, there can be bad answers.

> But then, that's probably why so many students end out
> taking 5 to 6 years to get that degree because they really don;t know
> why they are even there.

I believe David took 8 years before getting a degree in geology. And you are
correct, many don't know why they are there when going to university. A
university should help students at least partially figure out what they are doing.

>> My reply was "You aren't going to learn a job. You're going there to
>> learn how to learn, and think, and to learn about the world that you haven't
>> seen yet."
>
> And partly a wrong answer. Colleges are trade schools. They are
> trade schools for the white collar class. Bankers, CPA's, chemists,
> lawyers, future CEO's and yes, systems analysts (which is actually
> a higher level programmer than today's buzzword, "coder".) You are
> certainly not going to learn any of that in the local Vo/Tech or even
> Community College.
>
>>
>> As to teaching Cobol, learning computer languages should be a part of
>> university, if the student chooses. I had a semester of Cobol when I was in
>> school, maybe 50 some years ago.
>
> 50 years ago? What school and what degree program? Computers were in
> their infancy in the University system in those days with only a couple
> major colleges offering degrees in it.

I graduated from the University of Pittsburgh in 1973. At that time they didn't
have a CS major. My BS is in math.

>> What I would not agree with is misinformation. If a professor is misleading
>> students based upon his/her own bias about how the world should be run, well,
>> that's dishonest, and it should be "former professor".
>
> But that is what too much of college has become, and especially in CS.
> They are no longer satisfied with merely driving the bus they now want
> to even tell the riders where they want to go.

I may have mentioned over inflated egos in the past ...

>> As for skills, to me is seems it always comes down to OJT. No school is going
>> to teach exactly what a particular employer needs. Some basics, and how to
>> learn, yes. Details, no.
>
> That's true up to a point. A new entry level job always includes OJT.
> But there is an expectation that the candidate has basic skills for
> the tasks they are expected to do. You don't start in the construction
> business as a master carpenter but your boss expects you to know which
> end of the hammer should strike the nail.

Some idea of "how to do", yes, I agree. My CS minor included multiple languages
and subjects. I still remember toggling in a boot loader on the PDP-6. Cobol
and Fortran languages. But it was only on the job that I learned Basic.

> Again, we really come down to the CS/CIS difference. If one is going
> for a CIS degree it is expected that they will come arrive at that
> first job with the basic knowledge required by the job. That means
> COBOL, Databases, including SQL programming, web concepts and probably
> HTML, JavaScript and PHP and even UI concepts. They won't design and
> code a shopping cart the first day, but they should understand what it
> entails. Sadly, all of that is there except for the language needed
> for the backend. For some, as yet never explained, reason that part
> was dropped. And, the most interesting thing about it is how close
> to each other they all dropped it. That is the stuff conspiracy
> theories are built on. :-)
>
>>
>> As an example, I was taught about linked lists. I wasn't taught about what I
>> needed them for, that came later on the job. The school taught the concept,
>> the job taught the need and design.
>
> Very true. I had been in the business for over 40 years before I
> started taking classes for a degree (which I got 4 years before my
> somewhat forced retirement!) I got to observe a lot of our upcoming
> students in these classes. It was funny listening to chatter among
> the Discrete Math students. "Why are we learning about nodes?
> What is this Venn Diagram crap? Who cares about Linked Lists? I
> just want to learn how to be a programmer." Of course, having done
> this for 40 years I knew exactly how all this stuff fit in. Like
> it or not, COBOL fits in the same way. It uses a paradigm not quite
> the same as the procedural paradigm of Pascal or Ada. And the
> students who plan to do this for a living should at least have the
> basics under their belt before they hit that first job. At least
> a 3 credit course although 6 credits would do them much better in
> the real world.
>
> Will it happen again? Who knows. But I am betting it won't happen
> at the University level. Another major truism about the academic
> world is they never admit to making a mistake. That would be a sign
> of weakness.
>
> bill
>
>

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

> > As an example, I was taught about linked lists.  I wasn't taught about
> > what I needed them for, that came later on the job.  The school taught
> > the concept, the job taught the need and design.

> It was funny listening to chatter among the Discrete Math students.
> "Why are we learning about nodes? What is this Venn Diagram crap? Who
> cares about Linked Lists? I just want to learn how to be a programmer."

This is why Dave (above) is partly wrong. Stuff they try to teach you
in the abstract is likely to be "why do we need this?" and won't stick,
especially to typical college age kids.

You need to walk out with a handle on what it is, and how you use it,
and the general class of problems you're going to hit with it. If you
get some clue of how to read documentation and where to look for answers
and how to take problems apart in the general sense, and a toolkit full
of stuff like big-O and venn diagrams and linked lists and such, you'll
land on your feet when your boss hands you a deranged-ass task you've
never heard of before.

Or, you can walk out with barely enough skills to ask vague questions on
stackexchange and copypasta incorrect recipes, but get told you
shouldn't do that.

De

On 2/20/2022 12:17 AM, Dave Froble wrote:
> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>> On 2/19/22 21:07, Dan Cross wrote:
>
> Bit of a trim of the old stuff needed ...
>
> To me, a university is there to teach a person how to think and learn.
>
> When my son started school, he asked "what type of job should I learn to
> do?". My reply was "You aren't going to learn a job.  You're going there
> to learn how to learn, and think, and to learn about the world that you
> haven't seen yet."
>
> As to teaching Cobol, learning computer languages should be a part of
> university, if the student chooses.  I had a semester of Cobol when I
> was in school, maybe 50 some years ago.

> As for skills, to me is seems it always comes down to OJT.  No school is
> going to teach exactly what a particular employer needs.  Some basics,
> and how to learn, yes.  Details, no.
>
> As an example, I was taught about linked lists.  I wasn't taught about
> what I needed them for, that came later on the job.  The school taught
> the concept, the job taught the need and design.

Yes.

The software world is quite diverse when it comes to problem
domains, development methodologies, programming languages,
libraries and tools.

It is not realistic for an education to cover what is
going to be used.

Furthermore people will be working 40-45 years after
getting their degree.

Even if what they learn is actually used in their
first job, then it it unlikely to be used in their
last jobs.

They key is to learn to think the right way.

And I think it sort of get proved by the fact that
people with non-IT degrees like math, physics, chemistry,
astronomy etc. tend to get just as good software
developers as those with an IT degree in computer science
or software engineering.

So priorities:
1) Learn to think the right way
2) Learn the general stuff that keeps being relevant
about data structures, algorithms etc. "the Knuth stuff"
....
99) Learn some specific technologies needed by the industry last year.

What programming languages to learn is less important.

I will recommend at least 3 to get a broad perspective.

And they should of course be a bit different to achieve that goal, so:
- both static and dynamic types
- include procedural, object oriented, generic and functional
programming

Popular languages in education has changed over time.

Something like:

Pascal -> C -> C++ and Delphi -> Python, Java and C#

I don't think there is many aspects of Cobol that makes it
relevant in education.

Maybe for something including ISAM files.

Arne

On 2/18/2022 2:12 PM, Bill Gunshannon wrote:
> On 2/18/22 10:49, Dan Cross wrote:
>>                           Most of the COBOL work has been
>> outsourced,
>
> Another meaningless industry buzzword.  Outsourced to who?  I mean
> 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.

JP Morgan, BoA, Wells Fargo, Citibank, Goldmann Sachs, Capital One
and State Street all get IT work done in India.

And it is generally assumed that Cobol work is very much outsourced
to India due to the common model of outsourcing maintenance of
older system and do development of the new systems closer to business.
And a quick check of skill demand seems to confirm it - in the US the
ratio of Cobol to Java jobs is like 1:50 while in India it is just 1:4.

Arne

On 2/20/22 12:29, Dave Froble wrote:
> On 2/20/2022 9:49 AM, Bill Gunshannon wrote:
>> On 2/20/22 00:17, Dave Froble wrote:
>>> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>>>> On 2/19/22 21:07, Dan Cross wrote:
>>>
>>> Bit of a trim of the old stuff needed ...
>>>
>>> To me, a university is there to teach a person how to think and learn.
>>
>> That's definitely part of it.  BUt, based on observing life around us
>> today, they appear to have abdicated the part about learning to think
>> as well as COBOL.  :-)  They do  not teach yo how to learn.  It is
>> pretty  much assumed you got that in the schools before you got to
>> University.
>
> Bad assumption.  In secondary schools, and grade schools, one is taught
> facts. One isn't taught to think much about the facts.  After all, onme
> would need the facts before being able to think about them.  But at some
> time some more abstract thought about the world around us is needed, and
> that should happen at university.  At least, that's how I see it.

I think a bit of confusion. Students learn how to learn before
University. Universities then present information and it is up
to the student to "learn". Professors really don't care if you
learn anything in their class. Not their responsibility. No one
gets individual attention. After all, if you don;t learn the
material the first time around you can always take the class again.

>
>>> When my son started school, he asked "what type of job should I learn
>>> to do?".
>>
>> Bad question.
>
> I always say, there is no such thing as a bad question.  If someone has
> a question, that indicates he/she "doesn't know", and is trying to find
> out. However, there can be bad answers.

There can certainly be bad questions. The question he should have been
asking is what do I want to do with my life. Asking someone else what
kind of job you should get just sets you up for disappointment and a
very stressful life. Learned from experience. :-)

>
>>  But then, that's probably why so many students end out
>> taking 5 to 6 years to get that degree because they really don;t know
>> why  they are even there.
>
> I believe David took 8 years before getting a degree in geology.  And
> you are correct, many don't know why they are there when going to
> university.  A university should help students at least partially figure
> out what they are doing.

Nope, not their job. They are not psychologists and they are not
guidance counselors (although my experience with them in high school
left much to be desired!) One should have made the decision about
what one is going to study even before they have picked the school
they are going to attend. Once you get there they can only recommend
what courses of study they offer. None of them may be the right fit
for any particular student.

>
>>>        My reply was "You aren't going to learn a job.  You're going
>>> there to
>>> learn how to learn, and think, and to learn about the world that you
>>> haven't
>>> seen yet."
>>
>> And partly a wrong answer.  Colleges are trade schools.  They are
>> trade schools for the white collar class.  Bankers, CPA's, chemists,
>> lawyers, future CEO's and yes, systems analysts (which is actually
>> a higher level programmer than today's buzzword, "coder".)  You are
>> certainly not going to learn any of that in the local Vo/Tech or even
>> Community College.
>>
>>>
>>> As to teaching Cobol, learning computer languages should be a part of
>>> university, if the student chooses.  I had a semester of Cobol when I
>>> was in
>>> school, maybe 50 some years ago.
>>
>> 50 years ago?  What school and what degree program?  Computers were in
>> their infancy in the University system in those days with only a couple
>> major colleges offering degrees in it.
>
> I graduated from the University of Pittsburgh in 1973.  At that time
> they didn't have a CS major.  My BS is in math.

Which is where most of the CS Departments came from. I am surprised
they offered COBOL, but then Pitt was at the forefront of CS and is
still a very good bet.

>
>>> What I would not agree with is misinformation.  If a professor is
>>> misleading
>>> students based upon his/her own bias about how the world should be
>>> run, well,
>>> that's dishonest, and it should be "former professor".
>>
>> But that is what too much of college has become, and especially  in CS.
>> They are no longer satisfied with merely driving the bus they now want
>> to even tell the riders where they want to go.
>
> I may have mentioned over inflated egos in the past ...
>
>>> As for skills, to me is seems it always comes down to OJT.  No school
>>> is going
>>> to teach exactly what a particular employer needs.  Some basics, and
>>> how to
>>> learn, yes.  Details, no.
>>
>> That's true up to a point.  A new entry level job always includes OJT.
>> But there is an expectation that the candidate has basic skills for
>> the tasks they are expected to do.  You don't start in the construction
>> business as a master carpenter but your boss expects you to know which
>> end of the hammer should strike the nail.
>
> Some idea of "how to do", yes, I agree.  My CS minor included multiple
> languages and subjects.  I still remember toggling in a boot loader on
> the PDP-6.  Cobol and Fortran languages.  But it was only on the job
> that I learned Basic.

A single 3 credit course in COBOL is barely enough time to learn "how
to do". Today even more so as the functionality of the language has
expanded greatly over the years. There is a lot done with COBOL today
that your professors probably hadn't even anticipated.

>
>> Again, we really come down to the CS/CIS difference.  If one is going
>> for a CIS degree it is expected that they will come arrive at that
>> first job with the basic knowledge required by the job. That means
>> COBOL, Databases, including SQL programming, web concepts and probably
>> HTML, JavaScript and PHP and even UI concepts.  They won't design and
>> code a shopping cart the first day, but they should understand what it
>> entails.  Sadly, all of that is there except for the language needed
>> for the backend.  For some, as yet never explained, reason that part
>> was dropped.  And, the most interesting thing about it is how close
>> to each other they all dropped it.  That is the stuff conspiracy
>> theories are built on.  :-)
>>
>>>
>>> As an example, I was taught about linked lists.  I wasn't taught
>>> about what I
>>> needed them for, that came later on the job.  The school taught the
>>> concept,
>>> the job taught the need and design.
>>
>> Very true.  I had been in the business for over 40 years before I
>> started taking classes for a degree (which I got 4 years before my
>> somewhat forced retirement!)  I got to observe a lot of our upcoming
>> students in these classes.  It was funny listening to chatter among
>> the Discrete Math students.  "Why are we learning about nodes?
>> What is this Venn Diagram crap?  Who cares about Linked Lists?  I
>> just want to learn how to be a programmer."  Of course, having done
>> this for 40 years I knew exactly how all this stuff fit in.  Like
>> it or not, COBOL fits in the same way.  It uses a paradigm not quite
>> the same as the procedural paradigm of Pascal or Ada.  And the
>> students who plan to do this for a living should at least have the
>> basics under their belt before they hit that first job.  At least
>> a 3 credit course although 6 credits would do them much better in
>> the real world.
>>
>> Will it happen again?  Who knows.  But I am betting it won't happen
>> at the University level.  Another major truism about the academic
>> world is they never admit to making a mistake.  That would be a sign
>> of weakness.
>>

bill

On 2/20/22 14:57, Arne Vajhøj wrote:
> On 2/20/2022 12:17 AM, Dave Froble wrote:
>> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>>> On 2/19/22 21:07, Dan Cross wrote:
>>
>> Bit of a trim of the old stuff needed ...
>>
>> To me, a university is there to teach a person how to think and learn.
>>
>> When my son started school, he asked "what type of job should I learn
>> to do?". My reply was "You aren't going to learn a job.  You're going
>> there to learn how to learn, and think, and to learn about the world
>> that you haven't seen yet."
>>
>> As to teaching Cobol, learning computer languages should be a part of
>> university, if the student chooses.  I had a semester of Cobol when I
>> was in school, maybe 50 some years ago.
>
>> As for skills, to me is seems it always comes down to OJT.  No school
>> is going to teach exactly what a particular employer needs.  Some
>> basics, and how to learn, yes.  Details, no.
>>
>> As an example, I was taught about linked lists.  I wasn't taught about
>> what I needed them for, that came later on the job.  The school taught
>> the concept, the job taught the need and design.
>
> Yes.
>
> The software world is quite diverse when it comes to problem
> domains, development methodologies, programming languages,
> libraries and tools.
>
> It is not realistic for an education to cover what is
> going to be used.
>
> Furthermore people will be working 40-45 years after
> getting their degree.
>
> Even if what they learn is actually used in their
> first job, then it it unlikely to be used in their
> last jobs.

Depends very much on the job. I started in COBOL in 1980.
Eventually moved on into many other facets of the IT world
mostly at the system level as opposed to the application
level. In 2012 I took a job as a, you guessed it, a COBOL
programmer. I was able to hit the ground running because
other than some much nicer flow control (EVALUATE instead
of 50 level deep IF-THE-ELSE) nothing had really changed.
The job had remained the same, why should the language
morph into something else (although attempts to do just
that had been tried by academia and soundly rejected by
the real world practitioners.)

>
> They key is to learn to think the right way.
>
> And I think it sort of get proved by the fact that
> people with non-IT degrees like math, physics, chemistry,
> astronomy etc. tend to get just as good software
> developers as those with an IT degree in computer science
> or software engineering.

Nice thought, but my experience has somewhat differed. I have
had to maintain and modify business programs written in Fortran
by engineers.

Don't get me wrong, I am not saying that one needs a degree to
do any of this. I did most of what I did for over 30 years
without a degree. And, at no point did the degree have any
real effect on my ability to do the job. For me, the degree
was like the documentation. Not done until the project has
ended. :-) But it took a lot of learning. I am lucky in
that I have always had excellent learning skills. I learned
Pascal from the Jensen & Wirth book in one week of vacation
reading in order to further my position as a Systems Analyst/
Programmer in the Army. Many people need a more structured
learning environment and that should be provided by the
schools they attend. But the schools should also teach what
the student is likely to need in the future (which, again,
depends on the student actually picking the right track for
their future).

>
> So priorities:
> 1) Learn to think the right way
> 2) Learn the general stuff that keeps being relevant
>    about data structures, algorithms etc.  "the Knuth stuff"
> ...
> 99) Learn some specific technologies needed by the industry last year.

More importantly, unless your degree is in something like Philosophy
or Humanities, learn something you will need today in order to succeed
at what yo plan to do with that degree. Otherwise, might just as well
skip the whole college thing and save the massive debt. :-)

>
> What programming languages to learn is less important.

If your going to have to learn a programming language at all
it should be one that actually applies to where you are planning
on going after college. My department changed from Pascal to
Ada as the introductory language (this was before the advent
of C in the typical CS environment). For some it was their base
language for all four years at the University. I received dozens
of emails from former students bitching about how they had been
forced to learn and use a language that had no value whatsoever
when they got out in the real world.

>
> I will recommend at least 3 to get a broad perspective.
>
> And they should of course be a bit different to achieve that goal, so:
> - both static and dynamic types
> - include procedural, object oriented, generic and functional
>   programming
>

I agree with that. But make sure they are not three that are
totally tied to the same paradigm and only the reserved words
change. And don't tie the students to the language du jour
which is likely to change when they graduate or very shortly
thereafter.

> Popular languages in education has changed over time.
>
> Something like:
>
> Pascal -> C -> C++ and Delphi -> Python, Java and C#
^
|
You forgot Ada. :-)

>
> I don't think there is many aspects of Cobol that makes it
> relevant in education.

The fact that it is different from the other paradigms and still
used extensively in the IT world make it very relevant.

>
> Maybe for something including ISAM files.

Should be included, but there is much more to COBOL today. By the
way, IBM zOS is still very much into VSAM. Maybe that touch of
ISAM would help. :-)

bill

On 2/20/2022 3:46 PM, Bill Gunshannon wrote:
> On 2/20/22 12:29, Dave Froble wrote:
>> On 2/20/2022 9:49 AM, Bill Gunshannon wrote:
>>> On 2/20/22 00:17, Dave Froble wrote:
>>>> On 2/19/2022 11:02 PM, Bill Gunshannon wrote:
>>>>> On 2/19/22 21:07, Dan Cross wrote:
>>>>
>>>> Bit of a trim of the old stuff needed ...
>>>>
>>>> To me, a university is there to teach a person how to think and learn.
>>>
>>> That's definitely part of it. BUt, based on observing life around us
>>> today, they appear to have abdicated the part about learning to think
>>> as well as COBOL. :-) They do not teach yo how to learn. It is
>>> pretty much assumed you got that in the schools before you got to
>>> University.
>>
>> Bad assumption. In secondary schools, and grade schools, one is taught facts.
>> One isn't taught to think much about the facts. After all, onme would need
>> the facts before being able to think about them. But at some time some more
>> abstract thought about the world around us is needed, and that should happen
>> at university. At least, that's how I see it.
>
> I think a bit of confusion. Students learn how to learn before
> University. Universities then present information and it is up
> to the student to "learn". Professors really don't care if you
> learn anything in their class. Not their responsibility. No one
> gets individual attention. After all, if you don;t learn the
> material the first time around you can always take the class again.

I do remember at least one professor saying "I'm here to present the
information, learning is your job." I also remember that professor, and others,
who would be very helpful in one on one consultations. Quite a bit of
individual attention when it was asked for.

>>>> When my son started school, he asked "what type of job should I learn to do?".
>>>
>>> Bad question.
>>
>> I always say, there is no such thing as a bad question. If someone has a
>> question, that indicates he/she "doesn't know", and is trying to find out.
>> However, there can be bad answers.
>
> There can certainly be bad questions. The question he should have been
> asking is what do I want to do with my life. Asking someone else what
> kind of job you should get just sets you up for disappointment and a
> very stressful life. Learned from experience. :-)

Well, there you go ...

He didn't know to ask that question. Then what. That is why I told him he was
in school to broaden his horizons. And he did.

>>> But then, that's probably why so many students end out
>>> taking 5 to 6 years to get that degree because they really don;t know
>>> why they are even there.
>>
>> I believe David took 8 years before getting a degree in geology. And you are
>> correct, many don't know why they are there when going to university. A
>> university should help students at least partially figure out what they are
>> doing.
>
> Nope, not their job. They are not psychologists and they are not
> guidance counselors (although my experience with them in high school
> left much to be desired!) One should have made the decision about
> what one is going to study even before they have picked the school
> they are going to attend. Once you get there they can only recommend
> what courses of study they offer. None of them may be the right fit
> for any particular student.

I'd choose to partially disagree with that.

>>>> My reply was "You aren't going to learn a job. You're going there to
>>>> learn how to learn, and think, and to learn about the world that you haven't
>>>> seen yet."

The way things worked out is, David took a number of elective classes. There is
that "broaden horizon" thing again. One of the classes was an intro to geology,
not something he'd ever considered, and he really liked the subject. He went on
to get a degree in geology.

So yeah, a university can have much to do with a person choosing what to do with
their life.

And after working in the field for a while, he moved on. Currently a reactor
operator at a nuclear power station. Strange how things change over the years.

>>> And partly a wrong answer. Colleges are trade schools. They are
>>> trade schools for the white collar class. Bankers, CPA's, chemists,
>>> lawyers, future CEO's and yes, systems analysts (which is actually
>>> a higher level programmer than today's buzzword, "coder".) You are
>>> certainly not going to learn any of that in the local Vo/Tech or even
>>> Community College.
>>>
>>>>
>>>> As to teaching Cobol, learning computer languages should be a part of
>>>> university, if the student chooses. I had a semester of Cobol when I was in
>>>> school, maybe 50 some years ago.
>>>
>>> 50 years ago? What school and what degree program? Computers were in
>>> their infancy in the University system in those days with only a couple
>>> major colleges offering degrees in it.
>>
>> I graduated from the University of Pittsburgh in 1973. At that time they
>> didn't have a CS major. My BS is in math.
>
> Which is where most of the CS Departments came from. I am surprised
> they offered COBOL, but then Pitt was at the forefront of CS and is
> still a very good bet.
>
>>
>>>> What I would not agree with is misinformation. If a professor is misleading
>>>> students based upon his/her own bias about how the world should be run, well,
>>>> that's dishonest, and it should be "former professor".
>>>
>>> But that is what too much of college has become, and especially in CS.
>>> They are no longer satisfied with merely driving the bus they now want
>>> to even tell the riders where they want to go.
>>
>> I may have mentioned over inflated egos in the past ...
>>
>>>> As for skills, to me is seems it always comes down to OJT. No school is going
>>>> to teach exactly what a particular employer needs. Some basics, and how to
>>>> learn, yes. Details, no.
>>>
>>> That's true up to a point. A new entry level job always includes OJT.
>>> But there is an expectation that the candidate has basic skills for
>>> the tasks they are expected to do. You don't start in the construction
>>> business as a master carpenter but your boss expects you to know which
>>> end of the hammer should strike the nail.
>>
>> Some idea of "how to do", yes, I agree. My CS minor included multiple
>> languages and subjects. I still remember toggling in a boot loader on the
>> PDP-6. Cobol and Fortran languages. But it was only on the job that I
>> learned Basic.
>
> A single 3 credit course in COBOL is barely enough time to learn "how
> to do". Today even more so as the functionality of the language has
> expanded greatly over the years. There is a lot done with COBOL today
> that your professors probably hadn't even anticipated.

But it is certainly enough to get one started, so additional skills can be learned.

--
David Froble Tel: 724-529-0450
Dave Froble Enterprises, Inc. E-Mail: davef@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486

In article <j7dsr3Fqp7nU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@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?

In article <j7f2o5F37kcU1@mid.individual.net>,
Bill Gunshannon <bill.gunshannon@gmail.com> wrote:
>> As to teaching Cobol, learning computer languages should be a part of
>> university, if the student chooses.  I had a semester of Cobol when I
>> was in school, maybe 50 some years ago.
>
>50 years ago? What school and what degree program? Computers were in
>their infancy in the University system in those days with only a couple
>major colleges offering degrees in it.

50 years ago was 1972. COBOL was already a teenager at that point,
Unix was a going concern, C made its first appearance that year, and
computers were hardly in their infancy. We even had the ARPANET by
then, driven largely out of academia.

- Dan C.

Dan Cross <cross@spitfire.i.gajendra.net> wrote:
>In article <j7dsr3Fqp7nU1@mid.individual.net>,
>Bill Gunshannon <bill.gunshannon@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.

Academics shouldn't be teaching programming languages, they should be
teaching programming concepts. If you know C or Pascal, learning
how to write the procedure division code in COBOL should be a matter
of a couple hour's study. Once you know the concepts, learning the
syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
so horrible, but easy.)

So, I don't think there is any need to teach the programming part of
COBOL in school.

What's interesting about COBOL is that there is a big data description
language attached to it, and the data description language is different
than anything else students will have seen. So I think it's important
to at least talk about COBOL (and maybe RPG) because some of the basic
paradigms behind it are different than that of a canonical programming
language.

But I don't think this should take more than a day or two in a programming
language survey class, because once students understand the basic concepts
they can figure it out on their own if they need it.

Understanding the basic concepts, though, is important to figure out how
some modern systems got to be the way they are today.

It doesn't matter whether a thing is dead or not, it matters whether a
thing can be used to teach useful concepts. Real CS programs are about
teaching concepts, not methods. It's expected that students can learn
methods as needed.
--scott

--
"C'est un Nagra. C'est suisse, et tres, tres precis."

On 2/21/2022 10:19 AM, Scott Dorsey wrote:
> Academics shouldn't be teaching programming languages, they should be
> teaching programming concepts. If you know C or Pascal, learning
> how to write the procedure division code in COBOL should be a matter
> of a couple hour's study. Once you know the concepts, learning the
> syntax is easy. (Frustrating, perhaps, because the COBOL syntax is
> so horrible, but easy.)
>
> So, I don't think there is any need to teach the programming part of
> COBOL in school.

Learning the basic building blocks of variables, if, loops and
call are relative easy. Most people can learn that stuff.

There are more difficult topics. Some that I know cause a
lot of problems for people to grasp are:
- covariant and contravariant generic types
- currying and partially applied functions

Note that those are not language specific either - they can
be shown in different languages - even though far from all
languages support them.

Arne