Please get it running at least PHP 8.3. Running PHP 5 or 7 on servers available to the public is negligent in 2025.

Ok, i actually cried at this part.

(Actually, the reworked story in free verse style, which is its most popular form)

TFA is cute but it kinda misses the point, because the original Mel didn't write code that was simple or easy to understand. It was simple to him, and arguably there was some elegance to it once you understood it, but unlike the PHP from the updated story, Mel's code was machine code, really hard to understand or modify, and the design was all in his mind.

Mel would also scoff at PHP.

Lots of software projects don't have this luxury, sadly.

c'mon, you're talking about 200 LoC here. anything except BrainFuck would be maintainable at this scale.

have you ever had to fix a non-trivial third party WordPress plugin? the whole API used to be a dumpster fire of global state and magic functions. i dont know what it is now, but 15 years ago it was a total nightmare.

I think of "straight-line code" as a distinct sort of code. It's the sort of code that does a thing, then does the next thing, then does the next thing, and if anything fails it basically just stops and yields some kind of error because there's nothing else to do. Programmers feel like they ought to do something about it, like this is bad, but I think there's actually great value in matching the code to the task. Straight-line code is not necessarily improved by some sort of heavyweight "command" pattern implementation that abstracts it into steps, or bouncing around a dozen functions, or through many objects in some other pattern. There's a time and a place for that too; for instance, if these must be configured that may be superior. But a lot of times, if you have a straight-line task, straight-line code is truly the best solution. You have to make sure it doesn't become hairy, there are some traps, but there's also a lot of traps in a lot of the supposed "fixes", many of them that will actually bite you worse.

For many years now I've been banging on the drum that if you've been living solely in the dynamic scripting language world for over a decade, you might want to look back at static languages to put one in your tool belt. When the dynamic scripting languages first came out, they would routinely be estimated at using 1/10th the lines of static languages, and at the time I would have called that a pretty good estimate. However, since then, the gap has closed. In 1998, replacing a 233-line PHP script with a merely 305-line static-code replacement would have been unthinkable. And that's Go, with all its inline error-handling; an exception-based, modern static language might have been able to effectively match the PHP! Post this in the late 90s and people are going to be telling you how amazing it was the static code didn't take over 2000 lines. This doesn't represent our tools falling behind... this represents a staggering advance! And also the Go code is going to likely be faster. Probably not in a relevant way to this user, but at scale it would be highly relevant.

A final observation is that in the early PHP era, everything worked that way. Everything functioned by being a file that represented a program on the disk corresponding to that specific path. If you want to get fancy you had a path like "/cgi-bin/my.cgi/fake/path/here" and had your "my.cgi" receive the remainder of the path as a parameter, and that was a big deal. It took the web world more-or-less a decade to get over the idea that a URL ought to literally and physically correspond to something on the disk. We didn't get rid of that because we all hate fun and convenience. We got rid of that because it produces a lot of big problems at even a medium scale and it's not a good way to structure things in general. It's not something to mourn for, it's something we've had better ways of doing now for so long that people can forget why they're the better way.

Simple is robust.