RadioRavenRide

joined 1 year ago
[–] RadioRavenRide 1 points 1 year ago

Sonic has the benefit of having a lot of good voice actors throughout the years, so when a new one comes along they can fit in just fine. Notice how people just accepted Deven mack very easily because they're like "oh he's sort of like Roger Craig Smith and Jason Griffith".

[–] RadioRavenRide 2 points 1 year ago

I still back my idea of a Horseshoe crab. Its evolutionary line has remained the same for eons because it works, but changing coastlines and the modern era have led to population decline.

[–] RadioRavenRide 3 points 1 year ago

Sorry, our project isn't far along enough for complete code generation yet. However, we're thinking of making examples in the future.

[–] 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.

[–] RadioRavenRide 3 points 1 year ago

Thank you for putting our project on the beginner list! Regarding the topic of the logo, I personally think that's quite alright to acknowledge that COBOL is a weird and old language with a rich history going all the way back to Grace Hopper and even Flow-matic before her. However, the problem I have with the dinosaur imagery is that they are in fact dead because they could not adapt to the changes in their environment (besides the feathered ones of course). If you're in the market for a mascot animal I would suggest the humble Horseshoe Crab, whose biological order spans back to the Ordovician Period but still exists today.

 

cross-posted from: https://programming.dev/post/265357

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

 

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