"I prefer a lack of magic for my programming [production systems]" the dev says while they write in a language for a compiler they don't understand, with algorithms in the standard library they couldn't implement, performing processor specific optimizations they've never heard of, to run on a virtual computer whose amount of allocated RAM and CPU is mostly a polite fiction, where it will eventually be reduced to a microcode before running on a processor that simulates the software out of order.
Conversation
Notices
-
Embed this notice
Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 30-Nov-2024 03:45:28 JST Hrefna (DHC) -
Embed this notice
Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 30-Nov-2024 06:02:49 JST Hrefna (DHC) Spectre and malloc are both great examples.
Really at some point you just accept that everything you are writing is pseudocode that mostly runs in a way that approximates what you expect and is _good enough_. Most of the time.
Until it isn't.
-
Embed this notice
Gerbrand van Dieyen (gerbrand@fosstodon.org)'s status on Saturday, 30-Nov-2024 06:02:50 JST Gerbrand van Dieyen @samir @hrefna The problem with magic is that it leaks, spills over and doesn't compose.
-
Embed this notice
samir, stack-based (samir@mastodon.functional.computer)'s status on Saturday, 30-Nov-2024 06:02:50 JST samir, stack-based @gerbrand @hrefna Yeah, it’s all leaky eventually (Spectre is a great example), but when we’re complaining about magic, we’re almost never complaining about `malloc` lying to us about available memory, are we?
-
Embed this notice
samir, stack-based (samir@mastodon.functional.computer)'s status on Saturday, 30-Nov-2024 06:02:52 JST samir, stack-based @hrefna Oh, I love this observation.
I’ve been very guilty of protesting against “magic” in the past. On reflection, I think what I’m wary of is leaky abstractions. I want to be able to reason about my code/software, and I’m fine with magic as long as it doesn’t interfere with the reasoning.
So thank you for making me dig into this.
-
Embed this notice
Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 30-Nov-2024 06:07:08 JST Hrefna (DHC) You also don't have to scratch very hard in compiler optimizations either before you start running into it causing actual real problems or unpredictable behavior in production code.
Not even in a JIT either. In a standard AOT compiler.
That's without getting into Tomasulo's algorithm or how modern branch predictors work.
-
Embed this notice
dontony (dontony@hachyderm.io)'s status on Saturday, 30-Nov-2024 09:53:57 JST dontony @hrefna i like my footguns to stare at me in the face, not be an abstract concept that is nondeterministic
-
Embed this notice
Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 30-Nov-2024 09:55:24 JST Hrefna (DHC) @dontony Cool, enjoy programming on paper with pi calculus.
-
Embed this notice
Structuralist (structuralist@mastodon.social)'s status on Saturday, 30-Nov-2024 14:53:16 JST Structuralist It is all a rube Goldberg device.
-
Embed this notice
Hrefna (DHC) (hrefna@hachyderm.io)'s status on Saturday, 30-Nov-2024 14:53:16 JST Hrefna (DHC) @Structuralist worse, because a good half or more of the complexity is necessary complexity.
Rube Goldberg devices you can simplify and get the same output. The ball can still be moved.
No such luxuries here, where most of these things exist for a reason. This is less Rube Goldberg and more Chesterton's Fence.
-
Embed this notice
Alexandra Magin 🏳️🌈 (recursive@hachyderm.io)'s status on Saturday, 30-Nov-2024 15:15:30 JST Alexandra Magin 🏳️🌈 @hrefna I like all the reasonably durable abstractions we can manage, but with a bias towards ones we can prove some things about
Although on some level things like this I consider a challenge 🙃
Like maybe I should learn all about Infiniband, just because
-
Embed this notice
Larry Cannell (lcannell@hachyderm.io)'s status on Saturday, 30-Nov-2024 23:53:48 JST Larry Cannell @hrefna You may be interested in reading this Turing Award acceptance essay by Ken Thompson, published in the Communications of the ACM in August, 1984:
Reflections on Trusting Trust
https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
-
Embed this notice