
Open source projects for modern COBOL development - vezzy-fnord
https://opensource.com/life/15/10/open-source-cobol-development
======
Boggins
"...allows you to use COBOL in node.js".

What a vivisection of nasty things!

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

~~~
cnvogel
[http://www.coboloncogs.org/INDEX.HTM](http://www.coboloncogs.org/INDEX.HTM)

~~~
zapu
[http://www.coboloncogs.org/INVOLVE.HTM](http://www.coboloncogs.org/INVOLVE.HTM)

This is perfect :)

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

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

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

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

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

~~~
Kristine1975
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](http://groovy-lang.org/operators.html#Operator-Overloading)

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

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

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

~~~
paulhart
MicroFocus I presume? :)

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

------
eru
See
[http://www.coboloncogs.org/INDEX.HTM](http://www.coboloncogs.org/INDEX.HTM)

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

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

------
jevgeni
COBOL is like HNs shutter shades.

