- cross-posted to:
- programming_languages
- cross-posted to:
- programming_languages
Introducing Otterkit COBOL
Given that this is a community about the COBOL programming language, I’d like to take the opportunity to make a post about this project that I’m a part of. Our goal is to create a compiler implementing the ISO 2023 standard of the COBOL language. If you’re confused/interested in what that means, please read further.
Why a new COBOL Compiler?
It is often believed that COBOL is an antiquated and archaic language: the logo of this community is literally a dinosaur. But this is not true. Did you that as of the most recent version (ISO 2023), the language has:
- objects and classes
- generics
- concurrent async both locally and remotely (message passing)
Sounds more like a Java or C# than a fossil, doesn’t it?
As the “2023” in “ISO 2023” implies, the language has been evolving ever since it was created in the '50s. But why is the reputation of this language so bad? Firstly, it is that most code in COBOL adheres to the old 1985 standard: that was when the GNU manifesto was first published! This means that the language has been functionally stuck in the public eye for decades, as enterprise systems see little reason to put effort into modernization. This leads to a self-fulfilling prophecy, where COBOL programmers are assigned to tangles of technical debt and even FOSS compilers like GnuCOBOL target the 1985 standard because it’s the one that’s used. But it doesn’t have to be this way.
A Vision of the Future
It is our belief in the Otterkit Project team that modern COBOL, once free of propriety vendor lock-in and outdated stereotypes, has the potential to be a modern - nay, insightful language that deserves a place in the current programming language landscape. That’s why we’re making an Apache 2.0-licensed COBOL compiler on the .net platform to bring modern COBOL out in the open. This way, we hope to prove that even dinosaurs can walk again.
We would appreciate any help we can get: below are links to a presentation team head KT made on the project for the .net youtube channel, and a link to the github repo. Please take some time to look around, and if it strikes your fancy please consider contributing with either code or money, any bit helps.
Useful Links
Github Repo: https://github.com/otterkit/otterkit
Presentation: https://www.youtube.com/live/UASkE7cojSE?feature=share
What’s the pitch for using modern COBOL? Sure, I’ll take your word that it’s not nearly as bad as COBOL 1985, but that is true of most languages!
If I want to write in a language that’s like Java or C# I can always just write in Java or C#!
Great question. Because of its unique spot in computing history, COBOL takes a different approach as compared to other languages like the C or Lisp families, and we’d be here forever trying to figure out which differences are good or bad. So for now I will list a few benefits that COBOL may have for a project compared to other languages:
ADD
only refers to adding numbers, so there’s no ambiguity thereI hope that answered your most pressing questions.
Removed by mod
Hi, I’m Otterkit’s lead developer, I’ll add a few more reasons why you might want to choose COBOL.
COBOL takes a different and often unique approach to common problems that in my opinion is more efficient and elegant than most other approaches.
The way COBOL handles strings is in my opinion much more efficient than C#, Java or even Rust. In most newer languages strings are implemented as objects (C# and Java), which means that they’ll later need to be garbage collected at some point, which then leads to nondeterministic memory usage and forces it to always be heap allocated. In Rust they are (usually) heap allocated structs, and you have to deal with the borrow checker and the complexity Rust brings to the overall project.
In COBOL, strings are built-in primitive types, not an object or struct at all. This brings a couple of nice compiler optimization opportunities:
The way COBOL handles concurrency is much safer, more efficient, and in situations where you need both local and remote communication, much easier and painless to use. While other languages opted for multithreaded concurrency, where a single process runs on multiple threads, COBOL opted for multiprocess concurrency, where multiple processes run concurrently, sharing data through message passing. COBOL processes have a global per machine Message Control System process, which handles all the message routing between both local and remote processes.
A few other minor things that COBOL handles more efficiently or better than other languages:
public static class
and a GC (C#, Java) to write procedural code, if all you need are functions and don’t need any objects at all, you can write COBOL in a purely procedural way. On the other hand, if what you need are classes and objects with a GC to safely handle memory for you, then you can write COBOL is an OO way without stressing over a borrow checker or manual memory allocation (Rust, C). You can mix the two in a single codebase, and the compiler is free to optimize purely procedural code to not require a GC at all.0U
vs0UL
vs0ULL
in C). This also makes it overall easier to process binary data directly.try..catch
,if err != nil
or similar things everywhere in the middle of you code. You can define “declaratives” that run whenever an exception or error occurs, and as soon as it occurs your program will jump into the declarative for that particular error to handle it, and then if the program continues or not is defined by the user. You can easily use and import these into your source code without it becoming messy.Removed by mod