Open source projects for modern COBOL development | Hacker News Reader

Open source projects for modern COBOL development

opensource.com

53 pointsvezzy-fnord27 comments

Open articleView on HN

"...allows you to use COBOL in node.js".

What a vivisection of nasty things!

Your corporate overlords will love it however.

... I'd like to run it with Rails.

http://www.coboloncogs.org/INDEX.HTM

http://www.coboloncogs.org/INVOLVE.HTM

This is perfect :)

... oh ffs.

MicroFocus COBOL has been used to write websites, so maybe those people want to move to the newest buzzword but still want their COBOL.

Say what you want about COBOL, but at least it had a built-in data type for decimal numbers (looking at you, Java).

BigDecimal doesn't count? (I guess because it's "Big" rather than efficient.)

It's not built-in ;-) Also its syntax is horrible:

  d = a.add(b.mul(c));

instead of

  d = a + b * c;

Even COBOL's

  COMPUTE D = A + B * C.

was clearer than Java's OOP notation.

Java's decision to privilege "primitive" types was a failure of imagination. They decided they didn't want operator overloading but didn't make any way to replace it.

They should retrofit it as follows:

  interface Addable<T> {
    T add(T other);
  }

And then make the + apply to any Addable, which can be defined for the boxed primitives. And so on for the other operators.

It's been a while since I Java'd, but wouldn't this still have problems when mixing types?

A java string added to anything results in the toString() method being called. It doesn't matter if the string is before or after the + operator. How do you specify precedence in this new scheme short of an exponentially large `add` method handling all the cases. And each add method has to handle all the variety of cases.

Make it:

  interface Addable<RHS, Result> {
    Result add(RHS other);
  }

The problem is hardly new though. Groovy is very Java-like and has operator overloading: http://groovy-lang.org/operators.html#Operator-Overloading

Would be best to disallow mixing types I think, except for the legacy behavior with primitive types you describe. Those hidden conversions are a source of subtle bugs.

Exactly. I've been preaching for other languages to get that for years. Avoid many of these odd floating point issues, esp when handling money. On top of it, the POWER processors were wise enough to include a decimal unit to accelerate it.

The IEEE 754 floating-point standard even includes decimal- instead of binary-based floating-point types, i.e. which can represent e.g. 0.1 accurately: https://en.wikipedia.org/wiki/IEEE_floating_point#Basic_and_... I think this is what IBM's POWER CPUs implement.

And there's even a proposal to add it to the C++ standard: http://open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3871.ht... And the C standard: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1312.pdf

Oh heck I didnt even know that. Yes, the IBM chips implement it on top of FPU with hardware/firmware combo. Googling POWER decimal gave me a PDF with floor plan and all. Their reasoning is that, unlike scientific community, most people use FPU's while thinking in and requiring decimal properties. So why not offer them a decimal unit, eh?

Glad it might get into C++ standard.

I've deployed business apps in Scheme and used rational numbers for currency values.

> Most of the COBOL being written today is for maintaining legacy code, not starting new projects.

Funny thing, I worked on a project with a mainframe division, that replaced a crusty old COBOL-based mainframe app with... an RPG mainframe app. In the 2010s. Ostensibly because we could leverage existing knowledge from other divisions under the same parent company, but really because of politics, as these things normally are.

There's also some practical reasons for keeping a program on the mainframe. I currently work in mainframe development at a large company. We're in the beginning stages of "modernizing" some of our mainframe applications (moving the user interface from CICS to the web). The main workhorse processes will still be on the mainframe, and for good reason: it's a goddamn powerhouse. Should we get a high volumes, we can give the processes some extra CPU's and MIPS, and it'll chug along even faster. It's a bit more difficult to provision extra VMs for a distributed server environment in order to do such things.

Plus, for all of COBOL's faults, it's simply more efficient for "business-y" processes. All anyone cares about is manipulating data found within a file or database, and that's what COBOL excels at.

We use a COBOL variant from a company in the US that is not open-sauce, but is very, very efficient and in continued developemnt, and we like it. A lot. It has a simplified syntax over COBOL, for example, no 6 columns on each line before code, no weird definition section at the start, seemless integration with the DB (no sql, just "READ users INVALID KEY next sentence" will open and read a file and handle an error (no primary key found) ).

It's so efficient that it's hard to grok at first. And 'normal' COBOL sytnax works. And it comes with a web framework. If anyone on HN is sitting on an aging COBOL project/app you could do worse than to chat to Zortec in Tennessee.

MicroFocus I presume? :)

It's just called Z. Which is a name that is impossible to search because of the IBM Z.

See http://www.coboloncogs.org/INDEX.HTM

I still think it would be interesting to do a COBOL / RPG IV compiler to WebAssembly. The decimal handling will probably be an issue, but I am pretty tempted to give it a go when the WebAssembly stuff matures a bit.

Decimal handling shouldn't be too difficult. Use an integer of the appropriate size for storage and scale by 10^n where n is the number of decimal places. E.g. (my COBOL is a little rusty)

  price PIC 999V99
  ...
  move 3.14 to price

would result in the WebAssembly equivalent of

  price = 314

In other words: Use fixed-point arithmetic, but with base-10 instead of base-2.

COBOL is like HNs shutter shades.

Reply on news.ycombinator.com