COBOL Celebrates 50 Years

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

Comments

COBOL is nice for business processing

[zoomshorts]

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

Re:COBOL is nice for business processing

[BrokenHalo]

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.

Re:COBOL is nice for business processing

[thethibs]

That's one reason COBOL was deliberately made verbose: to avoid subtle typos in a hostile environment.

I handwrite a program on a coding sheet which is copied to punched cards by a non-technical keypunch operator and read by a sometimes reliable card reader; typos are guaranteed and you want the compiler to jump all over them. No spending half a day to find the place where "-=" should be "==".

Re:COBOL is nice for business processing

[Richard Steiner]

Heaven help those who forget that all-important period at the end of IDENTIFICATION-DIVISION :-) :-)

Re:COBOL is nice for business processing

[Kelsen]

But the wonder of MCP on the Burroughs mainframes was that you didn't *have* to deal with assembler, and there was no JCL. Always superior, Burroughs died out when bought by Sperry in the mid-80's to facilitate landing/fulfilling the Air Force's Phase IV contract. Ah, those were the days.

RFT!!!
Dave Kelsen
--
A good friend will come bail you out of jail, but a true friend will be sitting next to you saying, "Damn... we fucked up!"

A good knock in deed..

[bsDaemon]

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

Re:A good knock in deed..

[eclectro]

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

Though, to be fair, with games lasting up to 5 days, it just seems like 50 years.

Re:A good knock in deed..

[Eudial]

Yeah, I almost had time to write a hello world program in COBOL during a cricket game once. Though I couldn't find enough Libraries of Congress to save it in, so I had to chuck it. A shame, really.

75% of apps? Shaa, right!

[Adeptus_Luminati]

"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!

[duffbeer703]

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

Re:75% of apps? Shaa, right!

[Archtech]

"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!

[Anonymous Coward]

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!

[Fred_A]

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!

[Old97]

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!

[Anonymous Coward]

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!

[PhunkySchtuff]

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!

[drinkypoo]

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!

[MBGMorden]

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!

[yttrstein]

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!

[sgbett]

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

Re:75% of apps? Shaa, right!

[Anonymous Coward]

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!

[MBGMorden]

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

Re:75% of apps? Shaa, right!

[sgbett]

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

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

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!

[Anonymous Coward]

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!

[Anonymous Coward]

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

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

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!

[MikeBabcock]

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!

[Hurricane78]

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!

[SanityInAnarchy]

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!

[TheSunborn]

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!

[Hurricane78]

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!

[wisty]

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!

[ubersoldat2k7]

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!

[MasterOfMagic]

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!

[Anonymous Coward]

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!

[Anonymous Coward]

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!

[Bakkster]

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!

[defaria]

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.

Re:75% of apps? Shaa, right!

[JerryQ]

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.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

What Moron uses Windows for Mission Critical Enterprise applications?

Re:75% of apps? Shaa, right!

[Anonymous Coward]

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!

[Chrisq]

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!

[MBGMorden]

Trust me I would have loved to write it, but for whatever reason, management has decided that in-house applications are a dying breed, and that any major software to be used must be purchased from a vendor. Most of the coding we do now is simply for extracts, interfacing different systems together, and small web frontends for the public to view the data. Most of our in-house programmers are being converted to database admins.

Just for kicks and giggles though I actually started writing an equivalent app at home in my spare time, and within 3-4 months I'm pretty close to recreating what our old app did and mine's a lot more stable than the one we bought.

Re:75% of apps? Shaa, right!

[Just Some Guy]

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 sure do! Naive new programmers used to write programs that handled large amounts of data as batch jobs. Naive new programmers write programs that handled large amounts of data as event-driven GUI constructs. Hint: MVC. Second hint: MVC. Need another: MVC.

Even GUI code can be pretty simple when you enforce a strict separation between the interface and the backend. Write your underlying code first and get it perfected (or as perfect as your time and money budgets allow), and only then write a GUI to interact with it. It's OK to integrate the two if you're writing yet another paint program, but that isn't the kind of project you're dealing with here.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

Don't bother he'll never understand or believe that one. If he can't play Bejeweled or some first person shooter on it he'll never believe it's a computer.

Re:75% of apps? Shaa, right!

[Tablizer]

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

In theory, yes. In practice, no, unless you limit yourself to a lowest-common denominator. If you want to take advantage of the GUI system you have, you pretty much have to code for GUI-specific stuff. Plus, a middle layer of indirection to "protect" one from GUI system changes can become quite a sub-application in itself.
     

Re:75% of apps? Shaa, right!

[mindstrm]

I suspect your second reason is the major factor behind the continued use of cobol.

The systems that use it are so huge and complex that replacing them is seen as next to impossible.

Re:75% of apps? Shaa, right!

[orzetto]

Visual Basic

I think I see your problem here...

One, the complexities of a GUI makes codes many times more intricate [...]

Here's the rest of your problem. A GUI must never bump into a difficult or mission-critical algorithm. That's supposed to be its own library, which is accessed by the GUI through a clean and solid software interface. This is a major architectural fault: a Big Ball of Mud, and some languages encourage that more than others.

My suggestion would be: get a language with a lower density of script kiddies, sufficiently popular and object-oriented (Python, C++, Java, ...), get some good programmers with proven track record, and rewrite the client. Specify that you want all functions and variables documented, and test suites; if they say "that will cost you more", show them the door. If they say "we do it anyway", that's a good sign.

Re:75% of apps? Shaa, right!

[Brian Feldman]

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.

Really? I thought you could choose a definitive order in which to lock any two nodes -- perhaps based on strict ordering of a globally unique identifier -- and always lock them in that order, avoiding the possibility of deadlock altogether. Guess you learn something new every day.

Re:75% of apps? Shaa, right!

[VAXcat]

VMS clusters, with the Distribute Lock Manager, solved this problem decades ago.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

No one knows what the business rules are because they are embedded hither and yon in COBOL programs.

Re-read the parent. They need to change it because they don't understand it.

Re:75% of apps? Shaa, right!

[Pictish Prince]

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.

Apologize to Dr. Kissinger right now.

Re:75% of apps? Shaa, right!

[Acer500]

What Moron uses Windows for Mission Critical Enterprise applications?

I hate to tell you, but one of the big three credit bureaus has at least one MS Windows Datacenter Edition running a massive Oracle DB. And it works.

Re:75% of apps? Shaa, right!

[smcdow]

The fun stuff (Java, .NET, Web) ...

If by "fun", you mean "hammering #10 nails into my eyeballs", then I agree.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

Trust me the Fed does most every check transaction THEN sends it to your bank. I do work here. Wish it would show the IP addy to "prove" it.

http://www.federalreserve.gov/paymentsystems/truncation/

Re:75% of apps? Shaa, right!

[Anonymous Coward]

So COBOL, unlike Windows, doesn't delete parts of itself?

Re:75% of apps? Shaa, right!

[DrDoug]

Show me a construct in COBOL that wouldn't be much easier in something modern -- even Java, if we have to.

It is designed as a business language. I would say a couple of major points are that it uses decimal arithmetic to give the correct accounting answers, database manipulation in inherent in the language, and forms layout (think paychecks, tax forms, etc) is easy. Yes, you can do all of these via libraries in other languages, but they are rarely inherent parts of the language.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

75%-- in the world... makes sense.

And that 75% are the apps you never have to reboot, get a BSOD, or has some complicated user interface. It's the 75% of apps out there that you need 1-2 functions and works 100% of the time.

The desktop is just 1/3 of the computing stuff out there. Phones, POS systems, toll booths, anything mission critical is likely running Unix/Linux and some COBOL or Java backend somewhere. Open you eyes, it's not just a MS/OSX world as the advertisers says.

Re:75% of apps? Shaa, right!

[UncleTogie]

Trust me I would have loved to write it, but for whatever reason, management has decided that in-house applications are a dying breed, and that any major software to be used must be purchased from a vendor.

Ok, I'll bite... why isn't the vendor being held accountable and being asked to fix the bugs?

Re:75% of apps? Shaa, right!

[Major Blud]

Is this a government office? What state?

Re:75% of apps? Shaa, right!

[sycodon]

COBOL is the Mac truck or Diesel Electric Locomotive of Business Infrastructure applications.

It's not pretty like the myriad of sissy and strangely named languages (WTF is GlassFish?), It's not "nuanced" like the various OO languages, and it definitely doesn't do Web pages (that I know of).

But when you need to get down to business and process millions of transactions, generate millions of billing statements, or other reports, especially reports, COBOL is what you want.

When there's heavy lifting to be done, COBOL's the one.

----
Tongue only partially in Cheek.

Re:75% of apps? Shaa, right!

[sycodon]

I'm not up on all the new sissy languages. Do any of them have anything analogous to the Record construct?

