Hacker News Reader

Comment by tzmudzin | Hacker News Reader

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.

View on HN

Actually, 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.

Funny 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.

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

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

Yes, 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.

We 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.

How 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.

Wrong 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.

Reply on news.ycombinator.com