Rasmus Lerdorf Created PHP Despite Having No Idea How to Write a Language

Level 1: House with No Blueprint

Imagine you have a friend who decides to build a treehouse even though they don’t really know how to be a carpenter. They start with just one small room so they can hang out. Then more friends say, “Hey, it’d be cool if the treehouse had a second room, or a slide, or maybe a snack bar!” Your friend doesn’t have a plan drawn up; they just keep nailing on new pieces of wood and adding whatever seems needed next. Eventually, this little treehouse turns into a huge, funky house with no blueprint. It’s got doors of different sizes, stairs that zigzag in odd ways, maybe a window that opens into another room instead of outside. Strangest of all, whenever the plumbing starts leaking and water drips everywhere, instead of fixing the pipes properly, your friend just shuts off the water for a while and then turns it back on so it kind of resets. 🩹💧 The house doesn’t collapse – people still live in it and have fun – but it’s far from a normal, orderly house an architect would design. Developers find this funny because PHP is like that house: it started small and unplanned, grew in a wacky way, and now a lot of the internet “lives” in it. The creator of PHP basically said, “Yeah, I just kept adding rooms and didn’t really like doing the whole ‘architect’ thing.” It’s both silly and a bit scary, but hey, the house is still standing – we just have to restart the generator every now and then to keep the lights on!

Level 2: Just Restart Apache

So, why are developers laughing (and groaning) at this collage of quotes? Let’s break it down in simpler terms. The central figure here is Rasmus Lerdorf, the creator of the PHP programming language. PHP is a super popular language that was (and still is) used to build a huge number of websites – think of platforms like WordPress or old-school forums, all part of the classic LAMP stack (which stands for Linux, Apache, MySQL, PHP). Now, what’s shocking is that the guy who made PHP openly says he never really meant to create a proper programming language. He was just solving one problem after another for making web pages dynamic, and PHP sort of evolved on its own. That’s what we mean by “design by accident.” There was no grand plan or architecture blueprint for PHP in the early days; new features got added as needed, without always thinking about long-term consistency.

One of the quotes in the image literally says, “I have absolutely no idea how to write a programming language, I just kept adding the next logical step.” For a junior developer, this sounds crazy – the person behind a major language saying he didn’t know how to make one! But it’s true: PHP started as a set of simple tools to help Rasmus track visits to his personal webpage (its name originally stood for “Personal Home Page Tools”). It wasn’t like Java or C++ that had design committees and formal specs. It was more like a hobby project that kept growing. This ad-hoc growth (meaning, made up as he went along) is funny in hindsight because PHP ended up running a huge portion of the web. Imagine a toy project becoming the foundation for big enterprise websites – with all its little quirks included. That’s why developers joke about PHP’s LanguageQuirks and LegacyCode. A lot of those quirks (like inconsistent function names or weird behaviors) can be traced back to the fact it was never cleaned up from its early “just make it work” days.

Now, another key part of the meme: Rasmus’s attitude towards programming and code quality. He says things like “I’m not a real programmer” and “I throw together things until it works then I move on.” This is pretty much the definition of writing quick-and-dirty code. For example, instead of carefully organizing code into classes or modules (like you’re taught in school), one might just write everything in one big file and keep appending features to it. It’s fast initially, but over time you get a tangled mess – what we call spaghetti code (because it’s all tangled up like a bowl of spaghetti). Many junior devs actually start this way – just write code until it works. The problem comes when you or someone else has to fix or update that code later; without structure, it’s really hard to understand. PHP’s creator basically admitted that PHP as a language was built with this “just get it working” mentality. That set the tone for a lot of early PHP projects: quick results, but often messy under the hood. Senior devs find this both funny and painful because many of them spent countless hours untangling such messes in older PHP applications.

Let’s talk about the “restart Apache every 10 requests” quote, since we titled this level “Just Restart Apache.” Apache is the web server that, in a LAMP setup, runs the PHP code. Memory leaks were a common problem in early PHP (and C programs in general). A memory leak means the program keeps allocating memory (like RAM) for tasks but doesn’t release it back to the system when it’s done. Over time, a leaky program will gobble up more and more memory, eventually slowing down or crashing. The proper solution is to find where the leak happens in code and fix it (so the memory is freed). But that can be tricky and time-consuming. Rasmus’s tongue-in-cheek solution was, instead of fixing the leak, to just periodically restart the whole web server process (Apache) so that all the memory gets freed at once. When he says “every 10 requests,” he’s implying not literally every 10, but frequently – before the leak builds up too much. It’s like if you have a sink that’s leaking water onto the floor, and rather than repairing the pipe, you just mop the floor every hour so it never floods. It works, but it’s not elegant. This quote became infamous because it captures the very pragmatic (some would say crude) style of problem-solving that was common in the PHP world: “If it’s broken in a small way, just reset things and carry on.” For a junior dev, the lesson here is: quick fixes might solve immediate issues, but they create TechnicalDebt. Technical debt is when you solve a problem cheaply now (like rebooting a server) knowing that later on someone will have to pay the price (like figuring out a real fix, possibly under more pressure). It’s a trade-off that teams make often, but if you never go back to fix it properly, you end up with a very fragile system.

