3 ms·
For anyone criticizing COBOL for inducing alleged brain damage: yes, it is an old language, but it's a domain-specific language. The use case was processing of
by tzmudzin 6y ago
For anyone criticizing COBOL for inducing alleged brain damage: yes, it is an old language, but it's a domain-specific language.
The use case was processing of record-based inputs in an administrative context, based on a technology millions of times less powerful than current hardware, yet still able to sustain a massive administration (old-school banking, anyone?)
No, you will not write a compiler or a kernel module in COBOL, just like you won't write it in SQL, APL or Matlab. But for the purpose it was built for, you'll be a lot more comfortable than in most alternatives.
- 7thaccount 6y agoFunny note, but Aaron Hsu just wrote a pretty impressive APL-> GPU compiler for his dissertation. It's been discussed on HN a few times. Your point still stands though.
- Koshkin 6y agoActually, it could be an interesting exercise to write a non-trivial program in the original version of COBOL (or BASIC or FORTRAN); indeed, the people who created these now “old” languages were not stupid; rather, they had specific design criteria in mind, and the languages were constructed to fit those criteria. However “brain-damaged” these languages may seem today compared to more recent alternatives, I also think that an average student or an office worker would have a much better chance to casually learn programming in one of these simple “old” languages to a degree which would make the skill useful to them in their daily tasks, than to try, and fail, to attain practical level of command of, say, Python or JavaScript.
- stickfigure 6y ago> you'll be a lot more comfortable than in most alternatives. That certainly wasn't on display here. The equivalent Java program (to use everyone's favorite punching bag) would be a tenth the length. The value of SQL is easily demonstrated in a blog entry of less than 500 words. Now that I've had this introduction, I can't imagine ever thinking "oh this would be a great place to use COBOL!" Fantastic and educational article, however.
- tzmudzin 6y ago> The equivalent Java program (to use everyone's favorite punching bag) would be a tenth the length. Not if you started dealing with real-life record format specifications, including fixed-precision numbers for currency, dates etc.
- stickfigure 6y agoYes, really. Every one of the dozen languages I've worked in professionally has support for fixed precision numbers. Processing structured records of data is a thoroughly solved problem.
- tzmudzin 6y agoWe can debate and dispute this, but I'd rather propose: take a closer look at how this is handled in COBOL, and you'll re-evaluate. In shortest words: variable declaration is also used as I/O format specification. Pretty much all of IO is just reading into a buffer, and the values are automatically mapped for your use. Sure you can use the same method in pretty much every general-purpose language (mapping C structs etc), but here it comes just natural.
- stickfigure 6y agoHow about an example? Present a short COBOL program that is actually more concise than a (say) Java program? The example presented in this blog article seems a likely candidate, and yet would be much shorter in modern languages. If you want to make the case that COBOL is still a good DSL for its niche (report generation?), it seems like there should be some straightforward examples. This is super easy to do with the aforementioned SQL or Matlab.
- tzmudzin 6y agoWrong measure. COBOL is verbose (and I hate this), but the fit-for-purpose should not be measured in LOC. It's how natural it is to perform the work, and how easy it's for your successor to maintain your program.