COBOL

148 readers

1 users here now

Welcome to the programming.dev COBOL community!

COBOL (common business-oriented language) is an English-like programming language designed for business use.

Rules

Members of this community are expected to exhibit mature and respectful behavior.

Those who fail to uphold these standards may find their posts or comments removed, with repeat offenders potentially facing a permanent ban.

Please keep discussions in English so that they can be appropriately moderated.

Links

founded 1 year ago

MODERATORS

Ategon

Pigeon

KTSnowy

Introducing Otterkit: A Modern FOSS COBOL Compiler (github.com)

submitted 1 year ago by RadioRavenRide to c/cobol

6 comments fedilink hide all child comments

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

you are viewing a single comment's thread
view the rest of the comments

[–] RadioRavenRide 4 points 1 year ago (1 children)

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:

COBOL is based on English, which means that while it may be a bit harder to write, it's a little bit easier to read, which may help bring developers up to speed as a project grows in size. For example, the keyword ADD only refers to adding numbers, so there's no ambiguity there
COBOL programs are split into different divisions and sections, which means that the variables, functions, I/O, and other aspects are in predictable locations and just a ctrl+F away. Combined with the above point, this means that COBOL programs are less likely to become messy over time.
COBOL natively supports the fixed-decimal format for numbers, which, unlike floating-point numbers, does not lose precision for very large and very small numbers. This is very useful in use cases where numbers must be very exact, like banking. Hence why the banking system still runs on COBOL.
In my opinion, COBOL's message-passing model is superior to the thread-sharing model in terms of safety, which would otherwise require something like a borrow checker to stop race conditions and the like

I hope that answered your most pressing questions.