Should I tell Her

So you spent three weeks learning trigonometry, diving into DDA algorithms, and debugging why your walls look like a Salvador Dalí painting, only to realize John Carmack did this in 1992 on hardware that had less computing power than your smart toaster. And he did it while probably eating pizza and writing assembly like it was a casual Tuesday. The "box of triangles" bit hits different when you realize modern game engines abstract all this pain away with their fancy rendering pipelines, but back then? Carmack was literally casting rays and doing trigonometric calculations per pixel to fake 3D in Wolfenstein 3D. No GPU acceleration, no Unity, no "just import Three.js"—just raw math and the will to make demons shootable. Meanwhile, you're here in 2024 with Stack Overflow, ChatGPT, and 64GB of RAM, still struggling to get your raycaster to not crash when you look at a corner. Humbling stuff.

The tech industry's version of "Hard times create strong men, strong men create good times..." but make it about programming languages. Starting with Dennis Ritchie creating C in the golden age of computing, which led to prosperity that somehow birthed Python (because who needs performance when you can write readable code, right?). Python then spawned the AI hype train, which naturally created "vibe coding" – that beautiful era where devs let ChatGPT write their code while they sip oat milk lattes. And vibe coding? Well, that creates developers who can't actually code without an LLM holding their hand, which apparently circles back to creating "strong men" who'll have to rebuild everything from scratch. It's basically roasting the entire trajectory of software engineering from low-level mastery to AI-assisted hand-holding. The cycle suggests we're doomed to repeat this forever – strong engineers build powerful tools, those tools make things too easy, easy times create weak engineers, and weak engineers create such a mess that we need strong engineers again. History doesn't repeat itself, but it sure does rhyme in segfaults.

The fastest character development arc in programming history. Tweeted "I love C++" and 34 minutes later: "I regret this tweet. What in the name of f*ck." That's the standard lifecycle of a C++ project: initial excitement followed by existential dread when you encounter your first undefined behavior or spend 3 hours debugging a memory leak. The honeymoon phase with C++ lasts exactly until you try to use a string.

The programmer dating market has spoken, and it's absolutely savage. Everyone's fighting over that one Rust developer with memory-safe relationships while C++ devs are left wondering if they've been friend-zoned or just garbage collected. Notice how Java gets a question mark – even the dating pool has NullPointerExceptions when it comes to Java devs. Meanwhile, Python coders are getting attention despite spending hours arguing about whitespace, and JavaScript users somehow remain popular despite their toxic relationship with semicolons. The SQL enjoyer is probably great at relationships – they know how to properly JOIN tables at dinner parties. But that Rust developer? Memory safe, thread safe, AND relationship safe. The ultimate triple threat.

The girlfriend is worried about her partner thinking of another woman, but he's actually deep in philosophical programming territory: if text is called a "string" (a sequence of characters), shouldn't a single character be called a "strand"? It's the kind of shower thought that keeps developers up at night. The terminology actually comes from early computing where strings were literally sequences of characters "strung together," but nobody bothered to make the naming convention perfectly consistent with the singular form. Classic programming nomenclature being delightfully arbitrary.

So someone told you stack allocation is faster than heap allocation, and you took that advice a bit too literally. The function allocates a char array on the stack and then returns a pointer to it. Problem? That stack memory gets deallocated the moment the function returns, so you're handing back a pointer to memory that's already been reclaimed. It's like giving someone directions to a house that's been demolished. The comment "delicious segfault awaits" is chef's kiss accurate. Whoever tries to dereference that returned pointer is in for undefined behavior territory—could be garbage data, could be a crash, could be nothing at all until production when it spectacularly explodes. Stack allocation is faster, but returning stack-allocated memory is basically writing a check your program can't cash. Classic case of knowing just enough to be dangerous. Should've used malloc or just passed a buffer as a parameter. But hey, at least it compiles! (with warnings you definitely ignored)