ZILtoid1991

I'd agree, but here's one issue with that: we live in reality, not in a post-capitalist dreamworld.

Creativity takes up a lot of time from the individual, while a lot of us are already working two or even three jobs, all on top of art. A lot of us have to heavily compromise on a lot of things, or even give up our dreams because we don't have the time for that. Sure, you get the occasional "legendary metal guitarist practiced so much he even went to the toilet with a guitar", but many are so tired from their main job, they instead just give up.

Developing game while having a full-time job feels like crunching 24/7, while only around 4 is going towards that goal, which includes work done on my smartphone at my job. Others just outright give up. This shouldn't be the normal for up and coming artists.

I don't think that's a feasible dream in our current system. They'll just lobby for it, some senators will say something akin to "art should have been always a hobby, not a profession", then make adjustments for the current copyright laws so that they can be copyrighted.

Even worse is, in order to further humanize machine learning systems, they often give them human-like names.

Don't forget that the pirates usually don't say "art should have been just a weekend hobby, not a profession".

They need to rename themselves "Intelligent Archive" then claim they're an AI service that can just happen to regenerate whole books.

> ruins combat
> ruins warfare
> ruins swordfights
> ruins hand-to-hand combats
> ruins an entire fucking combat doctrine

Gunpowder, and its consequences...

Issue with C# is, that it's quite far away from a system language, and I would have to write the engine's main core in some more system-level language, and I don't consider it good practice to write every component that doesn't directly interfacing with the OS in a trendy scripting language.

I have talked to people about Rust gamedev (including those who left Rust for D due to gamedev), and it's not a very good one, due to the functional aspects. Outsiders often joke about how Rust has more game engines than games.

Zig has the header file problem. Header files were originally created to get around memory limitations of old workstations, that no longer exist. They also complicate coding, since you now often have to implement things at two places at once. However, Zig not only copied C++'s multi-inheritance, but also its header files, without understanding the actual reason why it existed in the first place.

Classes can be useful for abstraction. Just because they often overused doesn't mean they're bad.

Without an explicit class, I would either:

• had to reimplement them in a language without them (which looks extremely ugly and can be unsafe),
• create an "omnistruct" that keeps track of all posssible field (only looks a bit ugly),
• use uglier virtual functions for cases when I would need local states (doStuff(cast(void*)&localstate, values) vs localstate.doStuff(values)).

While structured programming was a godsend to the chaos preceding it, newer programming paradigms should have been instead seen as tools rather than the next dogma. OOP got its bad name from languages that disallowed its users to develop without classes, and enterprise settings making its devs to implement things that could have been simple functions as classes, sometimes complete with factories.

Same is with functional programming. There's clearly a usecase for it, but isn't a Swiss-army knife solution for all problems of programming.

It's too high level for my usecase, so unless I either use a preexisting game engine, or develop mine using a system language, so C# is only good as a scripting language in my usecase, and sometimes you want "hard-code" new features, not script them.