[Info-vax] The (now lost) future of Alpha.

[Bill Gunshannon]

On 08/04/2018 02:12 PM, Arne Vajhøj wrote:
> On 8/3/2018 6:57 PM, Bill Gunshannon wrote:
>> On 08/03/2018 06:28 PM, Arne Vajhøj wrote:
>>> On 8/3/2018 8:32 AM, Bill Gunshannon wrote:
>>>> On 08/02/2018 10:03 PM, Arne Vajhøj wrote:
>>>>> Embedded is not really me, but I would expect the role
>>>>> of C to decline as many embedded systems get much more
>>>>> CPU and memory.
> 
>>>> We heard that when Ada came out.  While a lot of
>>>> embedded work moved to Ada C remained a mainstay.
>>>> I expect the same will be true for other languages.
>>>> As the amount of embedded increases other languages
>>>> may make an appearance, but not supplanting C, just
>>>> in addition to it.
>>>
>>> C will certainly continue to be used.
>>>
>>> And to clarify - by "role of C to decline" I only
>>> meant the percentage of embedded programs in C not the
>>> number of embedded programs in C.
>>>
>>> But embedded with multi core SOC's and hundreds
>>> of MB of RAM gives more options.
>>>
>>> C, C++ or Ada still provide easy HW access and
>>> good real time characteristics, so they will
>>> not go away.
>>
>> But this is the same logic used to "prove" the decline of
>> COBOL.  There is as much and likely considerably more
>> COBOL today than in the 90's and yet because other languages
>> are being used for mostly time wasters (you know, those apps
>> on your phone) the fact that COBOL is still used for some of
>> the most important aspects of business is ignored and we
>> are told COBOL is dead.
> 
> Not really.
> 
> I expect the amount of COBOL code to have declined slightly.

Increased, actually as more COBOL is written every year.  Just not
as much as JAVA because you can't (or at least don't want to) write
Candy Crush Saga in COBOL.

> 
> But more importantly the amount of COBOL work has declined
> a lot.

NO, actually it hasn't.  Still a staple in banks, financials,
insurance, credit cards, mortgages and much more that it has
always been firmly entrenched.  Oh yeah, taxation and medical.
I can provide examples for most of the above that I have had
first hand experience with.  And then there is the DOD stuff
but, like VMS in DOD, if I told you I wold have to kill you.

> 
> I don't think neither is the case for embedded C.
> 
> That the amount of COBOL work has imploded is very visible
> from the lack of demand of COBOL skills. 

Guess it depends on how you measure that demand.  I know of at
least one job still empty after numerous attempts to fill it.
I know this because I was the last one to hold the position.
At least six vacancy announcements went out with no qualified
applicants.

>                                          A lot of COBOL
> programmers are retiring. 

This is true.  Creating a serious vacuum.

>                            A lot of COBOL programmers
> are either moving to other languages or moving to
> non-programming work.

Got any examples?  I know of no COBOL programmer who
voluntarily leaves COBOL for other languages.  The
desire to have me do that is why I left my last COBOL
gig leaving them with no one to continue babysitting
all the COBOL I left behind.  And, in case you are
curious, not all the work I did during my short stay
there was maintenance.  Some was new additions to the
stable.

>                         The influx of new COBOL developers
> are very small. 

And, why is that?  Not because of a lack of demand or desire.
No, primarily because academia not the industry decided that
COBOL was dead.  or at least they wanted it to be dead.

>                  But still there are no long lines
> of recruiters frantically lined up to try and persuade
> those with COBOL skills to work for them. That
> means that the the demand has decreased a lot.

Recruiters are like academia, only interested in the language
du jour.  If it ain't flashy they look elsewhere.

> 
> Every few years there come an article in some newspaper
> claiming that COBOL skills will become gold as all the
> old COBOL programmers retire. But it has not happened.
> Demand seems top as fast or maybe even faster than
> supply.

I see COBOL jobs advertised everyday.  Some of them
repeated day after day by the same organizations.

> 
> I believe that two of the areas where COBOL code
> has actually been replaced are:
> * reporting - instead of having a COBOL program
>    pull data out of RDBMS/ISAM file and generate
>    a report, then then the data just got moved to
>    a DWH and a drop and drag reporting tool is used
>    to produce reports

That has never been a function done independently of other
functions in the COBOL world.  It is just one of the last
stages of a much larger IS.

> * ERP/CRM systems - instead of bespoke COBOL applications
>    then companies buy SAP, Oracle, MS Dynamics and
>    customize those (and the customization is done in
>    ABAP, Java, X++ etc. not COBOL).

But none of these are actually replacing already existing
COBOL.  Just new work that could have been done better,
cheaper and more reliably by COBOL but the trade rags
are too busy pushing outsourcing to tell anyone that.
And we all know COBOL isn't glamorous.  (Did you know
that in a survey done over 30 years ago when COBOL was
at the top of the industry's view Programmers came out
as more boring than Undertakers.  :-)

> 
> There are still a lot of core COBOL applications
> running in financial industry, government etc.. And
> there is little appetite for replacing them - it will
> cost a fortune and there will be a long period before
> the new system will have as few bugs as the old one
> (and the stuff they run are often very important).
> But the exact same reason that keep the systems around
> keep the work done to a bare minimum. If a new feature
> can be implemented in some middleware in front of the
> old system, then that that option is typical picked to
> avoid the risk of impacting the core system. Sometimes
> new features has to go into the core and that require
> the org to keep a minimal staff of COBOL developers.

The biggest cause of minimal staff of COBOL developers is the
lack of COBOL developers.  One of these days Tech Schools will
figure this out and then watch the demand for college grads in
the IT industry really drop.

> 
>> There may be a lot of garbage written in Java, PHP and
>> even Python, but OSes and, yes, compilers are still being
>> written in C.
> 
> OS'es, compilers, databases, VM's for the new languages
> etc. are still mostly C/C++.
> 
> And the competition in this area is not Java, PHP, Python
> and similar but languages like Go and Rust.

Show me one textbook on writing compilers or OSes that use
Go or Rust.

Like it or not, just like they tried to kill COBOL, academia
is still driving the bus.

bill