100 DataRecord char(100)
      110 Name char(30)
              115 FirstName char(15)
              117 LastName char(15)
      120 Address char(40

etc.

It may seem cumbersome, but if you've ever been told to modify a 20 year old program, this kind of code is a dream.

Re:75% of apps? Shaa, right!

[mridoni]

The real problem with VB.Net is that it tries too hard to stay compatible with its awful and numbingly failure-prone predecessor (VB6). If you just activate a couple of language features ("option strict", etc.) VB.Net is actually a modern and well behaved language: there's no automatic type conversion, late binding is disabled, etc. Of course, when you do that, you also find out that writing directly in C# is much faster...

Re:75% of apps? Shaa, right!

[Anonymous Coward]

> Clusters are more available than a mainframe

I'd dispute this.

> if your mainframe goes down, you're down.

If your cluster goes down, you're down.

The idea behind clusters is that an entire cluster doesn't go down, absent a catastrophic failure, like an airliner crashing into the data centre. Unfortunately, it doesn't always work so well in practice. Most clustering systems have been found to have failure modes which can take down the entire cluster, e.g. cascading failures, or a critical node failing and the fail-over procedure not working as planned.

Re:75% of apps? Shaa, right!

[Mycroft_514]

Do you ship anything? Say with Fedex, UPS, or any of the other big shipping companies? Congratualtions, you have just created COBOL transactions.

Re:75% of apps? Shaa, right!

[MBGMorden]

They have been asked, but they treat bug reports as whining.

Literally, I had a dialog that crashed every time I ran a certain search - basically just hit search with no criteria to show all properties in the database. Upon informing them I was told that the control they were using capped out at approximately 90,000 results (I don't think it was an even number but the number was in that general range) and that since they didn't write it it wasn't their fault. When I suggested that maybe they should segment the results into smaller groups, or at a minimum just cap the number of returned results to prevent the crash, I was just brushed off.

When I let them know about the issue with it freezing up when clicking too fast their response was basically "then don't click that fast", leading to the aforementioned "1-1000" count between switching dialogs.

As per their contract they're required to provide support, but the quality level and any required timeframe is not specified (essentially, they're not legally required to fix them).

Re:75% of apps? Shaa, right!

[mferero]

Heck yes you can do web pages in Cobol, given the latest CICS (for you non-mainframers: Customer Information and Control System) setup. It's also possible to do so from MicoFocus COBOL http://www.microfocus.com/products/RMCOBOL/COBOLCGI.asp

Re:75% of apps? Shaa, right!

[daveime]

SELECT * FROM TABLE INTO CRAPPY_MICROSOFT_CONTROL_STRUCTURE ?

This is what happens when you employ MCSEs.

(Filter error: Don't use so many caps. It's like YELLING ... no it's called SQL, you Slashdot f***wit coders).

Re:75% of apps? Shaa, right!

[SlashDev]

"Big heavy-duty transaction-processing apps run overwhelmingly on mainframes, because they just work." Also because it would cost a shit load of money to re-write them.

Re:75% of apps? Shaa, right!

[Darinbob]

COBOL is long lived, since it's cheaper to maintain existing programs than to rewrite them from scratch in another language. As the saying goes, if it ain't broke, don't fix it.

Re:75% of apps? Shaa, right!

[Darinbob]

The last paragraph is interesting. It's true that a lot of "modern" programming seems to be all about marketing. Get the cool stuff done, show it off, and we'll patch it down the road if we get around to it. After all, few programmers ever imagine that their software will still be around in 5, 10, or 50 years. The goal is to get the customers today, or the investors, or to make the boss to stop breathing down your neck.

In the past there was a different focus on the economy of programming - computing was expensive, so you had to be efficient. That meant do the job quickly and simply. It also meant you designed differently, you couldn't afford many edit/compile/debug/repeat cycles, so you needed to make sure it worked on paper first. There used to be the days of systems analysts, designing large complex software without ever touching a computer.

Also interesting to compare those two languages; COBOL and Visual Basic. One was designed for a formal programmer, and the other for a git 'er done type.

Re:75% of apps? Shaa, right!

[baegucb]

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!

[SanityInAnarchy]

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

That's a bit like the guy who puts "10 years of Ruby on Rails experience required" in a job posting. Of course it can't have precisely the same track record if it hasn't been around that long.

It's also a bit like saying "I didn't know that modern cars had a 100+ year history of reliability, scalability

But take Erlang -- released in 1986, and has been known for consistent reliability, even in the face of programmer error -- catching errors, respawning those processes, and letting the programmer fix the underlying problem on the fly, patching an in-production application without dropping a single connection.

It's been used in things like telephone switches which have to run for decades nonstop, without dropping a single request.

Security -- what can a language do to help that, other than avoid encouraging blatantly insecure constructs? But then, Erlang doesn't ever allow non-Erlang code inside the Erlang process, save for the VM itself -- thus, any security hazards in C libraries are going to be severely limited in what they can access. And a DoS of such a library would only result in that process being restarted.

And scalability -- surely you're joking. Erlang is one of the few platforms on which you can comfortably spawn a few hundred thousand processes, and let the language itself manage scheduling -- so it scales to many cores. It's also based on message passing, which means RPC is dead simple, which means it scales about as easily to clusters as to cores.

And that's just one language. LISP is a whole other discussion, and still one worth having.

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.

Very true. However, there comes a point where the original code -- in any language -- has become so brittle that the cost of minor changes (remember the California minimum-wage fiasco?) suggests that a rewrite makes sense. If you've come to the point where a rewrite makes sense, I would think another language also makes sense.

Now, you can write good code in any language, so technically, if something is brittle, it's not COBOL's fault. COBOL is Turing-complete, after all. But the question is how easy a language makes it to write good code.

COBOL, well, tends to encourage spaghetti code. Properly structured code is a bit against the grain -- after all, what other language in popular use today has local variables as a bolted-on, after-the-fact feature? It would seem to me that local variables are kind of a huge step in the direction of developing a stable, secure, and bug-free program.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

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

I've never had Java crash due to a language bug -- and the fact that you can't even spell it makes me question your credibility.

But I wasn't suggesting Java, or C#, or C++. And "interpreted language" is a property of the implementation, not the language.

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

Which doesn't mean it's the best for a business transaction.

and is reliable.

Which is, again, true of many modern languages.

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.

Very true. It also strongly suggests that you're Doing It Wrong.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

Yeah, it really does seem cumbersome, compared to this:

DataRecord = Struct.new :first_name, :last_name, :address

Or this:

CREATE TABLE data_records (first_name VARCHAR(255), last_name VARCHAR(255), address VARCHAR(255));

Or this:

create_table do |t|
  t.string :first_name
  t.string :last_name
  t.string :address
end

It also seems like it'd be kind of frustrating for someone with a last name of MacGhilleseatheanaich, or Featherstonehaugh. With the kind of power you're dealing with in a mainframe, why are you arbitrarily limiting yourself to 15 characters?

Performance? Really? Somehow, I don't think names are the kind of data you need to run massive reports on, crunching through thousands of records a second, with rock-solid ACID compliance. The worst I can imagine is wanting to query by name, in which case, you'd just add an index.

In other words: Either I'm missing something huge, or you really should get up on the new "sissy languages" before you knock them. It'd be a bit like me knocking C# for not having lambdas -- I've since learned my lesson.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

Only if those existing programs are sufficiently well-written. Are you seriously going to tell me that California is better off spending six months retrofitting an old COBOL app for something as simple as printing a minimum wage check, then spend something like two years rewriting it from scratch so that such changes take ten minutes in the future?

I can see where California might take the short way out now, but remember, it only takes four such changes for the new system to pay for itself.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

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

What, adding a layer of abstraction? Especially one that someone else already added for you, in the form of a library?

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

In practice, no, unless you limit yourself to a lowest-common denominator.

I'm not sure I see how this lowest-common denominator is going to be worse than the COBOL interface you had before.

If you want to take advantage of the GUI system you have, you pretty much have to code for GUI-specific stuff. Plus, a middle layer of indirection to "protect" one from GUI system changes

Which sounds very much like not having code for GUI-specific stuff, outside of that "middle layer", which is, again, already implemented many times over.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

The idea behind clusters is that an entire cluster doesn't go down, absent a catastrophic failure, like an airliner crashing into the data centre.

Which is, you'll note, significantly more robust than a single mainframe. (With two mainframes, you're left with exactly the same problem as before.)

Unfortunately, it doesn't always work so well in practice.

Implying that it does sometimes work really well in practice.

I don't know... I'd sleep better at night knowing there's at least two or more copies of my data floating around the cluster, and if the cluster doesn't automatically bring itself back up, the data is at least still there. A catastrophic mainframe failure, and you're relying on backups.

Re:75% of apps? Shaa, right!

[Bakkster]

I've seen the JVM (that's one that is capitalized!) crash multiple times on more complex programs. One was a digital logic architect program written by a professor and several graduate students. After several years of development, it still crashed frequently on large projects, due to the JVM running out of memory. Crashes were common enough that we had to convince the professor to add an auto-save to make it less un-usable. Not saying it's due to Java specifically, but it did seem to be linked to the virtual machine.

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? Does the cost of design, development, verification, testing, and deployment provide at least as much benefit (in dollars/time) to the company? Is it worth the risk to replace a system that has worked well for decades with one that could introduce a serious compunding error that doesn't manifest itself until years down the line?

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. This isn't a bad thing for a general-purpose language with expansive libraries that can do everything, but for these kinds of transactions a special-purpose language should be able to outperform.

tl;dr You may have a case for new programs, but it makes no sense to rewrite working COBOL.

Re:75% of apps? Shaa, right!

[sycodon]

Either you don't know much about COBOL, or you are just really cranky today.

Re:75% of apps? Shaa, right!

[Jurily]

I'm not up on all the new sissy languages. Do any of them have anything analogous to the Record construct?

The only examples I can think of that don't are Brainfuck and Intercal.

Re:75% of apps? Shaa, right!

[BikeHelmet]

Java:

public class Record
{
public byte[][] Names = new byte[2][15];
public byte[] Address = new byte[40];
}

But java encourages self-explanatory methods attached to a struct/class.

public byte[] getFirstName() { return Names[0]; }
public byte[] getLastName() { return Names[1]; }
public byte[] getAddress() { return Address; }

But, truth be told... byte[] are rather primitive. Java encourages String use, so you'd never see this unless you designed it this way for a reason. I'm also inclined to believe that easier higher level code leads to less limitations on what software can do. Why limit to a first and last name? Why only 40 byte addresses? Why not add some setter methods that do length/validity checks, and then let the record store longer addresses, middle names, etc.? Anything nulled out(not used) is just handled as a null pointer/reference in java, so allowing up to say 5 names would only cost a max of 12 bytes per record - unless those names actually get added.

Doing a straight port from Cobol to Java would be pointless. When doing something like this, the shortfalls of the old software have to be examined, and corrected. You lose on performance and memory usage, so you had better gain on scalability, features, and perhaps ease of use.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

Not trying to impress just you fellas just have no clue WTF you are talking about.

Checks was BIG business till a few years ago but 10's of millions a paper checks still go though the system every day

http://www.federalreserve.gov/paymentsystems/checkrestruct/default.htm

The Check 21 system was brought online 2004

http://www.federalreserve.gov/boarddocs/press/other/2004/20041028/default.htm

It is a quasi-govt job. Not impressive in the least.

Never been to college and make 6 figures THAT, however, is. ;-)

Re:75% of apps? Shaa, right!

[bar-agent]

Decimal arithmetic is, I think, a major advantage. I am amazed that numeric processing is allowed to be as unsafe and inaccurate as it is, in most languages. No overflow or underflow detection? Can't test floating-point numbers for equality? WTF?! Hello, bugs!

And why is ratio handling so rare?

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

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

Re:75% of apps? Shaa, right!

[Anonymous Coward]

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

People didn't develop reliable, scalable systems because of cobol but despite COBOL.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

Some of both. Can you explain how my examples aren't equivalent to that COBOL declaration?

Re:75% of apps? Shaa, right!

[Anonymous Coward]

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.

show me a business case for replacing something that works.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

Pretty much every modern languages will offer serialization of data structures along those lines, with far greater flexibility.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

show me a business case for replacing something that works.

Paper ledgers work. What's your business case for replacing them with something else?

Horse-drawn carriages work. What's your business case for replacing them with horeseless carriages?

Not all COBOL needs to be replaced immediately. However, some of it is clearly showing its age. You sure you don't see a business case in upgrading to a system where a simple fucking salary change takes several minutes, instead of over a year?

Re:75% of apps? Shaa, right!

[lennier]

"GUIs can certainly be abstracted to the point where it's not an issue."

And yet, for some reason they're not. When was the last time you were able to, say, pipe the output of a bash script into a DataGrid control generated and displayed on the fly?

But it's doable in principle, right?

Just... not so much in practice? Perhaps because actually-existing GUI libraries are very tightly integrated with language VMs, OO class and type systems, calling conventions, ABIs, threading models, mutexes and semaphores, and because you have to get into the cogs and gears of whether you use C++ native objects, GObjects, Qt objects, KParts, COM objects, CORBA objects, OLE/VBX/ActiveX controls, ObjectiveC objects, WxWidgets wrappers, J2EE Beans, Plain Old Java Objects, Javascript objects, Ruby objects, PHP objects, and how (if) you can get any of them to share resources and exchange data?

Whereas if you're dealing with just text I/O streams and the occasional file, *all of this nonsense goes away* and is something you don't even have to think about?

