Like I said, a lot of people going into gamedev don't want to learn, they want to make. Good luck convincing those people that learning about rendering pipelines and implementing one themselves is a good idea and use of their time. The most common answers you'll get are

• "I don't have time for that"
• "Why, if engine X already does it?"
• "I want to make a game, not an engine"

It's time to return to the roots, to the ~~C programming language~~ CPU specific Assembly language

Fix'd

Joke aside, the answer to most of your questions is "because people with money said so". As to why programs lag despite computers being more powerful, because shitty programmers and a general "BLA is cheap" mentality, where BLA is processing cycles, RAM, storage, network speed, etc. Funnily enough, the "program using everything the hardware offers" is an old complaint, as even Unix was considered a cancer during the 1980s, mostly by people whose computers did nothing but run very specific LISP code.

C is not without its flaws, just like every other language. Teaching it over whatever the market desires may not necessarily make better programmers, nor better programs for that matter.

I look at how programming has changed (...) it was all for the benefit of giant companies or the government.

Giant companies first, govt second and as a side effect, as govts tend to be veeery slow in adopting certain computer related stuff. I suspect the main exception would be intelligence/espionage agencies, but they also much prefer others doing shit programming, makes their job easier.

I remember Netbeans IDE used to have an auto-generator of CRUD java server pages if you fed it with a ready database. No idea if that feature is still there, but it saved my ass during a final assignment once in college.

Before even thinking about "which engine", "which language", people need to train and master the fine art of being aware of their own competence level.

The second is being fully aware that your first game will likely suck and that not everything you make will come out as you dreamed.

The third is knowing where and when to stop, especially regarding features. Many visual novels, effectively the simplest game to make regarding programming logic, die out in early access because the single dev decides to add a new character one too many times, forgetting there's supposed to be an overall story to be told. Yes, feature creep is a problem even in fucking visual novels.

To be fair, you can go places knowing pure Javascript ever since HTML5 became widely adopted, back in 2012 or so. There's a variety of engines and frameworks, including for 3D games (Three.js and Babylon.js are the most known) and every major OS has a native web viewer, so you're not stuck to fucking electron.

The thing is that people want to do something, not learn how to do it. You'll find a lot more people with zero programming experience trying to get into gamedev and they're much better off learning planning and organization skills rather than any specific programming language. Feature creep kills loads of projects

Man, Jedi Outcast was when my noob ass would get relentlessly kicked on saber duels. Good times as I was taught some common online decency

Online gaming in 2004 indeed had much less people available overall. On the FPS front, it was mostly Counter Strike and Battlefield 1942 I guess.

Magnifying glass makes things bigger, checkmate! 🔍🔍

What newly liberated territories? The ones that always belonged to Russia and were mistakenly shown as being Ukrainian?

Changes from country to country, I suppose. I'm not even a teacher, but I know damn well Samuel is an absolute no. Most other biblical names also tend to rate highly on the "DON'T" list.

Putting stuff in place, which is an essential step for properly cleaning most stuff. Cleaning itself is easy-ish for me, organizing, or simply moving my shit so I can reach the dusty places is where I take way too fucking long.