The biggest problem with monads that I am aware of is that they don't compose: if m1 and m2 are monads, then you can't automatically derive a new monad m3 where m1 (m2 a) and m3 a are equivalent.
Monad transformers are one solution to this. This lets you write the composition rules for m2 once, and then reuse them for every m1. A solution, but boilerplatey.
I don't understand algebraic effects quite as well, but my understanding is that they do simply compose.
> You know what's the most interesting part of this whole article? The thing Rust is very famous for, memory safety, did not feature at all.
I think that's the essential point, really... It'd be hard to argue that the rest of Rust isn't overall "better" than C++, but the compromises made to flexibility and ergonomics to achieve memory safety in Rust are the biggest points of contention for Rust critics.
The GBA SDK is pretty minimal in terms of library support. It's mostly functions for accessing save data plus wrappers around syscalls found in the bootrom. Those syscalls are some basic math functions, a few decompression algorithms, and an early version of the MusicPlayer2000 sound engine.
I would not let the name distract you - it's equivalent to overloading, not "generics" (i.e. parametric polymorphism)
In that capacity I think it's quite a lot more sane than C++. Having a closed set of overloads, not having name mangling, not having complex name lookup rules are all a good thing.
> Within a structure object, the non-bit-field members and the units in which bit-fields reside have addresses that increase in the order in which they are declared. A pointer to a structure object, suitably converted, points to its initial member (or if that member is a bit-field, then to the unit in which it resides), and vice versa. There may be unnamed padding within a structure object, but not at its beginning
C99 §6.7.2.1.13
> An implementation may allocate any addressable storage unit large enough to hold a bit-field. If enough space remains, a bit-field that immediately follows another bit-field in a structure shall be packed into adjacent bits of the same unit. If insufficient space remains, whether a bit-field that does not fit is put into the next unit or overlaps adjacent units is implementation-defined. The order of allocation of bit-fields within a unit (high-order to low-order or low-order to high-order) is implementation-defined. The alignment of the addressable storage unit is unspecified.
Which is standardese for pretty much exactly everything you said :)
The consequence of the first rule is that there's only one sane way to lay out structs. The only way to break that rule which I can imagine would be to add extra padding - you can't swap the order of any members under these rules.
Etrian Odyssey released in 2007 and was a fun throwback to this sort of experience. The concept for this game is that the Nintendo DS's touch screen can be used to draw a map and keep notes while dungeon crawling. It's funny to think that it's about as old now as the style of games it was imitating then.
The 3DS also had a note-keeping system built into the main menu and usable in any game, but I don't think many people bothered.
Those rights, like to bear arms and freely associate, only exist on paper. That they are in a state of nominal existence and practical abrogation serves to deradicalise and defuse resistance against the government, not encourage it.
I think the point is that Intel had such a lead in the Bulldozer era that for AMD to overtake them was a tremendous failure.
I would not say that the first gen of Zen is was a clear winner over Skylake. It took a couple iterations before AMD clearly took the lead. AMD was simply so far behind that several large generational improvements were needed to do better than Intel.
The first smartphone I owned was a ZTE Blade 13 years ago. As a budget phone, that definitely had compromised performance.
It's been years and years since I ever felt like my phone's performance was holding back its usefulness to me. I have only ever replaced my phone because the battery could no longer hold a charge or the charging port was damaged beyond use.
It has a camera, web browser, chat apps, and receives emails. It also makes calls and texts. It doesn't lag while doing these things. That's plenty.
I was approaching it from the perspective of "What would be useful to do on a Wii?" When you approach it from the perspective of "I want to play with Jazelle - what can I use?" it makes much more sense. Thanks.
EDIT: Following one of the reference links, apparently you can enter Jazelle mode on the Nintendo 3DS's application cores. That's another suitable target.
https://github.com/SonoSooS/libjz
This seems roundabout. If Elon Musk objects to The Onion using InfoWars' X accounts, can't he just make up a reason to ban them after the sale goes through? It's not like X can't unilaterally and arbitrarily close accounts.
This seems very useless. I'm not sure Jazelle was ever used for anything, and I'm not sure why anyone would want to either - least of all on the Wii's IO processor.
Still, this repo links to some other stuff I found interesting. The Starlet exploit which is linked is funny for how basic it is, and it also seems to be part of a much bigger and more ambitious (but mothballed?) project.
Intel just can't stop floundering. Alder Lake and Arrow Lake were talked up a lot, but Alder Lake only approximately caught up to AMD, and Arrow Lake is still well behind.