Slashdot Mirror
COBOL Turning 50, Still Important
Death Metal writes with this excerpt from a story about COBOL's influence as it approaches 50 years in existence:
"According to David Stephenson, the UK manager for the software provider Micro Focus, 'some 70% to 80% of UK plc business transactions are still based on COBOL.' ... Mike Gilpin, from the market research company Forrester, says that the company's most recent related survey found that 32% of enterprises say they still use COBOL for development or maintenance. ... A lot of this maintenance and development takes place on IBM products. The company's software group director of product delivery and strategy, Charles Chu, says that he doesn't think 'legacy' is pejorative. 'Business constantly evolves,' he adds, 'but there are 250bn lines of COBOL code working well worldwide. Why would companies replace systems that are working well?'"
Why would companies replace systems that are working well?
Because the director of IT or whatever his title is will want to be able to put on his resume that HE moved a company from a "Legacy" and "Outdated" system to a modern "web based solution" that enables "greater productivity" among the workforce saving "millions of dollars". Now, he can put that on his resume and go for the CTO, CIO, or whatever jobs.
I've seen it and it works.
Why would companies replace systems that are working well?
So I can have a fucking job?
Being a new whippersnapper, how about some age old COBOL Jokes?
I'll get off your lawn now sir... ;)
I managed to finally figure out their world domination plan!
It's definitely not the Bilderberger group otherwise it would have been called boldorborgor. Naah, too borgish.
"Why would companies replace systems that are working well?" Strategically, this is a less important question than "would companies know how to replace their current systems if they wanted to (or had to)"? If all of the COBOL-hosted I/O is well-formed and buzzword-compliant, then perhaps it wouldn't matter (at least as long as what runs it can be replaced).
Does that mean my Java skill set is likely to keep me employed for the next 30 to 40 years?
Democracy Now! - your daily, uncensored, corporate-free
Before I start, I know all too well that you can write good or terrible code in any language. Still, most COBOL code I've seen is written to run well on hardware that is no longer relevant. A recent experience with an ex-coworker illustrated this pretty well for me:
Said fellow, call him "Joe", had about 30 years of COBOL experience. We're a Python shop but hired him based on his general coding abilities. The problem was that he wrote COBOL in every language he used, and the results were disastrous. He was used to optimizing for tiny RAM machines or tight resource allocations and did things like querying the database with a rather complex join for each record out of quite a few million. I stepped in to look at his code because it took about 4 hours to run and was slamming the database most of the time. I re-wrote part of it with a bit of caching and got the run-time down to 8 seconds. (Choose to believe me or not, but I'd testify to those numbers in court.) I gave it back to him, he made some modifications, and tried it again - 3 hours this time. I asked him what on Earth he'd done to re-break the program, and he'd pretty much stripped out my caching. Why? Because it used almost half a gig of RAM! on his desktop and he thought that was abhorrent.
Never mind that it was going to be run on a server with 8GB of RAM, and that I'd much rather use .5GB for 8 seconds than 1MB for 3 hours of intense activity.
So Joe isn't every COBOL programmer, but you and I both know that he's a lot of them. But back to the direct point, how much of that 250GLOC was written with the assumption that it'd be running on 512KB machines or with glacial hard drives or where making the executable as tiny as possible was an extreme priority? Doing things like storing cache data in hash tables would've been obscenely expensive back in the day, so those old algorithms were designed to be hyper-efficient and dog slow. Whether you think that constitutes "working well" is up to you.
Dewey, what part of this looks like authorities should be involved?
COBOL: Completely Obsolete Business Oriented Language
COBOL in the future
Why not translate? COBOL to C++ translators.
COBOL's still around, will perl last as long?
For instance there is now OO COBOL but the only people that use it are COBOL programmers who are stuck, perhaps because of their company's dictates, perhaps by choice, with COBOL. In the same way perl may be heading towards irrelevance wrt "mainstream" language. I've written commercial perl in the past, it was a pain then and it's still a pain now. The thing is that now there are alternative languages in the same space (python, ruby etc., php for web side) that do the "perl thing" better than perl.
Perl was great, it introduced many people to programming, just like COBOL did. But now it's time to move on. To move on to languages that learnt from perl, that improved on it, that don't have to drag around a syntax and culture that values neat tricks and trying to guess what the programmer really meant over providing the needed building blocks and letting you build code that does what you say, not what it thinks it heard you say. Or even, dare I say it, to move on to languages outside the perl family for some programming and choose the right tool for the job for a change.
I'd prefer to think of this as provocative rather than a flame, there is a difference you know.
That's what I get get for learning FORTRAN in college rather than COBOL...
at least my mad HTML skills..
oh wait... all websites are in FLASH or PHP now...
DOH!
Ok.. im going back to watch a movie on my Betamax or HD-DVD player....
Don't rush me, Sonny. You rush a miracle man, you get rotten miracles.
Comment removed based on user account deletion
COBOL is a perfect example of an "adequate" language, like most programming languages that are in common use. Adequate languages linger forever if there is a tool chain to support them because there is little in the way of economic rationale for replacing them.
The reason adequate languages proliferate over the long term is that only inadequate languages get replaced, and "ideal" languages become hopelessly politicized by purists and ideologues, leaving the adequate, practical, boring languages as the sound business choice. It is a real-world example of perfect being the enemy of good enough, but for economic reasons good enough always wins.
As just one data point, a certain place replaced a COBOL app that ran with millisecond response time just fine on a 2 megabyte 1 MIPS mainframe, replaced it with a spankin' fresh Java app that ran about 2000 times slower on an 8 gig 16-CPU, 800MHz very expensive water-cooled mainframe.
Now it could have been due to having a bunch of neophyte Java weenies doing the coding, but I'm just sayin', when there's three orders of speed and 3.5 orders of RAM, there may be something significant in the implementation language.
When I was working on my CS undergrad degree, more than one professor told me that I was really limiting my job prospects because I declined to take the elective COBOL classes. I knew enough about COBOL then to know that I could not drag myself out of bed in the morning to make a living with it.
The ranks of COBOL programmers out there are living drone like lives without passion or joy. That's not for me. I code for the love if it.
Why would companies replace systems that are working well?
The question is not, 'Does the code work?', the question is, 'Does the code follow good design principles?' If the answer is 'No, the code is not well-designed', then maintenance can be very costly. I like the snippet from this page:
"I was once told by an instructor in a design patterns class that the Y2K problem wasn't caused by using 2 digits to represent 4. Instead, it was caused by doing so all over the place. While the reality of the situation is a little more complicated than that, the principle is true. If the date handling code had been all in one place, a single change would have fixed the whole codebase rather than having to pull tons of Cobol coders out of retirement to fix all the business applications."
If and only if they're able to pull it off. It's also a nice way to end your carreer if you fail.
Just change company before failure becomes apparent. Then you prepared it all so well and successor just it all up.
Why is no one updating Cobol code? Because the skill to interact with other systems is disappearing.
As a Mainframe Utilities Programmer I hear it from customers all the time. "We can't touch that system because the guy who wrote it retired." System here just represent the code, but also the server backend stuff like database design.
I have heard stories of an IT department being 10 man team. In the 80s that team had everyone dedicated in maintaining the mainframes. Now, they still have 10 people but only 1 person is there to work on the Mainframe.
So now you have code from the 70s that no one understands, running a mission critical application, and you think the IT manager is going to touch it? He is praying it doesnt break on his watch or he might get a call from the COO. Even if it breaks, it is better to patch it then rewrite it because the database behind it is so vital to all the rest of the application that it cant be changed either.
The issue mainly is that no one is teaching old skills anymore. Skills that are still required, but really arent 'sexy' for young college students to learn. Even the name "Mainframe" has grandfather connotation to it while if people actually looked at the IBM Z Servers, one would see how high tech these systems actually are.
1. Cobol programs where written so bad and confusing that probably only the original programmer (he was the original maintainer) was able to maintain it.
2. The company was grabbed by the balls by the provider, who - along with the maintainer -, kept on saying "we can't assure that if you migrate this all will work fine".
and, since it was a "critical" application, we never migrated it. Managers never minded that in a demo I showed them the response with PostgreSQL was about 8 times faster.
that is what cobol was and is good for, grabbing a company by the balls and make it pay money to a provider for eternity. It's like having your main software written in obfuscated perl.
- Human knowledge belongs to the world
Hmmm. I suppose it could be that between the times that COBOL was developed (Grace Murray Hopper, FTW), and today...
There is more to a language than just being Turing-complete. There is syntax and geneeral usability, for example.
I know that there are still jobs out there for COBOL programmers. And it makes me sad.
It's more than adequate because it natively handles money data in transparently correct ways. Other languages have to be bent to fit. Integer and double precision data simply do not meet the need, though these days with 64bit integers it is easier to warp integers to be usable.
In addition it let one record right-size fields on disk and tape (in a day when disks were small and very very expensive).
I'm glad I no longer write code in COBOL, but for many years it was the only choice possible for business.
It was amusing in the 60s 70s 80s reading papers suggesting (32bit) integers and double precision (in C or whatever) as an alternative to COBOL data types. I guess the authors never kept their checkbook to the penny or never had as many as 5 billion pennies in that checkbook.
Sure, greater productivity is one benefit, but the language is completely irrelevant for that.
It's about how flexible the system will be when you have to change it. And you will -- that's the whole point of software, that it is soft, and changeable.
Old Cobol apps generally are not flexible. (stolen from this comment). It's worth mentioning that a decent object-oriented system would've gone a long way towards eliminating this problem -- any idiot can stuff a date into a Date class, which then encapsulates all the date-handling code.
Maybe some of it is very well designed. Drupal proves that you can write good, elegant code in any language, even if you are fighting the language and reinventing the wheel every step of the way. But the converse is also true -- you can write bad COBOL in any language.
My point here is that when changing minimum wage is even a tech story at all, that program is really fucking broken*. It's very likely too broken to be patched. Really, we've learned things in the past 50 years, and not all of them are buzzwords or ways to waste five times the RAM.
Not all of them have anything to do with programming languages, either, but if you're building a new system, and you have a choice of languages, why would you choose COBOL?
I agree in spirit. But what people have to remember is, if it ain't broke, don't fix it. So, if it's broke, fix it!
* I apologize for the profanity, but any program that can't change a fucking constant is a broken program. Or did they copy/paste 6.55 all over the place?
Don't thank God, thank a doctor!
Most COBOL books and tutorials are unavailable, out-of-print, or just plain gone.
What resources still exist for someone who wants to learn COBOL?
http://www.opencobol.org can easily be installed on Fedora Linux (for example) with a simple "yum install open-cobol", but what comes next?
If you're a zombie and you know it, bite your friend!
How does this add up?
1. Around a third of UK companies say they have even at least one COBOL program somewhere in their enterprise.
2. Around three quarters of all UK electronic business is coded in COBOL.
I'm aware that there are allegedly pockets of COBOL here and there with some fairly significant nuclei of usage within certain business sectors but seriously... 80% of all electronic transactions?
Monster.co.uk search for single keyword in title, 11th Apr 2009:
Java: 173 hits
C++: 142 hits
PHP: 95 hits
Perl: 39 hits
COBOL: 1 hit
This doesn't seem to suggest a great demand for COBOL coders at present which - one would think - suggests little use of COBOL.
I've heard this "the world secretly runs on COBOL" story countless times over my career, but seldom seen more than a few lines of COBOL actually deployed in businesses I've worked with. Is the whole thing just a weird industry myth?
OMG!!! Ponies!!!
Its not just the mythical "mission critical" aspect that keeps businesses dependent on COBOL. MANY of those programs required either financial analysts to "vet" the COBOL program, or lawyers to "vet" the COBOL program complied with laws (privacy, methods of determinations, etc.).
Not just are you putting in the cost to refactor the program from scratch, not just are you risking a bug costing your company hundreds of millions to billions of dollars, but you also have to take in the costs of expensive NON-programmers to "bless" the new program.
Then also realize that the new whizbang technologies like SQL and java will RUN LIKE A DOG compared to the COBOL program. That's because mainframes are optimized data I/O machines. They're not great for making intense calculations or retrieving indexed relationships, but they are a BEAST when it comes to pulling out gigabytes of user data, and then making simple calculations and updates to each. It also sounds like top notch COBOL programmers programmed to the machine for efficiency. That's not really done anymore by generic programmers.
New shops don't have to consider COBOL. But any large company (and gov't) could potentially take a huge hit on their finances (in legal issues) if refactor project has a bug. You can roll the dice, or you can just pay another couple million/year and hope nothing ever forces you to consider replacing your legacy COBOL programs that no one knows how they work, or how to change them.
There is no America. There is no democracy. There is only IBM and AT&T and DuPont, Dow, General Electric, and Exxon
As someone managing a number of legacy mainframe/cobol systems (we do pl/1 too), the biggest reasons to move away from them break down like this: #1: Cost - Mainframe hardware is expensive, support is expensive, keeping or contracting programmers are expensive. #2: Availability - Finding a competent cobol programmer is much more difficult than it used to be, while you throw a rock and you'll hit 20 perl/java programmers. #3: Maintenance - Programs that have been written 30 years ago, and have been updated year after year, mostly poor documentation are hard to keep going, and require more person effort to do so. #4: Flexibility - Out business has been changing over the last 30 years, how can one expect something written that long ago to continue to last the tide. It may be working now, but when that next important change comes down, it may take significantly longer to respond.
I've had an interesting run through IT environments so far. Each one of my employers has successfully used what would be called a "legacy system" to do core business transactions. I'm not old by any means, but I definitely see no reason to get rid of systems that are performing well.
The qualification for that statement, of course, is "performing well." The side effect to using older systems is all the bolt-ons you have to use to get newer functionality working. My current employer uses a midrange system from the early 80s to run the core of the operation, and it has tons of extra software and hardware riding on top of it to do modern things like access without terminal emulators and message queuing. The time to consider a replacement is when these systems become too unwieldy or brittle to manage. For example, if a transaction-processing system needs a daily FTP feed from some source, and it doesn't get it, will that blow up the whole system? If the answer is yes, it's time to fix the problem or replace the underlying system if it's bad enough.
I'm very skeptical of anyone who comes in and says, barely looking at the existing system, that it needs to be ripped and replaced. A lot of it stems from the fact that IT hasn't matured all the way yet. People still come into the field knowing little more than the Java they were taught in school, and don't have the big-picture attitude you need to really understand IT. You may think I'm an old fart, but I'm really not. I've learned the basic rule of IT -- you're not there to play with computers and have fun. You're there to make sure the business you support is able to do their work, preferably without calling you in every night to fix something.
Why would you want to replace 2 billion lines of working COBOL code?
Easy...COBOL, while still in use and working well now, is not a language which is still growing...it is shrinking. Nobody would choose COBOL for a new project. The only jobs left for COBOL programming are maintenance. That means that there are no "exciting" COBOL jobs, and that only coders who learned COBOL, not engineers who are good at design or interested in building/maintaining good design.
"So it's old and all you can get is people willing to maintain, not engineer, the COBOL universe. so what?"
Well, what's what is that:
a) over time, code maintained by "coders" rather than "engineers" i.e. those who are simply proficient in a language, rather those with true engineering talent, will degrade. I have worked with both. I notice a trend. Those with engineering talent...a knack for understanding large systems at a high level and seeing bigger pictures, tend to improve the cleanliness, stability, and re-usability of existing code as they fix or extend it, because they look at the big picture and try to make a change such that it works well in the whole system. "Coders" tend to find the location where the logic goes wrong, and make the most obvious spot adjustment to make the problem go away. Even extensions are treated similarly. Hence, with mostly these types of engineers working on COBOL code, those systems are going to degrade over time. This effect can happen rapidly...I've seen it happen to code that was less than 5 years old. The fact that COBOL code still works is probably more a side effect that all coders of that generation had some engineering skills beaten into them. The younger generation with their "learn a language and get paid" mentality will bring that code to it's knees in a decade or less.
(a) implies problem #2:
b) With code which will degrade as younger, less "design" oriented maintainers are forced to take it over, maintenance becomes a primary concern. Yet as the language gets older, and the code ages and begins to break, gaining more of a reputation for being in shambles, there will be less interest in working on it. Meaning that each generation will produce fewer and fewer COBOL programmers, an effect we are already seeing.
Businesses will be content to sit back and look at their well working, low cost maintenance systems, and think that things will always be that way as long as the don't ask anything new of the system that will cause it to need replacing. This is NOT the case. Eventually COBOL programmers will be all but gone, and those that remain will come at a high premium, and there will not be enough for everybody. At that point, the code will start to break, with nobody to maintain it.
This is when businesses will freak out and think "we need to replace this COBOL program with something in a modern language that we can find programmers for." Except that these old systems are probably not well documented at an algorithm level. The best document is, well, the code. So what they will need is simply someone willing to read through the old code and duplicate it's behavior in a more modern program. Well that doesn't sound SO hard..except, wait, what? You mean, in order to port a program away from COBOL, you need an engineer who still _understands_ COBOL? oh, crap...
"The GPL is viral by design, like any good religion."
In a lot of environments in-house web apps would only serve the purpose of being trendy. I suspect a company who is smart enough to keep their working code around would probably resist the temptation of unnecessary "webizing" their internal apps.
I am a physicist but i think about switching the job to softrware development. COBOL is one of the languages i consider to learn for a living (i wrote productive applications in pascal,basic,c,assembler,perl,python.lisp,tcl,java,javascript,tcl,matlab,shell languages). Any comments how to start from this starting point?
Get off my blue box!
Now you see why IBM embraces Java.
They've been saying the same thing about Smalltalk for years, but yet, it doesn't seem to actually happen.
Could you imagine if the FSF guys created a programming language. Like GNUbol--the first programming language that protects your Freedom(tm). It could have freedom protecting measures like only being able to compile on Certified Free Software. The official text editor of GNUbol, EMACS, would offer Freedom Enhancements like the ability to hit META L + DEL + SHIFT + @ and get a view of the assembly code generated for every statement. You could edit the assembly code or even change the microcode on the GPL'd GNUPU (GNU processing unit, the only GNU/CPU supported (though we prefer to call every CPU GNU/CPU because they wouldn't have anything to run without award winning GNU tools like cat, y, and pushd)). Since the entire stack, from GNUPU to the text editor is licensed under the GPL, you could rest easy knowing all software you create will automatically be licensed under the GPL!
I kid, I kid. Clearly you couldn't edit the GNUPU , at least in version 0.03. Maybe in 0.1, but that is many years from now.
But yes, you are right. If there isn't a politicized language, there should be.
When you want to be sure your financial calculations are accurate and not subject to floating point shenanigans
Quick disclaimer: IAACP (or rather I was in an earlier life, when I had to be).
COBOL's main drawback was never any real technical issue. It is simply that it can be very tedious to do. Having said that, once you understand it, it is also a very easy language to code in. But there's certainly no reason to throw away the code just because it isn't trendy any more.
Having said that, I do remember working on a site in the UK back in the '80s where the COBOL source to some important routines had long since disappeared, and my job was to patch the binary directly. Now that DOES take a bit of concentration. (Fun, though.)
> I declined to take the elective COBOL classes.
> I knew enough about COBOL then to know that I
> could not drag myself out of bed in the morning
> to make a living with it.
COBOL also encourages "heroic" programming. At a shop I worked at, they were very disparaging of the new systems using relational databases, and proud of the mainframe COBOL stuff, because it never went down.
If you don't count the 4 times in one year a hardware failure caused critical business systems to go offline for 2 days to 3 weeks at a time while teams of COBOL coders used tools to manually delete and rebuild tables and indexes when various failures caused -extensive data corruption-.
And the corrupt data caused by operator errors in nightly batch processing.
And the recoding to fix a major financials bug that went undetected for 10 years until we compared the numbers on the external PC system.
You see, that was "normal operations." by contrast, when a network failure occurred and the relational systems we built went offline for 45 minutes, and data recovery was "re-run the job", -that- was a disaster caused by the "sloppy PC programmers and their tinkertoy PC systems."
COBOL's great stuff...if you like being paged at all hours to manually fix data.
The Tao gave birth to machine language. Machine language gave birth to the assembler. The assembler gave birth to the compiler. Now there are ten thousand languages. Each language has its purpose, however humble. Each language expresses the Yin and Yang of software. Each language has its place within the Tao. But do not program in COBOL if you can avoid it.
The Tao of Programming, Book 1, Verse 3.
Help stamp out iliturcy.
My doctors discover that I have cancer and I will die, unless they put me into suspended animation and freeze me and the cancer so it does not spread until they can find a cure. But I have to sign an agreement that in order to pay for the cure and suspended animation I have to agree to work a job for the company that sponsors the cure and freezing.
So I sign, and wake up in 9999 AD and they cure my cancer.
I go to human resources for the company that paid for my freezing and cure and the HR director says:
"So, Orion Blastar, I see you are a computer programmer and I also see that you know COBOL. We have a Y10K problem and need to make all of our programs work with five digit years. You'll be spending the rest of your life debugging COBOL programs to solve the Y10K problem."
COBOL is not a dead language, it is an undead language like a Zombie or Vampire it is very hard to kill, as well as hard to work with.
Remember, Slashdot does not have a -1 disagree moderation, and no, troll, flamebait, and overrated are not substitutes.
Now where did Boomer and Star Buck get off to?
I may not be a smart man, but I know what an inode is.
As I understand it, it is a very common practice to train 23 year old guest workers to maintain the legacy COBOL systems.
At my company, all the time, the salesperson says "this new system will solve all your problems-will take 12 months to implement max, and be very cheap to maintain!!!"
And the executives bite on it every time.
And lately, everything is going to "end of life". Excuse me? Cobol, RPG, and Java don't seem to go to end of life. I'm sure there are others.
It's really hard when you finish a 2 year project (should have been 1 in salesman land), roll it out and debug production issues over the next year, and then 2 years later, it is "end of life".
I guess it's good to keep me employed but it seems kinda dumb.
"Wierd.. slasdot requires a wait... "It's been THREE minutes" --- at work it varies -- sometimes at 16 seconds it lets you posts while other times it takes the full minute.
She was like chocolate when she drank... semi-sweet at first and then increasingly bitter.
Comment removed based on user account deletion
David Gerrold (SF author) once told me the story of reading a manuscript by a new author. After he finished it he looked at the author for a moment before asking him: "And how long have you been a COBOL programmer?"
Yes the person was a long-time COBOL programmer, and yes David G. obviously knew enough about COBOL to know it when he saw it.
I do know from personal experience that DG had a keen understanding of what computers and programming might accomplish when he asked what it would take to design a device to automate the process of writing and editing manuscripts. He described a completely functional Word Processing system years before I saw and used my first DEC WPS-78 system, back in the days when all we had were simple text editors for writing code.
"It's the height of ridiculousness to say for those 9 lines you get hundreds of millions."
But this one doesn't involve turnips.
Isn't it about time someone made a COBOL compiler for the JVM/Java platform?
Could you imagine just how excited the PHBs and IBM mainframers would be?
Stick Men
If you think writing code for Java 5+ is "fashion," I don't think you're a very experienced programmer.
Generics and java.util.Concurrent are mandatory for scalable systems nowadays. Java 5 added a lot of features to make code more reliable, not mindless fluff.
If you're not using the latest features of the language where appropriate, you're doing your employer a huge disservice.
Sorry, buddy, but you need to learn your technology. Just because people will employ you to write on outdated systems, doesn't mean you're doing your company a favor by refusing to learn the latest technologies and writing your code to run on JDK 1.4.
That doesn't mean the rest of us need to give a $@*
You fools, COBOL is immortal because of the Lords of COBOL. COBOL can neither be created nor destroyed...
[signature]
I hear they are working on COBOL dev kit (CDK) for iPhone. Cobol-relation mapping (CRM) is an active topic as you know.
Cobol turning 50, still important. Buys convertible, viagra.
I first developed cobol based systems 32 years ago, along the way I was architect and designer of, amongst a number of large systems, DEC's global currency management systems - 40 clusters worldwide operating 365/24, with self healing properties. I built a ton of systems in the interim, though no cobol for 20 years, all the time trying to lose programming altogether from the steps between definition and delivery. I have effectively achieved this (www.2di2d.com), using ubiquitous tools. So, to answer the question posed, yes, there is value in replacing, because 250bn lines of code, whilst robust, ultimately becomes inpenetrable. It must, however, be replaced with something far simpler, more robust and certainly more transparent.
Based on the idea that COBOL is reasonably mature -- which is to say that the various versions and flavors are not going through the language version update of the quarter -- how about an overlay UI in some appropriate flavor (Java/Python/Turbo Pascal/whatever).
Dreamweaver was great because it hid all the Javascript stuff and HTML. It did the grunt work for you. Likewise, the current crop of CMS programs hide the base code by letting the user go straight to functionality. So, how about a COBOL tool that would:
- translate source into equivalent (language of choice) code
- identify loops, variables, constants, and so on.
- etc, etc, to suit.
Do you code directly in assembly or use an editor? It's like that. How deep do you have to go to polish the code enough to get reasonable speeds? If you have to play directly with the stacks, sure... you have to know all the bits and bobs. But if it's just consolidating a swarm of assigned constants into a table and letting them be modifiable, is COBOL really that opaque?
There is always money in a better mousetrap and more effective user/maintainer interface. COBOL could sure use one from the sounds of it!
Pacifist paratroopers yell, "Ghandi!" when they jump.
80 is the new 70. seriously. people would rather die on the job than retire ( and some of them have no choice because without a job they have no health care and would die anyway )
if i was your guys boss, i would kick both your asses. grow the hell up and get the damn program to run as the customer needs it to run, i dont care about your pissing games or how stupid you think each other are. you wasted all this time farting around with your personal issues instead of working. the janitor contributes more to this company than you do and is far more efficient. he doesnt sit around with his colleagues arguing about soap density for days on end while the toilet overflows. explain to me why i shouldnt train him to write code, promote him, and fire both of you for jacking off instead of doing your job.
...fixed that for you.
It's a little strange to talk about how old COBOL is when C came out in 1972. These languages were the obvious solutions to computing problems. It's not a surprise they'll be around for a while.
No COBOL-related article should go without a link to the list.
Pretty good is actually pretty bad.
This completely explains everything about the Lords of Cobol and the final episode of BSG!
(Which makes at least as much sense as the final episode made.)
seems that cobol has some good frameworks that could compete with rails and growing django
it's supported on modern web type terminals VT100 compatible
http://www.reddit.com/r/programming/comments/8bpdq/cobol_on_cogs_supports_standard_terminals_vt100/
developer http://flamerobin.org
most companies keep there COBOL systems running because no one is left that knows how they were originally set-up well enough to build a replacement. I know of a couple of places still running COBOL on Wangs because no-one knows how they work.
I worked for a company that tries to prot apps from COBOL to jva, web architecture... The java was slow, the users hated it. It stalled after it took about 4 times longer than expected to port the functionality from COBOL to Java.
What I say is Legacy == Tested :)
divide apples by people giving applesperperson
Sure, it is verbose, but I think the above statement is easier to read and understand than "float applesperperson=apples/people;". It might get worse with longer programs, of course.
Why do people hear mainframe and automatically thing cobol? There are other language compilers available on the mainframe (like C++). Associating Cobol with mainframes gives mainframes a bad name.
Coder's Stone: The programming language quick ref for iPad