This is actually pretty huge - up until now Microfocus (and IBM) have dominated the COBOL modernisation space. What would be really interesting would be a systems integrator taking up Otterkit and legitimising it / adding support and so on.
Show HN: Otterkit – COBOL compiler for .NET
51–60 of 85 posts
Re: Show HN: Otterkit – COBOL compiler for .NET
#52For anyone interested in COBOL, where can I check out the COBOL 2022 standard?
Re: Show HN: Otterkit – COBOL compiler for .NET
#53Slightly off-topic: but is there any useful reference to learn modern cobol, especially for newbies?
Re: Show HN: Otterkit – COBOL compiler for .NET
#54It is nice project for CV. I would hire you immediately.
Much harder problem is getting rest of the eco system working on something else than mainframe.
Re: Show HN: Otterkit – COBOL compiler for .NET
#55Earlier 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…
In a similar light, I recently spent some time working with modern Fortran, and was amazed to find it a modern, efficient, and intuitive language for scientific computing that in many ways makes Python look archaic. Not at all what I was expecting given its age And reputation.
If only there was a proper tutorial/course for it...
Maybe there is? Can you link any?
Re: Show HN: Otterkit – COBOL compiler for .NET
#56Earlier 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…
In a similar light, I recently spent some time working with modern Fortran, and was amazed to find it a modern, efficient, and intuitive language for scientific computing that in many ways makes Python look archaic. Not at all what I was expecting given its age And reputation.
AFAIU, Fortran acquired most of its bad reputation in the 60s and 70s. I think it was much more widespread than it is today. Then, as time went on, Fortran moved to the niche it was intended for originally (scientific computation) and was replaced by other languages for general purpose programming. Fortran continued to evolve, but few people got to see that, unless they cared to look. The rest of the world remembered the FORTRAN of old.
Re: Show HN: Otterkit – COBOL compiler for .NET
#57Who 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)…
I met an old colleague and during a chit-chat he said that he diverted into COBOL world. It turned out that the community is quite large, new versions are rolled out frequently and there's a demand for new devs. Looks like there's plenty of areas in our industry that are not covered daily on HN, but they exist and thrive.
Re: Show HN: Otterkit – COBOL compiler for .NET
#58Who 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)…
Mainframes aren’t legacy, they’re just different and not well talked about that much in public. They have a full Unix subsystem with modern ports and lots of integration via VS code extensions.
Re: Show HN: Otterkit – COBOL compiler for .NET
#59I'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 fr…
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 ;)
Re: Show HN: Otterkit – COBOL compiler for .NET
#60Earlier quoted context omitted.
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…
> 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.