There’s also mention of things like “protected properties” and “abstract methods” in one quote, with Rasmus saying “I don’t care about this crap at all.” These terms are from Object-Oriented Programming (OOP) – which is a way to design code using classes, objects, and careful access controls (like protected means “only accessible within the class or its subclasses”). In the mid-2000s, PHP started supporting more OOP features (PHP 5 introduced things like private/protected properties, abstract classes, etc.). By that time, Java and C++ had long had these features and many developers wanted PHP to have them for writing large applications in a cleaner way. Rasmus’s quote shows he personally wasn’t very interested in these theoretical or structured programming concepts. He added them mainly because the community and “computer science folks” expected them, not because he loved them. To a junior dev: this is basically a founder saying “We added fancy tools because people asked, but I think just getting stuff done is more important than those fancy tools.” It sets a cultural tone. If the creator isn’t enthusiastic about best practices, many users of the language might also cut corners. It’s ironic and a bit funny that a widely-used language had a creator who publicly said “I don’t understand why people actually like programming.” Imagine hearing the inventor of a sport say they don’t even like playing it – you’d chuckle and also wonder how that sport ended up popular. Similarly, these quotes make us chuckle and think, “Maybe that’s why PHP can be such a weird beast sometimes.”

Let’s not miss the PHP function naming oddities hinted by the meme. PHP has hundreds of built-in functions, but they’re notorious for inconsistent naming conventions. Some use underscores (e.g., htmlspecialchars, which does have an underscore actually as htmlspecialchars doesn’t, but mysqli_connect does... we see inconsistency even in examples), some use camelCase, some have abbreviations, and the order of parameters can be inconsistent (for instance, strpos(haystack, needle) vs in_array(needle, haystack) – the order flips!). This inconsistency is a classic symptom of a language that grew without strict oversight – different contributors added functions at different times, each with their own naming style. If you’ve just started coding, imagine if half of your library functions were namedLikeThis and the other half like_this, with no reason – you’d be confused. That confusion is exactly what many developers felt learning PHP’s standard library. It’s another form of TechnicalDebt (but at the language level): it makes the DeveloperExperience (DX) a bit harder because you must memorize a lot of exceptions. It’s humorous in our context because we see Rasmus basically implying, “Yeah, I just threw things in there, consistency wasn’t a priority.” When he says “this crap” in a quote, he’s dismissing formalities and niceties that many other language designers obsess over.

Finally, what about the meme’s visual style? All those quotes scattered around in a messy collage – that actually symbolizes the chaotic way PHP evolved. The meme creator is making a visual joke: PHP’s design was all over the place, and so is this image. There’s Rasmus’s smiling face in the middle (like the proud dad of a very unruly child) labeled “Breaking the Web” (a play on the phrase “Breaking the Internet”, implying PHP kinda broke or bent the web’s rules). Around him, the quotes are almost shouting from every direction, just like PHP’s various odd behaviors pop up and surprise you when you least expect it. If you’re a newbie who’s tried PHP, you might not have hit these weird cases yet – but ask any experienced PHP dev and they’ll have war stories. This meme is basically saying: “Look, even the creator knows PHP is a wild ride. Here are his own words about it!” It’s funny to developers because it’s like an inside joke: we all know PHP can be a mess at times, and here we get confirmation straight from the source, delivered with a heavy dose of sarcasm.

So in summary, at this level: the meme highlights how PHP was created in a very improvised way, which led to lots of quirks and technical debt in real-world PHP projects. It’s humorous because it’s true – those of us who’ve dealt with legacy PHP can relate to every quote. For a junior developer, the takeaway is: even hugely successful technologies can have very humble, messy beginnings. It also shows the contrast between quick-and-dirty coding versus organized, planned software design. When you do the former, you might solve the immediate problem (and maybe even create something popular, like PHP), but the trade-off is that future developers might curse your name when they trip over the rough edges you left behind. In PHP’s case, Rasmus himself is playfully admitting to all those rough edges, and the developer community can’t help but laugh (and maybe groan) along.

Level 3: Ghosts of LAMP Past

