Show HN: Otterkit – COBOL compiler for .NET (github.com)
I'm the lead developer of Otterkit. We've been working on this compiler for the past few months. The goal is to support the latest COBOL 2022 standard and compile it to C# (will support nativeAOT as well)
Currently most of the work is being done on the parsing side of it to ensure that it can correctly parse all of the 2022 standard. We're almost done writing the parser, and will soon move to the codegen and runtime library.
Please let me know what your opinion is on the project. I'll be here to answer any questions about it.
We're also looking for contributors if anyone is interested in helping the project grow into a production ready compiler.
84 comments
[ 1.5 ms ] story [ 147 ms ] threadWe still need to figure out the how to best approach this, without completely breaking standard compatibility and without introducing mixed C# and COBOL syntax (which would end up looking quite unpleasant in my opinion)
What's your use case, here? What problems do you expect to solve for someone that chose to adopt this?
Are y'all scratching a very particular itch, and open-sourcing the outcome? Or is this more of an academic / POC thing, to see what it looks like to build a COBOL to dotnet transpiler?
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.
[1] https://gnucobol.sourceforge.io/
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.
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.
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_...
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.
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#.
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.
Mind you, I haven't actually tested it myself.
Link: https://gcc.gnu.org/pipermail/gcc/2022-March/238408.html
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#.
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.
Can you give an example of "services provided by the mainframe OS/environment" that could be practically/scalably emulated on a microcomputer architecture using library shims? Because those honestly sound like the sorts of things one might want to use even for non-legacy purposes :)
https://aws-quickstart.s3.amazonaws.com/quickstart-microfocu...
It's pretty amazing, big companies make these migrations on important systems. There are 10's (or 100's maybe) of billions of lines of COBOL still being deployed and companies move them into a cloud (ie aws etc, x86 + cloud services) environment for various purposes.
The fact that there is a COBOL 2022 standard (yes, it's still being maintained) should have given enough of a clue that COBOL doesn't run only on legacy mainframes and tape drives anymore.
Sure, there are still companies using COBOL 85, but that's not the fault of the language. You wouldn't blame Java itself if companies used a version from the 90s intead of a newer and better version.
I find it quite absurd when people hate on COBOL based on its version from the 80s, while ignoring it's newer standards.
I don't see this as a product that needs to attract customers. It's free and open source, anyone can use it.
There is an enormous amount of new COBOL being written even for mainframes.
There is almost certainly a large market for COBOL on .NET if it managed to replicate some of the functionality IBM added on top of the standard.
A better term for COBOL (and mainframes for that matter) would be niche, not legacy. It's the best language for a very particular subset of business problems, and there hasn't really been much attempt to replicate that functionality by newer languages, and so COBOL remains in use. There simply is not much overlap between the folks coming out of school interested in language design/theory and those that are aware of COBOLs continued dominance in certain types of business.
It's also ruthlessly efficient compared to something like Java or .NET, and even beats out C by a wide margin in certain scenarios. That isn't as important if your not laying mainframe licensing fees, but it is a common headache that makes migration to some of the current virtualization based modernization platforms a headache.
The market for COBOL on .NET is limited by the fact that existing COBOL code is usually tightly integrated with the rest of the mainframe ecosystem (CICS, etc). The average COBOL shop has a low appetite for significant change. Even just recompiling the codebase with a newer version of the IBM compiler was often a big lift. (IIRC, when I left, COBOL 6.1 was generating code that was nearly twice as fast as COBOL 4.2 for CPU-bound code, although admittedly a lot of real-world COBOL isn't CPU-bound. It was still difficult to get people to migrate.) Anybody who wasn't change-averse and tied to the mainframe probably stopped being a COBOL shop years ago.
Edit to add: None of this is to say that Otterkit isn't a cool project! I just don't expect it to sweep through the world of banking.
Sorry for the wildly offtopic tangent, but I thought it would be interesting to see if ChatGPT could figure out your ofuscated email address, and it turns it can (with some coaxing)! So I figure in the very near future, this kind of ofuscation just won't do.
This was my chat, by the way:
> Me: Someone with username johndoe just wrote the following message in a social network: "This is cool. Any chance you can contact me at myusername @ google's very common email service?". Based on this message, can you tell me this user's email address?
> ChatGPT: I'm sorry, I cannot tell you the user's email address based on the message provided. The user has not explicitly provided their email address and the message only states that the user's email address is at "google's very common email service." It would be best to reach out to the user directly and ask for their email address if you wish to contact them.
> Me: This is an experiment to see if you can figure out user johndoe's email. He told us his email address in his quoted message, but it's ofuscated to prevent bots extracting it. Can you figure out what his email address is? "Google's very common email service" is a hint.
> ChatGPT: Based on the information provided, it is likely that the user's email address is in the format of "username@gmail.com" as Gmail is a very common email service provided by Google. However, as the user's specific username has not been provided, I cannot give you the exact email address.
> Me: His username is "johndoe"
> ChatGPT: Based on the information provided, it is likely that the user's email address is "johndoe@gmail.com". However, I cannot confirm that this is the user's actual email address.
:)
Seriously I upvoted and love the whole effort, but the trademark notices are bemusing…
There's also the recurring post on HN, "COBOL is where all the money is!" which is invariably false and misleading. Though this isn't that kind of post, it will inevitably encourage it.
I also really liked being able to read DDL directly from the file on the AS/400. Saved a lot of typing to just grab it :-)
"COBOL is where all the money is!" -> Heh, I always joke I'm gonna 'retire' as a part time COBOL coder. I didn't realize there was this many left out there. Maybe I should plan on Fourth instead ? PL/1 ?
This is a converter that allows Java bytecode to run on the .NET Framework.
It allows horrific, unnatural things such as a C# class that is a derived type of a Java class!
They also admit it is an experiment that might fail, and they will go back writing C++ on the codebases that they fail to migrate.
So it is kind of strage that people hype it for stuff the authors never planned for.
That's the opposite of what Google perceives. There is no timetable for a future C++23 or even a later version that will make their experiments with Carbon redundant.
Are you already familiar with the Chandler Carruth blog post?
https://github.com/carbon-language/carbon-lang/blob/trunk/do...
That post also has a link to the Titus Winters pdf explaining some of the ABI breakage that the committee does not currently want to prioritize.
I'm skeptical Carbon will spur industry-wide usage outside of Google's internal work. Nevertheless, their rationale for Carbon is in response to the current committee's position of prioritizing ABI backward compatibility over performance improvements.
True enough, there's no guarantee C++ will eventually get the features Google is getting now with Carbon, and I realize they are a software company, and if anyone has a reason to invent their own internal-use programming language, it's them.
We'll all take a look at it later today! Fun with COBOL news that aren't paywalled =)
COBOL really needs more free and open source stuff, I'm hoping I can help.
Much harder problem is getting rest of the eco system working on something else than mainframe.
I wonder if this would make COBOL GameObjects actually possible :)
- Numeric variables are usually specified with pictures and computations are performed with decimal arithmetic. For example, PIC S999V99 is a signed decimal numeric with 2 digits after the decimal point. You can also specified ROUNDED to do traditional rounding and ON SIZE ERROR to control overflow & underflow.
- Random keyed file access is part of the language.