Re: Gartner on Assessing the Age of Software Languages and Tools



"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:g2un6o0nl8@xxxxxxxxxxxxxxxxxxxx
Pete Dashwood wrote:
"Michael Wojcik" <mwojcik@xxxxxxxxxxx> wrote in message
news:g2s8ab031h4@xxxxxxxxxxxxxxxxxxxx
Pete Dashwood wrote:
(Client/Server development in COBOL (apart from sites already committed
to mainframe COBOL), is almost a twitching corpse...)
It's doing some Romero-level twitching, then. We have a lot of customers
with no mainframe COBOL (or mainframes) at all, writing client-server
apps. Some of those are ISVs who are among the largest in their sectors.

"a lot" is relative, Michael. If you had 10,000 even that would not be
lot
when considered against the number of computers running applications in
the world...

And general-purpose computers running general-purpose applications are a
tiny fraction (I think the figure Ed Nisley gave a few years back was 3%)
of all the computers running in the world. So what? I don't think that
relation is interesting in this context.

The important consideration is that "almost a twitching corpse" is
subjective, and it appears that what you consider a negligible level of
development, I consider substantial.

I expect COBOL will still be in widespread use in 2015, simply because
the industry does not, in fact, move very quickly.

That's an interesting idea. I've always considered computer people to be
reactionary and conservative for the most part, based on my own first
hand experience working on sites around the world. However, there is a
new generation arriving and they are much more clued up than their
predecessors were. They are confident and smart and many of them are
impatient for change. I think they will have an effect as older managers
retire.

I haven't seen any sign of this bright new generation. What I see, on
Usenet and other forums, and among the people I meet in person, is pretty
much the same distribution I've always seen of smart, eager folks and
grunts who just want to get something accepted with as little effort as
possible.

There's still a lot of Fortran and C development. Even APL still has an
active community of professional developers. There's been almost no
movement in general programming toward better (more expressive, safer)
languages like OCaml.

But are these pockets of "old time languages" significant in a global
context?

Most definitely. A great deal of scientific data processing is still done
in Fortran. That's significant, unless you don't care about empirical
science. A great deal of OS software (particularly for Unix platforms) and
FOSS software is still written in C; that's significant if you use either
of those.

For that matter, apparently much of the processing in certain specialized
but influential fields, like genomics and financial analysis, is done with
applications cobbled out of Excel macros. (There have been a number of
stories in the Register on this over the past few years.) That's a ghastly
environment, with very serious known bugs, but the people developing and
maintaining those applications haven't been motivated to rewrite them in
something sensible.

OCaml has appeal to purists but most people have never heard of it. If it
stays obscure you can hardly expect programmers to reach for it.

It stays obscure because most programmers and software-development
managers are not interested in improving the quality of software, if that
requires any significant effort or resources.

If programmers cared about software quality, they'd investigate ways to
improve quality, and they'd learn about safer and more-expressive
languages. But most do not.

I'm sure that in 7 years there will still be some COBOL usage. It just
won't be significant.

Unfortunately, this depends entirely on the subjective definition of
"significant", so it cannot be confirmed or refuted.

Remember there was a time when COBOL
was "the only game in town". We are not going ot see those days again...

Sure. Ford's never going to recapture the market share it had in the Model
A days, either. But - even given its current troubles - I bet Ford will
still be around for a good while longer.

And mixed-language development is finally beginning to become
significant in general-purpose applications, particularly in the .NET
environment. COBOL.NET does everything that any other .NET language
does.

No, it doesn't. It doesn't have reflection, delegation, event raising...
it can utilise the Framework, the same as any other .NET language, but it
doesn't have the innate capabilities of C# for example.

You're right; I was too hasty in writing that. MF .NET COBOL does have
delegation now (at least in NX 5.1), though. I'm not sure what you're
referring to with "event raising" in this context, so I can't comment on
that. (You can invoke RaisePostBackEvent properly from .NET COBOL, but I
assume you mean something else.)

However, reflection et al aren't "innate capabilities of the C# language".
They're capabilities of the CLR, and so they're potentially accessible to
any language that's compiled to CLI. The syntax for eg reflection may not
be in .NET COBOL yet, but there's no "innate" obstacle to providing it.

And of course the whole *point* of the CLI/CLR is that it simplifies
mixed-language programming, so it's trivial to use one .NET language for
the bulk of an application, and drop into another if it is better suited
for some particular aspect.

It's a better (cleaner, more expressive) language than C++.NET (which is
a nasty amalgamation of incompatible programming approaches), arguably
better than VB.NET (because VB is just inelegant), and about equivalent
to C#.

Others will disagree with you about .NET versions of C++ and VB;

Nah. I'm sure everyone agrees with me. :-)

I'll
disagree with you about C#. :-) Being fairly facile now in both these
languages I would contend that COBOL is not in the same LEAGUE as C# for
.NET development.

Fair enough.

(It's not as good as F#, probably the best .NET language, or the .NET
implementation of Ruby, but then no straight procedural-OO language will
be.)

Certainly there is growing interest and support for Ruby. MicroSoft are
providing support for Ruby with Silverlight and Ajax. I don't know enough
about Ruby to comment and I just don't have time to sit down and learn
another language at the moment. While we may debate the relative merits
of languages, I think you'd agree that all of this is bad for COBOL...
The more alternatives there are, the less incentive there is for people
to stay with it.

I could quibble over just what I'd consider "bad", but yes, I'll agree
that more alternatives tends to mean fewer people programming in any one
of the established languages.

I think COBOL's market share will continue to gradually decrease. I don't
see anything that would make it increase, and it's not likely to simply
hold steady. But I think that decrease is slower than you think it is, and
I suspect it will be asymptotic. Most of that will be because of the
essential conservatism of the industry.

I don't think it's impossible, though, that there will be at least some
new interest in COBOL thanks to modern free-format, OO COBOL and
environments like .NET. Most source code is a vile mess; most programming
languages are ugly, unsafe, and difficult; and people have historically
avoided the superior alternatives (indeed, even avoided learning about
them - how often do you meet programmers who have ever looked at literate
programming, for example?). But despite all evidence to the contrary I
still hope that some day some of that may change.

Avery good and balanced response. I have nothing to add except that I
endorse the sentiments in your last paragraph. As long as we still need
people to program computers it would be good if it could be done well :-)

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


.

Relevant Pages

  • Re: Is there a mainframe skills shortage?
    ... That's because the author of the article is comparing it to standard SQL. ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... stick to writing system software and leave applications to the COBOL ...
    (comp.lang.cobol)
  • RE: Programming
    ... Pascal, Modula-2, Perl, and 3 or 4 proprietary languages that nobody ... My first programming class in university was in COBOL. ... Those who had no prior exposure to programming, ... Languages whose compilers implement features in the translation to ...
    (Security-Basics)
  • Re: Is there a mainframe skills shortage?
    ... and material around Lamdas and functional programming. ... obvious which languages were the ones to learn. ... technology (and I am suggesting that Functional Programming and Lamda ... stick to writing system software and leave applications to the COBOL people. ...
    (comp.lang.cobol)
  • Re: Java is becoming the new Cobol
    ... things I though any professional COBOL programmer should know. ... I first started learning OO design in 1990 or so with C++. ... Cobol programming opening. ... I've been investigating many languages lately. ...
    (comp.lang.cobol)
  • Re: Java is becoming the new Cobol
    ... things I though any professional COBOL programmer should know. ... I first started learning OO design in 1990 or so with C++. ... Cobol programming opening. ... I've been investigating many languages lately. ...
    (comp.lang.cobol)