Live data from Hacker News

A Minecraft server written in COBOL

github.com

91–100 of 127 posts

Re: A Minecraft server written in COBOL

#91

Earlier quoted context omitted.

There's actually two completely separate games (Java edition and Bedrock) that can't cross-play with each other. You can buy a Bedrock edition Minecraft for Windows that should be able to cross-play with the switch. Java Edition is the original game and it's fairly easy to either host your own server (The dedicated server is just a .jar you run) or pay for a server ($10-40/mo) using a game server host. Unsure about b…

There are extensions/plug-ins to the standard Java server, allowing Bedrock players, and xbox accounts to join: https://geysermc.org/ (Plus Floodgate so they don't need a Java account) I just setup a new family minecraft server last week and have successfully hosted java and bedrock players simultaneously (one coming in from a Nintendo switch, another from their phone and several from Java clients). There are also pl…

Oh that’s awesome! I’ll have to try that.

Re: A Minecraft server written in COBOL

#92
post #85

Earlier quoted context omitted.

I don't think it's a fallacy. As someone who has 2 WIP games in Rust, I noticed that getting a very minimal gameplay prototype was pretty easy (given a sane engine choice)* but then adding features made the code balloon in size. Switching from singleplayer to multiplayer was a mess. I also fell for some fads and had to waste time removing them. And Rust really, really doesn't like heavily interconnected graphs of gam…

[flagged]

Isn't Tinyglade mostly custom code including the renderer, just using bevy_ecs as data storage?

Re: A Minecraft server written in COBOL

#93
post #90
post #32

Earlier quoted context omitted.

As a teenager I swore by Turbo Pascal's begin/end syntax and C++ at the time, with its overloads and macro system was just noise to me. Many years have passed since but C++ with its overloads and macro system is still largely noise to me.

#define begin { #define end }

Are you Stephen Bourne?

Re: A Minecraft server written in COBOL

#94
post #32

Earlier quoted context omitted.

As a teenager I swore by Turbo Pascal's begin/end syntax and C++ at the time, with its overloads and macro system was just noise to me. Many years have passed since but C++ with its overloads and macro system is still largely noise to me.

Overloading can be easily abused, but the very complicated expressions that can appear in programs for scientific/technical computing are immensely more readable when using operator overloading like in C++ instead of using named functions, like in languages that forbid operator overloading, e.g. Java. In scientific/technical computing you have frequently, even in the same expression, dozens of different kinds of addi…

> ”do” and “done”

“do” and “od” IIRC

Re: A Minecraft server written in COBOL

#95
post #5

> Well, there are quite a lot of rumors and stigma surrounding COBOL. This intrigued me to find out more about this language, which is best done with some sort of project, in my opinion. You heard right - I had no prior COBOL experience going into this. I hope they'd write an article about any insights they gained. Like them, I hear of these rumors and stigma, and would be intrigued to learn what a new person to COBO…

One of the rumoured stigma is that the object-oriented flavour of COBOL goes by the unwieldy name of ADD ONE TO COBOL YIELDING COBOL. At least it doesn't have the unrumoured stigma of older FORTRANs, which ignored whitespace, allowing: DO 10 I=1.10 to silently compile an assignment: DO10I = 1.10 instead of signalling an error for the syntax of the loop the flight software programmer had intended: DO 10 I=1,10

> One of the rumoured stigma is that the object-oriented flavour of COBOL goes by the unwieldy name of ADD ONE TO COBOL YIELDING COBOL.

Which is a joke. Rather than an extension, the COBOL standard itself incorporates OO support, since COBOL 2002. The COBOL standards committee began work on the object-oriented features in the early 1990s, and by the mid-1990s some vendors (Micro Focus, Fujitsu, IBM) were already shipping OO support based on drafts of the COBOL 2002 standard. Unfortunately, one problem with all the COBOL standards since COBOL 85 (2002, 2014 and 2023), is no vendor ever fully implements them. In part that is due to lack of market demand, in part it is because NIST stopped funding its freely available test suite after COBOL 85, which removed a lot of the pressure on vendors to conform to the standard.

