When “strongly typed” literally requires a hardware budget line item
Description
Cartoon-style panel viewed from above: four open laptops and one detached keyboard sit on a tan desktop. Every single keyboard is destroyed - keycaps are scattered like shrapnel, leaving empty switch wells and plastic debris across the machines. A small signature in the lower left reads "THEJENKINSCOMIC." Beneath the image, a caption says: "Don't get me wrong - I love strongly typed languages, but it is annoying having to get a new keyboard every few days." The gag plays on the double meaning of "strongly typed": instead of static type systems, the developer is apparently typing with literal force, annihilating keyboards at a pace that would alarm any procurement team. The scene pokes fun at veteran debates about type safety, static analysis, and the sometimes-overzealous evangelism that accompanies language choice
Comments
24Comment deleted
I love compile-time guarantees, but at this point my keyboard OPEX rivals my cloud spend - turns out type safety isn’t the only thing that’s static and brittle
After 20 years of explaining to stakeholders that 'strongly typed' doesn't mean aggressive keyboard usage, I've finally given up and just expense my Cherry MX switches as 'type system enforcement hardware' - the CFO thinks it's a security feature
The real cost of type safety isn't the learning curve or verbose syntax - it's the hardware budget. When your compiler insists that `Option<Result<T, E>>` needs explicit handling for the 47th time today, and you're three layers deep in generic trait bounds just to add two numbers, suddenly that mechanical keyboard investment becomes a recurring operational expense. At least with dynamically typed languages, your keyboard survives long enough to experience the runtime errors in production
Strongly typed languages: Enforcing type Consistency at the expense of Keyboard Availability - CAP theorem hits the hardware
Static typing eliminated our runtime crashes; procurement calls it shifting failure left - onto the keyboard
Type safety cured our runtime crashes; the keyboard budget became a P0 - apparently the compiler doesn’t ship with shock absorption
then, vehicles with internal combustion engine need new engines every few days, eh? Comment deleted
Fixed your meme Comment deleted
I feel their problem is that they are using Typescript, which is not a strongly typed language they think it is Comment deleted
Use vanilla JS, take responsibility! Comment deleted
yeah that's what i did for 10 years Comment deleted
That's boring, yes. You have to mix DB, backend and frontend to keep the fun going Comment deleted
yeah that's what i did for the past 5 years Comment deleted
Have you written a bootable MBR already, for fun? Comment deleted
*writes it in JavaScript Comment deleted
Never to late to learn asm Comment deleted
Y'all aren't writing your own uefi firmware? Comment deleted
no but i've committed sins by doing complex library initialization in DllMain Comment deleted
https://www.youtube.com/watch?v=vc6vs-l5dkc Comment deleted
That said, judging by the amount of the clown emojis, people completely missed the wordplay lmao Comment deleted
Those are from people who've overcomed the issue by using boards with industrial-grade keys. Comment deleted
At first, I thought that the broken keebs are due to them being angry with the type checker (I definitely wanted to smash my keyboard mulptiple times fighting against Rust's borrow checker, so I assumed that maybe some people feel as strongly about type cheks). Only later did I realise the word play. Comment deleted
This meme landed right in the middle of me trying to make typescript realize what my code is doing, so that's definitely where my mind went first Comment deleted
Says the gamer (not offensive) Comment deleted