Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

COBOL Celebrates 50 Years

CmdrTaco posted more than 5 years ago | from the cobol-is-for-old-people dept.

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

cancel ×

277 comments

Sorry! There are no comments related to the filter you selected.

COBOL is nice for business processing (1)

zoomshorts (137587) | more than 5 years ago | (#29489959)

I used to program in FORTRAN and COBOL. Now I just visit video chat sites :P

A good knock in deed.. (5, Funny)

bsDaemon (87307) | more than 5 years ago | (#29489973)

Though, to be fair, 50 years isn't quite as long as the average cricket game.

75% of apps? Shaa, right! (4, Interesting)

Adeptus_Luminati (634274) | more than 5 years ago | (#29489987)

"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

Re:75% of apps? Shaa, right! (4, Informative)

duffbeer703 (177751) | more than 5 years ago | (#29490053)

Do you accept or make payment via credit card, check or ATM debit? Congratulations, you (indirectly) use COBOL.

Re:75% of apps? Shaa, right! (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#29490283)

Can we get rid of it? Surely COBOL has developed faults over time, just like a train that's been running since 1850 would have.

Re:75% of apps? Shaa, right! (4, Insightful)

PhunkySchtuff (208108) | more than 5 years ago | (#29490343)

Can we get rid of it? Surely COBOL has developed faults over time, just like a train that's been running since 1850 would have.

Or, just maybe, it's proven itself to be stable, reliable, well-understood, suited to the purpose for which it's used and relatively bug free?

Nah, of course not. It's old and busted. Bring on the new hotness.

Re:75% of apps? Shaa, right! (1)

SanityInAnarchy (655584) | more than 5 years ago | (#29490689)

Stable, reliable, well-understood, and bug-free are true of many more recent languages.

I dispute that it's the best suited to the purpose for which it's used. Show me a construct in COBOL that wouldn't be much easier in something modern -- even Java, if we have to.

Re:75% of apps? Shaa, right! (5, Insightful)

MasterOfMagic (151058) | more than 5 years ago | (#29491167)

Stable, reliable, well-understood, and bug-free are true of many more recent languages.

<sarcasm>I didn't know that more modern languages had a 50 year history of reliability, scalability, and security to process transactions 24/7. Live and learn I guess...</sarcasm>

Further, the cost of developing, debugging, and testing the replacement in any language (including redeveloping the system from the ground up in COBOL) is quite expensive, no matter what language you choose. Likely more expensive than the big iron and software environments necessary to run the old code that has worked reliably for the last 20 to 40 years.

Re:75% of apps? Shaa, right! (0)

Anonymous Coward | more than 5 years ago | (#29491311)

Dont forget that switching to a newer language often means new hardware. For better or worse, an old, stable language will win out due to lock-in, until the entire system can be overhauled at once at a great expense.

Where is the benefit of moving to 'new hotness' when the old way of working it works fine enough?

Re:75% of apps? Shaa, right! (5, Insightful)

Bakkster (1529253) | more than 5 years ago | (#29491329)

Stable, reliable, well-understood, and bug-free are true of many more recent languages.

Yup, JAVA never crashes, C# is easily understood, C++ is free of bloat, and interpreted languages run faster. /s

I dispute that it's the best suited to the purpose for which it's used. Show me a construct in COBOL that wouldn't be much easier in something modern -- even Java, if we have to.

COBOL isn't used because it's easier to write than your JAVA or other new language. It's used because it was designed with business transactions in mind and is reliable. If you have to give up reliability or predictability to gain readability or 'modern-ness' (as has often been my experience with JAVA), it's not a good fit for businesses who can hire additional programmers to produce reliable code.

Regardless, if COBOL works well for the application already, then some modern language would have to one hell of a lot better to rewrite these applications for the incremental improvement to be worth the cost and risk involved with a complete rewrite.

Re:75% of apps? Shaa, right! (2, Informative)

Hurricane78 (562437) | more than 5 years ago | (#29490909)

GP uses the old "virtuality is reality" fallacy*. COBOL is not like a train, because it is not exposed to nature/physics. There is no natural disintegration in virtual things. It can lie there for a trillion years, and if the hardware is kept running and backups and error-correction are in place, it will not degrade in a single bit.

Also "surely" is no base for any arguments to put on top of it. :)

___
* The same one that media distribution companies use, to act as if the software on that media would be a real product instead of the result of a service.

Re:75% of apps? Shaa, right! (1)

Anonymous Coward | more than 5 years ago | (#29490833)

Do you think some of the bits will have worn out or something?

Re:75% of apps? Shaa, right! (-1)

Anonymous Coward | more than 5 years ago | (#29490315)

[citation needed]

Re:75% of apps? Shaa, right! (0)

Anonymous Coward | more than 5 years ago | (#29490525)

NOPE SORRY. I work at the Fed.

Maybe a few years ago but ALL of the check processing, Check 21, Treasury, etc at the Fed as moved to Unix based systems. Everything else in in the process of being moved of the mainframe. I would gu

Re:75% of apps? Shaa, right! (1)

Anonymous Coward | more than 5 years ago | (#29490775)

If you worked at the Fed, you would know that none of the things you mentioned are handled by the Fed.

Re:75% of apps? Shaa, right! (1)

Chrisq (894406) | more than 5 years ago | (#29491673)

If you worked at the Fed, you would know that none of the things you mentioned are handled by the Fed.

I think he means fully educated dropout. Been to college, knows it all, can't hack a real job but will try to impress people on /. by saying he works for the Fed.

Re:75% of apps? Shaa, right! (-1, Troll)

gavron (1300111) | more than 5 years ago | (#29491041)

No. You don't. Next bogus non-citation, please?

Re:75% of apps? Shaa, right! (0)

Anonymous Coward | more than 5 years ago | (#29491269)

Even if some of this is partly true it certainly does not equal 75% of the world's business apps. I spent many years writing business apps for a major investment firm and we NEVER used cobol (or even heard it mentioned).

Re:75% of apps? Shaa, right! (4, Informative)

Archtech (159117) | more than 5 years ago | (#29490061)

"It also runs about 75 per cent of the world's business applications"

Gee, I didn't know Windows Apps were coded in COBOL.

They can be, using the excellent Microfocus COBOL or many other implementations.

But actually, only a very few of the world's (important) business applications run on Windows. Seriously. Big heavy-duty transaction-processing apps run overwhelmingly on mainframes, because they just work.

Re:75% of apps? Shaa, right! (3, Insightful)

drinkypoo (153816) | more than 5 years ago | (#29490361)

I think what we're arguing over here is the application of the English language. As the sentence is written, it is probably incorrect. Due to logarithmic growth, it is virtually impossible that the numbers come out right. If one said that 70% of business transactions were facilitated through COBOL at least in part then it might be true, because of all the legacy code still doing its job out there at banks and other financial institutions.

Mainframes are breathing their last gasp; they will soon exist only in cases where you need very fast access to all of very large data sets. And honestly, clustering filesystems and databases are solving that problem too. Clusters will rule nearly every aspect of large computing because they are the only thing more reliable than a mainframe.

Re:75% of apps? Shaa, right! (5, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#29490863)

they will soon exist only in cases where you need very fast access to all of very large data sets.

Which is quite often.

And honestly, clustering filesystems and databases are solving that problem too.

Except that clustering filesystems almost always have to compromise on one of the ACID properties. For example, Amazon's Dynamo and CouchDB are highly available, redundant, and fast, but allow conflicts, assuming the application will correct for them. Ok, but that fails for a banking application -- if I were to withdraw my entire balance from two different nodes simultaneously, I'd have a massive overdraft, but I'd also have the money.

You could imagine trying to shard it instead, but what happens when you transfer money between two shards? You still need a transaction, only now it needs to be synchronized between two nodes. What do you do? Do you lock both nodes at once? Now you've got a possibility of deadlocks.

Clusters will rule nearly every aspect of large computing because they are the only thing more reliable than a mainframe.

Reliability can be defined in several ways. Clusters are more available than a mainframe -- if your mainframe goes down, you're down. But clusters are less consistent than a mainframe, unless you're willing to take such massive hits from synchronization that the performance advantage is gone.

For the vast majority of applications, some inconsistency is acceptable. Take Amazon's example -- if you tell one node to add item A to your cart, and another node to add item B, producing two conflicting versions of your cart, the cart application should be smart enough to merge them. The only synchronization needed is checkout, and here, all you'd need to do is refer to a specific version of that record in the form that's submitted.

But for applications which can't tolerate that inconsistency, unless there's some clustering method I'm unaware of, you're still going to want something like a mainframe.

Re:75% of apps? Shaa, right! (1)

TheSunborn (68004) | more than 5 years ago | (#29491021)

Mainframes are breathing their last gasp; they will soon exist only in cases where you need very fast access to all of very large data sets.

Why would you need a mainframe just for that? A fully upgraded SGI Altix 4700 will be faster then IBM's fastest mainframe and I also think that HP's superdrome is up there in performance.

Re:75% of apps? Shaa, right! (4, Insightful)

MBGMorden (803437) | more than 5 years ago | (#29490391)

I have to agree. We recently switched parts of our tax billing software from an old COBOL system running on an AS400 to Windows. There were some legitimate concerns involved - creating a graphical sketch wasn't possible on a text-mode system, and tax laws change very frequently, and the old system was just becoming difficult to maintain.

So, we switched to a Windows app with a SQL Server backend. FWIW the database backend has been rock-solid, but the actual client? It's junk. That old clunky COBOL system might have been awkward to use and a bit long in the tooth, but it NEVER crashed, and its mistakes were minimal to say the least. This new Windows system crashes constantly (including crashing if you work too fast - yeah I literally have to do a "one one-thousand" count when switching between properties or the client will lock up), and it goofs up the data frequently enough that in another 5 years I think our data will be reduced to an unreliable mess.

Truthfully though, it's not the fault of Windows, or whatever language the newer apps are written in (Visual Basic in the case of our new pile o' junk). You can certainly write good stuff in new languages on new systems. I think it's a two-fold problem. One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone), but also, programmers today look at problems differently. They program for "features" first so they can give a good sales presentation. In the old days it seems like a reduced feature set was fine so long as your code was done right. That's not the case anymore, which is a shames, because on most of our newer systems we use MAYBE 20% of of the features included, and I'd gladly trade the other 80% for stability and accuracy.

Re:75% of apps? Shaa, right! (3, Insightful)

sgbett (739519) | more than 5 years ago | (#29490499)

I don't think its the languages that are getting worse...

Re:75% of apps? Shaa, right! (1)

MBGMorden (803437) | more than 5 years ago | (#29490583)

Admit it - you skipped the last paragraph didn't you . . . ;)

Re:75% of apps? Shaa, right! (1)

sgbett (739519) | more than 5 years ago | (#29490619)

I guess that confirms me as one of those 'new' coders. *embarassed*

Re:75% of apps? Shaa, right! (2, Insightful)

SanityInAnarchy (655584) | more than 5 years ago | (#29490927)

One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone),

I doubt this is much of an issue. GUIs can certainly be abstracted to the point where it's not an issue.

programmers today look at problems differently.

Well, some programmers. (Hire me!)

I do agree, but recent programmers certainly don't have a monopoly on WTFs. I think you've got something of the success effect here -- that is, your old COBOL system was necessarily reliable, because if it wasn't, it wouldn't have lasted this long. So the old COBOL apps that are still in production are likely at least somewhat reliable.

But reliable and maintainable are different things. I'd argue rewriting them just to make them more maintainable -- carefully, of course, so they're reliable, but you also want to be able to open them up twenty years from now and make a minor change without pulling your hair out.

Re:75% of apps? Shaa, right! (1)

ubersoldat2k7 (1557119) | more than 5 years ago | (#29491163)

that is, your old COBOL system was necessarily reliable, because if it wasn't, it wouldn't have lasted this long.

Totally agree, I would like to check on the first year of that COBOL app running and see if it didn't bring down a whole mainframe to its knees. I believe that it isn't a feature of COBOL to be stable, secure or fast. It's just that those apps running in COBOL have 20+ years of maintenance put into them to make them work as they should. So even your VB app (ugh!) with 20+ years of patches and coding should run nicely, some day... give it 30 years xD

Re:75% of apps? Shaa, right! (0)

Anonymous Coward | more than 5 years ago | (#29491629)

One, the complexities of a GUI makes codes many times more intricate, making the job more difficult (and more error prone),

I doubt this is much of an issue. GUIs can certainly be abstracted to the point where it's not an issue.

Which perfectly fits the description "making the job more difficult".

Re:75% of apps? Shaa, right! (1)

wisty (1335733) | more than 5 years ago | (#29491119)

Agile programming focus on a reduced feature set that is actually tested.

I would guess there were lots of programs written 30 years ago that were crap, but you can bet that they didn't last. COBOL programs are only survivors because they got them right the first time.

Re:75% of apps? Shaa, right! (1)

defaria (741527) | more than 5 years ago | (#29491361)

Face facts. You simply bought a crappy software package. Why didn't you write it yourself so that it would perform exactly as you require? There is no excuse for any software that crashes - those are bugs. Having to work slowly or it'll break is just ludicrous. You got ripped off. Either purchase better software or write it yourself.

My 20% isn't someone else's 20% (1)

tepples (727027) | more than 5 years ago | (#29491391)

creating a graphical sketch wasn't possible on a text-mode system

Unless the text-mode system can output an SVG document for a graphical client to display.

on most of our newer systems we use MAYBE 20% of of the features included, and I'd gladly trade the other 80% for stability and accuracy.

All clients use the same basic 10% of the features, but they have a different other 10% that they use. Once software became off-the-shelf rather than bespoke, software publishers started to try to include every client's other 10% in the same product.

Re:75% of apps? Shaa, right! (1, Insightful)

Anonymous Coward | more than 5 years ago | (#29490119)

Oh God, you're one of those. Look junior, contrary to popular opinion, the majority of computers in the world does not run Windows. PCs are a minority.

Re:75% of apps? Shaa, right! (3, Funny)

Fred_A (10934) | more than 5 years ago | (#29490167)

Come on, 75% is a HIGHLY dubious claim. Where's the source / proof / evidence?

Actually if just Solitaire was coded in COBOL it would seriously skew the statistics already, numerous people would spend hours poking at a COBOL app each day.

Re:75% of apps? Shaa, right! (4, Insightful)

Old97 (1341297) | more than 5 years ago | (#29490171)

The wording is misleading. Perhaps it's more accurate to say that 75% of business computing by value depends on COBOL. I've worked at a number of places in the financial services industry and have a lot of friends who do as well. All of our core business functions are still in COBOL. A lot of the data is still in VSAM, IMS and Model 204 legacy stores. A lot of what is in DB2, an RDBMS, is VSAM files converted directly to tables instead of truly relational databases.

The fun stuff (Java, .NET, Web) runs the outward facing services and peripheral functions, but claims processing, credit card reconciliation, billing, accounting, etc. is still in COBOL. The computer industry press spends a lot of time admiring the new chrome and fins and that new built-in radio with FM, but business is still powered by the COBOL drive train running on mainframes.

Even the clued in managers want to get off of it and onto more flexible systems and more productive languages, but it's too scary (risky) because they are afraid to break something. No one knows what the business rules are because they are embedded hither and yon in COBOL programs.

Re:75% of apps? Shaa, right! (1)

yttrstein (891553) | more than 5 years ago | (#29490393)

Another big reason that people don't want to get off COBOL is because it's what the US Govt. is locked into for things like tax updates and computations. Anyone who's had the horrid experience of setting up or running a PeopleSoft Financial's installation knows all too painfully well about government tax updates and the COBOL they require.

Not that the COBOL itself was terrible to deal with. IMHO, it's an elegant, powerful language that doesn't get anywhere near the credit or respect it deserves.

Re:75% of apps? Shaa, right! (1)

Hurricane78 (562437) | more than 5 years ago | (#29491097)

And why would you change it? After all: Never change a working system.

You would not go an change anything foundational, if there isn't a reason to do so. What would the reason be in this case?
Maintainability does not really become harder for the same piece of code. Except if you constantly change things. Only the maintainers become more rare. But there is no reason they have to.

Hmm... what about the following solution: Stop changing *anything* in the basic COBOL code. If you change something, do the transformations on a thin layer that you wrap around it. And everything external then only communicates with that layer. Do this, until perhaps some time in the future, when every rule was changed at least once, no usage of the inner COBOL core remains.
You could even add another layer, if the new layer does become too old to change too.
Oh, besides: The decision if the old layer is too old, should be defined as the moment, where the cost and risk of maintaining that old layer becomes higher, than the cost and risk of introducing errors in the new layer. (Which for the above solution is theoretically zero, because you only add new things that would have to change anyway, and never re-implement any well working parts.)

Re:75% of apps? Shaa, right! (1)

JerryQ (923802) | more than 5 years ago | (#29491369)

And in shock news today, a significant proportion of Manhattan traffic crosses the 118 year old Brooklyn Bridge each day, rumours, as yet unconfirmed, suggest it even uses (shhhh...) rivets. We expect a number of the rising city engineers to press for abandonment of this obviously obsolete technology on the grounds that anything this old must be useless and, worst sin of all, uncool.

Lack of knowledge (4, Interesting)

zoomshorts (137587) | more than 5 years ago | (#29490327)

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:Lack of knowledge (1)

TreyGeek (1391679) | more than 5 years ago | (#29490855)

Get a grip, and learn. I suggest going back to school. Just my opinion though.

Ah, but here lies the problem. Schools are no longer teaching COBOL. They are teaching Windows and Linux, C++ and JAVA, and distributed/clustered computing. They, apparently, could care less about COBOL and mainframes.

Re:Lack of knowledge (1)

SanityInAnarchy (655584) | more than 5 years ago | (#29490951)

COBOL is solid. WinDoze is flakey.

False dichotomy. Even IBM is selling Linux on mainframes these days.

If it isn't broke, you don't 'fix' it.

If it's not maintainable, it's broke.

Visual this or that.

If you pull your nose out of your COBOL for a few minutes and bother to actually learn something, you'll find that Microsoft is one small part of a large ecosystem of languages and development tools, most of which are not called "visual" anything, and most of which are better than COBOL.

Apples and Oranges (1)

Comboman (895500) | more than 5 years ago | (#29491603)

COBOL is solid. WinDoze is flakey.

I agree, but so what? COBOL is a programming language; Windows is an operating system. I could replace your statement with "C++ is solid. VAX/VMS is flakey." and it would make as much sense to your argument.

I suggest YOU go to work for any major business and work on their accounting software.

How major? GM, Walmart, Citibank? Sure they have mainframes running COBOL apps, but most businesses are not that "major", and the "minor" ones outnumber them significantly. Also, not all business apps (which was the original claim) are accounting apps. I'm sure in some dusty closet somewhere you can find word processor or email app written in COBOL, but that's not what business use today.

Re:75% of apps? Shaa, right! (2, Insightful)

MikeBabcock (65886) | more than 5 years ago | (#29490907)

What are you, a college student? You honestly believe anywhere near 75% of the world's business applications runs on Windows?

Microsoft only wishes it had the big iron servers that do the fun stuff like banking and credit card processing.

Re:75% of apps? Shaa, right! (0)

Anonymous Coward | more than 5 years ago | (#29491387)

What Moron uses Windows for Mission Critical Enterprise applications?

Celebrates? (0)

Anonymous Coward | more than 5 years ago | (#29489991)

I don't imagine "Celebrates" is the right term for it. COBOL has no excuse to not have died long ago.

Re:Celebrates? (0)

Anonymous Coward | more than 5 years ago | (#29490013)

I wonder what happens if we mix Perl and COBOL.
Will the world end ?

Re:Celebrates? (1)

ta bu shi da yu (687699) | more than 5 years ago | (#29490665)

POBOL? If you think that's bad, then it would be interesting to see an object-oriented Perl-COBOL. I call it POOBOL.

Re:Celebrates? (2, Funny)

Archtech (159117) | more than 5 years ago | (#29490021)

Now if that isn't a troll...

Re:Celebrates? (1)

Goffee71 (628501) | more than 5 years ago | (#29491259)

Hey, Elite is 25 today - now that's an anni. worth celebrating! Confession - Quite liked COBOL at college but loved Elite!

People don't "use" COBOL (3, Interesting)

davidwr (791652) | more than 5 years ago | (#29490005)

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?

Re:People don't "use" COBOL (1)

DerekLyons (302214) | more than 5 years ago | (#29491671)

How many times a day do people use applications that rely other languages that predate the moon landing?

It would be interesting to see a graph of the ages of the languages people use/encounter (even, as with COBOL, unwittingly). I expect it would be an inverse bell curve, perhaps even a bathtub curve with steep walls at each end...
 
It would serve as a powerful lesson for language developers and programmers to quit mucking around with the latest 'paradigms' and programming fads and to concentrate on systems that Simply Just Work.

COBOL (4, Funny)

mcgrew (92797) | more than 5 years ago | (#29490019)

Happy birthday, Crappy Old Bad Obsolete Language! You need to take better care of yourself, you look a lot older than fifty.

Re:COBOL (1)

laejoh (648921) | more than 5 years ago | (#29490457)

Let us all hope YOU get as old as you look!

Re:COBOL (1)

FlyingBishop (1293238) | more than 5 years ago | (#29491613)

50 is 7410 in computer years.

(Assuming the universe began in 4000 B.C.)

Cue the fucktards. (0, Funny)

Anonymous Coward | more than 5 years ago | (#29490063)

Okay, now let's hear from everybody that can write a few lines of C code and considers themselves a 'programmer'. Please chime in about how language X is so much more advanced than COBOL and also please throw in an anecdote about how this brings you back to the old days. Come on, I've teed it up for you, now knock it out of the park!

Re:Cue the fucktards. (2, Insightful)

gardyloo (512791) | more than 5 years ago | (#29490179)

Come on, I've teed it up for you, now knock it out of the park!

Maybe we can make a touchdown from that half-court shot, as you so nicely handicapped the goalie.

Re:Cue the fucktards. (1)

R2.0 (532027) | more than 5 years ago | (#29491355)

"Come on, I've teed it up for you, now knock it out of the park!

Maybe we can make a touchdown from that half-court shot, as you so nicely handicapped the goalie.

You are aware that the base training level in baseball is called tee ball. Why? Because the ball is put on a tee.

Re:Cue the fucktards. (2, Funny)

some_guy_88 (1306769) | more than 5 years ago | (#29490505)

Look, I did a class on VB in high school so I know what I'm talking about.

COBOL is so crap that you can't even create a new COBOL project in Visual Studio anymore. You really need to get up to speed.

Greetings follow COBOL programers ... (3, Funny)

Anonymous Coward | more than 5 years ago | (#29490071)

... and GET OFF MY LAWN!

COBOL made me what I am today (5, Funny)

walkoff (1562019) | more than 5 years ago | (#29490123)

We were taught COBOL at college 25 years ago and i'm still a grumpy old git

Re:COBOL made me what I am today (1)

classicvw (743849) | more than 5 years ago | (#29490437)

How many programmers today have ever programmed Cobol, and used punch cards. That is how I started out.

Punch cards? Luxury!? (1)

Arthur Grumbine (1086397) | more than 5 years ago | (#29490921)

How many programmers today have ever programmed Cobol, and used punch cards. That is how I started out.

Why when I was young we used we used rocks [xkcd.com] and we were grateful!

Re:COBOL made me what I am today (1)

Ilgaz (86384) | more than 5 years ago | (#29491099)

What is the most trendy Unix today? As it is new, Apple, it is Snow Leopard right?

Run its Terminal, type "su", you won't see password being displayed, even as "*". Why? Because damn thing (UNIX) started on actual paper outputting terminals, more like typewriters. That is also why most used commands are mostly 2-3 char things.

I mean oldness doesn't mean it is outdated. You know what "77" in Fortran 77 means right?

Re:COBOL made me what I am today (1)

DarthVain (724186) | more than 5 years ago | (#29490753)

9 Years ago for me.... Wonder if they are still teaching it.

Re:COBOL made me what I am today (1)

R2.0 (532027) | more than 5 years ago | (#29491065)

"We were taught COBOL at college 25 years ago and i'm still a grumpy old git"

Hmmm ... 23 years ago we were taught FORTRAN. I wonder what that says about me? (other than the fact that I went to an engineering school).

"Celebrate" seems to be an overstatement (1)

Borealis (84417) | more than 5 years ago | (#29490135)

Given how much programming in COBOL is analogous to building computers with vacuum tubes, I think that celebrations are not really called for. I'm thinking we need a Dr. Kevorkian style mercy killing here.

COBOL's second purpose (1)

Ilgaz (86384) | more than 5 years ago | (#29491007)

COBOL and Mainframe stories serve a great purpose. We see how many of /. readers (commenters in fact) doesn't have the slightest clue about how real World goes on without breaking. Right, you can't logon to a bank mainframe which is likely underground in some forgotten place, monitored by armed guards but it doesn't grant you to say things like "COBOL runs on vacuum tubes" or "mainframes are dead".

If you don't have any clue, do as I do... Mute.

For example, I learned to shut up about audio processing software in movies and leave people do the real work as a video guy when I saw DTS movie audio track of a Hollywood movie was done on a MacOS 9 running Mac, back in 2003.

Re:COBOL's second purpose (1)

SanityInAnarchy (655584) | more than 5 years ago | (#29491123)

it doesn't grant you to say things like "COBOL runs on vacuum tubes"

You apparently don't know what the word "analogous" means.

"mainframes are dead".

There's a difference between "are" and "should be". Mainframes are very much alive. COBOL should be dead, and I'm not sure how much longer mainframes should survive, either.

It doesn't seem like many on Slashdot are unaware of how much COBOL is used. It seems more like most of us wish it would die a well-deserved death.

Vacuum tube (1)

tepples (727027) | more than 5 years ago | (#29491481)

Given how much programming in COBOL is analogous to building computers with vacuum tubes

Computers with vacuum tubes didn't die until about half a decade ago, when LCDs became the norm in desktops.

VFrist stOp (-1, Troll)

Anonymous Coward | more than 5 years ago | (#29490139)

to its 7aid-back legitimise doing

Typo (4, Funny)

winnitude (1352731) | more than 5 years ago | (#29490159)

"COBOL Celebrates 50 Years"

Should read:

"COBOL Bemoans 50 Years"

Re:Typo (1)

Cro Magnon (467622) | more than 5 years ago | (#29490293)

Nah! COBOL is celebrating. It's the COBOL programmers that are bemoaning. Or at least moaning.

Not So Bad (4, Insightful)

Ancient_Hacker (751168) | more than 5 years ago | (#29490301)

COBOL did a lot of things right, things that a lot of modern languages ignored.

Little things like:

* Having a manufacturer and machine and OS-independent standard.
* Quasi human-readable code.
* "MOVE CORRESPONDING"

that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.

Re:Not So Bad (1)

Chrisq (894406) | more than 5 years ago | (#29490467)

I'm not so sure about the "MOVE CORRESPONDING", I think that this can be better addressed wit inheritance. The one thing that COBOL does better than any mainstream modern language is record handling and formatting. I know that expert programmers can do the same thing with "C" printf statements and Java SimpleXXXFormat classes but in COBOL it was fairly easy and could be handled by trainee programmers with a low error rate.

Re:Not So Bad (1)

SanityInAnarchy (655584) | more than 5 years ago | (#29491009)

The one thing that COBOL does better than any mainstream modern language is record handling and formatting.

Formatting? Really?

Record handling, I dispute. Formatting, if it was really so much better, I'm sure I can build a library to replicate it.

Re:Not So Bad (1)

Virak (897071) | more than 5 years ago | (#29490529)

that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.

People like to say the same sort of thing about PHP and VB. What they neglect to consider is that all of these languages try to be seen as and are seen as numbskull-friendly languages, and thus have a wholly disproportionate amount of numbskulls using them. Furthermore, while it may be just as easy to write bad code in any language, how easy it is to write good code is very dependent on language and just as important if not more so, and COBOL is certainly lacking at this compared to Ruby or C++ (though less so the latter).

Also, many people would probably consider the second item of your list one of the greatest failings of COBOL; specialized notations are usually used for specialized purposes for good reason.

Re:Not So Bad (2, Insightful)

ChienAndalu (1293930) | more than 5 years ago | (#29490813)

* Quasi human-readable code.

Human readability doesn't count. You have to understand it too. Cobol uses English words instead of a more concise syntax with special characters, and is therefore more difficult to understand. Mathematical equations and chemical formulas have their special syntaxes, and computer programs should have them too.

that said, it's just as easy for numbskulls to write bad COBOL as to write bad C++ or bad Ruby.

Obvious. But can you show me *good* COBOL?

Re:Not So Bad (0)

SanityInAnarchy (655584) | more than 5 years ago | (#29490993)

Having a manufacturer and machine and OS-independent standard.

Java does this, but not an implementation-independent standard.

Ruby is close to this. C, Javascript, and many others have had this for probably a decade or more.

Quasi human-readable code.

Anything is "quasi human-readable". Lowercase is easier on the eyes, for one. And Ruby is a hell of a lot more readable than COBOL.

Then again, I don't know a lot of COBOL, and can't comment on MOVE CORRESPONDING.

Re:Not So Bad (2, Interesting)

Hurricane78 (562437) | more than 5 years ago | (#29491203)

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.

In baseball terms, please! -Koume (-1, Offtopic)

Anonymous Coward | more than 5 years ago | (#29490389)

SUZUKAWA KOUME

be afraid... (1)

Bloody Peasant (12708) | more than 5 years ago | (#29490433)

... "apt-get install open-cobol" would actually work. Yegads...

Happy 50th (5, Funny)

CharlyFoxtrot (1607527) | more than 5 years ago | (#29490443)

identification division.
program-id. birthday.
environment division.
data division.
procedure division.
main section.
display "get off my lawn!"
stop run.

Re:Happy 50th (1)

camperdave (969942) | more than 5 years ago | (#29491197)

10 REM Comeback
20 PRINT "Who's gonna make me, you and ALGOL?"
30 END

Re:Happy 50th (5, Informative)

Anonymous Coward | more than 5 years ago | (#29491263)

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID. CONGRATS.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400 DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500 DISPLAY "Congratulations with your 50th birthday" LINE 15 POSITION 10.
100600 STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800 EXIT.

Longevity (5, Insightful)

wandazulu (265281) | more than 5 years ago | (#29490563)

I worked at a company that had a Cobol-based program that went live back in 1969. A team of programmers had kept it going ever since. Shortly after I started (mid 1995), I was in a meeting when one of the Cobol programmers mentioned that so-and-so had died over the weekend. Everybody started talking about her, what a great person she was, etc. After the meeting, I asked who she was, and was told that she was the last surviving member of the original team that wrote and deployed the application. When the system was finally shut down back in 2003 or so (I had long since left, but still had some contacts there to tell me what was going on), I really felt weird about hearing it; here was this thing that had outlived its creators (and some of the later maintainers), and now it was gone too.

Isn't it strange how computer software is both unbelievably ephemeral, yet also incredibly long-lived. I've worked on both sides and I'm not sure which is more fulfilling; it apparently took several years to write the aforementioned Cobol program, but it outlived its creators. I wonder what a programmer on something like, say, Madden, would feel, knowing that this thing they're working so hard on will be totally supplanted by the next version, next year.

Strange business, this computing machinery. Strange indeed.

Re:Longevity (2, Interesting)

Ollabelle (980205) | more than 5 years ago | (#29491187)

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

Mandatory quote (2, Informative)

SignoffTheSourcerer (567014) | more than 5 years ago | (#29490685)

The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offence.
Edsger W.Dijkstra, 18 June 1975

Nightmares (1)

billy8988 (1049032) | more than 5 years ago | (#29490705)

Thinking about COBOL gives me nightmares.
In one of our classes ('87), we had to pass a programming test in which you are required to pick a problem from a box (Simplex method) and a language in which you have to implement (COBOL).
We were given 3 hours, needless to say I took the entire 3 hours and more (examiner was very sympathetic) while all my friends were outside the exam hall in 30 mins after doing problems like Gauss-Sidel in pascal & c.

Not just cricket ... (1)

srealm (157581) | more than 5 years ago | (#29490717)

Funnily enough, 50 years is half a century in ... you know, the ENGLISH LANGUAGE (and I'm sure it's also half of the foreign equivalents to the word century. Except in Russia, of course).

How is SNOBOL doing? (2, Funny)

TimSSG (1068536) | more than 5 years ago | (#29490893)

How is SNOBOL doing? Better or worse than COBOL? Tim S.

Re:How is SNOBOL doing? (1)

idiot900 (166952) | more than 5 years ago | (#29491435)

SNOBOL dropped out of high school and ended up working for a car dealership, last I heard. He was always the sleazy sort.

New survey suggestion (1)

Ilgaz (86384) | more than 5 years ago | (#29491147)

As they enjoy spending money for obvious, I suggest them to ask those general and professional Apple users (Macbook and iPhone included) if they know UNIX and if they know it celebrates its 40th year today. In fact, start with NeXT.

Declared dead for decades... (2, Insightful)

bostei2008 (1441027) | more than 5 years ago | (#29491195)

and still very much alive.

You cannot kill it (quite literally, mainframes have a MTBF of what, 40 years? How is your windows box doing?).

You can sneer at it, disregard it, ridicule it. But it is still there after decades of getting bad rep and no fresh blood. That is actually pretty impressive.

Yo, COBOL, I'ma let you finish... (1)

Evil Shabazz (937088) | more than 5 years ago | (#29491221)

...and I'm happy for you and all, but FORTRAN was the best old-school language of all time!

Cobol! (1)

nimbius (983462) | more than 5 years ago | (#29491353)

a few slogans we could tag this one with:
COBOL: yeah but the frontend is java.
COBOL: and so the AS400 is in the inventory once again.
COBOL: break it and we're fscked.
COBOL: ...so i CAN use goto?

Australian working 'day'? (1)

Blittzed (657028) | more than 5 years ago | (#29491455)

"...research which showed people still use COBOL at least 10 times throughout the course of an average working day in Australia."

Given that the average Australian works about 2 hours a day, that's a lot of COBOL...

COBOL is a dangerous language (1)

Shimmer (3036) | more than 5 years ago | (#29491697)

For any of you tempted to wax nostalgic about COBOL, let me explain[*] just one charming feature: Procedure calls in COBOL are not stack based. That's right, there is no call stack.

In fact, you can't even really call a procedure in COBOL. Instead, you invoke what amounts to a GOTO/COMEFROM [wikipedia.org] pair. COBOL programs are divided into "paragraphs". When you want to execute a procedure, you PERFORM PARA-1 THRU PARA-N. Yes, that's right - the return point of the invocation varies at the whim of the caller. Heck, the return point of the invocation can even appear *before* the starting point.

But wait, it gets even better! These invocations can overlap (again, rather than stacking). So if I PERFORM PARA-1 THRU PARA-5, then in the middle of PARA-3 I decide to PERFORM PARA-4 THRU PARA-6, guess what happens? As the instruction pointer passes the end of PARA-5, it doesn't continue through to PARA-6. No! There's still an active "COMEFROM" at the end of PARA-5 from the first invocation that returns control to the statement following that invocation. From there, it's like a whack-a-mole. The COMEFROM at the end of PARA-5 is cleared, but should control ever pass the end of PARA-6 for any reason whatsoever, there's still an active COMEFROM waiting there to send the instruction pointer back to the statement following the second invocation.

In short, pray that you never have to debug a poorly structured COBOL program. It is essentially impossible.

[*]Disclaimer: This information is based on suppressed traumatic memories from 20 years ago, so some details may be incorrect.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?