This meme hits senior developers right in the nostalgia and the PTSD. It’s a collage of Rasmus Lerdorf quotes – the creator of PHP – that reads like a confession booth for every LegacyCode nightmare we’ve ever debugged in a LAMP stack. The chaotic jumble of text snippets plastered around Rasmus’s Twitter-style profile isn’t just a design choice; it mirrors PHP’s historically ad-hoc evolution. Each quote is a little ghost of TechDebt past, haunting modern web architects who have inherited planetary-scale PHP applications (think WordPress, old Drupal, gigantic in-house CMSes) with all their warts.

Take the quote “I’m not a real programmer. I throw together things until it works then I move on.” Seasoned devs recognize this as the unofficial motto of SpaghettiCode. It’s funny because it’s painfully true: a huge chunk of early 2000s web code was exactly this – thrown together under tight deadlines, with little concern for architecture, and then left to run in production for years. PHP made that approach easy. You could mix HTML and PHP in one file, add a dash of SQL queries inline, sprinkle some business logic wherever – and lo and behold, it works. Until it doesn’t, and someone has to untangle the mess. The founder of PHP basically saying “I code like a hungry college student the night before a project is due” explains so much about why older PHP codebases look the way they do. No unit tests, inconsistent naming, functions that do a bit of everything – that’s the throw-together culture.

Now consider “The real programmers will say ‘Yeah it works but you’re leaking memory everywhere. Perhaps we should fix that.’ I’ll just restart Apache every 10 requests.” This one makes senior engineers laugh and cry at the same time. It’s a prime example of an anti-pattern that every on-call veteran knows: the quick reboot as a substitute for a real fix. It’s practically a meme on its own (“Have you tried turning it off and on again?” 😅). Here we have it straight from PHP’s creator that this was literally his approach to memory leaks in the early days! For those of us who have spent late nights triaging memory bloat in a production server, the idea of scheduling restarts instead of fixing the leak is both horrifying and hilariously relatable. In fairness, this mindset was born in an era when PHP scripts were typically short-lived (one request at a time). But as PHP apps grew into long-running processes (via FastCGI or mod_php workers), that “just reboot it” attitude became technical debt that had to be expunged with proper memory management. Still, any old-school sysadmin will tell you they had cron jobs to restart Apache periodically to keep PHP happy. That quote is basically the sarcastic embodiment of how we dealt with TechnicalDebt back then. It’s funny now, in the “ha-ha WTF” way, because we all know we should do better... yet sometimes, even today, LegacySystems leave us no choice but the reboot hammer.

Another quote in the collage: “Ugly problems often require ugly solutions. Solving an ugly problem in a pure manner is bloody hard.” This is a nod to the pragmatism over purity mantra that permeated PHP’s development (and in truth, much of real-world programming). Senior devs see humor here because it’s basically the justification for every hacky workaround that lives in production code. It’s the kind of thing you say to your team when you implement a gnarly fix and everyone knows it's not clean, but hey, it solved the customer’s issue by Monday. PHP as a language is practically the poster child of this slogan. Need to embed dynamic logic into HTML in 1998? Sure, just start <?php tags wherever you want – it’s not academically pretty, but it works. Password hashing available? Eh, just slap MD5 first, we’ll refine it later. Over time those “ugly solutions” pile up, and maintaining them becomes... you guessed it, “bloody hard.” The quote is funny because it’s true: pure solutions are hard, and PHP often didn’t even try for purity until much later in its life.

The collage also includes lines about not understanding people who like programming, not caring about certain “crap” (like protected properties or abstract methods), and bragging with a grin, “Yes, I am a terrible coder, but I am probably still better than you :)” in classic tongue-in-cheek style. Experienced devs chuckle at these because it’s the quintessence of DeveloperMemes and Sarcasm in our industry. Lerdorf’s disarming honesty is both amusing and a little alarming. We’re essentially seeing the LanguageQuirks of PHP explained by “I did what I had to, blame me.” When he says “I don’t care about this crap at all,” referring to things like formal Object-Oriented patterns or computer science theory, senior devs immediately think of PHP’s hodgepodge feature set: inconsistent function names (strpos vs str_replace vs array_search – why, oh why, no consistent naming convention?), the mix of functional and pseudo-OOP styles, the long deprecation list of weird features (magic quotes, anyone?). That quote is funny because it’s like the language itself shrugging and saying “yeah, I have protected methods now, but I added them just because people wanted – I still don’t really believe in them.” It’s the apathetic parent attitude towards code hygiene: “We have these tools and rules because the CS teacher said so, but I personally think it’s all overrated.” If you’ve ever worked on a team where one brilliant but eccentric engineer writes code that ignores all style guides because “pfft, I know better,” you know the vibe. Here that engineer happened to build a language used by millions. Legacy web architects are haunted by this because they often have to retrofit CodeQuality and structure onto systems built in that Wild West fashion. It’s like trying to impose building codes on a town that sprang up with no planning – so many exceptions and gotchas to handle.

