I'm all for humourous roasts of things, but does anyone really find this funny? Was the author possibly being serious? I don't know. What I do know is that I stopped watching after the first four examples because they were all deliberately incorrect or misleading, but also didn't seem funny to me.

1. Crazy initialization
   That sure is a lot of ways to initialize a variable! Even though some of these variables are quite different and would be initialized differently from each other in many other languages, even only counting the initializations that are functionally equivalent, there are a bunch of abuses of syntax that I've never seen used in the wild.

At this point I had hope that this was meant to be amusing.

2. Printing to the console
   C++ has had a version of C's printf function from the very beginning. That weird stream syntax has some hardcore fans but many people ignore it. I did my CS degree close to 30 years ago, and the only time I used stream syntax was for one lab class exercise in which we had to show that we understood how to use stream syntax.

They still could be going for a comedy roast, I guess.

3. Getting a random number
   Much like the printf statement for number 2 above, C++ had its own version of C's rand function from the start. I've never even heard of the stuff that's being shown in this part of the video.

OK that was virtually the same fake point as the previous one, and still no punchlines in sight.

4. Having to type "static_cast" every time you recast a variable
   Nope, you don't. You're free to ask the compiler to automagically recast your variables to another type without giving any further detail just like you can in C. In fact, they're often called "C-style casts". There are even implicit casts, where you literally don't add anything, and just cross your fingers that the compiler does what you think it should do. It's like a little bit of the thrill of dynamic typing brought into C++! By using the static_cast keyword, you can tell the compiler that you understand that there's a potential issue with this recast, but that you expect that the standard way of handling it will be fine. There are other keywords for more unusual situations; it's not just a random bit of busywork added for no reason.

Die Hard (for the NES)

Warning: You MUST read the manual!

At first glance it might look like a simple top-down scrolling shooter like Commando or The Chaos Engine, but it's so much more. It's very free and open, with seven floors to explore, and once the in-game timer ends you must go to the 30th floor for the final showdown. The thing is that there are a few ways both to pick off the terrorists singly or in pairs, and to extend the time limit. If you just hide in some corner of the building and wait for the timer to run out, you're going to get mown down by 30 armed terrorists in a fairly small space. But if you're good you can use that time to wipe out almost all of the terrorists, leaving only the leader Hans himself to face you, which is much more manageable.

Die Hard wasn't high on my list at all when I first played it in the 1990s, but I thoroughly enjoyed it. It's still one of my all-time favourites. But ever since AVGN did a video on it, it's become popular to dump on it.

Most "complaints" that I see about this game either show that the person hasn't actually played it for themselves at all, or are solved by reading the manual. Funnily enough, in that AVGN video he even says something like "Maybe this would make sense if I read the manual, but f*** that, who reads manuals?"

The only negative thing I have to say is that IMO the "foot power" meter, which affects movement speed, runs out a bit too quickly even when you walk everywhere instead of running. That being said, I've only noticed it on later replays, and I don't recall it being a problem the first time I played it all those years ago.

Only Winsocks.

Could someone expand a little on this statement, or point me toward an applicable resource? How do "real" (modern?) CPUs prevent unwanted recursion? As in, not the compiler or the OS, but the CPU itself? I've been searching for a while now but I haven't found anything that clears this up for me.

I don't know if this will work or even compile, but I feel like I'm pretty close.

long main () {
    char output;
    unsigned char shift;
    long temp;
    
    if (i < 152) {
        shift = (i & 1) * 7;
        temp = b[i >> 1] >> shift;
        i++;
        output = (char)(64 & temp);
        output += (char)((n >> (temp & 63)) & main());
        printf("%c", output);
    }

    return 63;
}

"If you were making food, would you use onion powder?"

I think that the demographics of gamers have been skewing older and older, and it's finally reached the point where a critical mass are past the age where they place significant value on the "newness" of a game.

You can still find 13-year-olds decrying PS3 and 360 games as being "unplayable" due to their perceived technological shortcomings, but every year they represent a smaller and smaller slice of the total market. The surveys I've seen lump 18-35 into one group, but I'd be interested to see the results of splitting that into two groups at around 26-27.

Similar concepts (i.e. connect to random strangers' devices when in close physical proximity, and trade mini profiles/trading tokens/whatever) have been done at least half a dozen times, both before and after Nintendo, but somehow they never seem to stick. Street Pass may have been the most successful iteration that I'm aware of. I think that it's hard to get critical mass. Users are excited at first when they set things up, but after a few days or weeks of not getting any hits, they tend to lose interest and turn the service off to save battery life.

If you want to emulate those systems, then yes, you're going to need a fairly beefy computer. You could, as others have suggested, buy a good secondhand system and upgrade it with a GPU and more/better RAM.

But I want to pass on a warning as someone who also loves emulation and wishes they could "have everything in one place": a lot of emulators just aren't there yet, but some people are eager to kid themselves and others that they are.

16-bit systems and before typically have outstanding emulators available. Some systems from the next couple of generations are also very reliable (e.g. PS1, Dreamcast), while others mostly work well with minimal tinkering and only a small handful of exceptions (e.g. N64, Saturn). But after those, the reliability of emulators drops off fairly smoothly. Even the venerable PCSX2, for example, will run almost every known PS2 game in some fashion, but many games outside the biggest hits still have problems that make them terrible. And I don't mean picky things like, "Three notes in the bassline on this background music are slightly off," I mean, "The walls aren't rendered in most areas."

I really recommend having a good look at the compatibility lists for emulators you're interested in before you dive too deep down this hole. It's one thing to have a powerful PC already and think, "why not give it a go?" but another thing to build a new (to you) PC specifically for emulating these systems. I suspect that you may have been spoiled a bit by that fact that even the RP4 only has enough power to run those more stable emulators for older systems.

The definition of the Date object explicitly states that any attempt to set the internal timestamp to a value outside of the maximum range must result in it being set to "NaN". If there's an implementation out there that doesn't do that, then the issue is with that implementation, not the standard.

80s Bobcat Goldthwait

And don't forget that git isn't GitHub! You can use git locally and make your own offsite backups, or I believe that there are other git-based online services as well. As a solo dev working on personal projects, I found it much easier simply to ignore the online issue completely, but git on its own is still super useful.