busybee Code

Lately there’s been a brewing culture war in the software community regarding the usage of LLM-based coding tools (ChatGPT, Claude, Gemini, etc.), and I’m seeing a lot of hardline discourse on both sides, but especially from the anti-AI side of things.

First of all, to be clear, I am not in favor of LLM-based programming. My personal opinion is that LLMs are catastrophic to the environment and to the Internet as a whole (especially due to the added burden of every server being overwhelmed by the relentless AI-focused crawlers), and to the intelligence of the humans who wield them.

However, in the current landscape, I have also found myself (begrudgingly) using them on occasion to a limited degree, and in the mind of some folks, this probably irrevocably taints my code. So I’d like to at least discuss my perspective on them.

After figuring out a basic anti-bot measure for Publ, I decided to try building a simple experiment for Flask in general.

Here is an extremely simple implementation that has worked amazingly well, having implemented it on The Flickr Random Image Generatr.

This morning I was once again thinking about how to put some proper antibot behavior onto my websites, without relying on Cloudflare. There are plenty of fronting proxies like Anubis and Go Away which put a simple proof-of-work task in front of a website. This is pretty effective, but it adds more of an admin tax (and is often quite difficult to configure for servers that host multiple websites, such as mine), and sometimes the false positive rates can have some other bad effects, such as disallowing feed readers and the like.

I started going down the path of how to integrate antibot stuff directly into Flask, using an @app.before_request rule that would do much of the same work as Anubis et al, but really the various bots are very stupid and the reason the challenge even works is because they aren’t running any JavaScript at all. This made me think that a better approach would be to have it just look for a simple signed cookie, and if that cookie isn’t there, insert an interstitial page that sets it via form POST (with a Javascript wrapper to automatically submit the form).

But then I realized, Publ already provides this sort of humanity test: the login page!

On SpinDizzy MUCK there are a bunch of “hug” verbs which are a bit whimsical and a bit nonsensical, and for reasons that are too silly to get into, I have been locked in an eternal battle with Austin in which I am constantly creating more.

A while back I ran into an issue with a few miscellaneous world scripts breaking around me, and it turned out to be that one of the global scripts, for reasons I’m still unclear on, attempts to parse every verb attached to a character object, and for other reasons I am also unclear on, it ends up attempting to push every name for the verb onto the stack.

Tired of dealing with the annoying processes necessary to run an unsigned application on macOS?

Here’s a simple thing to make your life a lot easier: dequarantine.zip

Download this file, open it up, double-click the dequarantine.workflow file, and then install it as a Quick Action. Now if you want to let an unsigned application run, right-click (or ctrl-click) it, select “Quick Actions,” then “dequarantine.” And then, done.

Have fun.

In the spirit of falsehoods programmers believe about names and time, here’s some falsehoods about email which are all too common.

Around a year and a half ago I wrote an article on the perils of relying on big-O notation, and in it I focused on a comparison between comparison-based sorting (via std::sort) and radix sort, based on the common bucketing approach.

Recently I came across a video on radix sort which presents an alternate counting-based implementation at the end, and claims that the tradeoff point between radix and comparison sort comes much sooner. My intuition said that even counting-based radix sort would still be slower than a comparison sort for any meaningful input size, but it’s always good to test one’s intuitions.

So, hey, it turns out I was wrong about something. (But my greater point still stands.)

A common pitfall I see programmers run into is putting way too much stock into Big O notation and using it as a rough analog for overall performance. It’s important to understand what the Big O represents, and what it doesn’t, before deciding to optimize an algorithm based purely on the runtime complexity.

A frequent thing that people want to do in making games or interactive applications is to shuffle a list. One common and intuitive approach that people take is to simply sort the list, but use a random number generator as the comparison operation. (For example, this is what’s recommended in Fuzzball’s MPI documentation, and it is a common answer that comes up on programming forums as well.)

This way is very, very wrong.