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

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.

--
Michael Wojcik
Micro Focus
Rhetoric & Writing, Michigan State University
.

Relevant Pages

  • Re: 7E7 Flight Controls Electronics
    ... was just good thing that that localization was not too easy - it would ... Please don't confuse abstraction skills of typical COBOL programmer (that ... I pointed at the current programming "biblioware" for commercial data ... > language was because I learned all the workarounds. ...
    (comp.lang.ada)
  • Re: Structured Coding
    ... more visual, some are more conceptual, some are more language oriented. ... I had major problems struggling with OO COBOL when it was first released. ... programming language ever written; light hearted, witty, amusing, ... Later I had to run some courses in Java Web programming and ...
    (comp.lang.cobol)
  • Re: New Cobol compiler written in Cobol
    ... It didn't have a visible operating system. ... > If I were writing a Cobol compiler, I wouldn't look at today's market. ... > What will a programming language need to be successful in that world? ... They'll use a language they can understand at a glance. ...
    (comp.lang.cobol)
  • Re: String Functions in MF
    ... installation standards that constrained the use of the language. ... You might wonder how such standards could have been written, ... Assembler, been dragged kicking and screaming into COBOL, and was determined ... Programming Languages should not be designed for the Lowest Common ...
    (comp.lang.cobol)
  • Re: Java compatibility issues (WAS: MF having issues?)
    ... language it can do most of what C, C++, and Java can do. ... 2002 COBOL standard addresses that, but having a standard is a far ... Some flavours do have libraries. ... On the IBM mainframe we have Language Environment but it does ...
    (comp.lang.cobol)