Hacker News Reader

Comment by KTSnowy | Hacker News Reader

I find COBOL to be a very interesting language, with a huge unexplored potential. For example, I'm sure that most people are not aware that COBOL has generics, method overloading, declarative error/exception handling, asynchronous messaging, etc.

This stuff is usually not taught by the current COBOL vendors. It's also very unfortunate that most compilers are closed source and quite expensive to use.

We're making a free and open source COBOL compiler to help improve the current state of the COBOL ecosystem. We hope that it will be production ready at some point.

View on HN

> I find COBOL to be a very interesting language, with a huge unexplored potential. For example, I'm sure that most people are not aware that COBOL has generics, method overloading, declarative error/exception handling, asynchronous messaging, etc.

But most COBOL systems are legacy systems, using a version of COBOL designed many decades ago, and without any of these features.

Starting to use the features you list will effectively be like learning a completely new language, only without any of the upsides of modernity and all of the downsides. If you are going to migrate from legacy COBOL to slightly-less-legacy-COBOL-but-at-the-same-time-all-these-frightening-new-features, you might as well migrate to a more modern platform and language.

Why not improving Gnu COBOL[1] then? It has better support for the COBOL constructs and libraries already.

[1] https://gnucobol.sourceforge.io/

I know about GnuCOBOL, but both projects have different goals and ideals.

Otterkit compiles to C#, and GnuCOBOL compiles to C. The two are meant for different use cases. You wouldn't use a huge C program in a .NET backend, it would be a pain to make it work correctly and difficult to maintain.

GnuCOBOL also doesn't support quite a bit of COBOL's features. It only supports the procedural part of the language, and that is only a small part of it compared to the object oriented side of COBOL. Otterkit will support both, and the new 2022 standard.

Thanks for the answer. Looking forward for your project success!

> Otterkit compiles to C#

Is it really a transpiler? Why not directly compile to CIL?

> I'm sure that most people are not aware that COBOL has generics

But this is only in the more recent standards, isn't it? I guess that 95% of existing Cobol applications still use the 1974 standard version.

> Why not directly compile to CIL?

This was asked and answered on reddit [0]:

> Exactly, there's no way that we could optimize the IL better than the dotnet compiler, so we chose to emit C# text and let the dotnet compiler do the optimization for us.

> This also makes it a lot simpler to generate code, without having to deal with the lower level IL.

[0]: https://old.reddit.com/r/csharp/comments/1074jdj/otterkit_a_...

JFYI, optimizations performed by C# compiler are not that great. They are present but their extent is pretty limited.

Actually I like it better when COBOL gets transpiled to C# and not IL but for another reason. COBOL -> C# pathway allows migration to something a bit more modern than COBOL itself. This may be crucial for some projects.

> Is it really a transpiler? Why not directly compile to CIL?

The end result of running Otterkit will be an executable or a C# DLL, so compiler would still be the most accurate word to describe it. If it stopped at the translation stage it would be a transpiler.

We're compiling to C# source text so that we can take advantage of the dotnet compiler optimizations. Otterkit calls the dotnet compiler after translating to C#.

> advantage of the dotnet compiler optimizations

That's mostly constant folding and a bit of peephole optimization; the CLI JIT or AOT compilers do most optimizations on the CIL level.

> so compiler would still be the most accurate word to describe it

Well, you do a source-to-source translation from Cobol to C#. The terminology is fuzzy, but usually we call it a transpiler if the output is yet another high-level programming language. But who cares.

If it is of any interest: In 2022, an announcement was posted to the GCC mailing list introducing a prototype implementation of a COBOL frontend to GCC, which would in theory compile COBOL directly to a target machine of choice.

Mind you, I haven't actually tested it myself.

Link: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html

> For example, I'm sure that most people are not aware that COBOL has generics, method overloading, declarative error/exception handling, asynchronous messaging, etc.

It is interesting, but the reality is the vast majority of cobol in the world is the 85 standard. And although the 2022 standard may have some nice features, the language is simply too verbose; similar to Visual Basic vs c#.

I think exactly like you, but about ADA, for a very long time compilers where closed-source, for crazy machines and additionally really expensive, the situation for ADA is now much better, but it lost it's momentum then, but regains a bit of it in the past years, especially because of the rust hype ;)

Reply on news.ycombinator.com