COBOL drinks from cloudy fountain of youth One of computing's longest survivors is being hauled into the world of cloud computing, object-oriented programming, and virtual machines. Micro Focus today plans to deliver Visual COBOL R3, a development environment it said positions COBOL for the next 10 years by meeting the needs of those maintaining it. Despite the …
Alan Perlis (IIRC) was in early seventies asked what kind of programming language people would use in the year 2000. To which he answered "I don't know, but they will call it FORTRAN".
What is called COBOL in the article seems to be in this category: It has only a passing resemblance to the COBOL of the 1960s, but still retains the name.
First book, third chapter:
The Tao gave birth to machine language. Machine language gave birth to the assembler.
The assembler gave birth to the compiler. Now there are ten thousand languages.
Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao.
But do not program in COBOL if you can avoid it.
- http://www.canonical.org/~kragen/tao-of-programming.html
Anderton said that taking existing $OLD_STUFF apps to the $BUZZWORD using $SHINY_NEW_VERSION would let you $BUZZWORD on the $BUZZWORD of $BUZZWORD $BUZZWORD while $BUZZWORD the $BUZZWORD of $BUZZWORD, $BUZZWORD, $BUZZWORD, and $BUZZWORD-y $BUZZWORD of the $BUZZWORD. Putting $OLD_STUFF in the $BUZZWORD would help $BUYERS on their way towards $BUZZWORDing their IT infrastructure, he said.
Bingo!
Aren't we feeling all-aBUZZ now? Maybe I should've translated it to smurfese instead.
COBOL .NET has existed for a decade. Uptake? Practically zero.
People don't stick with COBOL because it's lovely: they're working with COBOL because no one has budgeted for a complete reworking from the ground up. If you're working with fifty years of bizarre, unwieldy code, the last thing you want is to weld it to yet another freakish kludge; and you sure as Hell don't hand the maintenance of your business-critical COBOL dinosaur, to some finger-painter who can't deal with code outside of an IDE.
Announcements like this remind me of when Borland release Kylix, in the stated belief that all those shops who were still maintaining Delphi, were simply looking for yet another platform to port it onto.
Disclaimer! I work for Micro Focus, developing Visual COBOL.
COBOL.NET has existed for less than seven years, and it would be fair to say adoption to begin with has been slow, but we are now starting to see the adoption curve for COBOL .NET climb quite sharply, because market and technology reasons now make it more compelling.
With COBOL JVM, I think Micro Focus can honestly claim to be offering the only mainstream enterprise friendly programming language that provides cross-platform compatibility between both .NET and JVM. And COBOL is better at doing sums (38 decimal digit precision) than Java or C# - quite important when your application calculates mortgage interest or works with the national debt.
Finaly, the reason no-one has budgeted for that complete rewrite - it could easily run into tens of millions of dollars and hundreds of man years. And no guarantee that what you end up with encapsulates your original business rules or runs as fast. If you want it hosted in Azure or on Java application server, recompiling it is a safer and lower risk option.
Fujitsu was among the first companies to target COBOL for the CLR with COBOL.NET, back in 2001:
http://www.c-sharpcorner.com/UploadFile/nrsurapaneni/4MSNET12052005053040AM/4MSNET.aspx
(I know, because Wrox Press seriously considered writing a book about it, at the time, before the window-lickers in charge of the project were successfully distracted using some shiny paper and a small wind-up toy: it didn't prevent Wrox going bankrupt, but it did probably help postpone things by a few years.)
I wish you luck with it, but I know that cross platform compatibility with either .NET or JVM is not something my own company will ever want from their COBOL. If you talk to the developers, the only thing they really want it to do, is 'go away'.
This argument (which has lain at the belly of a lot of .NET/CLR marketing) that 'you can successfully maintain your legacy code, by building yet another layer of dependency into it' is a bit like a doctor telling you that he intends to improve things for you, by making it easier to cope with having a tumour. Sometimes it's the only option available, but don't expect the person receiving this news to jump for joy, or not to seek a second opinion.
Ah yes - I've still got some pre-release demo discs for the Fujitsu version somewhere, from maybe 1999. Most of my employed-programming has been in COBOL, albeit a different version again (BOS). I've been out of that game for a few years now, but for business applications, you really do need code that adds in decimal, not binary. (Remind me again what 1*(.5-.4-.1) equates to....)
...was retrained after his military service to write COBOL.
Until his retirement he had a private office and godlike status as the only person in a very large enterprise that could translate annual data in arbitrary formats from the lowest bidder to fit the fields of legacy inhouse iron.
A drag and drop environment would be a perfect fit for situations like this.
*Yes i do have one.
"Visual COBOL R3 converts COBOL's English-like statements – the essence that has made the language so accessible for programmers during the last 50-odd years – into files that the machine understands. "
How is this different from any other version of COBOL, or indeed any other compiler? And it sounds like a sentence from the Ladybird Book of Computers, not something one would read on a tech news site.
and also that this "accessibility" wasn't ment for _programmers_ (before outsoursing to elbonia became the hip thing to do) but for _managers_.
Gavin apparently couldn't withstand the verbiage so he hid behind that ladybird book while doing the old press release copy routine. See here now Gavin, look what you've done. You've gone all COBOL on us!
No, No No. Gigabyte memory slurping crashing, disk log filling crap java crossed with verbose, pedantic COBOL. Is there a supercomputer big enough to run the abomination long enough to do a mortgage ?
On its own, COBOL is a good language, fit for purpose, ie Business. Mixing it with java is like stirring sawdust into a chocolate mud cake for texture. Dirty sawdust, with asbestos contamination.
And yes, somewhere in my archives are visual cobol, kylix, delphi and basic compilers. Just say no. vi and a command line. Its faster, easier and just works if you have a real OS.
>>> So, there is no need for brace-and-bracket syntax, just ‘everyday’ language.”
Jim DuLaney, Owner and President, Jim DuLaney and Company Inc. <<<
Apparently braces and brackets are just too confusing for the average COBOL programmer!
(I await the flames from people still stuck with it)
I'd have thought that the kind of outfit that has the business sense not to replace working COBOL stuff just because it's not hiptrendy would also have the sense to ignore hype relating to "the cloud" etc.
But what do I know. I do know there are plenty of hiptrendy IT managers that will throw away working systems because they aren't hiptrendy, that's what I know. Usually these people also come certified Microsoft dependent.
Yup, not too long back I worked with a consultant building whizz-bang hiptrendy stuff to replace big chunks of and talk to the rest of our Jurassic Zoo. He started out referring to all the existing bits as "Legacy Software".
A couple of years and a shitload of cash burned later he'd got to the stage where if anyone mentioned the L-word he'd respond venomously with: "Round here we call it 'Working Software'."
Sorry to flame el reg. They aren't the one's making this program...
Anyone who's gone through a real Software Engineering course work should be able to easily pick up COBOL. Now the only reason, I'd go back to do something in COBOL would be for the $$$$$$ I could charge for my services. (Yeah, I can be a greedy SOB ;-)
But to say we're extending COBOL to place the masses of C# and .NET developers? C'MON!
Pure marketing hogwash to try and make COBOL relevant.
I was hoping that someone was going to take COBOL code and make it work against Hadoop as a competitor to Hive. Now that would be something to make COBOL relevant again!
(Since I'm not flaming El Reg, I rate this product a FAIL.)
30+ year old software written in an archaic language on old systems... I'd recommend that these companies bite the bullet and do a rewrite. The costs will work themselves out in to savings on decreasing their hardware expense and lower future maintenance costs.
The real reason M/F "try and make COBOL relevant" is so that they themselves can hack next year's model of the full monty (and what an expensive monty it is, all told) using this year's nag. (Tis true, the M/F COBOL compiler has always been written in COBOL).
"I was hoping that someone was going to take COBOL code and make it work against Hadoop"
Ah, if only there were a CLR map/reduce engine. Like, say, Qizmt. Or various projects building .NET frameworks for Hadoop. Or if only Hadoop itself were written in Java, now that COBOL can be compiled to Java bytecode.
In addition, of course, there is a whole industry base around avoiding having to change COBOL code at all. I used to work on a standalone PC based system which took output from a COBOL system and reformatted it to talk to more modern kit. The fact that the original format was not really a good starting point for the required output made the PC software extremely complicated.
The COBOL changes to do the same thing would have been much simpler but nobody would even contemplate that (if its worked perfectly well for forty years you aren't going to change it now).
Ironically the PC code was gradually growing into a bit of a dinosaur itself, and they were starting to struggle to find C coders to maintain it.
and a good example would be rpg on as/400. They regularly replace the innards with faster stuff and have changed architectures more than once, yet the same old software will still work on it.
It's down to the right tool for the job again. Business logic, excruciatingly boring, tends to be rather long-lived, so you pick something suitably long-lived to build it with.
"Visual COBOL R3 converts COBOL's English-like statements – the essence that has made the language so accessible for programmers during the last 50-odd years – into files that the machine understands."
Accessible!? WTF!!
This "essence" is EXACTLY what makes COBOL such a shitty language. There is not a single fricken reason to "talk English" to a computer to instruct it. English did not evolve from man-machine interaction. It is a clunky language at best to use to instruct computers. Which is why COBOL is, was and forever will be, a MASSIVE FAIL. Perform varying my ass...
And yes, I have written enough COBOL in the 80's, even re-entrant COBOL (courtesy of transaction monitors), to back this statement up with real experience.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