(I often wonder if we couldn't decouple GUIs from object systems and get back to a stream-based interface that could work equally well with multiple language backends... but that would be yet another layer of abstraction onto the whole pile.)

Re:75% of apps? Shaa, right!

[lennier]

Ever hear the term "leaky abstraction"?

First you have to pick your preferred abstraction layer. Then you have to work around the things it abstracts that you actually need to know about, and the things it makes you do that you don't... and maybe you need portability between different abstraction layers, so you add your own library on top of the abstraction layer... and then you have to make sure that the abstraction library is kept up to date with fast-moving external targets... before you know it, you've got a dozen layers *all of which you need to understand their subtle quirks and interactions*.

Or you just pick one and go 'that's sorta close enough and almost correct and I don't have time to properly test it, we'll sort that out in beta', and voila, you get the current state of desktop software.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

When was the last time you were able to, say, pipe the output of a bash script into a DataGrid control generated and displayed on the fly?

I have to admit, I don't have something that does this. But almost in the same breath, I also have to mention that it'd probably be very quick to do.

Perhaps because actually-existing GUI libraries are very tightly integrated with language VMs

Can't think of too many of those, and those VMs certainly allow other languages to do so.

you have to get into the cogs and gears of whether you use C++ native objects, GObjects, Qt objects, KParts, COM objects, CORBA objects, OLE/VBX/ActiveX controls, ObjectiveC objects, WxWidgets wrappers, J2EE Beans, Plain Old Java Objects, Javascript objects, Ruby objects, PHP objects,

None of these have simple bindings? Really?

Certainly, Ruby has native bindings. So does Javascript, for that matter.

I often wonder if we couldn't decouple GUIs from object systems and get back to a stream-based interface that could work equally well with multiple language backends... but that would be yet another layer of abstraction onto the whole pile.

Probably so...

I guess what I'm not seeing is where a textual interface is so much easier that the GUI is so necessarily either difficult or screwed up. My point wasn't that you can get a GUI for free, it's that GUIs don't necessarily make things more intricate.

Indeed, I've done GUIs (so to speak) in a website, and it didn't overly complicate the server-side. It got to where a view for the data was only a few lines of code, and once I had that view, exposing it via REST was damned-near automatic, and consuming it with jQuery was, again, only a few lines of code. Most of the rest of it, I let the browser handle for me.

But yes, the GUI absolutely was decoupled from the program logic, and it's difficult for me to see how anyone who even knows what MVC stands for could build the monstrosity described by MBGMorden:

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.

I mean, as hard as GUI might be, can you possibly imagine the complexities of any GUI system introducing crashes and data validation errors of this magnitude, unless the developer of this app was a complete moron? Is it that difficult to imagine that, given COBOL, this same developer might develop something equally disturbing?

Or maybe that was exactly the problem -- maybe they took a developer who knew how to write bad COBOL in any language, and they didn't quite grok VB?

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

First you have to pick your preferred abstraction layer.

Eenie, meenie, miny... It really doesn't matter so much which abstraction layer you pick. You could pretty much take a list of features, look for a layer that has those features, and go -- particularly if you bias towards higher-level abstractions.

Then you have to work around the things it abstracts that you actually need to know about,

Rare.

In the original Law of Leaky Abstractions article, for example, Joel talked about things like having to iterate over each string several times -- once to find the length, then once again to copy it to a new, just-allocated string. And of course, that if you're concatenating strings all over the place, rather than using some sort of StringBuilder, this is happening a lot, and also leaving a lot of garbage to be collected, and tripping the allocator, and...

And how often does that particular problem affect the development of a desktop front-end, something that pretty much just needs to display some records in some forms, and store the updated version back in the database? Even on a five or ten year old desktop, the performance gains by using C++ versus a scripting language, or using StringBuilder versus straight concatenation, are pretty much irrelevant.

Click "parent" a few times to find this example:

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.

In what way could that be caused by a "leaky abstraction"?

before you know it, you've got a dozen layers *all of which you need to understand their subtle quirks and interactions*.

12 layers seems like a bit much. I mean, most apps I write, I've got at most...

1. database
2. model (inside server-side app)
3. REST API
4. HTML view
5. CSS styling
6. Javascript client

So, about half that. What's more, these layers are mostly isolated from each other. The model sits completely between the REST API and the database. The CSS and JavaScript don't really need to know about each other at all -- the CSS only cares about the HTML itself, and the JavaScript cares about HTML and REST.

Subtle interactions? Sure, but it's not as though adding Javascript suddenly implies a huge and subtle interaction between the model and the database, or any change to the model at all.

The point isn't that the GUI is free -- I think I implied that, and I don't think I meant to.

The point is that, look at the stack I drew again. If you're having to change model code -- the heart of your application -- because of some GUI somewhere much farther down, you're Doing It Wrong. GUIs being "much more intricate" may lead to quirks, yes, but they should not lead to data corruption in any half-decent app.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

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

Perhaps not Windows apps, but Web apps are routinely coded in COBOL. Especially since an advanced web application framework is now available, called COBOL on Cobwebs. Sure, it is VERY expensive, and only really sold as an "enterprise" solution with advanced IT support, but it's there.

Re:75% of apps? Shaa, right!

[sycodon]

I wrote a crap load of text trying to explain what you asked for. Instead go here:

http://www.99-bottles-of-beer.net/

Look at the COBOL version and then others. Then imagine you had no clue what the program was supposed to do.

Re:75% of apps? Shaa, right!

[Water]

A 10 minute change? That is laughable estimate.

Maybe 10 minutes of coding time, but don't forget all the time to develop a project plan, agree to a timetable (with all affected departments in the government), write the requirements, have the stakeholder approve the requirements (this will take at least a week with more than one meeting), write the technical specification for the change, design a test plan, write your unit tests (if they don't already exist), make the code change, deploy the code to a test environment, fix any bugs that may come up that are production bugs (but the testers insist they need to be fixed for this release), get sign off from the stakeholder and deploy to a production environment.

10 minutes my ass. That's just as bad as you assuming it would take 6 months of coding work to make the change in COBOL.

Re:75% of apps? Shaa, right!

[Mike610544]

Good points, but I think there are a few good counter-counterarguments.

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.

If changes are infrequent, it might be worth it. Rewriting from scratch will necessitate finding and fixing a *lot* of new bugs, while the existing system has already been debugged over the past few decades.

If I did my accounting with a paper ledger, computerizing the process would probably make no sense to me

Nobody can covertly copy/sell your paper records with a thumb drive, and they need physical access to destroy them. Also they're immune to EMP.

if I became a fluent C/C++ programmer (especially C++), it might not be immediately obvious to me how useful garbage collection is

Less deterministic performance is a problem for some people, and there's always at least some performance hit.

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.

I'm stretching my devil's advocate theme with this one but maybe some features aren't in the main UI of an app because they tell you to interactively hack the Lisp.

Bloated by what metric?

No argument on that one. If you're rewriting a COBOL app today, you've probably got a few orders of magnitude more of every resource than the original app required.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

  I learned BASIC, PASCAL, Assembly, FORTRAN and COBOL 20-25 years ago.

More than 20 years of my career has been devoted to COBOL coding. The license plate on my car even says COBOL.

Why? Because I *love* it when I hear people talk about how "COBOL is dead". Or when they try to claim that it's hardly ever used.

Nearly every Fortune 500 company in 2007 had business-essential COBOL applications. And even in the world of e-commerce, a lot of the server-side work is done by largely stable and efficient COBOL coding.

I am going to start naming companies I have either worked or contracted or supported using COBOL over these years, ranging from Realia to MicroFocus to Fujitsu to HP3000 to IBM/MVS to VAX/VMS (some of these companies have changed names or are gone, but you may recognize them nonetheless).

Racal Milgo/Datacom, Baxter International, Tyco/Sensormatic, Hewlett-Packard, Compaq, Sony, QVC, Tree of Life, Bowater, Hoeganes Steel, ARCO Alaska, DaytonHudson/Marshall Fields/Target, Greyhound-Dial Corp, Gap/OldNavy, Warner Lambert, Army/Airforce Exchange Service (AAFES), Vons Groceries, Burger King, Toys R Us, United Health Care, US Mint, Bailey's, Hickory Farms, Honey-Baked Ham, Nordstroms, Coach, Hot Topic, Delias, Victoria's Secret, Steeda.com, Swell.com, Casual Male, Starstruck, American Musical Supply, Mack's Prairie Wings, Overtons, Urban Outfitters, Wine Country Gift Baskets, Micro Warehouse, Tiger Direct, Egghead, Programmers Paradise, Big Toe Sports, Softball Sales, Baseball Express, IdeaArt, Taylor Gifts, Coldwater Creek, On Campus Marketing, MCI WORLDCOM, Norwegian Cruise Lines, Sungard Systems.... I could go on, but you get the picture.

In fact, head over to Victoria's Secret, type in "thong" and click search. You just hit a whole series of COBOL applications.

I personally have coded everything from supply chain (warehousing, shipping, logistics) to e-commerce, from phone company systems (did Y2K at Worldcom), to reservations systems (cruise lines and medical transportation), from huge multi-channel and e-commerce to small-shop advertising companies. Interfaces linking Amazon, Google Checkout and Paypal/Ebay to "old legacy" commerce companies (for instance American Musical Supply products on Amazon were all fed there by COBOL interfaces drawing data from the company's conventional brick&mortar, catalog and own website data.

If you enter credit info to purchase something, most of the time you hit COBOL apps.

If you attend a university that uses Sungard Systems software for the school website, then you're hitting COBOL apps every click.

All of this said, I know most of the "old" languages like COBOL, FORTRAN and Assembly and BASIC, but plenty of the newer ones too. C++, Java, ASP.net, C#, VB.net, HTML, PHP, and with more on my list "to get to" (Perl, Python etc).

But nothing else really approaches the positive things that can be said about COBOL, which is why it is still entrenched after 50 years running our businesses.

Many don't even realize that OOP principles were born with the COBOL language, and that you can code it in a highly flexible/scalable fashion, if done right. There's even a COBOL.NET version. Heck, even "#include" isn't original... COBOL had "CopyLibs" performing the same functionality in the 60s.

OK my rant is over only because my fingers are tired.

Purplesteeda@yahoo.com

(and no, I am not like 60 or anything... I am barely 40, and have been coding since the age of 12)

Re:75% of apps? Shaa, right!

[jschlesinger]

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.

Except that most bank transfers don't actually use a transaction. In the exceptional case that you are transferring between two accounts on the very same system, you might use a transaction (but I know one very large UK bank where even that isn't true). More likely the transfer (or payment) is between accounts on two different systems. In that case, one approach (used for instance by SAP payments) is to run a short workflow where you first try and reserve funds at the 'from' account, if that succeeds you then deposit into the 'to' account, finally you confirm at the 'from' account. The ability to reserve funds was put into most branch accounting systems to accommodate ATM withdrawals.

The truth is that the standard example of a transaction (transferring between two bank accounts) was an academic invention with very little relationship to what really happens in real banking systems.

It is also worth noting that the majority of branch accounting systems in the UK (and the US) run on IMS on IBM mainframes and a lot of them are coded in assembler not COBOL. COBOL is more used in insurance.

Re:75% of apps? Shaa, right!

[Bakkster]

Maintainability.

Good code is maintainable, no matter what language it's written in. Bad code is unmaintainable no matter the language as well. I think the proof is in the pudding: COBOL programs that have been maintained successfully for decades can continue to be maintained. Until new hardware/software will no longer support COBOL, it's probably not worth the risk to rewrite it. If you need to write a new program, perhaps starting with a modern language will make it better, but there should be no rush to replace working code as long as it is expected to continue working.

A good programmer can be taught COBOL (or any language) and maintain it. If you're not hiring good coders, you have bigger problems than what language your software is written in. A COBOL program is more succeptible to some issues, just as modern languages are at risk from other issues. And I seriously doubt that a 10-minute change in Java would take 6 months in COBOL. Do you have some way to back this claim up?

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?

So, we're assuming 100x larger programs here. Adding 100x the RAM does not make performance equal. Programs run out of cache, not RAM, but even making that 100x bigger won't make performance equal, since the data needs to get there still. Even if the memory bandwidth is made 100x higher, still not the same performance due to the RAM's set-up time for reads and writes, as well as HDD/SSD access time.

You also ignore that your 100x larger program probably has additional instructions performing type-casting, error-handling, and all those other things that make the language 'safe'. So, instead of hiring programmers that avoid these errors in the first place, your code must check for them every single operation, whether your code is good or not. Hint, most of these errors are found and fixed quickly. This is additional processing time, which requires additional hardware to perform at the same speed.

