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

21–30 of 85 posts

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

#21

Post by helf »

TowerTall wrote: post #18
tomcam wrote: post #16

So glad they remembered to support these widely known trademarks: “FLOW-MATIC® (trademark of Sperry Rand Corporation), Programming for the 'UNIVAC® I and II”. My friends and I in /r/univac can’t stand it when the trademarks are dissed. One the mods banned a guy for using Eniac instead of ENIAC and we all thought the 18-month ban was way too light, but the new guard just doesn’t care like we do. Seriously I upvoted an…

I not sure I understand. Did someone get banned for 18 month because he used lowercase instead of uppercase?

I’m 99.999% sure they are just being a dick about the copyright notices :p

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

#22

Post by fortran77 »

helf wrote: post #21
TowerTall wrote: post #18

Earlier quoted context omitted.

I not sure I understand. Did someone get banned for 18 month because he used lowercase instead of uppercase?

I’m 99.999% sure they are just being a dick about the copyright notices :p

Trademark.

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

#23

Post by le-mark »

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

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

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

#24

Post by KTSnowy »

xvilka wrote: post #20
KTSnowy wrote: post #7

Earlier quoted context omitted.

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…

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 is only a small part of it compared to the object oriented side of COBOL. Otterkit will support both, and the new 2022 standard.

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

#28

Post by danielmarkbruce »

derefr wrote: post #15
danielmarkbruce wrote: post #8

Earlier quoted context omitted.

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.

> using all kinds of libraries emulating services provided by the mainframe OS/environment 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 :)

A database. To be clear though, it's usually a library plus a service. It could be library + sqlite etc though I guess. Look here for example, page 8:

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.

Post reply on HN