The fact that you have to explain what classes are, and what static methods are, a huge load of information, for a hello world program. And what's worse, it will leave students rightly confused about what the point of the class is, if it only has static members... Making it more likely they don't retain any of the information. Or alternatively, just say "type it exactly like this, don't think about what the magic words mean" which is a great way to ruin programming for people
The comic works because the people creating the standard want to solve the problem of too many competing standards, but instead they just make it worse.
JS framework creators are not trying to solve the problem of too many JS frameworks.
Happy to see they're actually putting the games onto the cartridges. Most projects like this just use pieces of plastic with an NFC/RFID tag containg the Steam game ID. For me, the fact that the data is actually right there in my hand is half the appeal.
I appreciate that as well, but SD cards still aren't the same as old game cartridges. On consoles up to the Nintendo 64, plugging in a cartridge expanded the physical memory of the system, and the CPU read data directly from the ROM on the cartridge. This is why there were no loading screens.
On SNES, and I believe N64 as well, cartridges could also expand the graphical capability of the system, which made some games really special.
Replicating this on a modern indie console would, of course, be prohibitively expensive and impractical. The speed of modern hardware and physical media, along with more sophisticated game engines, has also practically eliminated loading screens. And this likely wouldn't be an issue on small indie games either.
Still, this is not strictly about loading screens. There was something magical about game consoles before roughly the fifth generation which we're unlikely to ever experience again. Nostalgia probably plays a role in that feeling, but the way they worked was truly different from what we have today. Modern game consoles are essentially small PCs within a walled garden.
> I appreciate that as well, but SD cards still aren't the same as old game cartridges. On consoles up to the Nintendo 64, plugging in a cartridge expanded the physical memory of the system, and the CPU read data directly from the ROM on the cartridge. This is why there were no loading screens.
SD Express is just NVMe over a PCIe lane, so you'll get to do all sorts of fun DMA tricks when it starts becoming more popular.
What you said is true, but this project is about replicating the experience, not the hardware. Maybe it will feel less magical, but the hacks you described were cool but needed due to HW limitations of the time. Using commodity hardware not only makes economic sense now, but also makes the project much more accessible by not requiring a specific console.
AFAIK this hasn't been taught since the 40s. Now (since the late 60s) there are 3 different cursive scripts available, and it's up to the school to decide which one to teach (if any).
This can't be fully correct, though, at least for my (as-remote-as-it-gets) area. My father was born in '52 and had to learn it in school here. He still writes the small 'z' in Sütterlin, and it looks really nice.
Hmm, I believe you. The article also says "Sütterlin continued to be taught in some German schools until the 1970s but no longer as the primary script.[citation needed]"
Looks similar to the cursive z I learned - I guess in the late 70's/early 80's - in Scotland. It's still in my signature, although that's a right scrawl.
In terms of format string syntax, Rust is extremely similar to Python (and C++'s new std::format is also similar). So in that sense it seems Python-style "{name:fmt}" has won. Though the others don't support arbitrary expressions inside of the string.
On the other hand, you have formatting as an expression that evaluates to a string like f"..." in Python, vs formatting as a set of functions that take the same input format but do various things like printf/snprintf/write!/format!/std::print/std::format... Here it seems Python's approach had too many drawbacks, considering they just added formatted templates t"..." that don't evaluate to a string.
If I were to design a new language, I would use a Python-like "{expr:fmt}" syntax for formatting, but I would make it evaluate to some sort of FormatTemplate object that code can inspect.
> Here it seems Python's approach had too many drawbacks, considering they just added formatted templates t"..." that don't evaluate to a string.
That's not a fair characterization at all, since the plan was always to add something like the t"" strings. Having a version that immediately evaluates to a string is convenient, and adds very little complexity either at the implementation level or conceptually.
I don't think that was always the plan. Certainly the proposal has been tossed around for a while, but the overall historical evidence paints a different picture for me.
Agreed about TS, but Python type annotations are not ignored. They are executed as code (all type annotations are valid expressions) and the results are stored on the module/class/function object that contains the annotated variable
Python type annotations get turned into metadata which other tools may inspect at runtime, but the Python runtime itself does nothing with it. It's just well-structured comments.
In Python basically everything is executable, and so are type annotations.
Somewhat related: you technically can access some type metadata in TypeScript at runtime using the `emitDecoratorMetadata` and `experimentalDecorators` tsconfig options, along with Microsoft's `reflect-metadata` polyfill package. There was a trend at one point where people were writing database ORMs using decorator metadata (e.g. Typegoose, TypeORM, and MikroORM).
This of course requires your build tool to actually understand the TS type system, which is why it's not supported in tools like esbuild and tsx (which uses esbuild under the hood).
> Now I love dynamic typing - but not the Python kind - I prefer the Scheme kind - latent typing.
Could you elaborate on the difference? I was under the impression that "latent typing" just means "values, not variables, have types", which would make Python (without type annotations) latently typed as well.
I think he meant what's the scenario where you're using IPC via shared memory and don't trust both processes. Basically it only applies if the processes are running as two different users. (I think Android does that a lot?)
Optical disc media is pretty great, if only they didn't scratch so easily... Or get completely destroyed if something sticks to the label side and you try to pull it off... Or delaminate themselves from old age...
Enclosed discs like Minidisc solve most of those, but still die from age.
Still hope they can perfect those "laser-created point clouds in glass cubes" media someday
Minidiscs are the most practical physical media I’ve come across. The used discs I’ve bought are 20-25 years old and don’t have a case or anything and still play like they were recorded yesterday, even when their contents make it clear that they were recorded to shortly after the disc was manufactured. The CDs and DVDs I’ve burned of the same age are comparably in much poorer shape, some being entirely unreadable.
Their size is great, too, being about as small as you can get while still being easy to handle across the gamut of human hand sizes yet too big to easily lose, and they’re more fun than SD and CF cards with their outer plastic casings coming in all sorts of colors and patterns.
A new media format that takes these strengths and fuses them with those of flash storage would be wonderful. The only thing is that I don’t know how you’d solve is the bit rot problem flash has when spending extended time powered down — maybe dedicated storage for parity data? Capacitors that hold just enough juice to keep the flash “alive”? Redundant flash chips? This isn’t my area of expertise so I’m just throwing things at the wall haha.
I recently started an effort to make backups of all of my DVDs and blurays, and it's not a lot but I do have a number of older discs of both sorts that now have errors or even can't be read at all despite only leaving their cases a handful of times and having no visual damage.
I've yet to lose any data after validating a good burn on any M-DISC DVD even well over a decade now. I have also not experienced any loss in data for Verbatim Blu-rays after validating the burn.
I remember back when I was making xbox 360 back ups buying a cheap dvd just would not work most of the time getting to many errors. I think it was the Verbatim brand also burned at a slow speed that seemed to be the most successful.
My thought with that is that being cheap to save a few bucks on on discs might cost you your data. Buy the trusted brands who have a proven track record.
Yeah, I remember finding a good supply of Verbatim DVD+/-Rs and +RWs, and iirc the -Rs seemed to work better for my particular stock internal optical drive, and a slow burn speed was key. Once I got FTP setup to my desktop and sorted out the FATX situation, I upgraded my internal HDD and didn't really mess with disc-based backups for 360 as it didn't seem worth the hassle once I got it ironed out, which I'll admit was a decently complex project involving hot-swapping, but not much more complicated than the initial drive firmware flash. They're fun machines to mod, especially as I had just finished an OG Xbox softmod project at the time (~2007).
Edit:
This might be relevant to your interests, and to others interested in 360 modding.
> Bad Update is a non-persistent software only hypervisor exploit for Xbox 360 that works on the latest (17559) software version. This repository contains the exploit files that can be used on an Xbox 360 console to run unsigned code.
Addendum:
Modern Vintage Gamer's video of the exploit, which is amazing to see. I had no idea 360 softmods were a thing, and the exploit can run against a free trial version of a retail game, which is just chef's kiss.
> Any Xbox 360 can now be hacked in less than one minute
> A look a the newest V1.2 Badupdate Exploit - Xbox 360 software only Hypervisor Hack that we covered back in March 2025. It requires an Xbox 360 - any model including the later Winchester revisions! A USB flash drive and Rock Band Blitz Trial. This updated 1.2 hack runs much faster and reliable and is now a recommended option to hack any Xbox 360. In today's episode we take a closer look at the BadUpdate V1.2 exploit.
Oh I didn't see your comment right away. Yes I did hear about the mod you mention but what I actually did years ago was the Reset Glitch Hack (RGH) on mine and several other 360's. It required soldering in a tiny piece of hardware which required you to solder to the smallest of pads on the motherboard. I remember at the time I had the cheapest junk soldering iron and nothing to help magnify the board and the pad you need to connect a wire to is literally smaller then a pen tip. Many people screwed up and lifted pads causing big problems for their 360. I had some previous experience soldering and managed to have no problems with the install.
In the end my RGH worked really well and it would boot first try every time, some people it could take like a minute to actually boot. Then it would load into custom firmware and I was able to do what ever I wanted. I still have the thing and it still runs with an external HDD with about 1000 games (all personal back ups of course) and my kids never knew how lucky they were to be allowed to play all my games I had backed up.
It’s okay, most of what I wrote was with my OG Xbox in mind and I got my wires crossed talking about the 360, which I think I only did an optical drive firmware flash on. I never tried the RGH, that sounds kinda fun though I’d start with the soft mod I mentioned first or instead if I were to try again today.
reply