All the fun in computing happens when you figure out how to do something cool you're not supposed to be able to do.
https://mastodon.social/@falcon@mastodon.falconk.rocks/113784517935901980
=> More informations about this toot | More toots from hyc@mastodon.social
I think most people who learned programming from formal coursework probably have too many rules drilled in.
In my college asm class (EECS 381) one of the assignments was to write a software multiplier for MIPS3000. A buddy and I finished early and were just killing time in the lab, tweaking here and there to shave more cycles. We were neck and neck but then I figured out I could load a particular 32bit constant faster by just loading a nearby instruction into a register.
=> More informations about this toot | More toots from hyc@mastodon.social
Ordinarily, as a 32bit RISC, it would take 2 instructions to load a 32bit constant. But one of the instructions in my routine happened to have the exact bit pattern I wanted, and I could grab it with a PC-relative load in a single instruction, which saved one more cycle. My buddy couldn't figure out what I'd done, and finally couldn't match my code's performance.
I commented that bit explicitly before turning in the assignment. The TA wrote "you should not do this".
=> More informations about this toot | More toots from hyc@mastodon.social
People get too hung up on rules about programming. At the end of the day, code is just a sequence of bytes. Bytes are bytes. Types and other abstractions are for programmer convenience. When abstractions get in the way, or it's more convenient to ignore them, they should be ignored. (And of course, you must comment your code to show that's really what you meant to do and you know what you're doing.)
=> More informations about this toot | More toots from hyc@mastodon.social
One of my gripes with OOP is the attempt to hide internal state from callers. Public, private, protected, friend classes ... it's all nonsense that just slows you down. Invariably you find that you need more access because your original API wasn't quite right, and then you're stuck refactoring a ton of unrelated places just to make one more field accessible.
Good abstractions are easy to update, and easy to pierce when necessary.
=> More informations about this toot | More toots from hyc@mastodon.social
Other major problem with OOP - programmers aren't taught that creating/destroying objects is expensive. They construct and destruct them willy-nilly, and waste huge amounts of runtime in memory (de)allocation. And they write a whole slew of trivial classes where the overhead far outweighs the actual class content. Codebases like Mozilla's are hopelessly bad because of this.
https://mastodon.social/@hyc/113788387740198150
=> More informations about this toot | More toots from hyc@mastodon.social This content has been proxied by September (3851b).Proxy Information
text/gemini