In the world of LegacySystems, PHP is both a hero and a cautionary tale. This meme humorously validates what senior developers long suspected: PHP’s quirks and thorny parts aren’t just random; they stem directly from its creator’s philosophy (or anti-philosophy). It’s both cathartic and comedic to see Rasmus basically roasting his own creation. For a veteran developer, the meme elicits a knowing grin. We’ve been in the trenches: we’ve seen the $legacyApp that requires an ini_set('memory_limit') increase every other month, the 5,000-line single PHP file that “just kinda grew over the years,” or the LAMP server that we band-aid rather than rebuild because no one wants to touch it. These quotes are the haunted whispers behind those experiences – the ghosts of LAMP past. And like any good ghost story, it’s equal parts frightening and fascinating, with a dash of dark humor that only the initiated truly appreciate.

Level 4: Duct Tape Language Design

Under the hood, PHP’s original implementation was as unorthodox as these quotes hint. Rather than a carefully engineered compiler or a formal grammar, PHP grew through ad-hoc tinkering. Rasmus Lerdorf famously said, “I have absolutely no idea how to write a programming language, I just kept adding the next logical step.” This is basically a confession of design-by-accident. In classical language design, you'd define a grammar and write a proper parser to turn code into an Abstract Syntax Tree (AST). Rasmus, by his own admission, “still am really bad at writing parsers,” so early PHP parsing looked more like a bunch of C code duct-taped together than a YACC file. The result? A parser that accepted whatever worked and evolved organically. This often meant the syntax was full of idiosyncrasies – edge cases and surprises that formal language theory tries to avoid.

One absurd example of this DIY compiler approach: “Back when PHP had less than 100 functions and the function hashing mechanism was strlen().” Yes, you read that right – PHP once identified functions by the length of their name. Instead of using a robust hash algorithm to look up function names in a symbol table (as any compiler textbook would recommend), PHP’s early function dispatch was essentially doing hash = strlen(function_name). This is a comically naive hashing strategy; it’s as if you filed books in a library by the number of letters in their title. Collision resolution? Probably a lot of “let’s hope it doesn’t happen”. It might have “worked” when there were only a few dozen functions (and maybe they were all different lengths), but it’s a far cry from a CodeQuality-approved design. As PHP’s user base grew and more functions were added, they obviously had to replace this with a real hashing mechanism. But the mere fact it started that way shows how deep the TechnicalDebt was baked in from day one.

Memory management in early PHP followed the same ugly hack philosophy. A well-designed language runtime either employs garbage collection or careful manual memory management. PHP, however, ran mostly as a process embedded in the Apache web server (as a module in a LAMP stack) for each request. If there were memory leaks (and there were, given C extensions and the “just throw things together” coding style), the pragmatic solution wasn’t to engineer a sophisticated memory allocator or fix every leak — it was to periodically kill the process and start fresh. Rasmus joked, “I'll just restart Apache every 10 requests.” This isn’t normal advice from a compiler author; it’s more like a sysadmin quick-fix for a runaway script. In theoretical terms, he sidestepped the halting problem of a growing memory footprint by brute force: halt the program often! This reflects an underlying principle (or anti-principle) in PHP’s creation: solving an ugly problem with an ugly solution. Rather than ensuring proper cleanup of memory (a complex task that requires careful design), PHP’s early environment treated each web request as disposable. TechHistorian note: this approach actually aligns with the CGI model – each request in CGI spawns a new process, naturally cleaning up memory when it exits. PHP took that ethos and ran with it inside Apache: leak a bit of memory each time? No worries, just restart the worker process after X requests. It’s effective in practice and bloody hard to call elegant.

In summary, PHP’s internals in the early days were a patchwork of quick fixes. There was no theoretical LanguageArchitecture guiding it; it was evolution on the fly. If a LegacySystem like PHP were an organism, biologists would call it a “kludge” – useful mutations piled on without a plan. Every quote in the meme is basically pointing at a fundamental truth: PHP wasn’t designed in the academic sense; it was cobbled together to solve immediate problems, rules and purity be damned. And while that duct-tape engineering made PHP incredibly accessible and successful (anyone could pick it up and get stuff done), it also left a minefield of inconsistent behaviors and quirks that academic computer science would have caught (or outright banned) during design. The DeveloperExperience for those maintaining PHP’s core or building large frameworks on it has always involved tiptoeing around these ghosts of its ad-hoc birth. To this day, under the hood, PHP carries the fingerprints of a self-described “terrible coder” who solved problems pragmatically. That is both its charm and its curse – a Language that won the web by breaking the rules of language design, and a case study in how TechnicalDebt at the language level can echo for decades.