Slashdot Mirror
Modernizing the Common Language - COBOL
Frumious Wombat writes "Over at the Register Developers section, they are quoting the head of research for Ovum Consulting on the continuing dominance of COBOL in certain business applications. The antique language accounted for 75% of all business transactions last year, and some 90% of financial transactions. For all the time spent arguing the merits of Ruby vs. C#, should the community spend more time building tools to make COBOL livable? The article goes into what it terms 'legacy modernization', and lays out some details on how to go about it. From the article: 'The first stage in the legacy modernization process is to understand the business value embodied within legacy systems. This means that developers must give business domain experts (business analysts) access to the legacy, using tools that help them find their way around it at the business level. Some awareness of, say, COBOL and of the legacy architectures will be helpful but we aren't talking about programmers rooting around in code - modern tools can automate much of this analysis for staff working at a higher level.'"
Comment removed based on user account deletion
Honestly. You have some points, but one of the greatest in COBOL's favour is it's pervasivness.
A few years ago I was working at a job where we were doing everything in a 4th Generation Language. We got outsourced (thanks to a CIO who just popped in for a couple years to pad his resumee) to a company which had an integrated product written entirely in COBOL. (Of course they ran their code on an HP platform, which by now has been retired and HP support will soon, also end. COBOL survives because people still develop and keep old business apps written in it. Some work, by code, never changes.
The other major advantage of COBOL is it's library for handling business computation and I/O. That stuff exists in other languanges, but as an example with Microsoft's Visual Studio, it's all done differently (and somewhat stupidly re-defining formatting for the nth time.)
A feeling of having made the same mistake before: Deja Foobar
The big advantage COBOL has is that the language is serious about data storage. The language knows about structured files, databases, indices, and formatted fields. COBOL was the first language to have data structures.
Look at what a mess it is to talk to a database from Perl, Python, Java, or C/C++. There's fussy glue code required, and the language doesn't help you make sure that field XYZ in the database comes out as field XYZ in the program. In COBOL, it's straightforward. The language knows about databases. There's even a good interface to MySQL.
It also has some formatting capabilities that HTML should have had. You can write CREDIT-CARD-NUMBER PICTURE 9999-9999-9999-9999. In some systems, that will eventually result in an input field on a green screen that will only accept four fields of all numbers with all digits filled in and will display a blank form field accordingly. HTML FORM fields should have worked that way.
There are some real advantages to a language where components outside the individual programs can see, check, and use the data declarations.
You can take a fresh wet behind the ears kid, give him the code, and he can figure out what's going on without any significant trouble
I disagree. I once was that kid. It is much harder than you imagine. Why?
1) Sphaghetti code. Lots and lots of sphaghetti code. COBOL, despite improvements, is still not much more structured than assembly. It was doing maint. programming in COBOL that I vowed in all future development to try to be kind to the maint. programmer.
2) The kid still has to learn the problem domain. I do not understand the mind set where a person says "I don't need to know the busness, just let me code it". With out the background knowledge you never know if what you are doing is right, reasonable, solves a domain problem or if it over laps another part of the problem domain so that code can be shared. In fact, learning the problem you are solving is the hardest part.
putting the 'B' in LGBTQ+
Sorry but I had to let that one out. "Code that matches my passion." is priceless.
When you start looking at a mortgage payment, car payment, grocery bill, doctor bill, etc. you'll realize that you work on something you can do well. Save your passion for your hobbies. Code on the bleeding edge at home.
Do you honestly expect business to conform to what you want to do instead of what works for them? Answer truly. And if you don't come up with "Heck no!" you need to rethink how it works.
Sure COBOL may not be for you. Good deal. Don't learn it. But if you're applying for a job and they need LegacySystem 5.7 and you tell them you don't know it, won't learn it, but would consider writing in BleedingEdgeSystem 0.54 you can pretty much figure out what the answer is going to be.
I've been coding since 1976. Yes, 1976. I've learned many languages. Some I've liked, some I haven't. But if the business needs it I learn it. Sometimes I learn it just because I want to. I missed out on COBOL (don't ask) but may just add it to my list of things I want to investigate.
I'm not being a troll or at least I'm not trying to be one. Some people will probably read that first exclamation and not go any farther. But sometimes you really do have to wake up and smell yesterday's coffee burning in the pot.
... I can program in C/C++, Pascal/Delphi, Java, VB/Basic, Perl, a bit of Ruby, Python, and several shell scripting languages/applications like sed/awk. I find cobol to be the most obnoxious pain in the ass language I've ever used. I had to take two semesters of it in college and I hate it. I hate it just like I hate RPG. They're underpowered, obnoxious, and annoying to work with. Screw cobol, screw rpg. I'd sooner bag groceries than program in either language.
Shadus