> >[The COBOL] tipping point doesn’t worry David Dischiave, associate professor and director of Global Enterprise Technology, Syracuse University, who says, “I

> >[The COBOL] tipping point doesn’t worry David Dischiave, associate professor and director of Global Enterprise Technology, Syracuse University, who says, “I don’t buy into the idea that there is a shortage of Cobol programmers. If there is a shortage, why aren’t employers responding to my calls to get jobs for majors with Cobol experience? What employers do, rather than what they say, matters most.” > Why should a career-minded student spend their independent study time on COBOL? First, COBOL is shockingly simple and straightforward. It's not studied because it's boooring. You don't do amazing things with cobol. You do simple and reliable things with cobol. > COBOL articles also often make vague claims that it is better at some business-oriented tasks, but without a lot of specifics. The author gives this list: > - The capability for heterogenous “record-structure” data A well defined binary data format suitable for data exchange between heterogenous systems and organisations. Transactions between companies and departments who internally may choose whichever implementation they seem best. And a simple and straightforward description of the data RECORDs. > - The capability for decimal arithmetic Well defined arithmetics on arbitrary precision numbers. Behaving identically on PC, mainframe, Unix. > - The capability for convenient report generation This was initially invented relative to tty fixed width printing, but the templating mechanisms also work with contemporary outputs. > - The capability for accessing and manipulating masses of data (typically made up of heterogeneous data structure). Batch processing in b2b transactions. > I work on server-side Java/C++ at a Big-N, doing ETL pipelines and distributed applications, and I have trouble believing that COBOL is better at any of those tasks than a modern language with modern tooling/build system. If COBOL is so great, where are the new adopters? That's not b2b transactions you work on do you? > Why is Apache Spark supporting R and not COBOL? Because it's trivial to transform cobol records into something digestable by other tools. The gap is people liking boring reliable batch processing of piles of records. People liking to dig into existing 'boring' b2b transaction processing systems. It needs a very special breed of people who embrace the value of the simplicity and dependability of these existing architectures, who then evolve these existing systems instead of saying how shitty and how 60s they are. And then also people who live in both worlds and who bridge the gap e.g. into real time data mining and online processing instead of batching.