COBOL Celebrates 50 Years 277
oranghutan writes "The language used to power most of the world's ATMs, COBOL, is turning 50. It also runs about 75 per cent of the world's business applications, so COBOL should be celebrated for making it to half a century. In cricketing terms, that's a good knock. The author says: 'COBOL's fate was decided during a meeting of the Short Range Committee, the organization responsible for submitting the first version of the language in 1959. The meeting was convened after a meeting at the Pentagon first laid down the guidelines for the language. Half a century later, Micro Focus published research which showed people still use COBOL at least 10 times throughout the course of an average working day in Australia. Only 18 per cent of those surveyed, however, had ever actually heard of COBOL.'"
75% of apps? Shaa, right! (Score:4, Interesting)
"It also runs about 75 per cent of the world's business applications"
Gee, I didn't know Windows Apps were coded in COBOL.
Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%.
Adeptus
People don't "use" COBOL (Score:3, Interesting)
People "use" applications and embedded systems.
It would be more accurate to say people use applications written in the language several times a day.
I wonder how many times people use applications written in C or languages common to embedded systems? What languages, for example, are used to create the code that makes their automobiles, home entertainment centers, voicemail, etc. work?
How many times a day do people use applications that rely other languages that predate the moon landing?
Lack of knowledge (Score:4, Interesting)
Most businesses did not see any need to port mainframe stuff to WinDoze.
COBOL is solid. WinDoze is flakey. RM COBOL extended COBOL to modern
programmers. If it isn't broke, you don't 'fix' it.
Get a grip, and learn. I suggest going back to school. Just my opinion
though.
"Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence? Where I work, we have nearly 200 business apps and I'm pretty sure less than 2% of business apps were made in COBOL - possibly even 0%."
I suggest YOU go to work for any major business and work on their accounting software. Highly dubious? Hardly. Your business 'Apps' are probably front ends for a real language on a mainframe.
Visual this or that.
Re:Longevity (Score:3, Interesting)
Re:Not So Bad (Score:3, Interesting)
I disagree with the assumption that it's "just as easy". In some languages, it's definitely easier to write bad code. PHP is such an example. C/C++ is another one. In PHP it comes with the retardedness of the language. In C/C++ it comes with the freedom.
A good example for a language that has certain things in place to prevent bad coding, is Haskell. Type problems in running code are (except for the external input reader) simply impossible.
Re:COBOL is nice for business processing (Score:2, Interesting)
It is trendy to disparage COBOL, but it was and is a very reliable and effective language for dealing with business transactions. The only times it tended to break were when the data input contained funky characters which would precipitate a "subscript out of range" error. I found the best way to prevent that was to disable the keypunch-ops' "CTRL" keys.
Re:75% of apps? Shaa, right! (Score:3, Interesting)
Where I work we benchmarked database performance on existing servers vs. a Linux partition on the mainframe. Performance was 5 times faster on the mainframe. Massively parallel high speed IO made the mainframe faster So now we are converting stuff over to the mainframe. And if we want near 100% uptime, it's done on the mainframe, so the most important web sites run on the mainframe.
I do agree with your comment though about the 70% of transactions.
As a side note, COBOL is an easy language, but others are more fun to code in. I always liked assembler best :)
Re:75% of apps? Shaa, right! (Score:4, Interesting)
After several years of development, it still crashed frequently on large projects, due to the JVM running out of memory.
So, JVM memory leak, or application memory leak?
Regardless, I have yet to see a compelling argument to rewrite COBOL code in Java or any other 'modern' language. If the COBOL works, and will continue to in the near future, what is the benefit of a lengthy rewrite?
Maintainability.
The question is, does the COBOL do everything you need it to do? How much does it cost (in terms of time, money, manpower) to make a change you need to make? Add up that cost, estimate it over time, compare to the cost of a rewrite and how maintainable it would be after said rewrite.
Granted, sometimes, there's not going to be a lot of justification. But when a change wages requires six months of work, it's worth seriously considering how long a rewrite would take. Six months for what should be a ten minute change (generously), no matter what the language, demands a rewrite.
It's also something that has to be thought about carefully, because it may not be immediately apparent what such flexibility could buy you.
Some bad analogies: If I did my accounting with a paper ledger, computerizing the process would probably make no sense to me -- until you realize that once it's in the computer, it can automatically do much of the math, eliminating errors, or making them much easier to fix. Similarly, if I became a fluent C/C++ programmer (especially C++), it might not be immediately obvious to me how useful garbage collection is -- but there's a whole class of bugs that just disappear when you use a garbage-collected language. If you've only ever worked with punch cards, or with a slowly-compiled language, it may not be immediately obvious how useful an interactive command prompt (read-eval-print-loop, to use the LISP terminology) can be.
So it's worth considering, just pulling something out of my ass: If it only took a few minutes to author a report, what kinds of reports could you have? How specialized would they get?
Perhaps some modern language might be a best fit for a newly written program, but I'm still not convinced. While I can't say for certain that COBOL will compile to be any faster than the equivalent Java, my experience with high-level languages tells me that they tend to create bloated executables.
Bloated by what metric?
Especially, you mentioned "bloated executables" -- if /usr/bin/myapp is ten megs instead of a few hundred kilobytes, seriously, how much does ten megs of disk/RAM cost? And how much does a team of qualified COBOL programmers cost, how much of a direct cost is there due to COBOL taking longer to implement, and how much of an indirect cost due to whole classes of bugs that simply don't show up in another language?
And, when you add it all up, if your app is the kind that would work well on a cluster, how much more are you paying for your mainframe than it would cost to build the equivalent cluster out of PC hardware? Suppose you could triple the hardware and still save money -- thus a language that's three times as slow ultimately costs exactly as much as COBOL, performance-wise.
So, tl;dr on that one: The Big Picture is much more complicated than whether your executable is "bloated".