40 years from now, C-suites all over the world will be saying "COBOL Minecraft servers are dead."
A Minecraft server written in COBOL
61–70 of 127 posts
Re: A Minecraft server written in COBOL
#62I'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,…
People that get things done usually don't care about code quality. I noticed myself in a place where I just never finished anything anymore by trying to write something to last. Over the years I've found a good balance, but I've found that iterating over garbage will eventually turn into something good and I've been doing so since.
Is good software a Dorodango? A pile of mud that has polished enough to be pretty.
Re: A Minecraft server written in COBOL
#63I'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 towards business apps that are primarily forms, it doesn't have to care about all the edge cases of the web's presentation layer.
Concepts like durable messages queues (like Temporal.io) could be first class citizens so instead of the distributed mess of lambdas, queues, step functions, etc, you just have basic code that can be web scale.
I haven't given it too much thought. It just seemed like something interesting to explore.
Re: A Minecraft server written in COBOL
#64I'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,…
A minecraft server isn't exactly a small side project. There are some in works for 3-5 years and they are not yet complete, some have very specific features (like https://github.com/MCHPR/MCHPRS which is meant for redstone showcases). This COBOL server doesn't yet implement lighting and that's one of the hardest parts since mob generation also depends on it. It also didn't fully implement some blocks. You need years to finish a minecraft server so getting something done fast isn't the best path along the way.
Re: A Minecraft server written in COBOL
#65I'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 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 game objects where a game event can lead to updating multiple other types. There is friction in everything. One choice was to just live with it and write slightly more code. The other was trying to find some systematic solution that would take more code upfront and save me time later.
I chose the second options, went through some experiments but it feels like the breakeven point is way further than makes sense for a small one-person project.
*Even within one language, there can be order of magnitude differences. Rust has 2 usable 3D engines, one is well known, has dozens of contributors and gets donations that can supplant a Bay area salary. The other is written by mostly one guy who alternates between living from savings and working full time. The first engine heavily focuses on advertising and has been promising various features for years with little to show for it. The other is ahead in both number of features and implementation quality.
I think it's attitude. Some people code for the fun of it, some people have a clear goal in mind and focus on achieving it, some code for money, some code for public recognition, etc. I don't think an ugly messy codebase is necessary but there's a productive middle ground. People who focus on showmanship instead are more likely to chase fads and fancy architectures.
Re: A Minecraft server written in COBOL
#66I'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 think what you have identified is a truism.
Simple languages present a very lean cognitive load.
They also do not offer a bazillion choices, and that is perhaps their greatest appeal! When the language is simple, a programmer can apply more brain power to actualize the idea.
Re: A Minecraft server written in COBOL
#67I'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 think it's just the difference between real hackers™ who often have a fancy for simpler languages and can write the whole universe in anything you give them, versus code monkeys chasing the latest hype cycle. (For reference, I put myself into the second category.)
The author is clearly talented and experienced building server-side systems. So while the language itself is new to the author, the design and architecture would be largely the same if this project were written in Ruby, C, Python, or Javascript.
Had they built something outside of their comfort zone, the results would probably be a lot more messy.
Re: A Minecraft server written in COBOL
#68I'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 think what you have identified is a truism. Simple languages present a very lean cognitive load. They also do not offer a bazillion choices, and that is perhaps their greatest appeal! When the language is simple, a programmer can apply more brain power to actualize the idea.
You can't agonize on the best way to shave a yak if there's only one way to do it.
Re: A Minecraft server written in COBOL
#69Earlier quoted context omitted.
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
If you have to go to 1977 or prior to slag a language, there are tons of languages that will disappoint you.
PL/I
Re: A Minecraft server written in COBOL
#70Earlier 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…
It's precisely when "you have frequently, even in the same expression, dozens of different kinds of additions, multiplications, divisions, etc., between scalars, vectors, matrices, tensors, complex numbers, various kinds of physical quantities, and so on" that operator overloading should be driven by custom syntax macros. (E.g. in a Rust-like language you might define math_expr!(...), float_expr!(...), matrix_expr!(...) etc. syntax macros, each with its own special semantics for operator symbols.) That way a program can directly express the variety of overloading that's relevant in any given context, as opposed to relying on fragile hacks like special __add__ and __mul__ "traits" that are dispatched in a type-dependent way.