3 ms·

I really don't see the beauty of COBOL in those examples. The real reason COBOL is still used is legacy software that companies don't want to convert (because i

I really don't see the beauty of COBOL in those examples. The real reason COBOL is still used is legacy software that companies don't want to convert (because it's costly and because it works). My company also likes to tell newcomers that you don't need to have studied computer sciences to use it.

tabtab 9y ago
Agreed, those examples don't really show the up-sides of COBOL. It's optimized for financial and business data processing, mainly on either the "back end" or as batch jobs (such as nightly re-processing of the day's transactions). It has a lot of nice short-cuts and built-in "libraries" for that domain. You can get similar libraries/API's for say Java, but they'd be inconsistent for each shop because they are not built into Java. COBOL guarantees that a consistent set of business-oriented operations will be available, reducing the cross-shop learning curve and errors because they are time-tested. Both FORTRAN and COBOL survive by NOT trying to be general-purpose languages, instead making sure they serve their domain well and consistently. I'm afraid some languages such as C# try too hard to be everything to everybody: a systems language, an application language, a scientific language, etc.
commandlinefan 9y ago
I think that the "beauty" (if you want to call it that) of COBOL was mostly in how it did, for the most part, exactly what you told it to do and rarely surprised you with unintended consequences (I mean, don't get me wrong, it still did, but not like C or Java or Javascript do). The problem was that you gave up a lot of expressiveness for this; when I was working in COBOL, I'd find myself cutting and pasting the same snippet of code in dozens of places with minor modifications - the language just didn't allow enough dynamism to permit decent code reuse. So in exchange for making it harder to accidentally shoot yourself in the foot, you'd end up with a codebase that needed dozens of code changes, far distributed from each other, to make functional updates - and hope that you didn't forget to update one of the cases.

tabtab 9y ago

Agreed, those examples don't really show the up-sides of COBOL. It's optimized for financial and business data processing, mainly on either the "back end" or as batch jobs (such as nightly re-processing of the day's transactions). It has a lot of nice short-cuts and built-in "libraries" for that domain. You can get similar libraries/API's for say Java, but they'd be inconsistent for each shop because they are not built into Java. COBOL guarantees that a consistent set of business-oriented operations will be available, reducing the cross-shop learning curve and errors because they are time-tested. Both FORTRAN and COBOL survive by NOT trying to be general-purpose languages, instead making sure they serve their domain well and consistently. I'm afraid some languages such as C# try too hard to be everything to everybody: a systems language, an application language, a scientific language, etc.

commandlinefan 9y ago

I think that the "beauty" (if you want to call it that) of COBOL was mostly in how it did, for the most part, exactly what you told it to do and rarely surprised you with unintended consequences (I mean, don't get me wrong, it still did, but not like C or Java or Javascript do). The problem was that you gave up a lot of expressiveness for this; when I was working in COBOL, I'd find myself cutting and pasting the same snippet of code in dozens of places with minor modifications - the language just didn't allow enough dynamism to permit decent code reuse. So in exchange for making it harder to accidentally shoot yourself in the foot, you'd end up with a codebase that needed dozens of code changes, far distributed from each other, to make functional updates - and hope that you didn't forget to update one of the cases.