Re: A Minecraft server written in COBOL

#97

I'm sure this is some kind of fallacy, but I feel I quite often see ostensibly impressive small side projects like this written in simple plain languages like C (or here COBOL). Every similar, e.g., Rust project I see seems almost non-functional despite having 10x the SLOC. My working theory is that simpler languages lend themselves to blueprinting ideas and getting something working even with an ugly messy codebase,…

Rust has really struggled to break through in gamedev. Rust's core premise is trading off dev speed and flexibility for memory safety, but it turns out that dev speed and flexibility is far more important in gamedev than memory safety.

If you have a formally specified microkernel that's already blueprinted to within an inch of its life, Rust is probably a great choice for you. If, on the other hand, you need to rapidly throw slime at a wall to see what sticks and makes for fun gameplay, Rust is going to make that much more challenging than virtually any other language, and the benefits are far from obvious (your quick and dirty gameplay slice that took much longer to make is slightly more memory safe?).

I'm not the only person who's done gamedev in Rust and has since definitely turned away from the language for that use case, see e.g. "Leaving Rust gamedev after 3 years" [0], which remains one of the most widely discussed and liked Hacker News posts about Rust to date.

More broadly, it's obvious that Rust is far more hyped than Cobol is. That means there are many examples of valiant attempts at OSS or hobby projects in Rust by the devs most susceptible to hype (generally enthusiastic beginners). Conversely, writing a Minecraft server in Cobol requires slightly more whimsy and derring-do, which tends to correlate with greater experience.

[0] https://news.ycombinator.com/item?id=40172033

Re: A Minecraft server written in COBOL

#98
post #77

Earlier quoted context omitted.

What platform are you thinking you'd want to use this on that docker doesn't support

FreeBSD and Solaris mostly for me. There are many other OSs though than Linux and Windows.

FreeBSD should work with podman, which isn't literally docker but is probably drop in for this use and can use the Linux compatibility layer.

A quick turned up https://www.dbi-services.com/blog/freebsd-basics-8-running-l... which seems to confirm.

Re: A Minecraft server written in COBOL

#99
post #74
post #5

> Well, there are quite a lot of rumors and stigma surrounding COBOL. This intrigued me to find out more about this language, which is best done with some sort of project, in my opinion. You heard right - I had no prior COBOL experience going into this. I hope they'd write an article about any insights they gained. Like them, I hear of these rumors and stigma, and would be intrigued to learn what a new person to COBO…

Yeah, I love these insights. If you are interested, here are insights from making a COBOL to C# compiler: https://github.com/otterkit/otterkit-cobol/issues/40 I am now convinced that COBOL is just a high level assembler.

> I am now convinced that COBOL is just a high level assembler

In fairness, I think to some extent everything was just a high level assembler in its day, and then it never changed:)

Re: A Minecraft server written in COBOL

#100

I'm sure this is some kind of fallacy, but I feel I quite often see ostensibly impressive small side projects like this written in simple plain languages like C (or here COBOL). Every similar, e.g., Rust project I see seems almost non-functional despite having 10x the SLOC. My working theory is that simpler languages lend themselves to blueprinting ideas and getting something working even with an ugly messy codebase,…

I've sometimes thought perhaps coding would be much simpler if instead of creating a new programming language, we instead create a fantasy workstation akin to PICO-8/Picotron geared towards building business applications. On the user interface side, you only have to code to the fantasy workstation's fixed UI and it can be smart enough to automatically be responsive for different screen sizes. Since it's geared toward…

There have many attempts to do something like this. I'm arguably working in one of them now, a so-called low code environment. Much of it amounts to storing functions in a database instead of in a file tree, and losing access to modern conveniences like a language server and revision control. The latter quite a bit like working in the PICO-8 editor, really.
Post reply on HN