I thought folks here would be interested in this article about how hard it has been for governments and businesses to transition away from COBOL. Unlike Fortran, which is almost as old as COBOL, programmers are still learning Fortran and the language standard has continued to evolve and stay relevant.
4 Likes
I recently made a list of some of the “asbestos” that has accumulated in Fortran over the last 20 years. I thought this list might be of interest also to others, who’d like to avoid “exposure” (in order to live a more healthy programming life). So here it is:
-
Implementation inheritance (type-extension). Classification: Highly toxic! “Asbestos” that dates back to the 1960ies. Was long known to be obsolescent in Objective-C and Java, when it was introduced into Fortran 2003 (published in 2005). Modern alternative/antidote: Interface inheritance/Traits.
-
Procedure pointers. Classification: Hazardous! Moreover superfluous in languages that support dynamic dispatch (thus obsolescent since the 1960ies). Nevertheless introduced into Fortran 2003. Antidote: Closures.
-
Parameterized Derived Types. Classification: Unhealthy (they cause flatulence, like all half-baked things)! Not interoperable with the language’s object-oriented features. Antidote: Generic derived types that conform to Traits.
-
Submodules. Classification: Superfluous (in a language that supports object-orientation, OO). Submodules do not allow for full code decoupling as OO does, while adding tremendous complexity. Deleted by Niklaus Wirth already in 1986, when he went from Modula-2 to its object-oriented successor Oberon. Needless to say they, too, made it into Fortran (2008).
There’s a saying in Germany: “Wer im Glashaus sitzt sollte nicht mit Steinen werfen.” Given all these existential problems in our own yard, maybe we should not be laughing at COBOL.