3 ms·

The statement about Decimal being an import is a garbage, misleading statement. Decimal IS PART OF THE STANDARD LIBRARY!!!! It might not be in the global contex

by slaymaker1907 8y ago

The statement about Decimal being an import is a garbage, misleading statement. Decimal IS PART OF THE STANDARD LIBRARY!!!! It might not be in the global context, but that is a far cry from having to install an external library which this article makes it seem like. Also, performance wise COBOL might be faster on a single machine, but good like trying to scale it out. Plus, a distributed architecture can make it easier to deploy software and hardware upgrades since you can generally take out a few nodes without bringing down the whole system. I’m not saying all this code should be rewritten. If you have some code out in the wild that works, you should always weigh carefully the risks in terms of cost and potential new bugs before doing a rewrite. However, lack of fixed point is a lousy excuse to not upgrade.

Waterluvian 8y ago
Agreed. Importing standard library entities is just an organizational distinction.
fapjacks 8y ago
As to your last point: Totally! Old code is proven code, and battle experience is the hardest kind of experience to earn. The longer something's been working correctly, the higher the degree of confidence you can have in it to continue working correctly in the future.
jacoblambda 8y ago
I mean its obvious that we really should be looking at APL/K/Q/J as the replacement for COBOL. /s Actually though, I believe that modern Ada would probably be the best upgrade path in these cases. It has a strong static type system, it has first class support for fixed types, with Contracts and SPARK you can get strong guarantees of correctness, and as a compiled language is decently fast. Contracts and such do automatically insert runtime checks which can effect performance however if they are causing a legitimate issue can be reduced via compiler flags (not super safe) or by verifying that they are unnecessary in code. (demonstrating correctness to the compiler via SPARK) In systems such as Finance, languages such as Ada (in its modern form) have a real chance to shine given their speed, safety guarantees, and remarkable stability.
darren0 8y ago
It's comments like this that have me coming back to HN again and again.
gaius 8y ago
good like trying to scale it out COBOL demonstrably scales sufficiently to run the entire global economy, so no luck required.
- mmt 8y ago
  To be fair, the parent did specify scaling "out" and went on to claim other benefits of a distributed architecture, which are not even unique to that architecture [1]. Of course, that comment's definition of "single machine" ignores the intrinsically distributed nature of mainframe architectures, on which on might reasonably suppose COBOL would run. [1] e.g. a "single machine" only needs a single replica for those benefits. Sure, even that's a form of distributed architecture, potentially subject to at least some of the Fallacies Of Distributed Computing, but I'm confident that's not what was meant.
  - gaius 8y ago
    Indeed. I am no fan of IBM the company due to the poor way they treat workers they are laying off, and the way they keep winning big government contracts despite their many many high profile failures is deeply suspicious. And their cloud offerings are a joke. But I won’t deny that Sysplex has been proven to work in the field.
LaGrange 8y ago
> Decimal IS PART OF THE STANDARD LIBRARY!!!! It's not a builtin. If it's like the one place I've seen COBOL in, there's a lot of batch processing. When she talks about performance of the "import" statement, she's not kidding. Of course yes, that's a terrible architecture by modern standards, but now we're talking about more than replacing just COBOL.
lmm 8y ago
> Decimal IS PART OF THE STANDARD LIBRARY!!!! It might not be in the global context, but that is a far cry from having to install an external library which this article makes it seem like. It's very similar to using an external library (at least if you're in a language with decent package management). Yes there is a "standard" decimal library, but it's not a natural path to take when working with numbers in Python/Java/... : there's no literal support, and in Java's case not even arithmetic operators. These languages naturally drive you towards using IEEE 754 binary floating point, and by the time you've realised that wasn't what you wanted it's often too late to migrate.

Waterluvian 8y ago

Agreed. Importing standard library entities is just an organizational distinction.

fapjacks 8y ago

As to your last point: Totally! Old code is proven code, and battle experience is the hardest kind of experience to earn. The longer something's been working correctly, the higher the degree of confidence you can have in it to continue working correctly in the future.

jacoblambda 8y ago

I mean its obvious that we really should be looking at APL/K/Q/J as the replacement for COBOL. /s Actually though, I believe that modern Ada would probably be the best upgrade path in these cases. It has a strong static type system, it has first class support for fixed types, with Contracts and SPARK you can get strong guarantees of correctness, and as a compiled language is decently fast. Contracts and such do automatically insert runtime checks which can effect performance however if they are causing a legitimate issue can be reduced via compiler flags (not super safe) or by verifying that they are unnecessary in code. (demonstrating correctness to the compiler via SPARK) In systems such as Finance, languages such as Ada (in its modern form) have a real chance to shine given their speed, safety guarantees, and remarkable stability.

darren0 8y ago

It's comments like this that have me coming back to HN again and again.

gaius 8y ago

good like trying to scale it out COBOL demonstrably scales sufficiently to run the entire global economy, so no luck required.

mmt 8y ago
To be fair, the parent did specify scaling "out" and went on to claim other benefits of a distributed architecture, which are not even unique to that architecture [1]. Of course, that comment's definition of "single machine" ignores the intrinsically distributed nature of mainframe architectures, on which on might reasonably suppose COBOL would run. [1] e.g. a "single machine" only needs a single replica for those benefits. Sure, even that's a form of distributed architecture, potentially subject to at least some of the Fallacies Of Distributed Computing, but I'm confident that's not what was meant.
- gaius 8y ago
  Indeed. I am no fan of IBM the company due to the poor way they treat workers they are laying off, and the way they keep winning big government contracts despite their many many high profile failures is deeply suspicious. And their cloud offerings are a joke. But I won’t deny that Sysplex has been proven to work in the field.

LaGrange 8y ago

> Decimal IS PART OF THE STANDARD LIBRARY!!!! It's not a builtin. If it's like the one place I've seen COBOL in, there's a lot of batch processing. When she talks about performance of the "import" statement, she's not kidding. Of course yes, that's a terrible architecture by modern standards, but now we're talking about more than replacing just COBOL.

lmm 8y ago

> Decimal IS PART OF THE STANDARD LIBRARY!!!! It might not be in the global context, but that is a far cry from having to install an external library which this article makes it seem like. It's very similar to using an external library (at least if you're in a language with decent package management). Yes there is a "standard" decimal library, but it's not a natural path to take when working with numbers in Python/Java/... : there's no literal support, and in Java's case not even arithmetic operators. These languages naturally drive you towards using IEEE 754 binary floating point, and by the time you've realised that wasn't what you wanted it's often too late to migrate.