back to article Undead COBOL celebrates (another) 50th birthday

COBOL is celebrating its 50th birthday. Or at least the name is. In May 1959, during a meeting at the Pentagon in Washington, D.C., the US Department of Defense organized a committee charged with developing a "short range" approach to a common business computing language. And on September 18th of that year, the new Short Range …

COMMENTS

This topic is closed for new posts.
  1. Jonathan McColl

    You can't mean ...

    You gave a tail-end mention to "a Navy officer named Grace Hopper". I suppose your next article on relativity might give passing thought to a post office clerk named Albert Einstein and one on cryptanalysis to a soldier named Alan Turing.

  2. Anonymous Coward
    Thumb Up

    Other reasons for COBOL's longevity

    I did some programming in COBOL back in the 20th century, and I'd say the main reason COBOL is still around is that it is a very simple, limited language that is being used for simple, limited tasks. Even the more recent versions of COBOL lack features -- such as dynamic memory allocation (!) -- that programmers in other languages take for granted. A weak language for simple tasks is just what the business community wants, because it greatly reduces the types of bugs that can arise. Don't want memory leaks? Don't allow the programmer to allocate or deallocate any memory during program execution! Don't want stack pointer problems? Easy: no pointers... and no stack! These omissions make solving difficult problems with COBOL very hard, but they make simple programs all look and work in a similar way, with very few surprises.

    I'm not suggesting anyone go learn COBOL and replace Python, Ruby, PHP, C, LISP, C#, or anything else with it. But if you want to put a stake through the heart of COBOL, you would need to make a very simple, safe, language that could be easily learned by people with limited technical background, instead of the the current generation of more powerful, more expressive, and more esoteric languages.

  3. Anonymous Coward
    Boffin

    Formula translation

    I'm not a fan of Fortran, but it doesn't belong in that list. Fortran is still used extensively for number-crunching applications in engineering.

  4. Michael Hoffmann Silver badge

    FORTRAN "come and gone"?

    Last I spoke to some scientists who worked in the fields or meteorology, astrophysics or elementary particle research (that was about 4 years ago or so), FORTRAN is alive and well and with a massive code base as well.

    Quite possibly for the same reasons: programs, once working tend to just run and run and run.

    As some of the systems using it were deployed in places such as Antarctica where you couldn't just send somebody to press ctrl-alt-del, I can imagine it will never die. It's the unkempt, wild-haired nutty professor twin to COBOL's three-piece-suited accountant persona.

  5. Mr Templedene

    @AC 23:30

    Ever heard of a choke on a car, put simply, when you started your car on a morning you had to set the choke manually to mix more or less air with the petrol, 30 years on and this is done automatically by the car itself.

    To me (programmer, 20 years experience) having to allocate memory to something is exactly the same, it should be a relic of the past.

    The fact a 50 year old programming language lets me not bother with such mundane (but sometimes complex) tasks is amazing, and when you list your more "advanced" languages most of the decent ones do memory allocation automatically as well.

    I do know that in some esoteric tasks it IS essential to have such micro managed control, but to be honest, for 99.999% of computer programming it just is not worth the effort.

  6. Jean-Luc
    Pint

    2045 - Undead Java celebrates 50

    Java - COBOL for the 21st century.

    Similar mind share, for sure, amongst the biz folk as what COBOL has in 1980. No alternatives are acknowledged to the One True Language.

    Mind you, I recently wrote some Cobol and it wasn't that bad. Fun even.

    What floored me is that I was expected to write my own function to pad a string with blanks. No one else, given a rather large library for the framework at hand, had written a common function. Not difficult no, but the total opposite of the "let's design a Customer class which can solve everything for the whole company" approach seen in Java and OO circles (sometimes at the cost of actually solving the immediate problem at hand).

    And, no, there is no valid reason for low level memallocs in your everyday biz app. That's just silly! Java got that right at least.

  7. amanfromMars 1 Silver badge

    R&A! Secrets! in! a! Registered! Post!?.

    "I do know that in some esoteric tasks it IS essential to have such micro managed control, but to be honest, for 99.999% of computer programming it just is not worth the effort." ... By Mr Templedene Posted Saturday 19th September 2009 01:24 GMT

    Mr Templedene [and I shall not play upon thy name as a Temple dean] ..... I would also agree that in some esoteric tasks it IS essential to have such micro managed control, and would go further and suggest/posit that in all esoteric tasks it IS essential to have micro managed control, in order to control 99.999% of all computers programming. The insignificant remainder being always a simple reminder of the need for a constant due diligence to defeat a vain complacency which will render victory to one's phantom enemies and more competent enabling competitor in the Field/Live Operational Virtual Environment for Advanced IntelAIgent Machinery.

  8. Daniel 4

    Re: Java

    To everyone talking about not needing to do memallocs in Java - you, the programmer may not need to, but there is still a hell of a lot of dynamic memory allocation and deallocation going on in Java. This can result in all sorts of headaches when programmers who have no clue of "what goes on under the hood" create and destroy objects at a ferocious rate. I've seen systems brought to their knees by what are really nothing more than the modern day version of poor memory management practices on the part of programmers.

    IMO, no one should be aloud to touch a production Java application until they've spent several years programming in a language where you have to get intimate with the fine details of what's going on. Until then, too much of what happens is voodoo magic, and they are an inherent danger to any project they touch. Of course, after that, by all means switch to Java.

    -d

  9. rtweed

    MUMPS "Come and gone"?

    You'll find that MUMPS is very much alive and kicking too, particularly in healthcare and financial services. In fact not so long ago I seem to remember the Register did an article on the Veteran Administration's VistA EHR which is, guess what: written in MUMPS.

  10. David Harper 1

    Patently obvious

    @Jonathan McColl:

    Einstein was a patent office clerk, not a post office clerk.

    But your point is still well made.

  11. Anonymous Coward
    Anonymous Coward

    @Jean-Luc

    You don't need a function to do that (padding) - it's a standard part of the way COBOL handles variables. You just dynamically allocate a new variable to be your existing variable with spaces added.

    As it's dynamic you only need declare it once at the start of your programme.

  12. This post has been deleted by its author

  13. Anonymous Coward
    Anonymous Coward

    Old Cobol joke statement

    DIVIDE 8 INTO CAKE GIVING SLICES.

    rather than divide cake into 8.

    Oh well.

  14. Graham Marsden
    Boffin

    If it ain't broke...

    ... why change it for something that might break and cost you a load of dosh to fix, simply because it's newer or cooler or flashier?

  15. Winkypop Silver badge
    Thumb Up

    COBOL

    I salute your cody-goodness!!

  16. Admiral Grace Hopper

    It does what it does and does it well

    For a certain class of processing, such as simple transactions on large amounts of data, there's never been anything to touch COBOL which is why it is still with us. for many of the things that computers are used for nowadays it's irrelevant, but for the dull quotidian stuff that makes the world's businesses run then it does the job simply and most of all reliably.

    Am I fan? Go on, guess.

  17. ratfox
    Boffin

    Fortran

    Numerous computations libraries used by engineers have been written in Fortran long ago. They work so well that nobody wants to undertake the massive task of porting them to another language. And even if someone did, the result would likely be less efficient and contain more bugs, so...

  18. Paul Webb

    FORTRAN is alive and well

    in the Astrophysics community. At least it was yesterday...

  19. peter 5 Silver badge

    @Daniel4 Re: Java

    In the late eighties I seem to recall hearing similar arguments about C programmers who hadn't spend several years coding assembler...

  20. copsewood
    Linux

    @ratfox

    No need to port Fortran numerical function libraries to other languages. These functions are routinely called from other languages. You only need to get the Fortran language and toolset out again on the odd occasions when the library or ancient applications needs recompilation, e.g. to another instruction set or library API. Maintaining the toolset in the longer term is easier now that the Fortran compilers still being used for such purposes are written in 'C'.

  21. Anonymous Coward
    Thumb Up

    @ It does what it does and does it well

    "it does the job simply and most of all reliably"

    You forgot to mention "predictably". COBOL, bless her, has few-to-no nasty surprises and gotcha's.

    To everyone who has never worked with COBOL or has failed to understand that simplicity is in fact a virtue, the clue is in the name: COBOL.

    I like to imagine it'll still be here in another 50 years. It works extremely well. But sadly, since when has that been a guarantee of anything lately?

  22. Anonymous Coward
    Anonymous Coward

    @ AA

    "But if you want to put a stake through the heart of COBOL, you would need to make a very simple, safe, language that could be easily learned by people with limited technical background, instead of the the current generation of more powerful, more expressive, and more esoteric languages."

    REXX?

  23. Anonymous Coward
    Anonymous Coward

    cobol a simple language?

    I know nothing of cobol myself, but this (http://home.ccil.org/~cowan/cobol-horrors.html) may be of interest.

  24. Anonymous Coward
    Pint

    @FORTRAN "come and gone"?

    Close - Fortran (even Fortran 77) is still used because for heavy lifting numerical calculations it is fast compared to all of the 'modern' languages.

  25. Beelzeebub
    Flame

    TPF

    What about TPF?

    Yours Crustily

  26. Lars Silver badge
    Happy

    Adjectives

    Adjectives are very difficult words. What is old, Cobol is younger than I am so how could it be old.

    How often should we "invent" a new language. What kind of quality do you expect from programmers who are forced to learn the new and fantastic "language" every three years.

    Is the car old, is fish and chips too old.

    There is a lot of business and politics in every effort to produce a new fantastic language.

    Time to read "There is no silver bullet" for all of us.

    Used lots of different programming languages (including Cobol for years). Well, you use whatever the company you work for uses.

    And the reality is that you can produce shit with any programming language and not.

    Programming is much more the programmer than the language.

    (Eventually all decisions regarding programming languages will be made bye people who do not have any clue about it.)

  27. Ian Bush
    Boffin

    Fortran Dead ?

    Well FORTRAN is dead, it's been Fortran for for almost 2 decades. That said

    1) Virtually all people in my area (HPC) program in Fortran

    2) I teach fortran all around the UK - and it is one of out most popular courses

    I will barely start on the misconceptions that people have about what modern Fortran. Suffice to say that Fortran, post the Forrtan 90 standard which compilers have implemented for well over a decade, has little to do with the language that the prejudiced refer to,

    Ian

  28. jake Silver badge

    @Mr Templedene &@amfM

    Mr Templedene scrive:"

    Ever heard of a choke on a car, put simply, when you started your car on a morning you had to set the choke manually to mix more or less air with the petrol, 30 years on and this is done automatically by the car itself.

    "To me (programmer, 20 years experience) having to allocate memory to something is exactly the same, it should be a relic of the past."

    To me, a car & computer guy, it helps to understand what's going on under the hood. It makes no difference to me if I have to set the choke in my '63 Ford Falcon manually, or if I allow the computers to set the air/fuel ratio in my '99 BMW M Coupe ... What DOES matter to me is that I know how the entire system works, so I can fix it when it breaks.

    Folks who don't know how or why to "set the choke" on a computer aren't qualified to figure out how to fix it when it breaks. They don't know how the complete system works.

    amfM: Stop trolling, already ... you're too smart for that ;-)

  29. Greg J Preece

    Happy Birthday COBOL!

    One of a newer generation of COBOL coders salutes you!

    But then, I just love learning stuff like that. Nearly bought a book on Ada yesterday. ;-)

  30. Herby

    Yes, Fortran is still alive and well

    Having done Fortran programming since the "Fortran II days" I can attest that it is alive and well. My last position had it well ingrained in the functionality they were using, and while I did leave a year ago, they had more Fortran lines than could be converted so they must still be using it. Yes, it was mostly Fortran 90, but the code base dated back to the Fortran 66 (Fortran 4) days.

    As for Chokes on automobiles, what was usually required was a couple of pumps of the gas pedal before engaging the starter. That was the "automatic" part of it. On VW's if you took out the "automatic choke" (which usually didn't work anyway) the engine ran a few RPM faster, which on a 1200cc (later 1400cc) engine helped!

    Look in a few years, we will celebrate Fortran's 60th!

  31. amanfromMars 1 Silver badge
    Coat

    Horses for Courses

    "Folks who don't know how or why to "set the choke" on a computer aren't qualified to figure out how to fix it when it breaks. They don't know how the complete system works.

    amfM: Stop trolling, already ... you're too smart for that ;-)" ..... By jake Posted Sunday 20th September 2009 05:58 GMT

    jake,

    Whenever you know how the complete system works, you spend all of your time/as much of your time as you would care to choose, Big Game Phishing. ........ Hunting for SMARTer Animals ..... with IntelAIgent XSSXPlosive dDevices which are a QuITe Perfect for Invisible Export to any Post Modern Model Army into Progress with ITs Higher Levels Of Confusion.

    "@amanfromMars 1: sorry to see you are still a net addict. Aint there any soccer clubs in your location ? Maybe they can help you back into reality ? Or the British Army ? (Maybe they need a Confuser General or something to this effect)" ... By Frank Gerlach Posted Saturday 19th September 2009 08:26 GMT

    :-) Which/Whose reality would that be then, Frank. And as for soccer .... is that not virtual opium for zonked out, practically brain dead masses. A childish game turned into a money spinner. Nice "work" if you can get it though but it aint really kosher, is it, with so many day-dreaming of its easy riches for sleazy bitches? On a scale of 1 to 10 of what is important in Life, would it even register. And yes, I would agree that the British Military needs a Confuser General or something to that effect, especially as they will up against and expected to combat Virtual Forces in Fleet of Mind Phormations/ESPecial Theatre Operations.

    It may surprise you to discover that they have been Carefully and Transparently led to that Particular and Peculiar Trough of NEUKlearer Water to Drink, and it would inappropriate today for me to say anything more on the matter....... other than SMART and Thirsty Beasts Drink to Survive and Play Revitalised as Leading Peers in Common Herds/Stallions in Deep Cover Duties.......... and that is an Addictive Satisfying Pleasure for anyone into Nets and Networks InterNetworking Special Applications of ProgramMING.

    Is all of that above, a troll, .... http://en.wikipedia.org/wiki/Troll_%28Internet%29 .... or just a number of different realities uncovered?

  32. James Melody
    IT Angle

    Lords of COBOL

    The Lords of COBOL don't exist and there is only one true god.

    But enought about Battlestar Galactica - what is the IT angle on all of this?

  33. ShaggyDoggy

    Any language

    I always say ... a good Cobol programmer can write Cobol in any language

  34. Ken Hagan Gold badge

    Why Fortran survives

    The memory management in older versions of Fortran is rather limited, and the memory model and aliasing rules are similarly low-tech. This causes relatively few problems for programmers in the domains where Fortran is strong (though I wouldn't want to write GUI software in F77) but allows compilers to optimise the code to within a gnat's whisker of perfection.

    For comparison, C (and C++) spent about a decade (the 90s, since you ask, starting with the "noalias" proposal that was (perhaps apocryphally) blown out of the C89 standard by Dennis Ritchie saying "either it goes or I do") trying to make it possible to write similarly optimisable code within a language that historically had allowed far more latitude and made life far harder for compilers. I believe it is now possible to write C code that optimises as well as Fortran in the numerical domain, but it requires a rather deeper understanding of the language, so there is still a barrier for serious number crunchers thinking of migrating.

    In short, Fortran survives because in the last fifty years no-one has come up with a decent alternative. Much the same can be said of C, C++ and Cobol. Probably not for Java or VB or C#, mind, so we can look forward to these languages going the way of Pascal.

  35. K.S. Bhaskar

    Rumors of MUMPS' demise are exaggerated

    As noted in a previous comment, MUMPS is very much alive as the language in which the highly regarded and increasingly widely used VistA application is programmed. Furthermore, MUMPS is also the mainstay of many high end health care applications. The reason it is not as visible is that it is a back-end workhorse, and accessed via other front end technologies - such as Javascript.

    There is an active news group - comp.lang.mumps - and GT.M (http://fis-gtm.com), which I manage, is a FOSS implementation of MUMPS on Linux that has been downloaded thousands of times from Source Forge.

  36. Anonymous Coward
    Anonymous Coward

    What's odd, really...

    ...is that so many people (including far too many journalists) seem to think that anything "old" needs to be got rid of and replaced by something new and shiny. The English language, while it is continually evolving, is at least 500 years old in its present from. So, using Cade Metz's logic, why don't we replace it with an entirely new language that's harder to use?

    We should treasure and appreciate simple solutions to well-known problems. They free us up to tackle new and more difficult problems.

  37. Anonymous Coward
    Headmaster

    Smalltalk and Fortran certainly haven't gone

    My company's product is written in a mixture of Smalltalk, C++ and Fortran, the bulk of which is Smalltalk. So, I can assure you that Smalltalk and Fortran most certainly have not 'gone'.

  38. Steve Carr 1
    FAIL

    FORTRAN

    I recall working on some FORTRAN code many years ago, that was designed to compute the correct/safe dose of radiation to be used when irradiating a patient tumor. For a language that is still in use, it certainly was far from ideal for use in such a critical application. These days we seem to take for granted that calculations will be 32 or 64-bit, but back in the day, different manufacturers and different memory architectures abounded, and these routines were ported from architecture to architecture with seeming gay abandon. As a result, the code I was faced with had HUGE known errors in its calculations, almost all down to precision errors caused by the changes in arithmetic precision.

  39. Jonathan McColl

    @David Harper 1

    Post office/Patent office: either I have a stupid keyboard or stupid fingers. I knew 'Patent' [Muphry's Law again]. Thank you for your comment!

  40. Anonymous Coward
    Thumb Down

    COBOL update coming soon

    See coboloncogs.org

  41. amanfromMars 1 Silver badge

    Heavenly CodeXSSXXXX for PerlyGatesPython Fans into AI = NEUKlearer HyperRadioProActive IT*

    "And the reality is that you can produce shit with any programming language and not.

    Programming is much more the programmer than the language.

    (Eventually all decisions regarding programming languages will be made bye people who do not have any clue about it.)" ...... By Lars Posted Saturday 19th September 2009 19:42 GMT

    Two out of three aint bad, Lars. I disagree with the final eventuality and would posit the exact opposite.

    The best program languages are those which are human machine readable and autorun with the supply of future source. Sticking a name upon them is fashionable and a novel way of reinventing the wheel to provide security for supply. And some names are chosen to both inform and confuse analysis in equal measure and are as a signature of both past experience and future intent, with the latter always being the only really important feature in such virtual fields, as would be providing instructions to computering machines and Content Management Systems.

    * Which could be a deliberate misdirect for misunderestimation but perfectly true too.

  42. Anonymous Coward
    Go

    We'd have gotten rid of COCOL long ago, except...

    ...except that the hardware has become so much faster that we don't need our software in a shiny new language.

    Our mainframe could probably run BASIC and nobody would notice any performance issues...

  43. John Smith 19 Gold badge
    Coat

    Read a book on CICS once

    Took we half way through to realise what it was for.

    COBOL could not handle interactive input and output.

    It's a terrible truth but COBOL predates such cleverness.

    However the latest standard (COBOL 90?) is considerably better.

    yes you can guess what was in my pocket.

  44. A J Stiles
    Coat

    @ AC 11:04

    It's the right way round. "Divide into" and "divide by" are opposite actions, not synonyms. So you might legitimately

    DIVIDE 2 INTO DIAMETER GIVING RADIUS

    If you remember doing long division in school, you'll understand. Suppose you were dividing 203 by 7 ..... 7s into 2 don't go, 7s into 20 go 2 remainder 6, 7s into 63 go 9, no more digits, answer is 29. You're dividing 7 *into* 203.

    Mine's the one with the crude chalk drawing on the back.

  45. Matt Bryant Silver badge
    Happy

    And the other "old fogey" in the article?

    Slightly off topic maybe, but consider the list of "six big-name computer manufacturers" mentioned as the fathers of COBOL - Burroughs Corp., IBM, Minneapolis-Honeywell, RCA, Sperry Rand, Sylvania Electric Products - and which name is the only modern giant that stands out? Ol' International Business Machines Corp again! I'm sure part of COBOL's survival is also down to the success and longevity of IBM's mainframe range.

  46. David Shields
    FAIL

    The problem is ...

    ...that all COBOL's seem to have been eaten by MicroFocus. They certainly ate Ryan McFarland and seem to have swallowed acuCOBOL.

    Now, I may be wrong now (as I haven't looked at MF for a year or two) but MF's COBOL offerings are *bloody* expensive. I was looking at about 5 grand for a development environment just so I could attempt to keep a company going that had some legacy COBOL from the 80's. For a small company, this was simply not achievable.

    As an ex COBOL codegrinder in the 80's I'd love to be heroically recompensed for my obsolete skills, but COBOL offerings in the north are few and far between.

    Gizza job anyone ?

  47. Pedantic Twat
    Coat

    amanfrommars (1?)

    aardvark hatstand biscuit-barrel

  48. Anonymous Coward
    Anonymous Coward

    Possible extensions

    We had a COBOL course when I was a student (to make the degree meet BCS requirements, I think). The geek set sat at the back, not heckling, but inventing extensions such as "GOTO A VIA B" which would execute one statement at B before jumping to A; switching run-time checking on and off with PROCEED CAUTIOUSLY and PROCEED CONFIDENTLY, Roman numeral formats (actually Common Lisp has those!) and various other things we felt would fit.

  49. Steve X

    @Tom Welsh

    "...so many people (including far too many journalists) seem to think that anything "old" needs to be got rid of and replaced by something new and shiny."

    And in general, after 5 years or so of "development" the new replacement looks just like the old stuff it replaced, except that it is twice the size and half as fast.

  50. regadpellagru
    WTF?

    @George Schultz

    "Close - Fortran (even Fortran 77) is still used because for heavy lifting numerical calculations it is fast compared to all of the 'modern' languages."

    I'm amazed this myth is still alive 10 years after I left the supercomputing area ...

    I suppose myth just mean that: a lie that can live for decades or centuries :-)

    F77 was only known to be faster in the very early 90s, when Cray only started an optimised C compiler for their systems. Ever since, on open source platforms, Fortran and C have the same backend so the code is the same. There is 0 reason in the languages themselves why one would produce more optimised code than the other. At all.

    No, Fortran 77 is a retarded language, with no syntax to speak of, and no dynamic memory allocation, only still present because many programs are still here and no one has the time/money/energy to rewrite them, and also because a number of IT people can't learn !

    http://catless.ncl.ac.uk/Risks/5.66.html

  51. Anonymous Coward
    Joke

    Patent Office vs. Post Office.

    There's a difference?

  52. Anonymous Coward
    Coat

    Another COBOL joke

    always have a paragraph in your program called ING-SEAL,

    That way your program will have a PERFORM ING-SEAL

  53. Stevie

    Bah!

    How sad that this is still being debated. Cobol does its job and does it well. The popular old-saw criticisms of the language do not withstand study by people who actually know how to write the stuff and are easily avoided in practice. Not to mention, you know, the "billion lines" of code still in use etc etc...

    Most of the problem is that people are so busy trying to debunk the language from the experience they had writing one report in it as coursework in college that they fail to engage their brains to ask the question "why, then, is it so widely adopted and still going strong?" or if they do, they spit back the old Linux-v-windows answer - because peepul is to stoopid to do the right thing.

    The Wikipedia article on Cobol has at times been riddled with the most ridiculous nonsense, of which I think "it can't do accurate math" (along with example code containing the Cobol-101 Howler that "proved" the point) was perhaps the funniest.

    As for the examples of what you *could* do with the language (AC 09:56 et al), such things were not used by anyone wanting to keep their job, since ALTER, VIA and all those no-memory, card-to-card era innovations (so that compact monolithic code could be written that would run in 256-or-thereabouts words of memory) were declared obsolete and dangerous once resources were available to allow people to do the same job in a straightforward manner. It's illuminating to compare such constructs with what is considered clever in perl circles today though.

    I wouldn't mind, but there was the most awful kerfuffle recently when it was uncovered that the clever sods that persuaded certain financial institutions to toss their Cobol stuff in favour of more modern (aka "better") alternatives had not understood the code they were tossing out and had re-written basic currency calculations as floating point operations (rather than decimal-scaled integer, which can be found in every version of Cobol under the data type "Computational"). No-one is sure how much money was lost as a result of this "improvement". What a shame that so much focus was on the language used that none was spared for understanding the task at hand. What a shame no-one considered that Cobol factors that sort of oversight into the language by having an intrinsic datatype for doing the job. It also handles records (C calls 'em structures) better all-round than any other language I'm familiar with. Oh well.

    An acquaintance put it best: "Cobol is an excellent DP language. C [and C-type languages] is an excellent IT language".

    Thanks Dan. You put your finger right on the key issue.

  54. vincent himpe
    Coat

    naaah

    Who needs high level languages... Just key hex straight into ROM. Any programmer not knowing the opcodes of the machine he is writing for is not worth his salt...

    As for me:

    MOV @ME, COAT

    SJMP #DOOR

This topic is closed for new posts.