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

71–80 of 85 posts

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

#71

Post by jimbo99912 »

KTSnowy wrote: post #10
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…

Additionally, it should be noted that mainframe IBM COBOL has also continued to be updated and extended, to the extent that it has native support for JSON serialization/deserialization for building web services.

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.

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

#72

Post by jasode »

gymbeaux wrote: post #65
pjmlp wrote: post #43

Earlier quoted context omitted.

Carbon team is the first one to assert that Carbon is for Google internal purposes, or anyone that eventually shares their point of view regarding C++, everyone else should go with Rust or any other safer alternatives. 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 neve…

I don't know that I have seen anyone hype it, I just think it's funny that Google invented yet another programming language, and that (to me anyway) it's really just to gain access to features that are probably coming down the pipe in C++ in due time anyway.

>Google invented yet another programming language, [...] just to gain access to features that are probably coming down the pipe in C++ in due time anyway.

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.

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

#73

Post by bob1029 »

jiggawatts wrote: post #27

This reminded me of the IKVM project: https://github.com/ikvm-revived/ikvm 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!

For a while we used a variant of this in production to interop with an IBM iSeries from .NET. It was mostly about getting access to the DB2 connection, but we also had to run some programs on that system.

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

#74

Post by gymbeaux »

jasode wrote: post #72
gymbeaux wrote: post #65

Earlier quoted context omitted.

I don't know that I have seen anyone hype it, I just think it's funny that Google invented yet another programming language, and that (to me anyway) it's really just to gain access to features that are probably coming down the pipe in C++ in due time anyway.

>Google invented yet another programming language, [...] just to gain access to features that are probably coming down the pipe in C++ in due time anyway. 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/c…

Interesting. I haven't seen that blog post. Thank you for sharing it!

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.

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

#75

Post by Semaphor »

Rochus wrote: post #60
KTSnowy wrote: post #24

Earlier quoted context omitted.

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…

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

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

#77

Post by KTSnowy »

Rochus wrote: post #60
KTSnowy wrote: post #24

Earlier quoted context omitted.

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…

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

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

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

#78

Post by garganzol »

Semaphor wrote: post #75
Rochus wrote: post #60

Earlier quoted context omitted.

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

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

#79

Post by Rochus »

KTSnowy wrote: post #77
Rochus wrote: post #60

Earlier quoted context omitted.

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

> 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…

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

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

#80

Post by IainIreland »

jimbo99912 wrote: post #71
KTSnowy wrote: post #10

Earlier quoted context omitted.

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…

Additionally, it should be noted that mainframe IBM COBOL has also continued to be updated and extended, to the extent that it has native support for JSON serialization/deserialization for building web services. 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…

Eh. I worked on IBM's COBOL compiler for four years or so, and I think you're overselling COBOL. COBOL is the best language for extending the functionality of critical legacy systems already written in COBOL. I have a soft spot for the language, in the same way you might for a puppy that is big-hearted but ultimately not very bright, but I can't imagine a greenfield project where COBOL is the right implementation choice. (Idiomatic COBOL does end up being surprisingly fast, mostly because the idioms were established in the 60s where things like "dynamic memory allocation" and "a call stack" were too expensive.)

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.

Post reply on HN