Ok. Can we at least revert to sanity in the FOSS realm then?
My guess is no, since for many writing FOSS software is just a way to hone their saleable skills for BigCorp where they'll spend their days finding new creative ways to put ads in front of people's eyes.
The only significant difference in priorities as regards speed would be the modern prioritization of "developer time", ads, and telemetry.
I can run Windows 95 applications at better than era-appropriate speed, in an x86 emulator written in javascript running on a web browser. That's at least 3 layers of virtual machine abstraction and the applications are still faster.
So if you're saying "the comparison isn't fair because modern software is too shit to hold up", then I agree, but if you're trying to tell me there is something else inherent to modern computing that makes software so many orders of magnitude slower, than I request that you show data to support that claim.
Why does it follow that software designed for modern hardware, running on modern hardware, should be slower than software designed for older hardware running on slightly newer hardware?
> You say he has more credits but only one of those is programming since Braid.
He did start a company after that you know. A successful one that makes money and employs people to make art. I don't imagine that running a business takes no time from his life.
> But even at the time Braid could have been written in python SDL wrappers and probably had similar performance
Braid did a lot more than you give it credit for. Here's a GDC talk about the rewind system in which he explains some of the hurdles he had to deal with: https://www.youtube.com/watch?v=8dinUbg2h70&t=5s Pay particular attention to the discussion of the background particles and how to get that to work within the RAM constraints.
> On the other hand, on a software engineering level those paint by numbers Modern Warfare and FIFA games are both more technically impressive and are designed for fast iteration
Hardly anything about these games change from release to release. They're not exploring new gameplay problem spaces, they're not doing anything super interesting or surprising on a technical level either and I don't get why you think they are. Of course if you keep using essentially the same engine and know exactly what you're trying to make, making another like a goddamned factory is going to happen quicker than if you're trying to make something unique and meaningful.
> If clean code is about maintenance and time to market, the Blow paradigm hasn't proven that its needed or fixes the holes in clean code.
I have heard "maintenance and scaling" as an excuse for poorly performing software for a long time now, yet what I'm not seeing is software that has features added on quick schedules and without bugs. So at best I'd say that it isn't accomplishing what it is supposed to and, at the same time, it is wasting our time and resources by producing slow software to boot.
Yes, he is a good example. His games are as highly regarded as they are because he takes the time to really work through everything about them and ensure they're the product he wants. If you watch his streams you'll see that he is constantly experimenting with things, both gameplay-wise and in the engine... and now in his own compiler for his own programming language.
Jon is not making the by-the-numbers annual entry in the Call of FIFA series here.
But also, as a nit pick, Jon isn't just programming all the time, he's running a business and he is very involved in the indie game community and a founding member of indie fund. And when he is programming it isn't always for his own games. Here is a link to the credits page for him at MobyGames:
It isn't about "micro-optimization", that's just what bad developers use as an excuse for never caring at all about performance. Casey uses the term "depessimization" to describe the process of making a program not run like shit.
Modern computers are ludicrously fast, and modern developers have somehow managed to make them slow.
Regardless, these programs should be spending 99% of their time waiting for user input, but instead they're working data through a mountain of abstraction layers on the faulty assumption that it is a) saving developers' time, and 2) that that is worth much more than user time.
Casey is a bad example of a game designer and he'll be the first to admit it. However, it is worth noting that Jonathan Blow very much does design while he codes and recommends the practice. He also generally abstains from library dependencies and implements a lot of thing himself.
Of course, part of the point of Handmade Hero is to show that you can totally reimplement everything from first principles. Libraries are not magical black boxes, they're code written by human beings like you or me, and you can understand what they're doing.
For instance, he wrote his own PNG decoder[0] live on stream, with hardly any prior knowledge of the spec, even though I'm confident that under normal circumstances he'd just use stb_image. I'm sure he did this just to show how you'd go about doing that sort of thing.
[0] He only implemented the parts necessary to load a non-progressive 24bit color image, but that still involved writing his own DEFLATE implementation.
I think this is hilarious when talking about someone like Muratori, who has had his hands in more games' code than most people on this site have ever even played. He is incredibly productive by comparison to all the people making excuses why their programs are slow bloated garbage fires.
There's a lot of good aspects of Windows. The NT kernel is actually really good, the driver model is largely user mode, it had application-specific sound mixing, PowerShell is really good, etc.
> Is it about having a stable easy to maintain and full featured Linux Desktop. I really do think we have reached that point. Especially now that many workflows have moved to the web I am having a hard time coming up with use cases for which Linux would really not be suited. Even gaming has become very viable.
Damning with faint praise. The success of Linux gaming is due to the efforts of projects that re-implement Windows APIs, and things moving to the web are obviously not targeting Linux either.
I'd say the success of the Steam Deck is a testament to the maturity of the Windows API[0]. Old enough and reliable enough that it is a better target for games on Linux than Linux Desktop's own shit show.
[0] and of course the efforts of the WINE project and proton.
I doubt very many people would be willing to pay out the nose for the education if it didn't come with that piece of paper at the end. Sure, we may value some things along the way, but what matters is the piece of paper.
I disagree. University is primarily about getting a degree to put on your resume. I can't think of anyone I've ever met who cared about what they actually learned in school, only that they got a piece of paper at the end.
One could argue that such a policy actually just ends up incentivizing politicians to accept bribes. Then again, it isn't like the current salary of a congressman seems to be preventing that anyway.
A guess as a beginning Japanese learner: Japanese has a lot of homophones because it has so few syllables. It is also almost always written without spaces. Kanji is actually pretty helpful in reading because it provides semantic meaning that disambiguates homophones as well being more terse and breaking up the writing along grammatical boundaries.
I'm approaching this from the angle of wanting to understand video-game Japanese, and when I am trying to parse some 8-bit era all-katakana chunk of text I find myself wishing it included kanji even though I can only recognize a few dozen just so the grammar is more clear.
Also the internet wasn't as big a thing so marketing hadn't taken over computing yet.