I concurr that The Big Picture is more complicated. While you've shown there could be a small benefit to rewriting the COBOL to make it accessable to programmers who can't be bothered to learn it (are these the programmers you want?), you haven't mitigated the risk of inducing errors with a rewrite or of failing to meet run-time performance. Especially since most of these systems can't run as a cluster easily (they would require parallel processing techniques, which are additionally risky).

I fail to see why you think that COBOL, a language that has successfully been running business apps for decades, is so unacceptable that it must be replaced with a new general-purpose language immediately.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

I've seen less than a paragraph, unless you mean you wrote a bunch of text, then deleted it.

It looks kind of absurdly verbose -- makes Java look good. If your point was making something maintainable, that even a newbie can pick up later, you fail. What does this do?

DISPLAY SPACES

Half of it is just weird compared to an alternate version. The other half is just unnecessary.

There's also a classic WTF in there -- the For-Case paradigm. Here, some simple Ruby, if you really want to have that many special cases:

99.downto(3) do |bottles|
  puts "#{bottles} bottles of beer on the wall, #{bottles} bottles of beer. Take one down, pass it around, #{bottles-1} bottles of beer on the wall."
end
 
puts '2 bottles beer on the wall, 2 bottles of beer. Take one down, pass it around, 1 bottle of beer on the wall.'
puts '1 bottle of beer on the wall, 1 bottle of beer. Take one down, pass it around, no more bottles of beer on the wall.'
puts 'No more bottles of beer on the wall, no more bottles of beer. Go to the store and buy some more, 99 bottles of beer on the wall.'

That's essentially what the "pretty" version is doing -- but when you've got over 20 lines just allocating memory, that's not particularly pretty or maintainable.

The only reason I can think of including those special cases in the loop itself, is if you wanted to actually refactor it a bit:

def bottles count
  case count
    when 1
      '1 bottle'
    when 0
      'no more bottles'
    else
      "#{count} bottles"
  end
end
 
99.downto(1) do |count|
  b = bottles(count)
  puts "#{b} bottles of beer on the wall, #{b} bottles of beer. Take one down, pass it around, #{bottles count-1} bottles of beer on the wall."
end
 
puts 'No more bottles of beer on the wall, no more bottles of beer. Go to the store and buy some more, 99 bottles of beer on the wall.'

None of the other examples made any sense.

Now, look at my last example, there. Imagine you had no clue what the program was supposed to do. Show me an example of a COBOL version that's even half as readable.

I mean, if nothing else, it's got the verse actually there in one line that almost says what you want...

Re:75% of apps? Shaa, right!

[Tablizer]

I'm not sure I see how this lowest-common denominator is going to be worse than the COBOL interface you had before.

What is a "COBOL interface"? It does not have a built-in UI. Due to Turing Equivalency, it can in theory run any GUI you can conjure. (Whether it would be pleasant to code for such a task or not is another matter.)

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

Good code is maintainable, no matter what language it's written in. Bad code is unmaintainable no matter the language as well.

Granted, every language is Turing-complete. That doesn't mean it's easy.

To me, the measure of a language is how easy it is to write good code, not whether it's theoretically possible to write good code. Drupal is a great example that shows PHP can be maintainable -- but Drupal is also not the usual case for PHP apps, and if I need to make any kind of significant change, PHP is still going to slow me down by about a factor of 2, compared to a decent language.

I think the proof is in the pudding: COBOL programs that have been maintained successfully for decades can continue to be maintained.

This is the success effect -- COBOL programs that made it to decades without being replaced must either be somewhat maintainable, or be seriously on life support.

I seriously doubt that a 10-minute change in Java would take 6 months in COBOL. Do you have some way to back this claim up?

I'm too lazy, but Google for "California COBOL". Six months to change a salary. Nine months to change it back.

So I suppose another important question is: What kind of code does the language encourage? I can't imagine anyone writing a mess like that in any decently modern language.

So, we're assuming 100x larger programs here. Adding 100x the RAM does not make performance equal.

Granted. However, having a binary 100x bigger doesn't necessarily imply that it's 100x slower.

as well as HDD/SSD access time.

I feel like I have to keep reminding you that we aren't in the 70's anymore. Reading ten megs from disk and caching it somewhere in a few gigabytes (terabytes?) of RAM is just not a big deal.

There's also a bit of old wisdom here: Premature optimization is the root of all evil. Build the app the way it makes sense, and build it as quickly as possible. Then you can actually profile it, get some meaningful real-world numbers, find actual (not theoretical) bottlenecks, and optimize those.

If needed, you rewrite pieces of it in C -- even assembly. But a program that's mostly high-level, with a few bottlenecks in assembly, still seems much saner to me than a program that's entirely COBOL.

You also ignore that your 100x larger program probably has additional instructions performing type-casting, error-handling, and all those other things that make the language 'safe'.

Just so.

So, instead of hiring programmers that avoid these errors in the first place,

who will sometimes fail,

your code must check for them every single operation,

only if your compiler/VM isn't particularly smart.

Hint, most of these errors are found and fixed quickly.

Key word: Most. Do you want to trust your savings to a system that has more bugs than necessary, because you chose to require programmer skill when you could've had the machine handle it?

It's a bit like a manual transmission vs an automatic. In theory, you can use your human intelligence to squeeze more performance, or more fuel efficiency, out of a manual than you could get out of an automatic. If you were racing, you might train yourself to the point where those few seconds add up, and it's worth it.

But in the rest of the world, automatic makes much more sense. It means no possibility that you'll make some mistake with the clutch and stall out your engine, or destroy it. And those few times you misjudge with a manual, resulting in wasted fuel, probably more than cover any savings you might have -- especially considering how good automatic transmissions have gotten.

Let me ask something else: Would you prefer assembly to COBOL? If not, why not?

Whi

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

Maybe 10 minutes of coding time,

That was the point. All the machinery you mentioned doesn't get any easier (or harder) with COBOL.

That's just as bad as you assuming it would take 6 months of coding work to make the change in COBOL.

That wasn't my estimate.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

If changes are infrequent, it might be worth it.

Fair enough -- but this can be a self-fulfilling prophecy. For example, California's problem of six months to lower wages, then nine months to restore them, probably means the change won't happen.

I'd argue that if you can afford to rewrite it such that it takes ten minutes (or a few days, maybe a month, counting all the administrative BS), it really doesn't take that many changes for it to pay off, and you'll probably find yourself making more changes -- that is, things that previously would've been "nice to have, but we can't afford to change it" now become reasonably possible.

Nobody can covertly copy/sell your paper records with a thumb drive, and they need physical access to destroy them. Also they're immune to EMP.

Two words: Encryption and backups.

Encrypted -- no one can covertly copy/sell your records without having your password. Paper records, someone can still covertly copy/sell them, it just takes a xerox machine.

Destroy -- multiple offsite backups, meaning they'd need multiple passwords. And nothing's stopping you from making a physical backup.

EMP -- multiple offsite backups.

Both of these make your data more private and more robust than paper, and they're much more difficult to do with paper.

Less deterministic performance is a problem for some people,

Very true. But it's not a problem for the vast majority of people, especially those who complain about garbage collection -- and with a generational collector, it's not going to be nondeterministic in any noticeable way for your typical end-user application.

I can see it mattering in embedded software, or in a device driver, but not many other places.

maybe some features aren't in the main UI of an app because they tell you to interactively hack the Lisp.

In other words, the fact that the feature is available might make programmers lazy?

Yeah, that is stretching. That's like an open source app suggesting you change a header file and recompile, rather than providing at least a config file -- in practice, most apps will use a config file for anything they expect a user to have to change, even if they are open source.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

What is a "COBOL interface"?

Fair point, but I was referring to MBGMorden's old COBOL app, with a "clunky interface", which was later rewritten as a Windows app.

Perhaps it'd be better if it had been straight ported? Then again, that's a WTF all its own.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

Yikes.

Well, you've just convinced me of the merits of balancing my checkbook and otherwise maintaining my own finances. At least I can use double-entry accounting with transactions, and correct the bank when they're wrong.

Because that really sounds like a "when", rather than "if"... *shudders*

Re:75% of apps? Shaa, right!

[DragonWriter]

Security -- what can a language do to help that, other than avoid encouraging blatantly insecure constructs? But then, Erlang doesn't ever allow non-Erlang code inside the Erlang process, save for the VM itself

That's either not true or at least misleading. Non-Erlang code that's not part of the distributed VM can run inside Erlang processes as a "linked-in driver" (whether such a driver is essentially a new part of the VM is, I suppose, debatable), which may sometimes be desirable for performance reasons though it is generally discouraged because of the fact that errors in the driver can potentially crash the system.

Erlang is one of the few platforms on which you can comfortably spawn a few hundred thousand processes, and let the language itself manage scheduling -- so it scales to many cores.

