Cobol and research community (Score 2, Interesting)

The software engineering research communities have been aware of the problems (decreasing number of developers, hardcoded business rules, required integration with other systems, ...) tied to legacy software systems, and there's still active research going on in these areas.

<shameless plug>
In our research group e.g., we're evaluating aspect-orientation (AOP) as a means to both reverse-engineer (understand) and re-engineer (modify) legacy software written in Cobol or C. To this end, we've designed and implemented an aspect language called Cobble (http://faramir.ugent.be/~kdschutt/cobble/) and applied it on some typical legacy problems like Y2K, transition to Euro, encapsulation of web services, ... (see http://allserv.ugent.be/~badams/publications/2006/ ao4vittel.pdf). Similar work is done for C (http://users.ugent.be/~badams/aspicere).
</shameless plug>

Now, the biggest problems we encountered for Cobol (contrast this e.g. with the Java world) were:

• dozens of existing Cobol dialects coupled to the sheer absence of open source Cobol software (to experiment with)
• lack of a decent (free) IDE or some other infrastructure to start tweaking
• lack of an unambiguous Cobol parser
• Cobol's sheer unlimited number of features

Eventually, we had to implement our tools from scratch, tied to a subset of one particular Cobol dialect. This severely reduced the time for actual research. So, Cobol is not so simple as it may seem at first sight and this is aggravated by the limited (compared to Java, C#, ...) available tool support.