The story of Max, a real programmer

> Max didn't need a request router, he just put his PHP file at the right place on the disk.

This also elides a bit of complexity; if I assume I already have the Nginx and gunicorn process then my Python web server isn’t much worse. (Back in the day, LAMP stack used Apache.)

I’ll for sure grant the templating and web serving language features though.

It still runs much of Facebook, I think

I would argue those days are coming back. Thanks to LLMs, I have probably 10x more "utility" scripts/programs than I had 2 years ago. Rather than bang my head against the wall for a couple hours to figure out how to (just barely) do something in Python to scratch an itch, I can get a nice, well documented, reusable and versatile tool in seconds. I'm less inclined than ever to go find some library or product that kinda does what I need it to do, and instead create a simple tool of my own that does exactly what I need it to.

There is still use for small niche programs. I host my own gif repository, a website for collecting vinyls and my own weather dashboard. I don’t expect anyone else to use these sites so they’re tailored to my user experience and it’s great.

It still makes sense to self-host, to have that ownership.

> It’s a fun trip down memory lane, but the real story today, the sadder story, is that there is no longer any use for simple little programs like this that scratch an itch.

> They’ve all been solved 100x over by founders who’ve been funded on this site. It used to make sense to have a directory or cgi-bin of helpful scripts. Now it only makes sense as a bit of nostalgia.

Why does it make more sense to learn the syntax for someone else's helper scripts than to roll my own, if the latter is as easy or easier, and afterwards I know how to solve the problem myself?

"Itch-scratching" programming is all I ever do now, as my career pivoted away from being a full time developer a long time ago.

But they're personal itches, not productizable itches. The joy is still there, though.

This is something that's been on my mind a lot over the past few years. I think things were on that trajectory, but somewhere along the line it got out of wack.

User interfaces became more user-friendly [0], while developer experience - though simpler in many ways - also became more complex, to handle the complex demands of modern software while maintaining a smooth user experience. In isolation both of these things make sense. But taken together, it means that instead of developer and user experience converging into a middle place where tools are a bit easier to learn and interfaces a bit more involved, they've diverged further, to where all the cognitive load is placed on the development side and the user expects an entirely frictionless experience.

Specialization is at the core of our big interconnected society, so it's not a surprising outcome if you look at the past century or two of civilization. But at the same time I think there's something lost when roles become too segregated. In the same way homesteading has its own niche popularity, I believe there's a latent demand for digital homesteading too; we see its fringes in the slow rise of things like Neocities, the indie web, and open source software over the past few years.

Personally I think we just have yet to see the 'killer app' for digital homesteading, some sort of central pillar or set of principles to grow around. The (small) web is the closest we have at the moment, but it carries a lot of technical baggage with it, too much to be able to walk the fine line needed between approachability and flexibility.

Anyway, that's enough rambling for now. I'll save the rest for a blog post.

[0] user-friendly as in being able to use it without learning anything first; not that that's necessarily in the user's best interest

Who said you can't do that now? This article is about apache and php and a single script. You can do that today.

I don't think it's unrelated at all. I saw the same picture and just closed the tab right away. Why should I read this article, the whole thing might be written by an LLM.

Your comment reminds me of people complaining about how using emoji in communications/text has become normalized. Generating images with AI is pretty fun and seems like an appropriate thing to do for a personal blog. As in, this is the exact sort of place where it's most appropriate.

It's not like this person was ever going to pay someone to make a cartoon drawing so nobody lost their livelihood over it. Seems like a harmless visual identifier (that helps you remember if you read the article if you stumble across it again later).

Is it really such a bad thing when people use generative AI for fun or for their hobbies? This isn't the New York Times.

same. Would have prefered a lo-fi stick figure drawn on a napkin. The cartoon Max detracts from the rest of article, which is a good read.

Dislike it or not, its normalised as is everything else that is useful.

Ahh lamp stacks… I remember there was a distro that had everything preconfigured for /var/www/ and hardened but for the life of me I can’t remember its name.

You actually don't need to. Just upload this little php script to a shared host for $1/mo and call it a day.

For years every external pentest of every perimeter of companies with old-school stuff like this has been finding these things and exploiting them and there are usually several webshells and weird stuff already on the server by the time they get to it. Very often the company forgot, or didn't know they had the thing.

The end state of running 15 year old unmaintained PHP is that you accumulate webshells on your server or it gets wiped. Or you just lose it or forget about it, or the server stops running because the same dev practices that got you the PHP means you probably don't bother with things like backups, config management, version control, IaC etc (I don't mean the author, who probably does care about those things, I just mean in general).

