Not true - cobol code is often very unstructured. It's very difficult to limit variable scope in cobol, and functions that would normally be a few lines long have so much cobol boilerplate around them that each "function" is usually put into its own source file.
Try dealing with "just" 14k lines of cobol that you haven't written; try to make minor changes to it (and wait a minute for your $3000 piece of shit Micro Focus compiler to run) without breaking things. Try getting fed up and spending a year of your life rewriting the code in Pascal. You won't like it, but when you're done, you'll say "thank god i'm free of cobol!"
Come to think of it, Micro Focus is usually behind these lame annual PR campaigns to try to drum up talk about cobol. Their business isn't growing. Some reasons:
* Installing their product is a big pain. (At least on Solaris/SPARC and Linux.) Bugs in the installer script mean that you have to spend an hour or more on the phone just to install their junk. Support is included with the $3000 fee, but only for a year. So if and when you have to reinstall, prepare to pay a few hundred for the incident.
* Their product uses flexlm, and it sucks just like most consumer DRM, only worse, because it's buggy. I imagine that MF sees it as another form of copy-protection.
* The compiler doesn't play nicely with make, so when you rebuild your project, object files that are up-to-date are recompiled anyway.
* Interoperability with other languages and database systems is so cumbersome that you'll just end up writing output into some cumbersome flat text file, and have the rest of your system poll it to display progress from to your cobol program.
* The free/OSS cobol compilers won't compile non-trivial systems.
If you still think that the only problem is that it's "unfashionable", there are two possibilities: either you don't really know much about cobol (haven't used it in a real production environment), or you don't know much about anything but cobol.
You can make a list like that about any language - there are plenty of things wrong with Java too, such as the amount of boilerplate code required for EJBs, or the fact that the fragile superclass problem still hasn't been solved, or there are application servers with stupid licensing. I can't see COBOL being much worse than Java for any real-world project.
> Their product uses flexlm, and it sucks just like most consumer DRM, only worse, because it's buggy. I imagine that MF sees it as another form of copy-protection.
I meant that they see the bugs as a form of inadvertent copy-protection because their resolution requires a support call.
Try dealing with "just" 14k lines of cobol that you haven't written; try to make minor changes to it (and wait a minute for your $3000 piece of shit Micro Focus compiler to run) without breaking things. Try getting fed up and spending a year of your life rewriting the code in Pascal. You won't like it, but when you're done, you'll say "thank god i'm free of cobol!"
Come to think of it, Micro Focus is usually behind these lame annual PR campaigns to try to drum up talk about cobol. Their business isn't growing. Some reasons:
* Installing their product is a big pain. (At least on Solaris/SPARC and Linux.) Bugs in the installer script mean that you have to spend an hour or more on the phone just to install their junk. Support is included with the $3000 fee, but only for a year. So if and when you have to reinstall, prepare to pay a few hundred for the incident.
* Their product uses flexlm, and it sucks just like most consumer DRM, only worse, because it's buggy. I imagine that MF sees it as another form of copy-protection.
* The compiler doesn't play nicely with make, so when you rebuild your project, object files that are up-to-date are recompiled anyway.
* Interoperability with other languages and database systems is so cumbersome that you'll just end up writing output into some cumbersome flat text file, and have the rest of your system poll it to display progress from to your cobol program.
* The free/OSS cobol compilers won't compile non-trivial systems.
If you still think that the only problem is that it's "unfashionable", there are two possibilities: either you don't really know much about cobol (haven't used it in a real production environment), or you don't know much about anything but cobol.