I learned COBOL in the late 1970's. I never used it professionally, but it and numerous other languages that come from that period and before (e.g RPG) are all about data processing and business systems. Newer tools that map to that space we now call ETL (think Ab Initio, Informatica, Data Stage). The reason COBOL went out of vogue is because the applications built in that language have stood the test of time - no-one was need to build replacement bceuase the originals worked. This meant we (as programmers) moved on to languages that support other needs. C++, Java and related languages are great for what they do (for instance ETL tools tend to be written in C++), but they are not suitable for many business systems application without first building up a code infrastructure that supports them. If I were writing a new business systems application, I probably would choose a modern ETL tool over COBOL (less coding to get the job done), but I would think long and hard before abandoning COBOL for an existing application just because it is "old". I would also point out that just because we understand the concepts needed to properly design and implement an interactive application does not mean we have the concepts needed to properly design and implement a data processing application.
Slashdot Mirror
I learned COBOL in the late 1970's. I never used it professionally, but it and numerous other languages that come from that period and before (e.g RPG) are all about data processing and business systems. Newer tools that map to that space we now call ETL (think Ab Initio, Informatica, Data Stage). The reason COBOL went out of vogue is because the applications built in that language have stood the test of time - no-one was need to build replacement bceuase the originals worked. This meant we (as programmers) moved on to languages that support other needs. C++, Java and related languages are great for what they do (for instance ETL tools tend to be written in C++), but they are not suitable for many business systems application without first building up a code infrastructure that supports them. If I were writing a new business systems application, I probably would choose a modern ETL tool over COBOL (less coding to get the job done), but I would think long and hard before abandoning COBOL for an existing application just because it is "old". I would also point out that just because we understand the concepts needed to properly design and implement an interactive application does not mean we have the concepts needed to properly design and implement a data processing application.