Hacker News Reader

Comment by amelius | Hacker News Reader

What makes COBOL cool compared to, say, JavaScript, which can do everything COBOL can and more (such as pass functions/closures around, etc.)?

View on HN

The programs are very uniform. There is not multiple ways of doing things (at a presentation level). So you get to use hundreds of thousands of existing apps written over the last N decades in your modern web application.

You just couldn’t write them all over again, there isn’t a team on earth that could, even with infinite money. You’d be talking, I think, more than high double digits, millions of LOC.

JavaScript by comparison .. today it’s React/Angular, but it is very fluid. Not much code will be practically reusable in 5/yr from now.

> There is not multiple ways of doing things (at a presentation level).

Love the insight. Established businesses like banks look for this kind of stability. And upstarts who build from ground up to challenge status quo, they go on to figure out ways to win with es6 and their friends.

Not much code will be practically reusable in 5/yr from now.

Is that really true? If you look at a lot of JS from 5, 10 or even 20 years ago it still works. The main things that stop it working are security changes, which is arguably a good thing. I don't see why many of today's JS libs will stop working in the future unless there's a good reason why they should.

It's not that they won't work, but that nobody will be doing anything new in JS in 10 years. It will become forgotten, mysterious, scary -- like COBOL is today.

I can't say I agree, but secretly I hope you're right because I'll make a fortune consulting on people's old web apps.

How does one search and utilize the use hundreds of thousands of existing apps written over the last N decades? Is their a CPAN like tool for COBOL?

I'd guess

1. They are already in place and in use.

2. Vendor/consultant is aware of them.

I see. First rule of COBOL club. Don't talk about COBOL club.

That makes sense. In this view, how well would a modern, purely functional language do, compared to COBOL?

That depends on how well it inter-links with COBOL, surely?

It gives you correct answers to simple questions like this:

    > console.log(0.1 * 0.1)
    0.010000000000000002

I’m not sure I get your joke. Every system, JavaScript, COBOL, C, Java, etc etc etc, has this behavior. Floating point decimals when converted to binary, are a rather rough thing for a system to handle. For example, 0.1 in binary is a repeating number. Basic operations on those binary values are very very fast but not always 100% accurate due to the binary nature of decimals. There are packages which allow for very precise floating point calculations but will cause performance degradation compared to the basic operations. It all depends on what you need.

COBOL uses fixed-point decimal arithmetic, not binary floating-point. You'd declare these variables as PIC V99 and then get a nice neat .10×.10=.01 (or as PIC 99V999 and get 00.100×00.100=00.010, or whatever). This is because it's a Business-Oriented Language, and businesses don't want floating point rounding errors in their finances.

Incidentally, this was actually faster than binary floating-point on the machines for which COBOL was designed, which used EBCDIC and had special circuitry for arithmetic on binary-coded-decimal numbers. You could operate directly on the decimal representation without having to do any conversion for I/O.

Nit: the COBOL spec dates to 1960; EBCDIC came later, ~1963. In 1960, character codes were specific to the manufacturer, and sometimes to the machine. IBM had a 6-bit BCD code that was mostly consistent across its line, but Univac had its own which was quite different.

Intel x86 can also work natively with BCD numbers.

https://en.wikipedia.org/wiki/Intel_BCD_opcode

Very cool. Unfortunately it's no longer supported in Long mode (x86-64). :-(

I used to do a lot of BCD in embedded POS stuff. No one will miss it. You can do anything you can do in BCD with regular integers if you have any understanding of integer arithmetic. Yeah, it is going to take a little more time to convert to/from decimal digits you can display/input but processors these days have fast integer division so that doesn't matter.

A current issue is that a lot of programmers are bad at integer arithmetic. It isn't really taught in school.

Reply on news.ycombinator.com