my experience with fixing programming builds is spending 9 hours debugging a build failure to then stumble upon some post that is like "well, did you try the --unfuck-the-build option?" and i'm just like "WHY IS THAT EVEN AN OPTION?!?!?!"
- she/her
Principal engineer at Mercury. I've authored the Dhall configuration language, the Haskell for all blog, and countless packages and keynote presentations.
I'm a midwife to the hidden beauty in everything.
💖 @wiredaemon
twitch
twitch.tv/GabriellaG439discord
Gabriella439
discord server
discord.gg/XS5ZDZ8nnplocation
bay area
private page
cohost.org/newmoontwitter
twitter.com/GabriellaG439You must log in to comment.
in reply to @fullmoon's post:
"you mean you don't want to choose if the compiler works or not???" /j
That reminds me of the days that Visual Studio used to have a set of radio buttons for optimization, to optimize for Speed or Size. Beneath the radio buttons, they'd show a note saying that, for the fastest code, you want to optimize for size rather than speed.
And look, I know what they mean, here. Paging was a big deal, before the Internet found a bigger slowdown. But...I don't know, maybe at least change how you describe the options? Or eliminate it...
I do like the idea of a "make my program slower" compiler flag, I should fork gcc to make it add random useless IO calls in funny locations...
Ooh this reminds me of the time a friend's Display Manager wouldn't start up due to running out of disk space. That took us a very long time to debug, why would you make logging a blocking task AND a critical one at that?