Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Otterkit – COBOL compiler for .NET

github.com

Post reply on HN
Print view View original

1–10 of 85 posts

Show HN: Otterkit – COBOL compiler for .NET

#1

Post by KTSnowy »

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.

Show HN: Otterkit – COBOL compiler for .NET
github.com

Re: Show HN: Otterkit – COBOL compiler for .NET

#4

Post by eckza »

I'm fascinated with this.

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?

Re: Show HN: Otterkit – COBOL compiler for .NET

#5

Post by KTSnowy »

richardjam73 wrote: post #3

How will this be integrated into dotnet? Will you be able to call dotnet libraries?

We're planning to make a COBOL C# bridge library, which will allow you to call C# methods from COBOL. The idea will be to find a way to expose C# classes and methods using COBOL's existing syntax.

We 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)

Re: Show HN: Otterkit – COBOL compiler for .NET

#6

Post by qbasic_forever »

Who do you expect to use this? As I understand it most COBOL use is on legacy mainframes that definitely aren't going to also be running .NET anytime soon. When a company is hiring a COBOL programmer they aren't hiring someone to just sling code--anyone can learn the language--they're hiring someone who can parachute into decades old legacy systems with zero documentation, archaic and non-existent media (tape drives), wildly out of date systems and tools, etc. and instantly be productive. Modern interop with this world is curious.

Re: Show HN: Otterkit – COBOL compiler for .NET

#7

Post by KTSnowy »

eckza wrote: post #4

I'm fascinated with this. 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?

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.

Re: Show HN: Otterkit – COBOL compiler for .NET

#8

Post by danielmarkbruce »

qbasic_forever wrote: post #6

Who do you expect to use this? As I understand it most COBOL use is on legacy mainframes that definitely aren't going to also be running .NET anytime soon. When a company is hiring a COBOL programmer they aren't hiring someone to just sling code--anyone can learn the language--they're hiring someone who can parachute into decades old legacy systems with zero documentation, archaic and non-existent media (tape drives)…

Modernization projects move COBOL code running on mainframes to COBOL code running on the jvm or .net, on x86 machines, using all kinds of libraries emulating services provided by the mainframe OS/environment. It's pretty amazing really.

Re: Show HN: Otterkit – COBOL compiler for .NET

#10

Post by KTSnowy »

qbasic_forever wrote: post #6

Who do you expect to use this? As I understand it most COBOL use is on legacy mainframes that definitely aren't going to also be running .NET anytime soon. When a company is hiring a COBOL programmer they aren't hiring someone to just sling code--anyone can learn the language--they're hiring someone who can parachute into decades old legacy systems with zero documentation, archaic and non-existent media (tape drives)…

Given the amount of proprietary and paid-to-use COBOL compilers which run on .NET and the JVM, I would say that you're not correct. It does in fact run on .NET already.

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.

Post reply on HN