Klipsch was famous for making speakers using acoustic horns, which was somewhat esoteric. When they finally made a speaker which used a conventional woofer, they named it “the heresy”.
A 3dfx card running in an O2 surely deserves a similar moniker :)
I would guess that most folks would consider a bunch of problem prompts with no reference solutions to be not so useful. How would you check your understanding? How would you know if you were writing go code which would be frowned upon by industry veterans?
I think it has more to do with the fact that when you offer zero salary for moderators, you have to take what you can get, and it ain't good. I don't really see a connection to the voting mechanic.
> but it is really hard to make a good sounding cassette
It is unfortunate that cassettes are the lowest fidelity consumer medium (of modern times). But there is some room to optimize within that space. If you are curious:
The cassettes available today are Type I, Type II ("high bias") and Type IV ("metal"), each being higher fidelity than the last, but not all portable players supported these types of tape.
Dolby B/C noise reduction could improve the dynamic range of tapes a bit, but again not all portable players supported this.
The ultimate was "dbx", which dramatically improved noise reduction and dynamic range ("tape hiss" was essentially inaudible), but now you're in the territory of needing dedicated rack-mount equipment to record and play your tapes.
My dad was a bit of an audio buff, so I got to experience these things as a kid.
Edit: according to gemini AI:
* Type I had a dynamic range of about 50bB (roughly 8 bits)
* High quality tape with Dolby B, C and dbx yielded roughly 65, 75, and 85dB SNR (about 11, 12.5, and 14 bits)
So you could get pretty close to CD quality, but not quite.
For typical apps, the four variables here are backend latency, network latency, client-side deserialization, and client GUI rendering. (Less commonly, apps which have complex client-side state will also spend time reconciling server and client state.)
Keeping UI rendering under 16ms is the gold standard for native apps. That leaves only deserialization as the other target which the mobile developer can optimize. However, the typical solution there involves convincing the backend to ship a different format (i.e. switching from JSON to binary PList or to SQLite DB file).
Something like StarCraft, but each unit has to be piloted by a human (using a first person shooter interface). The leader player sees the traditional high-level StarCraft interface, and directs the troops. Each individual troop sees some on-screen representation of its “orders” (“attack this unit”, “move over here”).
A 3dfx card running in an O2 surely deserves a similar moniker :)