Comment Re:Ruel of Thumb (Score 1) 551
Unfortunately the current strategy seems to be "don't maintain, rewrite." Regardless of the quality of the original code.
Put another way, the programmer's time finally became more valuable than the machine's time. Once that happened, the rules changed - something which those some of those people with "no background in IT" figured out years ago (I hear it's because they had a background in some dark discipline called "accounting") and which a lot of IT people still can't wrap their minds around.
Unfortunately "those people" appear to have a background in accounting and nothing else. Believe it or not, squeezing the last precious, tasty drop of profit from an endeavor is not the ultimate goal.
The problem is, it's much harder to recognize quality, especially in modern products, thus there is no market pressure for it. But there is a market pressure from the investor's end to produce as much things as possible.
Ultimately, it's an issue of asymmetric information and trust.
Bruce Schneier wrote about a similar concept, itself written by American economist George Akerlof.
What I find offensive are the complaints from people who voluntarily go the cheaper route, then complain that the cheaper product [doesn't perform as well | isn't as reliable | doesn't recover from errors as well | etc.] as the product created by idealistic engineers.
It's good for the economy to produce stuff that people have to replace regularly. We should produce crap that breaks every few months.
A project specified mostly by people who don't know what the system is supposed to do, implemented by people who don't understand the business, replacing a legacy system containing within its labyrinthine bowels the combined knowledge of tens or hundreds of expert users past and present. What could possibly go wrong?
You do realize you've just described most reengineering efforts, right?
So why has nobody bootstrapped themselves a bit by writing some libraries or extending/improving the language?
On IBM mainframes, there are the Language Environment (LE) callable services that provide a bit more functionality than native COBOL. Otherwise, most corporations write their own.
Or at least written a good editor. It's been around for a long time. Hasn't some bored guru written his own vi/emacs clone for it in the last 40 years?
There is an Eclipse-based product.
Or improved the compiler to make the errors easier to understand?
IBM reportedly asserts that the error messages from their Enterprise COBOL product are all self-explanatory. IBM's customers have varying opinions of that assertion.
Or addressed any of the other complaints I've seen upthread?
Seriously... Is there something about cobol that makes that effectively impossible?
Like what?
"no pointer/references" - COBOL has had pointers since the 1985 standard.
"low functionality" - What does that mean, specifically?
"[...] not only is all of your data global to your program, in a typical batch cycle all of the data is global to ALL of the programs" - The first part is as true as your application design makes it (you can have more than one program in a source code member (read: file) and it's your choice whether or not the data in the enclosing program is visible to the nested program(s). The second part is true in the same sense that all data in the database is global to an application. Again, if you design something badly, don't blame your tools.
Really, COBOL has its faults, but these aren't them.
"peculiar" "awful" "miserable" "weak" "arcane" - these are just people exhibiting a personal preference. No doubt there is (or was) a problem they needed to solve and COBOL was a bad fit. Or maybe they're just parroting what some instructor or TA told them.
Over the last couple of decades I've been paid to write code in a baker's dozen programming languages on a half-dozen operating systems. No matter which language I'm using, I always get to a point where I wish I could add in just a bit of another's features. I find the most important thing to remember is that different languages have different problem spaces in which they're appropriate.
"Engineering without management is art." -- Jeff Johnson
