3 ms·

> 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 hav

> 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
> Eg have fun implementing an event-driven GUI app Which leads to the question: why is this harder in COBOL than in Javascript or Java? Is it just the lack of a library? If so, does the lack of libraries make a programming language a DSL? Or is it because it is difficult to create such a library? If so, why is that difficult for COBOL and not for Javascript/Java and what else is difficult to build with COBOL. > I guess COBOL the language but not necessarily the runtime works well also for writing backend service implementation code I'm sorry to be picky on words here, but as it is the core of the whole discussion: "works well" is quite meaningless if not put into context. "Works better than X" or "has an advantage over X in some way, for example..." is much more fruitful for a discussion about this topic. > 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. I don't want to be ignorant here... and I'm also not a fan of Java. In fact I dislike Java so much that I declined highly paid jobs. However, is COBOL really better in these things? So I have seen some production COBOL code at work before and I just looked up some COBOL questions on stackoverflow, e.g.: https://stackoverflow.com/questions/48016044/formatting-date-time-in-cobol https://stackoverflow.com/questions/48016044/formatting-date... Sorry, but even Java's horribly verbose syntax looks way better than this. Apart from the annoying verbosity, I think Java's new time library as well as BigDecimal/BigInteger and also its SQL libraries are not too bad anymore. And if one wants nicer syntax - there are enough languages out there that do it better. Okay, having SQL directly embeddable is nice, I agree. I don't think it is good programming language design to do that, but then again SQL has been very stable over time and it's certainly nice to use it like that. As for... > statically-typed structured file I/O What does that mean? I tried to find it out but didn't really get an idea what you mean by that. > 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. That's true, but that doesn't make COBOL better - it just makes Java worse. ;)

valenterry 6y ago

> Eg have fun implementing an event-driven GUI app Which leads to the question: why is this harder in COBOL than in Javascript or Java? Is it just the lack of a library? If so, does the lack of libraries make a programming language a DSL? Or is it because it is difficult to create such a library? If so, why is that difficult for COBOL and not for Javascript/Java and what else is difficult to build with COBOL. > I guess COBOL the language but not necessarily the runtime works well also for writing backend service implementation code I'm sorry to be picky on words here, but as it is the core of the whole discussion: "works well" is quite meaningless if not put into context. "Works better than X" or "has an advantage over X in some way, for example..." is much more fruitful for a discussion about this topic. > 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. I don't want to be ignorant here... and I'm also not a fan of Java. In fact I dislike Java so much that I declined highly paid jobs. However, is COBOL really better in these things? So I have seen some production COBOL code at work before and I just looked up some COBOL questions on stackoverflow, e.g.: https://stackoverflow.com/questions/48016044/formatting-date-time-in-cobol https://stackoverflow.com/questions/48016044/formatting-date... Sorry, but even Java's horribly verbose syntax looks way better than this. Apart from the annoying verbosity, I think Java's new time library as well as BigDecimal/BigInteger and also its SQL libraries are not too bad anymore. And if one wants nicer syntax - there are enough languages out there that do it better. Okay, having SQL directly embeddable is nice, I agree. I don't think it is good programming language design to do that, but then again SQL has been very stable over time and it's certainly nice to use it like that. As for... > statically-typed structured file I/O What does that mean? I tried to find it out but didn't really get an idea what you mean by that. > 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. That's true, but that doesn't make COBOL better - it just makes Java worse. ;)