3 ms·

I think the elitist attitude towards COBOL really should stop. COBOL is a domain-specific language for implementing commercial/financial batch processing jobs,

I think the elitist attitude towards COBOL really should stop. COBOL is a domain-specific language for implementing commercial/financial batch processing jobs, no more, no less. With adequate control over decimal arithmetic and established declarative practices for structured file exchange, subroutine reuse, and job control. Based on a language spec with reasonable portability. It's not about good or bad but fitness for a purpose. COBOL programs can be very clear and to the point compared to eg Java programs replacing them with lots of misguided OOP patterns and metaprogramming.

valenterry 6y ago
COBOL just didn't improve as a language (yeah, I know that there is also OOP COBOL) and hence it's not productive to use it. Even Java is improving more than COBOL and improving fast is certainly not Java's strength...
- glangdale 6y ago
  For those who haven't seen this old joke, Bruce Clement suggested in SIGPLAN 1992 that OOP COBOL should be called "ADD 1 TO COBOL GIVING COBOL".
- cogman10 6y ago
  I think it is fair to say that Java up till about Java 8 had a problem with not evolving fast enough. However, I'd say now Java is really one of the quicker evolving languages out there, which is really impressive. They went from a go like evolution pace to being closer to a Rust or Javascript evolution. Turns out, fast release cycles do a lot of good for a language.
  - valenterry 6y ago
    Java certainly got faster, which is good. Related to the manpower, it is still moving super slow. Which makes sense to some degree as the language just has so many old problems and does not want to considerably break compatibility and also hasn't invested into how to move fast as a language.
danpalmer 6y ago
You make a good point, I’ve not thought about COBOL as a DSL before but the analogy fits. I think there are legitimate criticisms, such as the fact that it’s not portable between architectures, compilers are typically closed source and expensive, code is typically not portable between compilers. These are all things we mostly expect languages to have gotten past now, so I can understand the feeling that it’s stuck in the past. The thought experiment of what would a DSL for banking look like though does suggest COBOL isn’t too bad. It feels like this approach would work well with the approach of companies like MicroFocus: compile COBOL to JVM/CLR, and then allow pieces to be replaced with Java/CLR languages as necessary, and allow running on “normal” machines, removing the dependencies on architecture (by emulating in the compiler). That way, these old codebases almost become a specialised VM language, while regular modern languages can be used to augment.
- eb0la 6y ago
  Plus you don't need to pay for more cpu / lpar licenses on the mainframe.
- valenterry 6y ago
  First of all, why would COBOL be considered a DSL? Is Java a DSL too then? Second, you make it sound as if COBOL would be somehow better than using Java, C#, ... because it is a DSL. But that's not the case - or can you give some more concrete points for why it should be better?
  - tannhaeuser 6y ago
    > First of all, why would COBOL be considered a DSL? Let me answer as GP and having made that claim. Because COBOL can't really do much anything else ;? Eg have fun implementing an event-driven GUI app (actually there are/were solutions for running COBOL green-screen mainframe apps on browsers, and things like IBM's HATS for running 3270 apps in Java portlets). Though apart from batch processing, I guess COBOL the language but not necessarily the runtime works well also for writing backend service implementation code. More seriously, as I recall it, COBOL simply has straightforward idioms for arithmetic, date calculations, statically-typed structured file I/O, ISAM file access (and SQL?) as part of the language rather than Java's BigDecimal and various date libraries that all suck in a different way and at best cause enormous fluent-style expressions with cognitive overhead. Plus, COBOL doesn't have reflection and metaprogramming so self-important idiomatic Java code golf is spotted immediately as out of place next to actual business logic.

valenterry 6y ago

COBOL just didn't improve as a language (yeah, I know that there is also OOP COBOL) and hence it's not productive to use it. Even Java is improving more than COBOL and improving fast is certainly not Java's strength...

glangdale 6y ago
For those who haven't seen this old joke, Bruce Clement suggested in SIGPLAN 1992 that OOP COBOL should be called "ADD 1 TO COBOL GIVING COBOL".
cogman10 6y ago
I think it is fair to say that Java up till about Java 8 had a problem with not evolving fast enough. However, I'd say now Java is really one of the quicker evolving languages out there, which is really impressive. They went from a go like evolution pace to being closer to a Rust or Javascript evolution. Turns out, fast release cycles do a lot of good for a language.
- valenterry 6y ago
  Java certainly got faster, which is good. Related to the manpower, it is still moving super slow. Which makes sense to some degree as the language just has so many old problems and does not want to considerably break compatibility and also hasn't invested into how to move fast as a language.

danpalmer 6y ago

You make a good point, I’ve not thought about COBOL as a DSL before but the analogy fits. I think there are legitimate criticisms, such as the fact that it’s not portable between architectures, compilers are typically closed source and expensive, code is typically not portable between compilers. These are all things we mostly expect languages to have gotten past now, so I can understand the feeling that it’s stuck in the past. The thought experiment of what would a DSL for banking look like though does suggest COBOL isn’t too bad. It feels like this approach would work well with the approach of companies like MicroFocus: compile COBOL to JVM/CLR, and then allow pieces to be replaced with Java/CLR languages as necessary, and allow running on “normal” machines, removing the dependencies on architecture (by emulating in the compiler). That way, these old codebases almost become a specialised VM language, while regular modern languages can be used to augment.

eb0la 6y ago
Plus you don't need to pay for more cpu / lpar licenses on the mainframe.
valenterry 6y ago
First of all, why would COBOL be considered a DSL? Is Java a DSL too then? Second, you make it sound as if COBOL would be somehow better than using Java, C#, ... because it is a DSL. But that's not the case - or can you give some more concrete points for why it should be better?
- tannhaeuser 6y ago
  > First of all, why would COBOL be considered a DSL? Let me answer as GP and having made that claim. Because COBOL can't really do much anything else ;? Eg have fun implementing an event-driven GUI app (actually there are/were solutions for running COBOL green-screen mainframe apps on browsers, and things like IBM's HATS for running 3270 apps in Java portlets). Though apart from batch processing, I guess COBOL the language but not necessarily the runtime works well also for writing backend service implementation code. More seriously, as I recall it, COBOL simply has straightforward idioms for arithmetic, date calculations, statically-typed structured file I/O, ISAM file access (and SQL?) as part of the language rather than Java's BigDecimal and various date libraries that all suck in a different way and at best cause enormous fluent-style expressions with cognitive overhead. Plus, COBOL doesn't have reflection and metaprogramming so self-important idiomatic Java code golf is spotted immediately as out of place next to actual business logic.