4 ms·

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 p

by eckza 4y ago

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?

KTSnowy 4y ago
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.
- deleted 4y ago
  [deleted]
- xvilka 4y ago
  Why not improving Gnu COBOL[1] then? It has better support for the COBOL constructs and libraries already. [1] https://gnucobol.sourceforge.io/ https://gnucobol.sourceforge.io/
  - KTSnowy 4y ago
    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.
    - xvilka 4y ago
      Thanks for the answer. Looking forward for your project success!
    - Rochus 4y ago
      > 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.
      - Semaphor 4y ago
        > 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_new_free_and_open_source_cobol_to_c/j3l5p68/ https://old.reddit.com/r/csharp/comments/1074jdj/otterkit_a_...
        garganzol 4y ago
        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.
      - KTSnowy 4y ago
        > 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#.
- le-mark 4y ago
  > 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#.
- nix23 4y ago
  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 ;)
- the_af 4y ago
  > 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.

by eckza 4y ago

KTSnowy 4y ago

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.

deleted 4y ago
[deleted]
xvilka 4y ago
Why not improving Gnu COBOL[1] then? It has better support for the COBOL constructs and libraries already. [1] https://gnucobol.sourceforge.io/ https://gnucobol.sourceforge.io/
- KTSnowy 4y ago
  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.
  - xvilka 4y ago
    Thanks for the answer. Looking forward for your project success!
  - Rochus 4y ago
    > 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.
    - Semaphor 4y ago
      > 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_new_free_and_open_source_cobol_to_c/j3l5p68/ https://old.reddit.com/r/csharp/comments/1074jdj/otterkit_a_...
      - garganzol 4y ago
        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.
    - KTSnowy 4y ago
      > 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#.
le-mark 4y ago
> 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#.
nix23 4y ago
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 ;)
the_af 4y ago
> 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.