Slashdot Mirror

← Back to Stories (view on slashdot.org)

COBOL Celebrates 50 Years

Posted by CmdrTaco on from the cobol-is-for-old-people dept.

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.'"

8 of 277 comments (clear)

  1. 75% of apps? Shaa, right! by Adeptus_Luminati · · 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

    --
    No trees were killed in the making of this post; however, many trillions of electrons were horribly inconvenienced.
    1. Re:75% of apps? Shaa, right! by baegucb · · 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 :)

    2. Re:75% of apps? Shaa, right! by SanityInAnarchy · · Score: 3, 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".

      --
      Don't thank God, thank a doctor!
  2. People don't "use" COBOL by davidwr · · 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?

    --
    Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
  3. Lack of knowledge by zoomshorts · · 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.

  4. Re:Longevity by Ollabelle · · Score: 2, Interesting

    I can believe it would have taken a long time to write one of those programs. When I was in college back in the late 70's, my first programming class was in Fortran, and one assignment was a simple look-up table to determine how much to charge for a taxi service between different locations using different vehicles. At this time, it was all punch cards, so excluding the start and stop cards, the whole program was about 12 - 15 cards. AFterward, the professor announced that this same program in the COBOL class was a 3-person team effort that generally required 900+ cards; I vowed at that time to never take the class. It was always a sight whenever one of those students would drop their stack of cards all over the computing room floor....

    --
    Ibid.
  5. Re:Not So Bad by Hurricane78 · · Score: 2, 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.

    --
    Any sufficiently advanced intelligence is indistinguishable from stupidity.
  6. Re:COBOL is nice for business processing by BrokenHalo · · Score: 2, Interesting

    So did I. Fortran was (and still is) fun, COBOL was tedious and Burroughs B3700 Assembler should have been even more so if it were not for the fact that it is that much harder to do.

    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.