If these things are not a big deal (often it is not! and it's fun!) then absolutely go for it. In a non-work context I have no issues.

TBH I'm not 100% sure that either the PHP version _or_ the go versions of that code are free from RCE style problems. I think it depends on server config (modern php defaults are probs fine), binary versions (like an old exiftool would bone you), OS (windows path stuff can be surprising) and internal details about how the commands handle flags and paths. But as you point out, it probably doesn't matter.

Am I just doing the meme? :)

The next version was equally open to the public.

Have you seen Common Lisp’s condition system? It’s a step above exceptions, because one can signal a condition in low-level code, handle it in high-level code and then resume back at the lower level, or anywhere in between which has established a restart.

https://gigamonkeys.com/book/beyond-exception-handling-condi... is a nice introduction; https://news.ycombinator.com/item?id=24867548 points to a great book about it. I believe that Smalltalk ended up using a similar system, too.

> It would need to be the case that code that doesn’t want to handle errors (like Max’s simple website) doesn’t have any error handling code, but it’s easy to add, and common patterns (e.g. “retry this inner operation N times, maybe with back off and jitter, and then fail this outer operation, either exiting the program or leaving unaffected parts running”) are easy to express

Lisp’s condition system can handle that! Here’s a dumb function which signals a continuable error when i ≤ 3:

    (defun foo ()
      (loop for i from 0
            do (if (> i 3)
                   (return (format nil "good i: ~d" i))
                   (cerror "Keep going." "~d is too low" i))))

If one wishes to retry up to six times, one can bind a handler which invokes the CONTINUE restart:

    (let ((j 0))
      (handler-bind ((error #'(lambda (c)
           (declare (ignore c))
           ;; only retry six times
           (unless (> (incf j) 6)
             (invoke-restart 'continue)))))
        (foo)))

In terms of developer ergonomics, try/catch seems among the best we've come up with so far. We want to focus on the success case and leave the error case as a footnote.

That's the simplicity argument here too: sometimes we only want to write the success case, and are happy with platform defaults for error reporting. (Another thing that PHP handled out-of-the-box because its domain was so constrained; it had started with strong default HTML output for error conditions that's fairly readable and useful for debugging. It's also useful for disclosure leaks which is why the defaults and security best practices have shifted so much from the early days of PHP when even php_info() was by default turned on and easy to run to debug some random cgi-bin server you were assigned by the hosting company that week.)

Most of the problems with try/catch aren't even really problems with that form of error handling, but with the types of the errors themselves. In C++/Java/C#/others, when an error happens we want stack traces for debugging and stack walks are expensive and may require pulling symbols data from somewhere else and that can be expensive. But that's not actually inherent to the try/catch pattern. You can throw cheaper error types. (JS you don't have to throw the nice Error family that does stack traces, you could throw a cheap string, for instance. Python has some stack walking tricks that keep its Exceptions somewhat cheaper and a lot lazier, because Python expects try/except to be a common flow control idiom.)

We also know from Haskell do-notation and now async/await in so many languages (and some of Rust's syntax sugar, etc) that you can have the try/catch syntax sugar but still power it with Result/Either monads. You can have that cake and eat it, too. In JS, a Promise is a future Either<ResolvedType, RejectedType> but in an async/await function you are writing your interactions with it as "normal JS" try/catch. Both can and do coexist in the same language together, it's not really a "battle" between the two styles, the simple conceptual model of try/catch "footnotes" and the robust type system affordances of a Result/Either monad type.

(If there is a war, it's with Go doing a worst of both worlds and not using a true flat-mappable Monad for its return type. But then that would make try/catch easy syntax sugar to build on top of it, and that seems to be the big thing they don't want, for reasons that seem as much obstinance as anything to me.)

Abstracting error checking pays huge dividends, then. In PHP, if something crashes, it continues running and outputs nonsense (probably alright for the simplest of sites but you should turn this off if your thing has any kind of authentication) or it stops processing the page. PHP implicitly runs one process per request (not necessarily an OS process); everything is scoped to the request, and if the request fails it can just release every resource scoped to the request, and continue on. You could do the same in a CGI script by calling exit or abort. With any platform that handles all concurrent requests in a single process, you have to explicitly clean up a bunch of stuff, flush and close the response, and so on.

There's a similar effect in transactional databases - or transactional anything. If you run into any problem, you just abort the transaction and you don't have to care about individual cleanup steps.

1. Define Errors Out of Existence https://wiki.tcl-lang.org/page/Define+Errors+Out+of+Existenc... 2. Treat errors not as something going wrong but as incomplete actions leading to alternate valid code paths.

On the second point, make errors part of the domain, and treat them as a kind of result outside the scope of the expected. Be like jazz musician Miles Davis and instead of covering up mistakes, make something wrong into something right. https://www.youtube.com/watch?v=FL4LxrN-iyw&t=183

Speak for yourself! Some of us don't think about the problem at all, write the code, then don't think about it afterwards either!

This is how "features" get added to most Microsoft products these days :thumbsup: