Smithsonian Celebrates 50 Years of COBOL 178
wiredog writes "The Atlantic reports the news that the Smithsonian's National Museum of American History has a new section of their website dedicated to documenting COBOL's history. An exhibit will open at the museum this spring."
Good Times (Score:5, Insightful)
It may be crass to admit, but I had some great experiences working in my first COBOL position. Sure it dates me...so what, I got a lawn and am proud of it. I do appreciate the development tools I use as a current developer, but something about the simplicity, and the structure make me feel nostalgic. Lately I see code with no documentation, no good structure and buggy. COBOL, FORTRAN, and Pascal separated IT programmers (and staff) from middle managers and office workers that today think writing an Access VBA makes them a .net developer. You can't go back (nor would I, but for the need of a job), yet I would like to see some of the foundations that went into development groups make a comeback.
Re:Oh My... (Score:4, Insightful)
Dear God, I'm old.
"Celebrates"? (Score:4, Insightful)
Is "Celebrates" the correct word to use in this context?
Re:I thought COBOL basically died after Y2K. (Score:5, Insightful)
While that's likely true, it's hardly unique to COBOL.
Any codebase which is over, say, 5 years or more, is likely creaking under its own weight and nobody really knows how all of the parts work anymore.
The software also likely runs day in, day out, 365 days/year, and does everything it has been developed to do. I've seen projects that try to replace such legacy systems -- after you've spent millions trying to write something new which does most of what you need, you discover that there's huge gaping holes in your coverage, and you're nowhere near where you'd need to be to replace it. Often, the project gets scrapped at that point as people realize you're never going to be a viable replacement.
Hell, I knew a guy in the 90s who was retired from a company, and drawing his full pension, and working as a consultant at big $$$ rates to maintain the stuff he did before he got paid. All said and done, he was making about 4x in retirement what he made before he retired. They simply had no other people who could have possibly had the 30 years of experience he had on this mammoth system which ran on mainframes.
Trying to get rid of that old creaky legacy code is nigh on impossible in some cases.
Re:I thought COBOL basically died after Y2K. (Score:4, Insightful)
A high enough threshold for expensive can make for impossible.
Not hardly. This was several senior people on both sides all trying to capture requirements and understand the scope. By necessity, their own senior people had to limit the scope of the initial project.
Over time, however, you discover everything that the legacy software does ... and frequently discover that half of what they told you about the system is utterly false, and the other half was woefully incomplete. So, everything you've built in that depends on your understanding of uniqueness, scope, and content ... well, suddenly none of that is true (and quite possibly never was across the whole system).
I question if you've been involved in replacing a legacy application with 30+ years of history and data in it.
This isn't about people not being on board, or some lame-ass low bid by someone who didn't understand what they'd gotten into. Some of these systems have effectively been built up iteratively over decades, and are business critical. Replacing them can be completely non-trivial ... and, in some cases, almost insurmountable without massive investments.
Mainframes = Non-disposable code (Score:4, Insightful)
Yeah, it is real easy to get all snarky about COBOL. I have always hated it even though it was a popular language when I was in school (late 70's). My CS department had three separate non-overlapping courses you could take.
The thing is that just about any programmer, even if they don't know COBOL, could go in and change it. COBOL is readable. The record based functionality is simple to comprehend. Something written 30 years ago is still running because there is nothing wrong with it. It does what its supposed to do. It was the perfect solution to the most important business problems of its day, and that legacy is why it is still around while other languages of its era are not.
Should new programs be written in it? HELL NO!!!! The problem set to which COBOL applies is pretty well solved. The new problems require new solutions.
-Xanthos