Gartner on Assessing the Age of Software Languages and Tools
in [Cobol]
|
Prev: MicroFocus Java
Next: MicroFocus Java
From: Pete Dashwood on 12 Jun 2008 18:57 "Robert" <no(a)e.mail> wrote in message news:cpn05418j72uo9rqrk355cdb8mg040q3ef(a)4ax.com... > On Thu, 12 Jun 2008 10:33:19 +1200, "Pete Dashwood" > <dashwood(a)removethis.enternet.co.nz> > wrote: > >> (Client/Server development in COBOL (apart >>from sites already committed to mainframe COBOL), is almost a twitching >>corpse...) > > If you received a phone bill, there is a 60-70% probability it was > produced by Amdocs > Ensamble written in Cobol and running on Unix. The system was rewritten in > C++ seven years > ago and called Enabler. Enabler has not replaced Ensamble anywhere > Ensamble was already > installed, AFIK. > > The US federal student loan system is Cobol on Unix. Most US state child > welfare systems > are Cobol on Unix. > > Tens of thousands of organizations, including Air New Zealand, run > Peoplesoft ERP and/or > HRMS on Unix. It is written in Cobol and Peoplecode. About 4,000 run > Lawson ERP, written > entirely in Cobol, on Unix. > > None of this runs on mainframe. Most of the sites don't have a mainframe. > > Cobol is dead on the client side, but not on the server. And there is more > batch > processing than people realize. There is a batch process involved every > time you hear > 'three to five business days.' I accept there is a large COBOL/Unix base. However, I believe that the next few years will bring some fundamental changes in what is expected from computer systems and how we interact with them. As for packages written in COBOL, that is NOT the same as in house COBOL development. 4000 clients running a COBOL application that they didn't write and don't maintain, is not gainful employment for COBOL programmers. Nevertheless, I take your point re COBOL/Unix. Pete. -- "I used to write COBOL...now I can do anything."
From: Pete Dashwood on 12 Jun 2008 19:25 "Michael Wojcik" <mwojcik(a)newsguy.com> wrote in message news:g2s8ab031h4(a)news4.newsguy.com... > 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... Your point about ISVs is good, though. > 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. >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? 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. > > The success stories for improvements in software development, like > widespread (though by no means universal) adoption of OO in > general-purpose programming, investigation of agile and empirical > development processes and adoption where appropriate, and so forth are > hugely overshadowed by the industry's overall conservatism and inertia. > Most general-purpose software is still essentially produced the way it was > thirty years ago, with little evidence that we've learned anything about > software development since then. I really hope you're wrong, but I can't disagree... :-) > > Not long ago I got a query from a major corporate customer about a product > that hasn't had a significant release in ten years. They're running it on > OS/2. There's a migration path; they just don't see any justification for > taking it, unless and until they're forced to. Yes, the old "if it ain't broke..." argument. I guess you can't blame them... > > That's generally the case with the industry. IPv6 still isn't widely used. > IE/MSHTML still doesn't support XHTML correctly. (Hell, it doesn't support > HTML correctly, even in IE8, though it's finally getting close.) Good > security practices are still not widespread. It's not like any of these > things are particularly hard to fix - they're just not compelling. > > Seven years is *far* too short a time for even a majority of existing > COBOL users to decide to transition to some other language, much less > actually make that change. Don't be too sure. In the last 10 years I have personally seen 8 sites move away from COBOL. I'm currently working with another one. While some of these are SMEs, some of them are not... As COBOL jobs dry up it accellerates the rate of decline. I'm sure that in 7 years there will still be some COBOL usage. It just won't be significant. Remember there was a time when COBOL was "the only game in town". We are not going ot see those days again... >It doesn't matter whether the superiority of the alternative is >self-evident. And it isn't; COBOL is pretty good for what it does, >especially well-written modern COBOL. > > 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. >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; 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. However, it is a matter of opinion and neither of us can really change any minds. >(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. > > COBOL.NET may never be a significant player, but it won't be because other > languages are superior. Other languages for that environment mostly > *aren't* superior, and the ones that are don't see widespread use, because > most shops simply don't care to move to better tools or approaches. I mildly disagree (I think there is much truth in what you say, but my own experience is showing increasing interest in moving off COBOL.) Pete. -- "I used to write COBOL...now I can do anything."
From: SkippyPB on 13 Jun 2008 11:08 On Fri, 13 Jun 2008 10:57:53 +1200, "Pete Dashwood" <dashwood(a)removethis.enternet.co.nz> wrote: > > >"Robert" <no(a)e.mail> wrote in message >news:cpn05418j72uo9rqrk355cdb8mg040q3ef(a)4ax.com... >> On Thu, 12 Jun 2008 10:33:19 +1200, "Pete Dashwood" >> <dashwood(a)removethis.enternet.co.nz> >> wrote: >> >>> (Client/Server development in COBOL (apart >>>from sites already committed to mainframe COBOL), is almost a twitching >>>corpse...) >> >> If you received a phone bill, there is a 60-70% probability it was >> produced by Amdocs >> Ensamble written in Cobol and running on Unix. The system was rewritten in >> C++ seven years >> ago and called Enabler. Enabler has not replaced Ensamble anywhere >> Ensamble was already >> installed, AFIK. >> >> The US federal student loan system is Cobol on Unix. Most US state child >> welfare systems >> are Cobol on Unix. >> >> Tens of thousands of organizations, including Air New Zealand, run >> Peoplesoft ERP and/or >> HRMS on Unix. It is written in Cobol and Peoplecode. About 4,000 run >> Lawson ERP, written >> entirely in Cobol, on Unix. >> >> None of this runs on mainframe. Most of the sites don't have a mainframe. >> >> Cobol is dead on the client side, but not on the server. And there is more >> batch >> processing than people realize. There is a batch process involved every >> time you hear >> 'three to five business days.' > >I accept there is a large COBOL/Unix base. However, I believe that the next >few years will bring some fundamental changes in what is expected from >computer systems and how we interact with them. > >As for packages written in COBOL, that is NOT the same as in house COBOL >development. 4000 clients running a COBOL application that they didn't write >and don't maintain, is not gainful employment for COBOL programmers. > It is great employment if you work for the company that wrote the application and maintain it. I know because that's what my employer does and I've been with them for nearly 28 years! >Nevertheless, I take your point re COBOL/Unix. > >Pete. Regards, //// (o o) -oOO--(_)--OOo- "You've got the brain of a four-year-old boy, and I'll bet he was glad to get rid of it." -- Groucho Marx ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Remove nospam to email me. Steve
From: klshafer on 13 Jun 2008 11:13 On Jun 11, 5:17 pm, "klsha...(a)att.net" <klsha...(a)att.net> wrote: > Gentlepeople, > > MicroFocus has a courtesy copy of a Gartner Report, _Assessing the Age > of Software Languages and Tools_.It includes analysis and criteria for > "categorizing" a programming language by "age" and offers some > "management policy" recommendations. > > The report is free, but you will have to fill out a "contact > information" form. > > I did so and am pleased. It is rather short, only seven pages, but to > the point. > > The report can be accessed by going to... > > http://www.microfocus.com/ > > and then clicking on the Gartner icon under Resources. > > After "enough" of us have had a chance to read it, perhaps we could > discuss it here. Here are a few more observations and clarifications regarding the report... I thought it dispassionate, but I expected as much. I think my only disappointment was the omission of Ada from the list. I would have been curious about what they might have to say about it. I also took note of how Visual Basic 6 is also considered "elderly", and suffering compatability and skills issues. FORTRAN is also "elderly", except for massively parallel versions, which are still "adult." And although also C is "aging", it still has a nice niche in aerospace/automative/ embedded systems (probably a lot of real-time stuff.) When categorizing languages, they offer the cautionary "In same cases all implementations (of a language) will be at the same stage, while in more broadly used instances (such as COBOL), the vendor and variant (of the language) must be separately evaluated." And yes, under "Elderly" (limited or no support, high priority to replace) they have the "obsolete variants", such as COBOL II. But under "Mature", they refer to "current variants" (usually CoBOL 88 or 2002) and IBM LE. I presume that this include other vendors besides IBM and Microfocus. I don't have a good feel for what is the market share of non-IBM, non-Microfocus "current variants" - what would that be? Unisys? Are there others worth mentioning? Regarding life expectancy, what Gartner said, precisely, was: "Taking a longer view, a legacy language such as COBOL has _at least_ (emphasis added) another decade of useful life..." Because the future can be difficult to divine, I would rather concentrate on Gartner's policy recommendations. Yes, for "aging" or "elderly" languages (and "obsolete" CoBOL variants are deemed "elderly"), the recommendations are the likes of "actively discourage" or "forbid expansion", or "avoid new use" and "high priority to replace." (Presumably with "younger" languages.) There are CLC participants here to help clients in these circumstances do just that. That is a puzzle worth working on. For "mature" languages, and for Gartner, these are the "current variants" (COBOL 88, 2002, LE), the recommendations are to "assess architectural suitability", "migrate to most-current form", and "increase tool use." That is also a puzzle worth working on. For me, right now, that is the puzzle that interests me more. I don't see it as a question of whether the "report" will extend the life of COBOL. I don't even see it as a question of whether _we_, we CLCers, can extend the life of COBOL. In those matters, it is what it is. It will be what it will be. What we _can_ do is make the rest of that lifetime as "comfortable" for the client as possible. I see that as the essence of keeping up with the "most current form" and "increasing tool use", so the client gets maximum productivity from the current paradigm. I would like to hear from others of you in that regard. Thanks, Ken
From: klshafer on 13 Jun 2008 11:19
On Jun 13, 11:13 am, "klsha...(a)att.net" <klsha...(a)att.net> wrote: Oops, I made a typo; to avoid confusion, this is what I should have typed: When categorizing languages, they offer the cautionary "In _some_ (emphasis added) cases all implementations (of a language) will be at the same stage, while in more broadly used instances (such as COBOL), the vendor and variant (of the language) must be separately evaluated." Later, Ken |