While both the first and second halves are true, the "so" linking them isn't really. The fact that the VM handles scheduling doesn't make it scale to many cores (originally, the Erlang environment was optimized to run separate VMs per core communicating as separate Erlang nodes.) But the fact that it is designed that way means that once the heavy lifting was done to convert from a non-threaded, single-OS-process set of VM-managed "processes" (Erlang processes aren't OS processes, they are more like green threads with very limited shared state with restricted means for accessing that state to avoid conflicts) to a backend which had SMP support and distributed the work of the VM "processes" across different OS threads that this change was completely transparent to Erlang code. But SMP support in Erlang is comparatively new (from about 2006).

Re:75% of apps? Shaa, right!

[DragonWriter]

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.

Um, the six months wasn't six months of pure coding, and the wages weren't just being changed, the basic premises of how other things were calculated from the wages (and how wages -- which often weren't hourly in the first place -- were identified from other information in the system) were also to be changed, as well as the information that was gathered and other business processes that were external to the code itself. The six months was the entire time it would take to implement the change, including requirements gathering (a high-level policy directive is not the same as a complete set of requirements), designing, coding, and testing the system and the associated business process, and not just for the facility to make the initial change, but to be able to do the new things that would be required when the minimum wage period ended.

Six months for what should be a ten minute change (generously), no matter what the language, demands a rewrite.

I don't think you understand the problem if you think it would be anything like a 10 minute change in any case.

Re:75% of apps? Shaa, right!

[DragonWriter]

For example, California's problem of six months to lower wages, then nine months to restore them, probably means the change won't happen.

Since it took less time than that for the underlying issue to be resolved that prompted the order, sure.

I'd argue that if you can afford to rewrite it such that it takes ten minutes (or a few days, maybe a month, counting all the administrative BS), it really doesn't take that many changes for it to pay off, and you'll probably find yourself making more changes -- that is, things that previously would've been "nice to have, but we can't afford to change it" now become reasonably possible.

Sure, but it would take much longer than the combined time for the changes on both ends to the existing system to rewrite the system so that that one need could be accomplished in a quick switch-flip style change whenever desired in the future, and since the change was a major business process change not a simple parameter change, the changes that would be needed to make that an instant would -- no matter the language -- have at best only tangential relevance to any other change that might be needed in the future.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

Non-Erlang code that's not part of the distributed VM can run inside Erlang processes as a "linked-in driver"... which may sometimes be desirable for performance reasons though it is generally discouraged because of the fact that errors in the driver can potentially crash the system.

Yes, that's my point. Granted, even if there wasn't native support for this availability, the Erlang source is open, so it's always possible. But doing that is, from a security/stability/sanity perspective, roughly like using eval.

While both the first and second halves are true, the "so" linking them isn't really. The fact that the VM handles scheduling doesn't make it scale to many cores (originally, the Erlang environment was optimized to run separate VMs per core communicating as separate Erlang nodes.)

You're right. However, Erlang does currently have SMP support:

Erlang processes aren't OS processes, they are more like green threads with very limited shared state with restricted means for accessing that state to avoid conflicts

And SMP Erlang doesn't use OS processes either -- it uses threads.

Still, if you can make it scale to multiple machines using the RPC support, you can certainly scale to multicore. By the time the number of cores is such a limiting factor that you need the SMP, I imagine it'll be a few years from now when the SMP is, well, older.

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

it would take much longer than the combined time for the changes on both ends to the existing system to rewrite the system so that that one need could be accomplished in a quick switch-flip style change whenever desired in the future

How many times longer, though? If it takes three years to replace it, that means four changes makes it worth it.

no matter the language

I argue that some languages tend towards modularity, flexibility, maintainability, and otherwise good code, while other languages (COBOL among them) tend towards shortcuts, brittleness, opaqueness, and otherwise bad code.

You can write good code in any Turing-complete language, but is it going with the grain of the language, or against it? In other words, how easy does the language make it to write good code, versus how seductively easy is it to write horrendously bad code?

This is why modern languages tend not to have goto -- you can write good code using goto, and indeed, the CPU is essentially using goto anyway (jump commands). But higher-level constructs make it easier to write good code, and using those constructs instead of goto makes it harder to write bad code. The same could be said of garbage collection and references vs manual memory management and integer pointers.

Re:75% of apps? Shaa, right!

[DragonWriter]

How many times longer, though? If it takes three years to replace it, that means four changes makes it worth it.

So, you'd only need four times the length of the current history of the State of California to reach your expected break even point?

Re:75% of apps? Shaa, right!

[SanityInAnarchy]

So, in other words, the State of California has never altered wages? Wow.

Re:75% of apps? Shaa, right!

[Anonymous Coward]

Do not compare your shop's apps with major government apps. 200 of your business apps is probably the equivalence of one line of code of the massive programs of governments and large companies. They are the main user of Cobol!
Cobol was used to do what needed to be done i.e. it was productive
Java and newer high level languages are loaded with bells and whistles that are counterproductive...but are fun and easy to use!

Re:75% of apps? Shaa, right!

[DragonWriter]

So, in other words, the State of California has never altered wages?

No, the existing state system is very good at handling altered wages, it handles them every day without extended reprogramming.

Its bad at temporarily at doing temporary mass changes that affect the basis of pay (many of the people who would have been paid at the federal hourly minimum wage were salaried employees that weren't normally paid based on hours worked, many of the rest are paid on a quasi-salary basis with a monthly based pay but dock or overtime calculated hourly, and some were actual hourly employees) that also involve all-kinds of non-standard treatment of the way various things that are normally calculated from or along with wages are treated.

Re:75% of apps? Shaa, right!

[Hognoxious]

You seem to be confusing business applications and office applications. And while the 75% figure is probably high, it's quite likely that the ones that do are big, busy, and important.

Celebrates?

[Anonymous Coward]

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

Re:Celebrates?

[Anonymous Coward]

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

Re:Celebrates?

[Archtech]

Now if that isn't a troll...

Re:Celebrates?

[ta bu shi da yu]

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?

[Goffee71]

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

Re:Celebrates?

[Anonymous Coward]

What does speaking out loud what everyone thinks already have to do with trolling?

People don't "use" COBOL

[davidwr]

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

[DerekLyons]

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

[mcgrew]

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

Re:COBOL

[laejoh]

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

Re:COBOL

[FlyingBishop]

50 is 7410 in computer years.

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

Re:COBOL

[troll8901]

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

No, no, it began on one of these dates:

• December 30, 1899. (Visual Basic)
• January 02, 1904. (Excel alternate date system)
• January 01, 1970. (Unix)
• January 01, 1993. (According to my old computer's CMOS Setup whenever it loses its clock information.)

What? The computer is my universe. And the end is near!

Re:COBOL

[mcgrew]

Actually I look a lot younger than I am. But then, my parents look younger than they are, too, so I can't take any creadit for it.

Re:COBOL

[mcgrew]

ENIAC (the first electronic programmable computer) was patented in 1947 and first switched on that fall. See Growing Up with Computers. That makes the computer itself sixty two years old.

For those of you still hanging on

[kriston]

For those of you still hanging on:
http://www.amazon.com/C-COBOL-Programmers-Business-Approach/dp/0805316604/ref=sr_1_1?ie=UTF8&s=books&qid=1253538164&sr=8-1

Cue the fucktards.

[Anonymous Coward]

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.

[gardyloo]

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.

[some_guy_88]

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.

Re:Cue the fucktards.

[R2.0]

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

[NewbieProgrammerMan]

People playing tee ball usually can't knock it out of the park, though.

Re:Cue the fucktards.

[R2.0]

Yeah, but they don't know that.

Greetings follow COBOL programers ...

[Anonymous Coward]

... and GET OFF MY LAWN!

COBOL made me what I am today

[walkoff]

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

[classicvw]

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

Re:COBOL made me what I am today

[DarthVain]

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

Re:COBOL made me what I am today

[R2.0]

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

Re:COBOL made me what I am today

[Ilgaz]

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

[Anonymous Coward]

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.

Don't know about Unix, but that's not the reason why it's like that now in Linux. It's for a bit of extra security paranoia of the 'no one should even be able to see the *length* of your password when shoulder surfing' variety.

I know this because there was a request from the Ubuntu end to change it to display '*'s and that was (summarized) the developer response. IIRC this is documented in the appropriate bugzilla entry.

Re:COBOL made me what I am today

[Chris Mattern]

Yes, I do. Do you know what the "2003" in Fortran 2003 is?

Re:COBOL made me what I am today

[Anonymous Coward]

We used to have to punch our own cards, using paper clips...

Re:COBOL made me what I am today

[AshtangiMan]

The number of puppies killed in creating it?

Re:COBOL made me what I am today

[daveime]

The number of people in the world who can code in it ?

(Assuming of course that 2003 is a base-4 number).

"Celebrate" seems to be an overstatement

[Borealis]

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.

Typo

[winnitude]

"COBOL Celebrates 50 Years"

Should read:

"COBOL Bemoans 50 Years"

Re:Typo

[Cro Magnon]

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

Not So Bad

[Ancient_Hacker]

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

[Chrisq]

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

[Virak]

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

[ChienAndalu]

* 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

[SanityInAnarchy]

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

[SanityInAnarchy]

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

[Hurricane78]

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:Not So Bad

[orzetto]

A good example for a language that has certain things in place to prevent bad coding, is Haskell.

I have been studying some Haskell in the past few months, and while I am in awe at Haskell's type system, and how you can write a language without for and while, and lazy evaluation, and functional purity, and partial application, and so on, there are two things that made me give up:

1. Functional purity makes I/O a major mess. Monads are complex, unintuitive and unwieldy. I think I spent over one month only trying to warp my mind around that. It does not help that Haskellers keep repeating that "monads are really simple", there is a reason why they are the most asked-about topic in newsgroups.
2. The worst thing is the Haskell community's coding standards. Single-letter variables are common, and I actually read some delirious rant about this being necessary "because it's so abstract you cannot name it". If it's so abstract you cannot name it, you abstracted too much, or you don't understand what you are doing. There seems to be a proliferation of operators, since Haskell foolishly allows to define new ones, even completely useless ones like $. Coding function with undocumented one-liners seems to be considered a virtue.

Haskell has many good ideas, but it will never be a successful language because it's just too damn difficult, and no one in the Haskell community seems to care about it. I gave up when I thought that, even if I learned it, it would be utterly useless because few other people will bother to learn it. It also weighed in that there are so few software projects based on Haskell.

Haskell is a great language to calculate factorials, but very little else.

Re:Not So Bad

[An ominous Cow art]

My knowledge of COBOL is limited to what I remember from a summer class between my junior and senior years of high school, many years ago. I have worked extensively in the Foxbase and Foxpro variants of 'xbase', and they always felt to me like a mix of Pascal, BASIC, COBOL and Fortran - the COBOL mostly in the PICTURE clauses available to some commands.

Re:Not So Bad

[Ornedan]

Functional purity makes I/O a major mess. Monads are complex, unintuitive and unwieldy. I think I spent over one month only trying to warp my mind around that. It does not help that Haskellers keep repeating that "monads are really simple", there is a reason why they are the most asked-about topic in newsgroups.

I'm suspecting that's because they really are quite simple. You can think of monads in general as a way to formally define types of computation that may have a context in which they operate. There're error monads like Maybe, where the computation may fail at a step, aborting the rest of the computation. State monads like State, where the computation has access to implicit state. Non-determinism in List, which computes all possible results. And IO, which is a bit like a state monad where your state is the whole of the rest of the world.
Try reading Real World Haskell? The text is available online.

The worst thing is the Haskell community's coding standards. Single-letter variables are common, and I actually read some delirious rant about this being necessary "because it's so abstract you cannot name it". If it's so abstract you cannot name it, you abstracted too much, or you don't understand what you are doing. There seems to be a proliferation of operators, since Haskell foolishly allows to define new ones, even completely useless ones like $. Coding function with undocumented one-liners seems to be considered a virtue.

OK. Let's take the simple example of map:
-- | Gives the list obtained by applying the given function to each element of the given list.
map :: (a -> b) -> [a] -> [b]
map f (e:es) = f e : map f es
map _ [] = []

What longer variable names would you use there and would those really make it more understandable?

Presence of one-letter variable names generally indicates that the function doesn't care about the internal details of the value in that variable. That could be due to either the function being polymoprhic (where it can't access the internals) or operating on simple types like numbers (where there are no internal details to care about).

$ is occasionally handy when creating a partial application. For example:
fs :: [a -> b]
v :: a
map ($ v) fs

That's in addition to cutting out extra parens when you're applying multiple functions:
f1 (f2 (f3 (f4 v)))
  vs.
f1 $ f2 $ f3 $ f4 v

One of the places where custom operators are very usefull is with combinator libraries. Making the most commonly used low-level combinators operators helps keep the code using the combinators reasonably short and thus more readable than if they were bloodyLongNamesFullySpelledOut.

Re:Not So Bad

[Anonymous Coward]

In some languages, it's definitely easier to write bad code. [...] C/C++ is another one.

There's no such language as "C/C++".

Re:Not So Bad

[Anonymous Coward]

> Functional purity makes I/O a major mess. Monads are complex, unintuitive and unwieldy.

No they aren't.

> I think I spent over one month only trying to warp my mind around that. It does not help that Haskellers keep repeating that "monads are really simple", there is a reason why they are the most asked-about topic in newsgroups.

AFAICT, the reason is that so many programmers simply can't get their head around the fact that there isn't actually anything that you need to get your head around. Because the I/O system is associated with some fancy name from category theory, everyone seems to assume that there's some critical point which they're missing. And there isn't.

Imperative code in Haskell looks and behaves just like imperative code in every other programming language. But because Haskell gives a name (monad) to something which imperative languages take for granted, people get confused trying to understand what that name "means" (it just means a type with associated functions named ">>=" and "return", and that's *all* it means).

> The worst thing is the Haskell community's coding standards. Single-letter variables are common, and I actually read some delirious rant about this being necessary "because it's so abstract you cannot name it".

That's usually true. Do you complain about fundamental mathematical functions using "x" as a parameter name? Or loops using "i" and "j" as loop counters? What would you use instead?

> If it's so abstract you cannot name it, you abstracted too much, or you don't understand what you are doing.

You can never abstract too much.

You're probably used to creating functions which have a very specific use case. E.g. not only do all of the parameters have concrete types (e.g. date), but represent a very specific piece of information (e.g. date of birth).

In functional languages, it's common to make functions as generic as possible. Why require the function take a list of integers when the same algorithm can be applied to a list of any type? In languages like C, this is less common, partly because it's much harder (e.g. the lack of parametric types makes it awkward to write a function which isn't tied to specific, concrete types).

If you have a function which accepts a list of dates of birth, it might be reasonable to name the parameter "dates_of_birth". OTOH, if it works on arbitrary lists, you may as well just call it "l"; it's not as if "the_list" is any more descriptive.

> There seems to be a proliferation of operators, since Haskell foolishly allows to define new ones,

There's nothing foolish about it. What makes infix appropriate for the handful of operators which C defines but inappropriate for any other diadic function?

> even completely useless ones like $.

The $ operator is quite widely used in actual code. Why? Because while function application has higher precedence than any binary operator, $ has the lowest possible precedence. This means that you can re-write e.g.

      (f1 (f2 (f3 (f4 x)))
as:
      f1 $ f2 $ f3 $ f4 x

and eliminate the piled-up parentheses at the end.

Given that function application is about the most fundamental operation in the language (even more fundamental than assignment in C), it seems like a no-brainer to provide an operator for it.

> Coding function with undocumented one-liners seems to be considered a virtue.

In most languages, people only comment that which isn't blatantly obvious. As with most languages, Haskell programmers tend to consider "obvious" from the point of someone who is at least moderately familiar with the language, rather than a novice (even a novice who thinks that 10 years experience of C means that they get to skip the stage of being a novice when it comes to learning a new language).

Haskell isn't C, doesn't try to be C, isn't designed on the basis that C is somehow "natural", and that it therefore has to justify deviating from the way that C works. If anything, it has its roots in algebra, which has a couple of centuries' head start on most programming languages, and as such is considered the first place to look when it comes to choosing syntax.

Re:Not So Bad

[bar-agent]

Imperative code in Haskell looks and behaves just like imperative code in every other programming language. But because Haskell gives a name (monad) to something which imperative languages take for granted, people get confused trying to understand what that name "means" (it just means a type with associated functions named ">>=" and "return", and that's *all* it means).

What do >>= and return do? If the answer is, "anything you want," that's not the right answer. How are they intended to be used?

And can you explain what that "something" is that monads make explicit, without delving into category theory? Because while most mathematicians know what category theory is (I assume), most software engineers do not.

You can never abstract too much. You're probably used to creating functions which have a very specific use case. E.g. not only do all of the parameters have concrete types (e.g. date), but represent a very specific piece of information (e.g. date of birth).

Yes. Exactly. You can have too much abstraction, because, at the end of the day, you want to accomplish a specific task.

It is extra cognitive load to figure out which abstractions — or combination of abstractions — in your toolkit are even applicable, and more effort to decide which of those is the best choice. You want a specific use case, because that makes it easy to figure out a solution. You want to avoid choice paralysis.

It is also additional cognitive load to try to figure out how your own code can be made more abstract. It is easy and fast to crank out something that will do a specific task. It is considerably more difficult to consider if and how that code can be altered to work in the abstract task space, with arbitrary data and performance characteristics. Haskell development is the antithesis of the ideas behind extreme programming and rapid application development. Haskell software design is all about the analysis stage of the waterfall model.

Additionally, you can't easily learn a set of abstractions directly. You have to learn them by example, or by discussion. The documentation needs to lay out a set of examples or use cases and explain what the commonality is. This kind of documentation seems to be missing from Haskell, which should probably be using the GoF Patterns book as a model. But even with documentation, you need to work with these tools and experiment until they finally click.

Mathematicians — and math aficionados — love Haskell, because they do this kind of thing on a daily basis. It is their job and/or passion. They are good at dealing with the house of cards that comes from piling abstraction upon abstraction, because they get lots of practice. This is not true of the software industry as a whole. Most of us prefer to build a house of Legos (to extend the metaphor).

Coding function with undocumented one-liners seems to be considered a virtue.

In most languages, people only comment that which isn't blatantly obvious. As with most languages, Haskell programmers tend to consider "obvious" from the point of someone who is at least moderately familiar with the language, rather than a novice.

I don't know how hard it is to get to that "blatantly obvious" point. But I will point out an appropriate comic: "I don't document things that are 'no-brainers.'"

Re:Not So Bad

[orzetto]

You can think of monads in general as a way to formally define types of computation that may have a context in which they operate.

See, you are part of the problem. Is that supposed to be an explanation? If you cannot explain it in plain English, you do not really understand it yourself (I think I am quoting Feynman). Your explanation is also wrong (as most "explanations" about monads): Maybe has no context, and neither do lists. The general definition of monad has nothing to do with context, only with chaining.

Try reading Real World Haskell? The text is available online.

Read, until chapter 15 where I gave up around the Reader monad. I read the Thompson before. See below for horror example.

OK. Let's take the simple example of map:

f becomes function, e first, es rest.

However map is pretty easy to grasp. For the promised RWH horror code, here is one from chapter 14:

bindSt :: (SimpleState s a) -> (a -> SimpleState s b) -> SimpleState s b
bindSt m k = \s -> let (a, s') = m s
in (k a) s'

There are multiple issues: the SimpleState is not a state (problem common to the State monad), but a state processor, a function. I really would like to inflict pain on whomever decided the name. The authors use m presumably for a monad, then (the gods knows for which reason) k for a function. They also use a single apostrophe (the smallest character they could find, arguably) to distinguish the new state from the old. Funny thing, they actually try to follow up with a more "readable" version, in which they make a sorry attempt at readability, which fails hopelessly (step seems a noun, but is actually meant as a verb).

[...] helps keep the code using the combinators reasonably short [...]

Argh, no, you must not keep the damn code short! The alpha and omega is keeping it readable. Ideally good code should read almost as plain English. Operators are not English, and should be used sparingly (I once thought it was silly to limit the operators in C++... now I see the wisdom). Surely you can be too verbose, but at a minimum the code must be self-explanatory. Well that's the professional coding world, where Haskell does not belong, and never will.

Funny thing, I discovered that "terse" has a different meaning in English from what I expected. In my language (from which the word comes) it means clean, transparent, so I extrapolated "readable". Guess what, it took people praising Haskell for being "terse" for me to figure out that something was amiss.

Re:Not So Bad

[orzetto]

there isn't actually anything that you need to get your head around

Yup, that's why Haskell newsgroups are flooded with questions on monads and all Haskell books have multiple chapters. Because they don't exist. Anyway, nice try—that's an original escape route.

Because the I/O system is associated with some fancy name from category theory [...]

Who was talking about the IO monad? I was talking of monad in general. That includes State, Maybe and lists.

Do you complain about fundamental mathematical functions using "x" as a parameter name? Or loops using "i" and "j" as loop counters? What would you use instead?

There is this thing called "semantics". Good variable names can be address, customer, server, sum, widget or something that tells the reader what the variable is, not a random placeholder. If you cannot find a good name, you do not know what you are doing.

What makes infix appropriate for the handful of operators which C defines but inappropriate for any other diadic function?

The fact that +, -, *, / are widely recognized and any 3rd grader knows what they mean. R-e-a-d-a-b-i-l-i-t-y.

[...] and eliminate the piled-up parentheses at the end [with the $ operator]

Well done, if you left them there people could actually have understood something of the code.

(even a novice who thinks that 10 years experience of C means that they get to skip the stage of being a novice when it comes to learning a new language)

I never had the problems I had with Haskell when I learnt C++. Or Python, which I am learning now. Or Modelica (which is really different from procedural programming), which I use at work. That's got to stand for something.

[Haskell] it has its roots in algebra, which has a couple of centuries' head start on most programming languages, [...]

Heads up: algebra is not a programming language.

Re:Not So Bad

[SolitaryMan]

In PHP it actually comes with the retardedness of the standard libraries, which encourage you to write crappy code.

In C/C++ I'd say the crappy type system is to blame. You spend more time fighting it than actually designing code.

Haskell has an excellent type system and libraries, but too hooked up on pureness and functionality, to my taste. This is probably why I fell in love with Scala.

Re:Not So Bad

[Anonymous Coward]

So, since don't like RWH, what would you consider a good resource - particularly any resources aimed at experienced programmers with no functional language experience (well, I used LISP in college, but that was long ago and only part of one semester)? Thanks in advance.

- T

Lack of knowledge

[zoomshorts]

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

[TreyGeek]

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

[SanityInAnarchy]

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.

Re:Lack of knowledge

[Brian Feldman]

A language is a language. Successful schools teach the art of programming which results in sufficient experience to learn new languages in the future. It doesn't matter which particular languages are used as examples in the process.

Re:Lack of knowledge

[Anonymous Coward]

COBOL is an appropriate language for solving certain problems. I just finished writing a LIS (Laboratory Information System) for a start-up bio-tech company. I wrote it in a mixture of TCL/TK (for the workstation interfaces), c (for the automated backups, printing, etc.), and *COBOL* (for the main "business logic"). One of COBOL's major attributes is its "self documenting" feature (read that as "verbosity"). *THAT*, I believe, is why so many programmers hate it. They just HATE to document ANYTHING --- especially when the language forces it!

Re:Lack of knowledge

[Anonymous Coward]

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

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

If it's not maintainable, you can't 'fix' it. It's not broke until you find a bug.

Re:Lack of knowledge

[SanityInAnarchy]

It's not broke until you find a bug.

Or a missing feature.

Or you decide to just document a particular bug, or lack of a feature, in some "known bugs/limitations" document, because it's cheaper than actually trying to fix the bug.

That is: The speed at which you can fix a bug or implement a feature greatly influences what you consider to be a bug.

be afraid...

[Bloody Peasant]

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

Happy 50th

[CharlyFoxtrot]

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

Re:Happy 50th

[camperdave]

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

Re:Happy 50th

[Anonymous Coward]

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.

Re:Happy 50th

[Anonymous Coward]

Got a bug - you missed a period...

Re:Happy 50th

[slinks]

Thats COBOL?! what's the one where the chicks whale on each other ?

Re:Happy 50th

[Anonymous Coward]

#!/usr/bin/perl

printf "Congratulations on your 50th birthday\n";

exit;

Longevity

[wandazulu]

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

[Ollabelle]

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

Re:Longevity

[bbtom]

Well, ideally, they'd be able to get excited about doing it differently, maybe doing it better. We have to reconcile ourselves to the fact that non-programmers may make decisions about software for less-than-optimal reasons (A: "We're using XML"; B: "Why?"; A: "Well, anything that begins with 'X' has to be cool and the industry press has talked it to death."; B: "But, but..."; A: "I pay your salary."; B: "Okay then. I'll just take our CSV data and wrap it in a 'CSVData' element."), but that we can at least try to enjoy the ride.

What you said about software "both unbelievably ephemeral, yet also incredibly long-lived" is true of lots of things, but it reminds me a lot of jazz. That's certainly how I try and think of programming: whatever else changes, try and have fun with it, and try to work on interesting projects. If the implementation stays there for 50 years, great. If it doesn't, hopefully you still had fun implementing it, it still helps someone do something useful, and you have become a better programmer.

Re:Longevity

[CharlyFoxtrot]

Well, ideally, they'd be able to get excited about doing it differently, maybe doing it better.

Le mieux est l'ennemi du bien. (The better is the enemy of the good.) - Voltaire

Might be anecdotal but I've seen a few perfectly good system thrown out in the search for an ephemeral "better" that then failed to materialize.

Re:Longevity

[ActusReus]

Isn't it strange how computer software is both unbelievably ephemeral, yet also incredibly long-lived. ... 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.

I'm not sure where your career path has taken YOU over the years, but many (most?) of us reading this ARE that programmer you're curious about. Just about every major project I've ever worked on either failed due to a management reorganization or budget cut, or else was already planned for complete replacement by the time we finished. I've been in this industry for 15 years now, working for both start-ups and Fortune 500 companies, and I'd wager that the only code of mine to survive longer than 5 years has been small internal-user web apps or perhaps some Perl-driven reports.

I like new challenges, and new puzzles to solve. The chaos of this industry has a certain appeal. However, there is still a bit of emptiness and a sense that nothing you're doing really matters. Sometimes I do get a little tired of building sandcastles for a living.

Re:Longevity

[Mycroft_514]

I was one of a team of 3 that wrote a system in COBOL in 1983. Last I heard it is still running. It generated Maintenance schedules for a large plant automatically.

The next system I worked on after that (1985-88) was running until the company sold the division that used it. Don't know what happened after that.

Code from 1996-7 is still running for a tax system for an insurance company.

Code from 1999-2000 is still ordering merchandise for a major entertainment company (A certain Mouse you know).

And if you send packages by certain LARGE corporations then you use COBOL behind the scences. I wrote a new COBOL program for one of those a few weeks ago (and I'm a DBA, not a developer).

Re:Longevity

[vaporland]

as I've posted elsewhere on /., I wrote a multiuser microcomputer database (not SQL!) app that's been running more or less continuously since 1991. it started on a network of Mac Pluses, was converted to Windows 95 and is now a terminal server app being rewritten as a web app (by someone else - I'm a project manager now).

Some of the people at the government agency who help me write this are retired, some are dead, and a few are still working there.

so much technology has changed, but the Peter Principle has certainly remained consistent over the years...

Re:Longevity

[beegeegee]

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.

But that's like everything manufactured. 1.0 always get supplanted by 2.0. The thing is (and this is probably true of Madden too for all I know), 1.0 is often better than 2.0 and though plenty of people will purchase the newer version, those who know the product will just keep playing 1.0 and it will get the reputation as the "definitive Madden" (or whatever). People keep using a COBOL app because they have to no matter what a POS it is. Not really great analogies.

Mandatory quote

[SignoffTheSourcerer]

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

Re:Mandatory quote

[thethibs]

Intriguing. Dijkstra was big on the idea of code being provably correct by construction. I know of no language that makes that easier than COBOL.

Nightmares

[billy8988]

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

[srealm]

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?

[TimSSG]

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

Re:How is SNOBOL doing?

[idiot900]

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

Re:How is SNOBOL doing?

[An ominous Cow art]

It had a job as the 4th level of the TRON video game for a while.

Re:How is SNOBOL doing?

[Anonymous Coward]

For those of you who don't get the joke, "snowball" is a popular gay sex move where you suck off another dude (or felch sperm out of his ass) and then pass the sperm back and forth as you kiss.

Re:How is SNOBOL doing?

[Anonymous Coward]

SNOBOL is still kicking too

http://code.google.com/p/spitbol/downloads/list

Punch cards? Luxury!?

[Arthur Grumbine]

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 and we were grateful!

COBOL's second purpose

[Ilgaz]

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

[SanityInAnarchy]

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.

New survey suggestion

[Ilgaz]

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

[bostei2008]

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.

Re:Declared dead for decades...

[Anonymous Coward]

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.

And there is a real possibility it will still be there to dance on the graves of all the modern detractors!

Re:Declared dead for decades...

[Ant P.]

mainframes have a MTBF of what, 40 years?

AFAIK modern mainframes have redundant, hot-swappable everything, which would mean they can be kept running indefinitely.

Yo, COBOL, I'ma let you finish...

[Evil Shabazz]

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

Cobol!

[nimbius]

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?

My 20% isn't someone else's 20%

[tepples]

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:My 20% isn't someone else's 20%

[MBGMorden]

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

Well, yes, and that was sort of the case with the old system. Building dimensions were entered in a specific text format that we could easily take and convert to graphical (which we did during the data conversion), but what the users mostly wanted was a graphical input method. Rather than typing out the dimensions they just wanted to draw them, which was just not possible with a "green screen" application.

Australian working 'day'?

[Blittzed]

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

Vacuum tube

[tepples]

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.

COBOL's Youngest Coder Celebrates 95th birthday

[mcwop]

EOM [/could not resist, and yes there are some young ones out there].

http://www.reuters.com/article/pressRelease/idUS121649+18-Sep-2009+PRN20090918

Best joke I know about Cobol

[Jimmy_Slimmy]

http://www.xent.com/FoRK-archive/spring97/0143.html

Apples and Oranges

[Comboman]

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.

COBOL is a dangerous language

[Shimmer]

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

Re:COBOL is a dangerous language

[Anonymous Coward]

In fact, you can't even really call a procedure in COBOL.

This hasn't been true for a *long* time.

COBOL 85 (yes, the *1985* standard version of COBOL) supports 'nested programs' (i.e. procedures) with reference/value parameters and local variables (as well as adding all the other previously mssing standard structured constructs like scope delimeters (END-IF etc.), in-line perform, evaluate (=select/case) etc. etc.)

Unfortunately even relatively recent COBOL is still frequently written to the appallingly primitive 1974 or earlier standards. But that's not exactly COBOL's fault!

Re:COBOL is a dangerous language

[Anonymous Coward]

***WRONG*** That description describes a very old IBM IMPLEMENTATION of COBOL. Virtually ALL modern COBOLs ARE stack based, and none of those problems occur (though coding in the afore mentioned style is strongly discouraged - for readability and maintainability reasons).

Re:COBOL is a dangerous language

[Anonymous Coward]

Unfortunately even relatively recent COBOL is still frequently written to the appallingly primitive 1974 or earlier standards. But that's not exactly COBOL's fault!

It is and ever will be COBOL's fault, for ever having been such an eldritch horror. Or if that's not good enough reason for you, you'll probably just be required to code in a way compatible with the ancient tools, because they've worked so far and COBOL's COBOL, right?

Re:COBOL is a dangerous language

[Anonymous Coward]

Based on a bad IBM or Honeywell implementation. Virtually all modern (and most older i.e. Burroughs/UNISYS HP, Tandem, etc.) implementations are stack oriented and your straw-man example does not apply. Still no excuse for bad code, though.

Tools that just work

[davidwr]

Some tools' useful life is very short, they fall by the wayside quickly as either technology marches on or they get out-maneuvered in the marketplace a la BetaMax or are obsoleted by law or regulation a la analog television and the 42-50MHz FM Radio band.

I still use pen, paper, and pencils, all inventions which are well over a century old, every day. I rely on the modern printing press and laser printer, which are decades old, almost every day as well. On the other hand, my parents' and grandparents' generations used typewriters every day in business, but those are well on their way to obsolescence for most everyday business uses. My grandchildren's grandchildren may never have to even see a "typewriter style keyboard" outside a museum, holo-vid, or historical RPG.

Re:Tools that just work

[troll8901]

My grandchildren's grandchildren may never have to even see a "typewriter style keyboard" outside a museum, holo-vid, or historical RPG.

Will future people get to experience a "virtual cybersex" session using a screen and a keyboard? In the museum's fully interactive holo-vid, of course.

"Ewwww, people in the past have to type using keyboards? What's the fun in that?"

Ah ... I still relish my memories in MajorBBS' "Teleconference" feature. Chatting with multiple girls at once!

Re:Tools that just work

[DerekLyons]

I agree the useful life time of some tools are cut short by technology and progress. My point is that when it comes to programming languages, their useful life often seems determined not by technology and progress, but by 'technology' and 'progress'. By marketing speak, popularity, and fads.

COBOL Joke

[Haxzaw]

Jack was a COBOL programmer in the mid to late 1990s. After years of being taken for granted and treated as a technological dinosaur by all the Client/Server programmers and website developers, he was finally getting some respect. He'd become a private consultant specializing in Year 2000 conversions. Several years of this relentless, mind-numbing work had taken its toll on Jack. He began having anxiety dreams about the Year 2000. All he could think about was how he could avoid the year 2000 and all that came with it. He tried getting a job with an Orange County web development firm, but couldn't hack it in the end. Jack decided to contact a company that specialized in cryogenics. He made a deal to have himself frozen until March 15th, 2000. The next thing he would know is he'd wake up in the year 2000; after the New Year celebrations and computer debacles; after the leap day. Nothing else to worry about except getting on with his life. He was put into his cryogenic receptacle, the technicians set the revive date, he was given injections to slow his heartbeat to a bare minimum, and that was that. The next thing that Jack saw was an enormous and very modern room filled with excited people. They were all shouting "I can't believe it!" and "It's a miracle" and "He's alive!". There were cameras (unlike any he'd ever seen) and equipment that looked like it came out of a science fiction movie. Someone who was obviously a spokesperson for the group stepped forward. Jack couldn't contain his enthusiasm. "Is it over?" he asked. "Is the year 2000 already here? Are all the millennial parties and promotions and crises all over and done with?" The spokesman explained that there had been a problem with the programming of the timer on Jack's cryogenic receptacle, it hadn't been year 2000 compliant. It was actually eight thousand years later, not the year 2000. Technology had advanced to such a degree that everyone had virtual reality interfaces which allowed them to contact anyone else on the planet. "That sounds terrific," said Jack. "But I'm curious. Why is everybody so interested in me?" "Well," said the spokesman. "The year 10000 is just around the corner, and it says in your files that you know COBOL".

Add 1 to COBOL

[tepples]

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.

Yet we don't want all languages to become APL-style inscrutable symbol-fests either. For example, Python uses "and" where PHP and C use &&, and Python uses "is not" where (roughly) PHP uses !==. If a manager can quickly learn to read the notation without it impeding other desirable features, that's a plus (or should I say a +).

Compare "add 1 to cobol" to "c++".

Re:Add 1 to COBOL

[Virak]

Python is easily the language I use the most, so I'm quite familiar with it. The big difference is that Python merely uses English keywords in place of a few symbols. This isn't a particularly radical difference, most languages already make extensive usage of keywords, and using "and" instead of "&&" doesn't significantly bloat your source code (and e.g., "||" and "or" have the same length). COBOL, however, tries to be like English and not just something that uses English words here and there.

If a manager can quickly learn to read the notation without it impeding other desirable features, that's a plus (or should I say a +).

And the entire point of that little note at the end of my post was that it does impede other desirable features, far more important ones. It's also a fine case of premature optimization. Designing or even understanding a large system is far more difficult of a task than just learning the notation (learning the notation is also only a one-time cost). While it may make it easier to understand a hello world program, a manager who has no programming experience will be just as lost with anything decently-sized no matter how close the language is to English. I've come across more than a few math or physics papers where while I know what all the fancy symbols mean, the actual content is just completely over my head, and writing it out in English wouldn't have improved matters at all.

BOLOC

[GrahamCox]

I invented a similar language once called BOLOC. But I never had the balls to carry it through to market.

Re:BOLOC

[daveime]

You should have used a wheelbarrow.

(Sorry, throwback to an 80's comic featuring Buster Gonad and his Unfeasibly Large Testicles).

Java the new COBOL?

[Tablizer]

It's hard to predict the future, but it seems that Java is becoming the new COBOL. It shares many features with COBOL:

1. Open-standard (or at least semi-open)

2. Runs on many different platforms

3. Not the latest and slickest, but "good enough"

4. Known for its verbosity

5. Compiled

6. More popular on the back-end than the client

Not too many companies want to bet their future infrastructure on MS Dot-Net, especially after MS pulled that VB language switcheroo.

Re:Java the new COBOL?

[Vintermann]

2. Runs on all noteworthy non-embedded platforms.

3. All languages either are in that category, or will come into it shortly (unless they're really not "good enough")

4. - not inherently. Maybe in some standard libraries, but calling any C-syntax language "verbose" is nonsense. You can't have seen Ada. ( I like Ada, BTW.)

5. Compiled? Well, not entirely, not always. Not like COBOL is compiled, anyway.

6. Goes for just about all languages except maybe Javascript...

Re:Java the new COBOL?

[daveime]

7. It's another antiquated dinosaur ?

Re:Java the new COBOL?

[BikeHelmet]

2) The thing is, Java can be debugged/developed on a Windows box and deployed on a Linux box, without any further testing.

I mean, you'd be nuts to actually do it without testing, but if your coders are smart and multi-OS aware there won't be any problems.

I myself wrote a calendar app for personal use, on Windows 2000. One day I tried it on Ubuntu, and everything worked fine - although it looked like shit because Gnome skinning didn't work. Not the same category as a business app, but it didn't even need a recompile. When you can write something java in 2002, and it runs flawlessly on a 2009 OS that didn't exist when it was created, without a recompile... you have to factor that in as a feature.

3) Python? :P

Java's VM is impressive. When flipping from C-based to JVM-based, Python gets about a 2-5x speedup. At this point, Java is "the wheel", for a lot of non-business apps. Re-inventing the wheel in other languages is pointless - just build on top of it.

4) I agree with you here. Although Java encourages readable syntax, it's certainly not the best language available for it.

5) Java running in Server mode is effectively compiled. That's why it starts so slow. Java running in Desktop mode is quasi-compiled. Quasi-compiled works okay, because the Java interpreter is very fast, and it lets Java apps start quicker than C# apps.

6) Python and C/C++ are more popular for front-end apps - probably because there are more front-end apps than back-end apps. Java is extremely popular for DB stuff that connects with webservers. There seems to be a lot of government, banking, and business sites running on Apache Tomcat - but because of the nature of the JVM, each site is running its own unique applications.

add 1 to age giving age

[NonUniqueNickname]

For you youngsters, that's how you write ++age in COBOL. Now get off my lawn.

tags

[smoker2]

Which prick tagged this !kobol ? Does it SAY kobol anywhere in the title, summary or article ? Or is so that you can easily search for kobol later and not find this story (in which case you could have saved your typing) ? FFS. Next time there is a story about google I'm going to tag it !poodle.

18%!?!

[breadstic]

Where were they surveying exactly? Right outside an programming convention?

Not that I've ever been to Australia, so maybe u guys are all really tech savvy, but I doubt that 18% of the population of Britain would know what C or Java are (nevermind cobol), or even what an operating system is...

warheads...

[lordholm]

COBOL will be around for a long time. According to some of the StarTrek episodes, they still in the 24th century use COBOL yield warheads. I find it amazing that a truly hated programming language of our era will still be used to cripple people 300 years in the future.

Cobolscript lives!

[argent]

This is not a joke.

* "Hello world" program
      *
      DISPLAY `Content-type: text/html`.
      DISPLAY LINEFEED.
      DISPLAY `<HTML><BODY>`.
      DISPLAY `<CENTER>Hello World</CENTER>`.
      DISPLAY `</BODY></HTML>`.

Yes, server side scripting in interpreted COBOL.

Sussing out the business rules

[gznork26]

Back in the IT Pleistocene, I had to document and revise a business program that had been converted by software from Autocoder to COBOL. That conversion produced working code with elements named 'variable 1', 'constant 1' and 'subroutine 1'. So my first step was to use the known inputs and outputs to start naming things. The second step was to use the first wave of named things to deduce what the calculations were doing, and therefore be able to name the results of those calculations. Finally, I could put names to the routines. With all that in place, I was able to document the code, and then figure out how to make the requested changes.

My point is that analysis is important, and unless you really understand what that code in front of you is actually doing, you're likely to make assumptions based on what it was supposed to be doing. Black box programming is as reliable as black box voting.

+ + +

What's at the intersection of H. P. Lovecraft and politics? http://wp.me/p4ZDr-4R

Re:Sussing out the business rules

[pwfffff]

Jesus H. Christ, if you didn't get like a million dollars for that shit we need to start a union.

Re:Sussing out the business rules

[gznork26]

Don't I wish. That was on my first software job -- after ditching on a BS in Space Tech near Pad 39B, I entered IT via a bank -- and I got it because it was too distasteful for the higher-paid folks to want to deal with. I have to say that it was instructive, though. Doing that was more practice doing analysis than anything at school.

It works

[cjonslashdot]

Mainframe transaction platforms are rock solid - much more than one can say for most web app platforms.

How can a language be bug-free?

[Benfea]

If you could make a program bug-free just by choosing a particular language, don't you think all programmers would use that language to the exclusion of all others?

Re:How can a language be bug-free?

[thethibs]

That assumes that programmers make well-informed, rational decisions at all times. Chuckle.

Re:How can a language be bug-free?

[bar-agent]

If you could make a program bug-free just by choosing a particular language, don't you think all programmers would use that language to the exclusion of all others?

You'd think so, right? But we've had Ada and Eiffel for how long?

Re:How can a language be bug-free?

[bar-agent]

Oh, and Prolog. Forgot about that one.

I hate to break it to you buddy

[davidwr]

But odds are those weren't girls. Unless of course money changed hands.

In Soviet Russia

[Anonymous Coward]

In Soviet Russia.......
we still write in cobol..

Re:In Soviet Russia

[daveime]

Nice try, you must be new here, but seeing as you posted AC, who knows ?

I think what you meant to say was "In Soviet Russia, COBOL writes you !"

punch cards

[jDeepbeep]

It was always a sight whenever one of those students would drop their stack of cards all over the computing room floor....

A little pencilled number on each one goes a long way. ;)

Re:punch cards

[Ollabelle]

And it seemed that every semester a new batch of students had to learn it.

The London Stock Exchange

[fritsd]

For a while...
Get the Facts: LSE and Microsoft
Unfortunately, I can't find the proud LSE case study on Microsoft's Get the Facts webpage anymore :-(
Strange ;-)

Blame the programmer.

[Petersko]

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

I'm having difficulty imagining how the answer isn't "fire the incompetent front end developer".

Re:Blame the programmer.

[MBGMorden]

I'm having difficulty imagining how the answer isn't "fire the incompetent front end developer".

The app wasn't developed in-house.

Cut our losses, ditch the junk and go with a new vendor (or just do it in-house) is something I'd love to do, but I don't have the authority to make that call.

What's the problem?

[thethibs]

All but a few of the complaints about COBOL are just mindless groans with nothing specific to say. The only specific complaints are about COBOL's verbosity. The irony is that, now that we can have long names for things, verbosity has become a preferred programming practice.

It would be interesting to see a feature-for-feature review of COBOL 2002 against other big, compiled languages.

ATM's running COBOL?

[kindbud]

I doubt it. ATM's talking to a system running COBOL? I doubt it. ATM's talking to a proxy running on Windows or Unix that talks to a mainframe running an app written in COBOL? That's more like it, but probably omits another intermediate step.

I refused to do the COBOL assignment

[presidenteloco]

Way back when I was taking my Comp Sci BSc using stone tools,
I refused to do the COBOL programming assignment, which was
maybe worth 1% of the course mark in Programming Languages.

I didn't want to be qualified for a COBOL job.

I guess I was prejudiced against the all caps and most particularly
the lack of an ELSE statement to go with the IF.

I guess these problems have since been fixed, but I was
also trying to avoid programming accounting systems, which
would have been pretty much certain to have me banging my head
against the desk in boredom.

Amex uses TAL not COBOL

[Anonymous Coward]

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

No, my credit card is processed by a machine running TAL. Seriously, I checked, about twelve years ago. I visited the data center and spoke to the programmers. I doubt they have gone backwards into COBOL since then.

So when is..

[SlashDev]

COBOL 50 coming out?

Gee thanks, Microfocus!

[Nerdposeur]

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.

And I bet they were so grateful to learn! Now lets bring in the accountants, to open our eyes to all the lovely ways that double-entry bookkeeping touches our lives, and the concrete pourers, to explain how frequently we take reinforced concrete for granted.

Seriously, it's supposed to be surprising that most non-programmers haven't heard of your programming language? Most people don't even know what their own organs do.

how should that be possible

[AlgorithMan]

If COBOL still mattered that much today, then WHY can you hardly find any tutorials online? let alone formal language definitions! all I could find were some code examples which acutally look like the language is designed to be "compiled" using search & replace! seriously, it hardly looks like more than ASM with different names for the opcodes...

Re:how should that be possible

[Anonymous Coward]

Because COBOL isn't written, for the most part, by humans, but is more often generated by tools from notations like "action diagrams." Yes, COBOL code represents a huge fraction of real-world business applications, just as x86 binary code supports a huge fraction of end-user productivity and entertainment applications, but neither widespread COBOL skills nor widespread x86 assembly language programming skills are necessarily implied.

survivorship fallacy

[cinnamon colbert]

maybe cobol and language x same in reliability, just the bad cobol stuff got dropped 30 years ago.
like in mutual funds: took economists a long time to realize financial industry skewing results of mutual funds by not including all the funds that are started, but die early

Happy Birthday COBOL

[Anonymous Coward]

One of the rare experiences in my life is to encounter a technology platform that just does its job, only that and nothing more with only reasonable downtime for explainable problems. I have a robot lawnmower that works like that -- just keeps the grass cut to the length I set. As long as I clean it off every so often and lube it on occasion it just keeps going. Pity my robot vacuums are not so well designed.

My experiences with COBOL fall into the same catagory. While I managed to miss working with the stuff, I did take a Cobol course in school and except for the first program (missing period in the environment division) the rest all compiled and ran correctly the first time. Some years later I built a pre-compiler for my employer that modified Cobol programs to permit use of relational expressions with non-relational file architectures. While what I was doing was experimental, the Cobol side of it was stable and predictable -- a far cry from many other languages I have used over the years.

It is a pity that we are in love with the new -- COBOL just does its job and if I had to support business programming again I would prefer a language that the boss could actually read over something new that spread the logic of the program over a vast pool of disconnected pieces. Functionality is where it is at -- especially if there is money involved.

solitare? how about slots!

[vaporland]

when I was a mainframe computer operator in the late 70's I wrote a COBOL program to simulate a slot machine. It ran as a batch job, with the gaming interaction taking place on the system console. it was quite entertaining for long idle night shifts, but management didn't like seeing my timestamped game sessions in the console logs, so the program was quickly retired...

COBOL + X.25

[Loupitour]

The Almighty Combo.

Whippersnapper

[Anonymous Coward]

That Cobol is but a whippersnapper. Mark my words.

F. Ortran

As per below...

[Anonymous Coward]

you fail massively... your line 7 is even missing its full-stop. BIG mistake.
BIG.
And you don't terminate your program. Second major fail.
And the most obvious - where are your CAPS, YOU STUPID LITTLE BOY?

Typical teenager - now, get off our lawns, you idiot.

RIP Cobol

[Twyst3d]

Dear Cobol. Thanks for the memories and all that. We couldnt have done it without you. But, the times they are a moving. And its time you moved on with them. If I had disposal income in the millions. Id hold you the grandest of funerals. For now. I'll have to settle with a pint after work and peeing your name on the alley wall. RIP Cobol.

P.S. Make it two pints so I can pee a heart next to that too