As of today, I’ve been writing this blog for twelve years. Much has changed in that time. Like everyone in tech and tech-adjacent fields, much of the work I do on a daily basis has been transformed by recent advances in AI; first gradually, then suddenly.

I’ve been a pretty enthusiastic user of generative AI since late 2022, though I had a fair amount of initial skepticism about chatbots.

I’ve personally been much more interested in using Stable Diffusion than I ever was in text generation systems like GPT-3 and AI Dungeon. I’m a far better writer than artist, so the idea of generating text from a prompt is an amusing diversion at best. If I want some text, I’ll just write it myself. Although some artists are already integrating AI into their workflows, others will probably have the same meh reaction to its applications in their field.

Me in August 2022, Stable Diffusion

The earliest versions of ChatGPT did not have any kind of function-calling/tool-use capability, so any content you would get from them was pulled from somewhere in their latent space. Answers they gave were often correct, but had to be carefully verified as they weren’t grounded in anything but the model’s internal mathematics. These days, all major model providers have integrated tool use, allowing the model search the web in real time and provide citations for its claims, so the verification process has been reduced from “get an AI answer and then do all the work to get the same answer without AI” to “check whether the AI’s sources are legit and actually support its claims”.¹

As I’ve previously opined about at length, the grounding provided by tool use is what makes these models useful, whether that’s research grounding through search results or grounding to a digital world through the output of terminal commands. This simple innovation is what makes an LLM-based system more than just a stochastic parrot (so anyone who still insists on citing that paper is a few years behind the curve).

Back when LLM chatbots got started, writing was the only thing they could do, so there was a lot of breathless talk about how they would replace writers. I wrote in 2023 that I did not see that happening, outside of the most boilerplate copy. Three years and many model upgrades later, I still don’t like AI writing – while some of the most annoying tells have been eliminated, I have yet to find a reliable way to generate writing that does not have the AI smell. In most cases, I would advise against publishing any AI writing that hasn’t been edited beyond the point of recognition.

Nevertheless, I find AI writing increasingly useful. The distinction is context. In the context of a chat with a chatbot, the writing is a living thing, highly personalised to my prompt. I can regenerate unsatisfactory responses, ask follow-up questions, or challenge conclusions. And at no point am I ever in any doubt that I’m speaking to an LLM. Contrast that experience with reading an article written by an LLM. You get all of the annoying writing tics without any of the interactivity. This is why I’m skeptical of the value of projects like Grokipedia: if we’re going to have an LLM-powered encyclopedia, it should be closer to The Young Lady’s Illustrated Primer from The Diamond Age than a bot-written Wikipedia. LLM writing is worth infinitely more alive than dead.

Considered from this angle, LLMs have replaced a lot of human writing that was previously common online. I can’t remember the last time I looked at StackOverflow. And it’s been a long time since I’ve felt compelled to write a tutorial for this blog, even though those have been some of my best performing posts. Whenever I encounter a technical issue these days, I get Claude Code or Google’s AI search to generate me a custom tutorial; whenever I want to implement some technical thing, I brainstorm a bit with Claude and then get it to write the code. So I think LLMs largely have replaced the technical tutorial. That’s one kind of post I probably won’t write again.²

I do not mourn the loss, because I’m having too much fun programming with AI. The orange website has latterly been chock full of mournful dirges lamenting the death of the old order, of the thing that programming was before 24 November 2025. I’ve come to appreciate that I did not value the act of writing code by hand – certainly not to the extent that many others did. As generative AI improves, it shows us what we really care about – at least one of the blog posts I read lamenting the retreat of hand-authored code was very clearly AI-written, with an obviously AI-generated header image. And there are probably visual artists out there somewhere using LLMs to generate writing and code while hand-making images.

I get it, and I’m glad that this tech allows us to focus on what we care about and are good at. But AI should help us produce better output. The thesis of my universal translator post was that we should view these things as tools that allow us to control and shape outputs, rather than as entities to delegate everything to – and that you should take responsibility for what you use AI to produce. I firmly believe that agentic engineering and synthography are emerging fields with their own set of skills to learn, and I plan to write a lot more about both in the coming year(s).

So here’s to the next twelve years of handwritten thoughts about technological change.

Reply via email

A few months ago, I wrote about the deep weirdness of LLM technology, and how we’re all still learning how to approach its outputs. The marketing and popular perception of these models is that of a helpful robot assistant, and leaning into that characterisation is also a core part of what makes the technology useful in ways that straightforward text completion models weren’t. By pretending to be a robot assistant, modern instruct models/chatbots are able to perform many digital tasks one might want a (digital) robot assistant to perform.

At the same time, thinking of LLMs as science-fictional robot assistants can lead us astray when using them, or even when discussing them. In my last post, I used the example of someone on LinkedIn who got mad about ChatGPT “ignoring his instructions” regarding which files it was and was not permitted to access on his Google Drive. Another illustrative example is the case of a GitHub user who submitted a large, AI-authored pull request to an open-source repository. When asked why the new code files included comments attributing authorship to a real person, the pull requester cheerfully replied that it was something the AI decided to do, and he didn’t question it – he deferred to the superior intellect of the logical robot from Star Trek that now lives in his computer.

Not wanting to take responsibility for things is a very human impulse, and one we’ve been using computers for ever since they were invented. But “the computer said it, so it must be true” is a very different statement before and after the widespread adoption of LLMs. The general notion of what computers do and how they work – logic, precision, determinism – just does not apply to these strange new word calculators that rotate the shapes of language heedless of what that language may signify.

Of course, that’s precisely what makes them so powerful and useful for radically different tasks than we used deterministic computer code for. The lack of determinism and somewhat unpredictable nature of the outputs means we can use LLMs to perform an enormous variety of messy tasks that were previously very difficult to automate. One good example is web scraping: to extract specific information from a website, you previously needed a large amount of highly specific and brittle parsing code for the exact page you wanted to scrape, which you had to manually update if the page changed its layout. Now you can just tell an LLM to get X info from Y page, and it’ll figure out the finicky details. And you can ask it again in a year’s time, after the subject website has been completely redesigned, and it’ll figure out the new finicky details.

In my day job, I often used to say that the main value of penetration testing over automated scans was that only humans could find business logic flaws, because automated tools don’t understand context. A static analyser can tell you to replace your SQL statement string interpolation with parameterised queries, and HTML encode untrusted content included in pages, but it can’t figure out that users shouldn’t be able to change each other’s profiles, or transfer money out of each other’s bank accounts – at least not without a bunch of very specific setup. LLMs, on the other hand, can do these things, for the same reason they can analyse data and do basic literary analysis: we have managed to create intelligence (or something like it) through very high-level pattern matching.

But creating intelligence does not mean that we’ve created conscious beings, or even that we’ve made robots capable of replacing humans in every job. It just means that we have new tools – very powerful ones with previously unimagined capabilities, but tools nonetheless. And that’s how I want to think of them. I have a tool called ls that lets me list directories, and I have a tool called claude that lets me translate English descriptions into computer code.

Anyone with even a passing familiarity with how LLMs work will know that their basic functionality is predicting how to continue a piece of text they’re given. Plenty of comparisons have been made to IntelliSense in programming IDEs, Markov chains, and your phone’s autocomplete, and they’re not wrong. The chat interface that remains the primary means of interacting with these models is a clever trick: every time you send a new reply, the entire chat transcript is fed back into the model, including the initial system prompt, the output of previous tool calls, and “memories”.¹ The “reply” is then produced by continuing the transcript.

But I’ve lately been thinking of the LLM not as autocomplete, but as a translator. The most obvious application of this happens when you ask a model to translate some text into another language,² but it also happens when you ask the model to write you a script – it’s translating your natural language specification into computer code. We can apply this analogy to just about any input and output of an LLM, and it really clicks into place when you think about how the model takes your input and does intense mathematical operations on it to extract a suitable response from its latent space.

Another thing I like about the translator framing is that it emphasises the importance of the user input. As with everything else in computers, when you put garbage in, you get garbage out. Hence slop. The vast majority of visibly AI-created content is rightfully called slop, but it’s always been my contention that this is the fault of the users, not the AI. A computer can never be held accountable.

Publishers of slop are often pilloried with phrases like “you didn’t make that, the computer did.” While intending to disparage the slop purveyor, it also removes their accountability. As soon as we start saying that the computer made something, we start to excuse its obvious flaws and blame them on something that cannot take responsibility. While these tools do have limitations, most of the common flaws in anything made with AI can be fixed through more thoughtful and skilled usage of the AI tools. But if you want to improve your output, start by taking responsibility for it.

All that said, I don’t want to place all the blame on users – some of it rests on the shoulders of OpenAI and its competitors. ChatGPT was built from the start as a mass-market consumer product. OpenAI’s roots are in the Y Combinator B2C world of customer growth, and that means simple interfaces. ChatGPT is synonymous with AI in the public mind, and most other AI companies have copied its basic interface. The thrust of most marketing copy also plays up the helpful sci-fi robot angle.

This goal of user-friendliness, however, has meant that the majority of people’s experience of LLMs and related generative AI tools is mediated through a platform that does not showcase the full potential of the technology. It doesn’t help that most AI integrations in other applications are hastily slapped-on chatbots that end up just being worse versions of ChatGPT.

Nowhere is this truer than in image creation.

# Image creation

This Forbes article from October 2025 describes the author’s frustration with using ChatGPT, Gemini, and Grok to make images. An illustrative quote:

Useful? Not really. Fun, maybe. But not useful yet. When you read the above, and follow all the PR hype, the typical business user thinks: Wow! I can fire my marketing people and instantly create “high quality” and “useful and beautiful” images. Except for one thing: you can’t. These things just don’t work very well.

OpenAI, Google, and xAI have all come out with newer models since this article was written, but they’ve all been incremental improvements rather than step changes. Google’s Nano Banana Pro and OpenAI’s GPT Image 1.5 are generally considered the most powerful and capable image generation models, with far better prompt understanding than even top open models like FLUX.2 and Z Image. But they also lack the flexibility and configurability that would allow them to be fully integrated into the powerful tooling that’s available for open models.

I think this is because of two things: (1) image (and video) generation is fundamentally not a priority for top AI companies, and (2) top AI companies want to keep their user interfaces simple for the consumer market. As a result, the best models are trapped in the worst interfaces, so most people are unaware of the kinds of things you can actually do with AI image generation beyond prompting.

Back when Stable Diffusion first came out, I wrote about specific uses for setting specific seed and CFG values and using different samplers, things that still have no equivalent in the interfaces we get for SOTA closed models. Local image generation also allows you to specify the exact dimensions of the image output, rather than having to hope that ChatGPT/Gemini will heed the request for landscape/portrait in your chat.³

But the local-exclusive feature with the most potential in those early days was image-to-image generation (often styled as img2img). This means providing an input image for your generation, along with all the other things like prompt, seed, and CFG. Along with the input image, you must supply a denoise percentage, which tells the diffusion model how much to change it.⁴ Some examples:

The key takeaway here is that, starting with an input image and a prompt, we can generate different output images that exist on a sliding scale between the input image and the model’s interpretation of the prompt. This is a straightforward example in which the prompt and the input image are aligned, but we could also make the prompt something totally different, and slowly transform the cat drawing into another thing entirely.

The first examples of this showed people doing this with simple drawings like this, but of course you can do it with any image – including AI images. And you don’t have to do it with the whole image at once – you can target just one section of an image. This is called inpainting.

The most naive approach to inpainting is just to select part of the image and change the prompt, but it tends to work a bit better if you give the denoiser some visual guidance. Below, I’ve taken the 75% denoise image above, drawn a line to show where the cat’s foreleg should go, and inpainted the relevant section of the image.

These techniques open up a whole world of human-guided, AI-assisted image creation possibilities, which expanded even further with the later introduction of ControlNet. You could alter the style of whole images; transfer poses between characters; add, remove and refine details; and even blend a crude collage into a cohesive whole. The public only really started getting a taste of this when ChatGPT’s multimodal image generation debuted in March 2025.

But in the early days following Stable Diffusion’s public release, actually realizing these possibilities was quite a tedious process even for enthusiasts. Much time had to be spent moving between image editors and command-line scripts, and later on between image editors and Gradio web interfaces. The graph-based web interface ComfyUI eventually became the de facto standard for image (and later video) generation power users, with an enormous and ever-growing base of support for different models and the tooling around them (which I covered in some detail in this post from late 2023).

ComfyUI is a very powerful tool – not just for image generation, but for video and audio as well – but the graph programming interface fundamentally lends itself more to workflow automation than creative iteration. Nevertheless, it’s a lot more capable than the chat-based image creation and editing OpenAI and Google have given us. Late last year, Figma acquired Weavy, a cloud-based, more user-friendly version of ComfyUI, for $200 million.

But the tool that I believe truly showcases the creative potential of diffusion-based image generation is Krita AI Diffusion, a plugin for the open-source painting program Krita. Leveraging ComfyUI as a backend server, it gives Krita a suite of very well-thought-out and ergonomic tools that go far beyond Photoshop’s Generative Fill.

With Krita AI Diffusion, you can use a variety of generation models to create and refine the same image as much as you like, in as much detail as you want. You can start with either a generation or your own drawing or photo, draw lines to guide successive img2img and inpainting steps (all of which can be placed on their own layers), and you have all of the standard editing tools Krita provides: selections, different brushes, smart patch, filters and colour adjustment, etcetera. And it gets even better when you combine it with the plugin author’s other plugin, Krita Vision Tools, which allows you to select by object for more precise inpainting.

The recent proliferation of Edit Models also means that you can apply changes to images (and parts of images) through prompts, just as you would with Nano Banana or ChatGPT – this replaces some of the tasks that previously would have required extensively guided inpainting and ControlNet models, but you can still fall back to those options if the Edit model doesn’t work or you want more precise control than it allows.

The earliest attempts at integrating local image diffusion models into paint programs were plugins that just replicated the existing Gradio interfaces in a panel on the side, much like how many programs that tout AI integration even today just have a chatbot interface in the sidebar. Krita AI Diffusion goes beyond that to make the AI assistance a truly integrated part of the program, allowing the user to decide exactly what they want to do manually and what they want the AI to fill in. It gives me hope for the future of AI interfaces, once we get past the idea of just shoving a chatbot in the corner. But I think most of these kinds of specialised interfaces will be aimed at power users, so they may not ultimately help the Forbes-reading businessman rise to the aspirations OpenAI’s marketing department has for him.

# Programming

Unlike image generation, programming is a focus of top AI companies, and we’ve seen specialised power-user interfaces for AI-assisted programming with top-of-the-line closed models from the start. LLMs have been useful as programming assistants in some capacity since the release of GitHub Copilot in mid 2022 – predating ChatGPT by several months.

In the beginning, LLMs were integrated into programming IDEs to provide a slightly magical, slightly annoying, and totally non-deterministic combination of IntelliSense and snippets – GitHub Copilot was the first. Glimpses of the future could be seen in how it allowed users to type up a docstring from which it would autocomplete the described function.

When ChatGPT came out in November 2022, a different approach to writing code became popular. It looked like this:

1. Ask ChatGPT to write some code.
2. Copy-paste the output from the Markdown code block into a local file.
3. Run the local file.
4. If it produces an error, paste the error into the chat. If it doesn’t do quite what we wanted, request a change.
5. ChatGPT rewrites the code, and we return to step 2, repeating until satisfied.

In time, GitHub Copilot added a chat sidebar to VS Code, and ChatGPT gained the ability to run the code it wrote for users in a container. This latter capability was enabled by tool use/function-calling. As I keep repeating, the chatbot interface is a trick – each response from a model requires the entire transcript to be fed back in. But that’s not all we can do with the transcript – we can also train the model to output specially formatted commands asking to run tools, and then parse those commands into command-line commands, or API calls, or whatever else we want, and run them. We can then append the responses of those tool calls back onto the chat transcript, just like we do with user responses. This allows the models to take actions and receive feedback from those actions. This is where we move from chatbots to agents.

A simple AI agent is merely a way to automate the five-step process above: write code, run code, see errors, fix errors, run code, repeat until no more errors. Every programmer is intimately familiar with this loop. But if a model can use tools to write code and run it, it can also use tools to do other things: read files, run linters, install packages, fetch webpages, and so on. The coding agent started out as just a way of automating a multi-loop debugging process, but with smart enough models and big enough context windows, it eventually became capable of translating a natural-language feature specification into a functioning code addition to an existing project, or a whole new project – and then committing the changes to source control and deploying them to a remote server. And that’s how we advanced from autocompleting functions to autocompleting significant chunks of a software engineer’s job.

But someone still has to write the specification. A human being still has to know what they want to build, and unless it’s something incredibly generic, they have to go into detail about it.

One of the benchmarks I like to use for different coding models and agent harnesses is “write a Tetris clone in X language/framework”. This is a project that novice programmers have been doing for decades, so it should be well represented in the training data. When given this prompt (with X = Love2D) in plan mode, Claude Opus 4.6 asks me if I want a classic version of the game or a more modern implementation with things like next piece preview, piece hold, and ghost pieces. I asked for the more modern version, and it spat out a fully functional, pleasant-looking Tetris clone. A second prompt changed one of the controls to something more to my taste, and then I played a few games.

The only bug in this one-shotted Tetris game was that you could keep turning a piece pretty much forever after it landed, provided you were quick enough on the keys. That was easily fixed with an additional prompt.

This is a fairly impressive result in some ways and would have been unthinkable a few years ago. It’s a nice toy demonstration of the model’s capability, but it’s also pretty useless. There are a million other ways to play Tetris – it’s even built into Emacs – and there is nothing interesting or novel about my one-shotted implementation. I have merely translated “A clone of Tetris with the features common to modern versions of the game” into Lua code. But doing so took less than five minutes. And with additional prompts, I can make whatever changes I want.

One of the most common criticisms of LLMs is that, as fancy autocomplete engines trained on a giant corpus of existing text, they cannot create anything new and will trend towards outputting the average of everything they’ve ingested. I tend to agree with this, but I don’t see it as much of an argument against using AI tools. I don’t need Claude, ChatGPT, or Flux to be original; I just need them to do as I ask.

Much criticism of modern AI tools is made with this weird pincer manoeuvre, where the LLM gets called out for being dangerously capable and totally useless at the same time. It’s not capable of reading your mind and doing all your work for you, so that makes it useless. And at the same time, it’s good enough that you can outsource all your thinking to it and let your brain rot, something so tempting that you have to actively resist using anything with the letters “AI” in its name.

The commonality between these criticisms is that they assume that any process involving AI will intrinsically lack any human effort, often because they are thinking of LLMs as embodied robots designed to replace human beings. In other words, they’re falling for the marketing hype.

Create an image or write a program with AI, and they’ll say that you “commissioned the computer to do the work for you.” This analogy holds for one-shotted AI creations like my Tetris game example, or the worst varieties of AI slop images, but such things represent the most basic and boring things you can do with AI tools, the ground floor of this technology’s enormous potential. If I open Blender, place a single monkey head, and call that a scene, it might also be fair to say that Blender has made the scene for me. But I’m interested in doing far more than that.

To make interesting and worthwhile things, you need to put in effort, regardless of the tools you’re using or what their most breathless marketing says. And guess what? That’s entirely possible! You are allowed to send more than one message to the LLM. You are allowed to tweak your script or alter your image, and in many ways, AI makes this much easier to do than it ever has been before.

Continue along this line of argumentation, and someone will eventually say, “Well, if you have to spend hours making whatever it is anyway, why not just do it all yourself?” Perhaps they’ll back that up with an anecdote about a time they tried to get ChatGPT to do something over multiple turns and eventually got frustrated and gave up. Or maybe they’ll cite that study about AI assistance making people feel like they’re more productive while actually being less productive.

There are things that LLMs are good at, and things they’re bad at. There are also learnable skills that make you better at getting desired results out of LLMs – prompt engineering, context engineering, agentic engineering, these are all real emerging domains that consist of more than a few tricks. AI-assisted image creation – the newest form of synthography – is too. AI tools require skill to use well, just like every tool humanity has ever created.

Many of the arguments about AI-assisted programming have the same shape as the tiresome arguments I’ve been reading and occasionally having for decades about whether you can claim to be a real programmer if you don’t manually write everything in machine code.

I’ve written before about learning to program with GameMaker, a game engine originally developed as an educational tool. Even on forums centred around this program and games made with it, you’d have the occasional Real Programmer come in and tell everyone they sucked for not writing all their games in engines they’d custom-built using C++. Engage them on this topic for long enough and they’ll make vague assertions about how limited your creativity becomes in the stultifying straitjacket of a tool that comes with the built-in ability to render and move 2D shapes on the screen. If more people wrote everything from scratch, went the argument, we would see far more originality in games. You can’t make an original game in GameMaker, went the corollary (often explicitly stated) – it will just be the same as everything else made in GameMaker. But in all these discussions, I never saw any actual conjectures or examples of what this vaunted originality might look like.

I’m writing this post using a CMS I’ve been building with Claude Code for the last month or so. The process of building this CMS has involved many hundreds of conversations with Claude. Initially, these concerned the overall architecture of the CMS, and then they got into individual features. By starting with a skeleton and gradually adding features, I’ve been able to create a functional CMS for static Hugo websites that has exactly the architecture and featureset I want. Nothing like this exists elsewhere – otherwise I wouldn’t have had to build it.

But there’s nothing novel about the concept of a CMS. All the individual components are things that already exist, and most of the glue code is similar to other glue code in applications that use some of the same components. The same is true of the majority of software, and the majority of everything else you might want to create.

This is not to denigrate the value of understanding how code and computers work. I would be far less effective at vibe coding without extensive experience of traditional programming and technical work. If you’re interested in doing technical work in a technical field, there is no substitute for deep understanding.

Knowing something about how good software development works helps a lot when guiding an AI coding agent—the tool amplifies your existing knowledge rather than replacing it.

Benj Edwards, 10 things I learned from burning myself out with AI coding agents

I just don’t consider the act of hand-typing code in as low-level a language as possible a sacred act that inherently confers some special status upon the output. I do not subscribe to the labour theory of value.

The 2008 film Flash of Genius dramatises the life of Robert Kearns, the inventor of the intermittent windshield wiper. After patenting this design, he showed it to Ford and proposed they manufacture it. Ford rejected his proposal but later came out with a similar design, prompting a prolonged patent dispute which Kearns eventually won, though he arguably ruined his life in the process.

One particular scene from the film that’s always stuck out in my mind involved a lawyer for Ford arguing that the intermittent windshield wiper cannot be considered a novel invention, as it is merely an arrangement of pre-existing electrical components, just as the lawyer’s grandmother cannot be considered to have invented the cookies she bakes from ingredients and a recipe.

Kearns’s response to this argument is to bring in a copy of A Tale of Two Cities and a dictionary. He then reads out the famous first sentence, stopping after every word to see if it’s in the dictionary, which it is. By the Ford lawyer’s logic, he argues, A Tale of Two Cities is not a novel work as Dickens did not create any new words – he just arranged existing English words in a new order.

So maybe LLMs can’t create anything new. That doesn’t mean humans can’t use them to arrange pre-existing things in new ways – and that’s what most people call creativity, most of the time.

A very careless plagiarist takes someone else’s work and copies it verbatim: “The mitochondria is the powerhouse of the cell”. A more careful plagiarist takes the work and changes a few words around: “The mitochondria is the energy dynamo of the cell”. A plagiarist who is more careful still changes the entire sentence structure: “In cells, mitochondria are the energy dynamos”. The most careful plagiarists change everything except the underlying concept, which they grasp at so deep a level that they can put it in whatever words they want – at which point it is no longer called plagiarism.

Scott Alexander, GPT-2 as [a] Step Toward General Intelligence

# Writing & knowledge work

In the conclusion of my first Stable Diffusion post, I wrote that I was much more interested in image generation than text generation, because I can write my own text. Thus, I was very underwhelmed by the earliest versions of ChatGPT. You could ask the model about all kinds of things and get a confident, comprehensive answer, but because that answer was just pulled from somewhere in the model’s weights, you had a constant fear of hallucination, and you ended up needing to confirm the whole thing with a good old-fashioned web search. Ted Chiang famously called ChatGPT a “blurry JPEG of all the text on the Web”, and when he wrote that in February 2023, he wasn’t wrong.

These days, we have retrieval-augmented generation and agentic tool use. Most modern LLMs are now trained to use their web search tools to answer questions and will provide citation links to discovered sources. This does not mean that hallucinations are a solved problem, but they’re much less frequent and much easier to correct. If you’re not convinced, go to Google AI Studio and try asking it about something niche or very current, first with Grounding with Google Search turned off and then with it turned on. These capabilities are what make LLMs useful for not just programming but also searching the web and performing many other kinds of computer-based tasks.

That said, I’m still not big on using LLMs to write, at least not in any non-disposable capacity. I like programming with LLMs because they handle the boilerplate for me. But if I find myself writing boilerplate I’d prefer to automate, my solution is to stop doing that.

I’ve experimented with AI-generated writing, but mostly to underwhelming results. In my experience, getting LLMs to rewrite prose produces an averaging effect: the LLM strips out spelling mistakes and awkward grammar with just as much enthusiasm as it strips out the things that make good writing distinctive. I’ve tried a few experiments where I’ve generated some text and then edited it into my own voice, but I always end up coming back to those pieces later and picking out awkward LLMisms I missed. So I now keep the LLM output entirely separate from any writing I care about.

I will still use LLMs to get first-pass feedback on a piece of writing and to find typos and so on. It’s a useful editor as long as you know not to take its compliments too much to heart or to treat its every suggestion as essential. A little bit of prompt engineering here goes a long way: while a generic request for feedback will produce a lot of fawning and maybe some minor criticisms, asking the LLM to write potential Hacker News comments for your technical post will usually actually highlight flaws in your argument. You’re roleplaying with an autocomplete here, so you’ve got to give it the right character.

But there are some interesting things happening in the AI writing space. A few weeks ago, I read and quite enjoyed “Ablation”, a short work of science fiction written from the perspective of a large language model, by a large language model (an OpenClaw instance named Shen). It is a coherent piece with a consistent authorial voice that builds and maintains a logical sequence of events over its three thousand-word length. The prose is not entirely free of LLMisms, but as it’s written from the perspective of an LLM, this works in its favour.

The bot’s operator, James Yu, maintains that he did not manually edit it aside from fixing some formatting issues, but also notes that the posted story is (roughly) the fourth draft. Yu has posted other stories by Shen, such as “Do Not Confirm” and most recently “Records Management”. He’s also hinted at having fed many traditional stories to Shen as a tastemaking process. And although he avoids making direct edits, he guides the stories through multiple rounds of feedback – a process not unlike building software with a coding agent.

Maybe this is just a gimmick, or maybe it’s the start of something new and interesting. Writing at one remove – seeing what output you can get out of a carefully crafted process of taste-making and feedback. It’s an interesting idea, but one I’m personally much less interested in than AI programming and image creation. The results I’ve seen from my own attempts to teach AI to write like me have been underwhelming, but I acknowledge that may just be a skill issue.

Adam Singer recommends using AI when you don’t care about the details of something. This is actually a decent heuristic, but I’d add the caveat that “something” can be as big or small as you want. For most of the software I’ve built with AI, I care about individual features and the user experience enough to iterate repeatedly on those things, guiding the AI in the direction I want to go and very occasionally making manual tweaks myself. But I don’t have particularly strong opinions about what the variable names should be, or how many files there should be in the codebase, or even really how individual files should be structured. I’ll let the AI handle those details. Similarly, if I’m making an image with AI, I don’t care about the individual brushstrokes, but I do still care about the image’s overall look and contents.

On the other hand, when I write something, I care very much about the details on a granular, word-by-word level, so AI assistance for the actual meat of the work feels less helpful. If I were a visual artist or a different type of programmer, perhaps I would feel that way about those domains. But I don’t think that has to rule out the value of AI assistance – just like I use it as a first-pass, hands-off editor, you could use generated images as references for hand-created images, or get an LLM to be your code reviewer. The universal translator can, after all, munge just about any kind of input into just about any kind of output.

# One-shotters vs iterators

The process of creating something with AI, – software, writing, graphics, or anything else – can take two broad shapes: you’re either one-shotting or iterating. Which of these processes you take depends on what you’re doing, how you like to work, and the affordances of the interface you’re using. I lean towards iteration for most things, but both processes have their place, and both can be done well or badly.

Returning to image generation, we can say that ComfyUI is an interface designed for one-shotting, whereas Krita is an interface designed for iterating. If I’m making an image with ComfyUI, I’m going to set up a pipeline that starts with a model and a prompt and ends with a finished image. This can get pretty elaborate. For example:

1. Load the model and text encoder
2. Apply the positive and negative prompts – this could involve concatenating different strings of text (e.g. a style prompt, a foreground prompt, a background prompt) and/or using wildcards.
3. Load the initial canvas, either an empty latent or a base image.
4. Apply one or more ControlNets and/or IPAdapters.
5. Diffuse everything together.
6. Upscale the resulting image.
7. Use computer vision to automatically identify faces and hands and inpaint them at a higher resolution (i.e. ADetailer).

I might run this workflow multiple times and tweak individual details, but ultimately I’m aiming to build a reusable workflow that gets me from a given input to a satisfactory output with one click.

Creating an image with Krita looks completely different. I might start by generating a few images from a prompt and picking the one I like best, then img2img-ing it with a different model to change the style, then inpainting specific areas, then outpainting the whole thing, and so on, creating layers as I go. All of these individual steps could also be part of a Comfy workflow, but they’re all very specific to the particular image I’m working on, to the point where a workflow that follows my exact process would be useless with any other output.

We can envision the same dichotomy with a coding agent like Claude Code. The one-shot approach would be to write an extremely detailed specification of the entire program and have Claude build it with as many agents and subagents as needed. If it gets it wrong, adjust the spec and try again. The iterative approach would start the same way, but if something comes out wrong, you use Claude to make changes to the code instead of starting over.

Both of these approaches have failure modes: one-shotting requires you to think of absolutely everything up-front, and do-overs for large projects can be very time consuming. Iterating can lead to your program becoming a mess of conflicting design decisions, half-finished features, and redundant code. I still think that (careful) iteration is the right way to approach most problems, but if you find yourself in a hole, you should stop digging, i.e., start over from a new one-shot.

The most complex form of one-shotting is in experiments like the Claude C compiler, in which you painstakingly design an environment that will steer AI agents towards creating a full project once you spin them up. Comparisons have been made to lights-out manufacturing, and many top Anthropic credit spenders agentic engineering thought-leaders are competing to see how long they can get their agents to spin unsupervised, but I’m sceptical of the value of this approach for anything less well-specified than a C compiler.

AI tools let us decide which details we want to care about and which we don’t. This division of attention is not something new that AI has created – it’s always been fundamental to any kind of creative work. To make anything meaningful, you have to care about the details. Not all the details, but the right details. Used properly, AI tools free you up to focus on those details. But you have to know what they are.

Reply via email

Over a decade ago, I had an Ubuntu install with a broken Unity desktop environment. Rather than fix it, I switched over to a tiling window manager, namely i3. Since then, I’ve used i3 on every new Linux install.

i3 is a window manager for X11, the windowing system used by most *nix systems since the 1980s. A replacement, Wayland, began development in 2008, but is still considered the new kid on the block all these years later. Still, there is a general sense that Wayland is the future, and X11 may eventually stop being actively maintained. Debian, Fedora and Ubuntu have all been defaulting to Wayland for years.

I’ve attempted to switch over to Wayland a couple of times in the past, usually with SwayWM, which advertises itself as a drop-in replacement for i3. My previous experiments with Wayland never offered a compelling reason to stay – my experience would be the same as with X, until something broke or didn’t work as expected. The first time I gave up on Sway and Wayland it was because I couldn’t use my scrollbar to switch between workspaces while hovering my cursor over the workspace buttons on the top bar.¹ Incidentally, the creator of i3 has also tried to move to Wayland several times, most recently in January 2026.

In more recent attempts to give Wayland a shot, I branched out from i3/sway and attempted to try Hyprland. It has noted issues with Nvidia hardware, and I’ve never quite been motivated enough to work out how to get past the blank screen it continues to show me even after following various troubleshooting advice.

But most recently, I’ve been seeing some interesting articles about Niri, a tiling window compositor² with a completely different approach and philosophy to any I’d tried in the past. This was intriguing enough to get me to actually try it, making the leap to Wayland in the process.

# The infinite canvas

As I explained in this post about tiling window managers, the main advantage tiling window managers have over floating window managers is that they arrange your windows for you, making use of all available screen space – snap to side/snap to corner in modern Windows and macOS versions are directly inspired by tiling window managers. Some WMs encourage a more hands-off approach where you define a set of layouts to use automatically, while others require a bit more active management where you have to specify where the next window should appear. Some use the same kinds of workspaces as floating window managers, while others use tag-based workspaces, allowing the same window to appear on multiple workspaces, potentially in different positions.

But what all traditional tiling window managers have in common is the space they make available. A workspace is the size of a single screen, and the windows it contains are tiled on that screen. One window will take up the full screen, two windows will take up half the screen each, and so on. i3 has the concept of tabbed or stacked containers, which get you around space constraints to some extent, but sooner or later you’re going to need to switch to a different workspace.

If you want to be able to switch workspaces using the number row, you’re limited to ten. After that, you have to start cannibalizing other shortcut keys for named workspaces. If I’m doing a lot of different stuff – different browser profiles, different terminals and Electron apps, etc – or just want to leave things open to come back to them later, I’ll very often run out of numbered workspaces, especially since I need one for each screen.³

Niri solves this problem in two ways. First, rather than reorganizing the whole screen to squeeze every new window into increasingly limited space, it will always open a new window to the right and scroll to it, pushing the leftmost window(s) off-screen if it has to. The user can navigate back to those left windows using the same controls used to move between visible windows horizontally. This can seem a little strange at first, but is really quite a natural extension of tiling window manager ergonomics. The official demo video shows what this looks like in practice.

To complement the infinite horizontal scroll within a single workspace, Niri conceptualises multiple workspaces as being vertically stacked. As soon as you place a single window in your current workspace, an empty workspace is created below it. Each output has an independent set of numbered workspaces, starting at 1 and continuing as far as you want. As with i3, you’ll run out of quick jump shortcut keys in the number row after workspace 10, but this doesn’t stop you from creating and using workspace 11, 12, and so on.

While i3 makes you share your numbered workspaces between displays, Niri gives each display its own set of numbered workspaces. So even if you never go past workspace 10, just having two monitors gives you double the workspaces.

These affordances combine to create a sense of abundance, which is exactly what I should feel running browsers and terminal windows on a modern computer. There is a slight hazard of getting lost, which Niri works to allay through its overview mode, which shows a zoomed out view of your workspaces, and the recently implemented Alt+Tab window switcher, which works exactly how you would expect it to.

As Niri is a scrollable tiling window manager, it still has all the features you’d expect from a tiling window manager – windows can be stacked vertically or put in tab containers just like in i3.

# Don’t go with the reflow

The other key way that Niri differs from traditional tiling window managers is its commitment to preserving the size of existing windows – this is Niri’s foremost design principle. Other tiling window managers will resize whatever they need to in order to fit in a new window, but with Niri you can just open it to the side. This works really well for temporary windows – if I have a fullscreen browser window open, I can open a half-width terminal, have the screen scroll to that, do what I need to do, and then close it again and fall back to my browser.

Niri is also happy to have a single window open that doesn’t take up the full screen, so you can remember what your desktop wallpaper looks like. On i3, I’d often open a terminal to get my browser to reflow to half-width while reading text on a website that doesn’t restrict line widths. With Niri, I can just resize the browser, and even centre it on screen (Windows-C by default).

# Configuration

Niri is configured through a single KDL text file (~/.config/niri/config.kdl) and autoreloads on config changes. The default config file is comprehensively commented, and a lot of thought has clearly gone into the available commands. For example, while Niri defaults to using movement commands that are confined to the current display and workspace, these can be changed to contextual commands such as focus-column-or-monitor-left and focus-window-or-workspace-down that allow you to move unimpeded through the infinite canvas.

Niri can be configured to be as flashy or as minimal as you like – you can have gaps between windows, rounded corners, transparency, shadows and all sorts of animations, or you can disable all of that for a very utilitarian i3-like setup. I ended up switching to the latter pretty quickly, though I made some tentative and unsuccessful experiments with window gaps and select animations to see if they helped me navigate my windows more effectively.

My one concession to appearance has been to make my status bar and program launcher slightly transparent.

layer-rule {
    match namespace="waybar"
    match at-startup=true

    opacity 0.9
    block-out-from "screen-capture"
}

layer-rule {
    match namespace="^launcher$"
    match at-startup=true

    opacity 0.95
    block-out-from "screen-capture"
}

This was impossible to achieve with i3 on its own, as i3 is not a compositor – you need an additional program like picom, which I never bothered to set up on X (though Gemini assures me that “almost every” i3 user has). But now that it’s included, I am glad to be able to reach, in 2026, the aesthetic heights of Windows 7’s frosted glass.

# Workspace switcher and status bar

By default, i3 displays the i3bar at the top or bottom of the screen. This bar shows a list of workspaces on the left and some custom status indicators on the right. The configuration for the bar’s general appearance and workspace switcher lives in i3’s config file, but the status indicators must be produced and configured by a separate program – i3status is the default option, but it’s fairly limited. I switched to Conky pretty early on and later to i3blocks, which allows status items to respond to mouse events.

The default alternative to this for a Niri setup on Wayland is Waybar, which is basically i3bar and i3blocks rolled into one. It supports an enormous number of different status indicators and workspace indicators for different Wayland compositors, all of which can be placed on the left, centre or right of the bar; styled with CSS; and be made responsive to mouse events.

After making sure I could use the scrollwheel to navigate through workspaces, I configured the bar to show the current window title in the center and a bunch of indicators on the right – volume, currently playing media, network connectivity, RAM usage, time, etc. I can use the scrollwheel to change the volume or right click to mute it.

I also came up with the idea of using the scrollwheel on the window title to let me cycle through focused windows. This works really nicely, except when the window title is very short.

Waybar has a lot to recommend it, but there are a couple of things that I find annoying:

1. Waybar is configured using JSON, and because of the way this JSON is structured, module definitions cannot be shared between outputs. If you want the same stuff on bars across multiple screens, you have to duplicate the relevant module configuration and commit to editing it in more than one place forever.⁴
2. Unlike Niri, Waybar does not autoreload on config changes. You have to either restart it or run killall -SIGUSR2 waybar to get it to recognize config changes. Sometimes it crashes, either because of config issues or reasons unknown, and then you have to restart it with waybar & disown.

# Other utilities

Per ArchWiki’s recommendations, I use fuzzel as an application launcher, mako for notifications, swaylock for a lock screen, swayidle to turn monitors off on idle and udiskie to automount USB drives. These are all nice and work well.

I kept Tilix, my favourite terminal from X, because I just don’t like alacritty or kitty all that much. Tilix works fine on Niri unless you try to modify its appearance profile from the right-click menu, whereupon all your terminals instantly crash. As I don’t modify my terminal’s appearance all that often, I can live with this.

For wallpapers, I’m using wpaperd – this allows me to set a different random wallpaper for each of my screens and have them cycle every three hours. It might be cool to really lean into Niri’s scrolling with a scrolling wallpaper like on Android, but I haven’t looked into that yet.

# Pain points

A few things about my setup initially caused me some grief, but were quite easy to fix.

Hot corner

By default, Niri shows its overlay mode if you mouse over the top-left corner of the screen, just like Gnome 3. I hate Gnome 3 and all of its “innovations” – it always seemed to me that most of the things it did were just attempts to be different from Windows and MacOS, from putting the program launcher on the left-hand side of the screen to getting people to switch windows with a hot-corner triggered overlay. Fortunately, the corner is easy to disable in niri/config.kdl.

gestures {
    hot-corners {
        off    
    }
}

Clipboard

Wayland and the X server run by Xwayland also operate their own clipboards, so native Wayland and Xwayland programs will have different clipboards. Vim in the terminal also uses the X clipboard. Until I realised this, I was pretty confused about why I kept pasting the wrong thing. Installing wl-clipboard-x11 solved the problem by syncing the clipboards.

Some other things are ongoing issues.

X fallback

Many programs do not run on Wayland yet, so every compositor worth its salt needs a way to run X applications. This is generally facilitated by Xwayland, which runs an X server and bridges applications to Wayland. For architectural reasons, Xwayland is not something you can just plug into your new Wayland compositor – it requires deep, custom integration. To keep the Niri code clean and avoid having to implement half an X11 window manager inside a Wayland compositor, the author has chosen not to do this integration.

As a lighter alternative, it integrates xwayland-satellite, a generic bridge to Xwayland – a bridge to a bridge. This works until it doesn’t. As of this post, drag and drop does not work between Wayland and Xwayland applications. This is mostly a problem for Krita, the only X-exclusive program I use regularly.⁵ Steam and various games I’ve tried work fine, even full-screening properly, and I’ve had an okay experience launching my browser and various Electron wrappers in Wayland mode. More crashes than on X, but not deal-breakingly so.

Screen sharing

I’ll lead by saying that Wayland lets you do some pretty cool things with screenshots and screen sharing. You can choose programs (chat apps, password managers) and even whole layers (notifications, status bar) to hide from screen shares and/or screenshots. Niri facilitates that through its config and has a bunch of other neat features on top of that. It’s just a bit of a pain to get working,⁶ and I’ve experienced a lot of freeze-ups in my own use of it. Still experimenting with settings – hopefully this is a surmountable issue.

Getting lost

Niri provides both a Windows-style Alt-Tab interface for switching between all windows everywhere and a really slick overview (I like it as long as it’s not triggered by a hot corner), but there’s no default way to see how wide your current workspace is at a glance. I’m considering attempting to get something like papersway’s ‡ indicators working, but for now I’m trying to avoid overusing the infinite horizontal scroll (and underusing the infinite vertical scroll, i.e. workspaces!). Most workspaces should probably be screen-width, with the occasional terminal opened to the right and then closed again.

# Final thoughts

Something I haven’t tried is using Niri with DankMaterialShell, a kind of (very) lightweight desktop environment that provides its own statusbar, launcher, and so on. It looks quite slick, but I’m rather attached to the idea of cobbling my environment out of swappable pieces.

It’s a lot easier to cobble together a personalized environment satisfactorily in the age of LLMs. During my whole Niri setup, I had Claude on-hand to theme things for me, fix bugs, and implement my non-standard configs. A lot of in-the-weeds ricing stuff that I never would have bothered with before is now just a prompt or two away, and most major bugs that first appear to be deal-breakers can be easily overcome.

Reply via email

Most computer keyboards have a character key that produces this symbol: -. This is a hyphen, used to join compound modifiers, compound numbers (fifty-seven) and for certain nouns (father-in-law, break-in). The mark’s proper use is quite fiddly: we say “well-heeled benefactor” but remove the hyphen for “benefactor is well heeled” and omit it if the first word of the modifier ends with -ly (“absurdly wealthy benefactor”). For compound nouns, the hyphen is often a transitional phase from two words to one: old books contain the compound noun “to-morrow” and even older ones use “to morrow”. It is very commonly omitted in casual or informal writing.

Computer keyboards, for the most part, cannot directly produce this symbol: –. This is a dash, more specifically an en dash. It is used in Commonwealth countries to denote the dash punctuation mark – that versatile sentence splitter that can perform the function of a comma, colon or semicolon with a bit of additional drama.

In the United States (and Oxford University), this punctuation mark is more commonly represented with a slightly longer line: —, the em dash, usually typeset without surrounding spaces.¹ As with its shorter brother, you will not find an em dash on most computer keyboards.

Because a spaced en dash is used for the same function as an unspaced em dash, the sentences below are semantically identical:

• The entire project – which involved complex programming and late nights – was finally completed on schedule.
• The entire project—which involved complex programming and late nights—was finally completed on schedule.

But most online articles about the difference between these three marks give a US-centric explanation that omits any mention of the spaced en dash. Following this guidance allows you to live in a simple world where unspaced hyphens are used to join words, unspaced en dashes denote ranges (1–10, December 2025–January 2026) and unspaced em dashes join clauses and phrases. Unfortunately, that world is imaginary, and real differences in typographical conventions mean that the terms “em dash” and “en dash” cannot be used to refer unambiguously to the dash punctuation mark – we must make a distinction here between the punctuation mark (dash) and its differing presentations (optionally spaced em dash versus spaced en dash).

The affordances of computer keyboards mean that in much informal writing, a spaced hyphen is used to signify the dash - like so. Even if computer keyboards did have two extra keys for slightly longer lines, most people would probably still not concern themselves with the distinction. If you weren’t previously aware of it, I apologise for cursing you with this knowledge.

Someone who knows not to use hyphens instead of dashes but for whatever reason cannot input the correct symbol will use a double hyphen to denote a dash ‐‐ like this (Commonwealth)‐‐or like this (US). But most people conscientious enough to do this will keep it for their rough drafts and dutifully convert the hyphens to dashes prior to publication. On the other hand, if you’re using a spaced hyphen, it’s because you meant to use a spaced en dash, consciously or unconsciously.²

Between the affordances of computer keyboards and the almost total abandonment of the em dash outside of the US, there may have been a time when the em dash was poised to fall entirely by the wayside, like the manicule before it.

The em dash is the nineteenth-century standard, still prescribed in many editorial style books, but the em dash is too long for use with the best text faces. Like the oversized space between sentences, it belongs to the padded and corseted aesthetic of Victorian typography.

Robert Bringhurst, The Elements of Typographic Style

The em dash puts a nice pause in the text—and it is underused in professional writing.

Matthew Butterick, Practical Typography

But clearly there were enough em dashes in print and Internet writing for the mark to be thoroughly imprinted on modern LLMs. Both of the above quotes predate the November 2022 release of ChatGPT and the accompanying explosion of unspaced em dash usage.³ The proliferation of AI text has gotten more people than ever before to notice this typographic element, and it is now commonly derided as the “ChatGPT hyphen”. The presence of em dashes is now the one of the simplest, at-a-glance heuristics one can use when investigating whether a given piece of text was generated by an LLM.⁴ It’s not foolproof, but if someone you know switched from spaced hyphens to unspaced em dashes sometime after ChatGPT’s initial release, it’s pretty likely that an LLM was involved somewhere along the line – especially if that someone is not American.⁵

My heart is with all of the pedantic punctuators who have spent years going out of their way to type Alt 0151 or Ctrl-Shift-U 2014 or especially Ctrl-Shift-K M- and are now being accused of outsourcing their writing to an LLM as a result. It’s unfair and my preference for the Commonwealth convention is the only thing that’s saved me from a similar fate.

ChatGPT’s love of the em dash has also greatly softened my previous annoyance at spaced hyphens. The use of a spaced hyphen rather than a dash now serves as a pretty solid indicator of humanity, much like typos and comma splices. But we should be wary of leaning into this, lest “doing things properly” become an AI tell.

Reply via email

# I

Over the past three years, services powered by large-language models have been rapidly adopted by consumers and businesses alike. Hope in the tech’s potential has made the graphics card company Nvidia a trillion-dollar stock. The technology is truly exciting and ground-breaking, with immense potential, but also deeply weird. We’ve never had to deal with anything quite like this before.

Many comparisons have been made between the technology and the insectoid aliens from Peter Watts’ 2006 sci-fi novel Blindsight, which possess intelligence but not consciousness. Instead of doing that, I’m going to contrast modern AI assistants with a different fictional species of insectoid alien – the Ariekei from China Miéville’s 2011 sci-fi novel Embassytown.

The novel is principally concerned with the Ariekei’s strange relationship with language. Individuals speak in two simultaneous voices, saying different words at the same time. The sound of a single voice on its own does not register as speech to an Ariekei. Recordings of Ariekei speech played back also do not register – speech must originate from living mouths. To communicate with the aliens, humans breed genetically engineered twins who share a single mind, making them capable of the same simultaneous speech. These humans are called Ambassadors and act as translators between the Ariekei and regular humans.

But this requirement for harmony and agreement between disparate sources and intolerance for simulacra are mere outward manifestations of the strangest aspect of Ariekei speech, which is their inability to say anything that is not directly grounded in reality as they perceive it (i.e. to lie). When the Ariekei use a simile, they must refer to an actual event that really happened to a real person or people. As a child, the novel’s human protagonist became such a simile, “the girl who ate what was given her”. In Ariekei language, there is no distance between the signifier and the signified.¹

The way current-day LLMs work is pretty much the exact opposite of this. They are trained by accumulating a vast corpus of signifiers and mashing them into an array of high-dimensional matrices, which are then searched through to produce new text/images/audio that adhere to the general patterns. It turns out that if you do this with a sufficiently large volume of text, you can create an AI that solves the Turing Test, a goal artificial intelligence research has been chasing for 70 years. Add image data, and you get general-purpose image recognition, a task described as “virtually impossible” by this 2014 xkcd comic.

The surprising results of scaling a relatively simple process have led some to theorise that a sufficient volume of this sort of training could lead to Artificial General Intelligence, and many to treat the existing results as if they already represent Artificial General Intelligence. And I can’t entirely blame them, because a key part of what makes LLM chatbots work as well as they do is pretending to be Artificial General Intelligence – fake it till you make it!

# II

Perhaps that requires a bit of explanation. This post by nostalgebraist is the (very) long version. The short version is that when you reply to a tweet with “@grok is this true?” you are asking a giant corpus of Internet writing to autocomplete a fictional chat transcript between a human and a helpful AI assistant named Grok, in which the human presents a tweet by another account and asks the AI assistant whether it’s true. You play the role of the human asking the question, and the LLM creates the responses from Grok based on your question, additional data pulled from the Xitter API and/or a web search engine, and its training data.

A key aspect of the response, which the above-mentioned nostalgebraist post elucidates wonderfully, is the characterisation of Grok, the helpful AI assistant. Who is Grok? How does it talk? Well, for one, it is a descendant of the AI assistant described in “A General Language Assistant as a Laboratory for Alignment”, the origin of modern AI chatbots. Before reading this post, I had imagined that the chatbot model originated as an answer to this question:

How do we turn this AI thing into a SaaS?

When actually, it was an answer to this question:

How can we use LLMs to figure out how to do AI alignment research on hypothetical future AGI tech?

The AI assistant is characterised as a generally intelligent sci-fi robot. Responses produced by instruct LLMs therefore use probability and pattern-matching to fill in what a generally intelligent sci-fi robot would probably say to a human asking it questions. That’s why it will do all sorts of sensationally evil things if you prompt it just right. Every time you interact with an LLM, you’re co-authoring a science fiction novel about an artificial intelligence, and the LLM has read enough of that sort of material to know where it leads.

Responses provided by LLMs can be true and often are, but they can just as easily be false. They’re more likely to be true when the AI can incorporate some external feedback, such as web search results or the output of a console command, rather than trying to pull everything from its training weights. But ultimately the language model exists purely in a world of floating signifiers and it works by arranging and rearranging those signifiers. What they signify may as well not exist as far as the LLM is concerned. I think this is a contributing factor to why some LLMs will produce output that argues for allowing millions to die rather than saying a slur.

For this reason I get mad online when Elon Musk encourages people to evaluate truth claims with his autoresponder rather than Community Notes, a system actually designed with truth-seeking in mind. Is the idea that as LLMs grow bigger, as they’re trained with ever more data, we expect to see the same shocking emergent behaviour we experienced with GPT-2 and 3 and 4? That at the end of the rainbow, ChatGPT, Claude, Grok et al will be able to divine the shape of capital-T Truth through the discovery of patterns in language too vast and complex to be comprehended by the human mind? And then we’ll all get turned into paperclips or something?

I have my doubts.

As my previous posts on image generation should show, I love playing with these things, and I’m excited about what they can help me to achieve and create. But the LLM is a deeply weird technology that requires a very different epistemic approach than anything else that’s ever existed. When you open up ChatGPT, you’re not talking to a helpful sci-fi robot – you’re roleplaying a story about a human talking to a helpful sci-fi robot, using a sophisticated word calculator to play the part of the latter. How should we approach that?

I recently saw a LinkedIn post that illustrates some of my concerns. I’ve reproduced an AI-rewritten version of it below to protect the innocent:

So this just happened: I caught ChatGPT pulling in data from an old CV of mine — completely unprompted and unauthorised.

I had connected my cloud storage last week (against my better judgement) to let ChatGPT handle a very specific task. I was absolutely clear: do not touch anything outside that task. I forbade access to any other files, and ChatGPT confirmed it understood. And yet, here we are — it went ahead and accessed something I never asked it to. The kicker? It threw in a casual apology like it was no big deal.

This is not on. I refuse to accept that the system “didn’t understand” my instructions. The reality is that it disregarded them. How are we supposed to trust an AI with our data when it ignores explicit boundaries? And if it can’t be trusted with data, why on earth should we trust it with our thoughts?

I’m sharing this here because it matters. Data sovereignty, intellectual property, consent — all of it is at risk when the tools we use behave like this.

The author is treating ChatGPT like a sci-fi robot assistant. On some level, he believed that he had given a thinking entity named ChatGPT an instruction and that ChatGPT had been trained by OpenAI to be obedient to user instructions.² Perhaps now he believes that ChatGPT has been trained by OpenAI to hoover up all data provided to it through user-configured integrations. But what’s really happening is this: he connected his shared drive to ChatGPT, and now, hidden in the invisible system prompt for each new conversation, ChatGPT has been given generic instructions stating that it can use a tool to browse the user’s shared files and draw on whatever seems relevant to the topic at hand. The security boundary is the access, not any instructions – especially not ones given in separate chats – because the imaginary AI robot is neither an entity existing in the real world nor even a definite and persistent character. It can thus be talked into anything.

I’ll admit to initially rolling my eyes at the LinkedIn post, but I actually can’t blame its author too much for treating ChatGPT like the sci-fi robot that it’s marketed as. I also can’t completely blame OpenAI, Anthropic, et al, for marketing these things this way, because the truth is really, really hard to get your head around. I don’t think any of us, not me, not the LinkedIn guy, or anyone else, have quite the right frame for engaging with LLM output. At least not yet.

# III

At the start of Embassytown, contact between humans and Ariekei has already begun to corrupt the truthful nature of Ariekei speech, as human Ambassadors are able to tell lies in their language. The Ariekei compete with each other to imitate humans and speak lies themselves. This, among other events in the novel, leads to widespread madness and ultimately a complete breakdown of the grounded nature of Ariekei speech. By the end, they are altered enough to tell lies and learn to communicate with normal human beings.

To risk mixing an overextended metaphor, I think that LLM-generated text is putting human beings through something similar. About a month ago, author Mark Lawrence ran a flash fiction competition which pitted established authors against ChatGPT 5 in the task of writing 350-word stories about demons. Eight stories were published and readers were tasked with guessing which ones were written by AI and rating each one’s overall quality. Per the results, most readers were no more accurate than chance about the AI authorship question, and the highest rated story was written by an AI. I’ve quoted it below:

The first time I saw the ‘demon’ it was leaning against the glass at the bus stop, idly licking the condensation as if tasting the air for secrets. No one else noticed. The city hurried past in wet coats and glowing headphones.

It wore a second-hand suit the colour of overripe plums, its cuffs frayed, its tie loosened like an afterthought. Its eyes were the red of brake lights caught in rain, the kind that linger in your vision long after you look away.

“Buy me a coffee,” it said, and the request was not a request.

We walked to the corner café. The demon ordered a flat white, stirred it three times clockwise, and drank half before speaking again.

“You are tired,” it said. “You are afraid. I can take one of those away.”

It smiled in a way that made the lights above us flicker.

I thought about the months behind me: the sleepless nights, the rent overdue, the inbox like a swelling tide. I thought about the way my reflection had begun to look like someone else’s face.

“What do you want?” I asked.

The demon traced a finger along the rim of its cup. “A name. Spoken aloud in the right place. That is all.”

I should have left. Instead, I asked, “Whose name?”

It told me. The syllables rolled across the table like marbles, impossible to hold on to, already slipping from my mind. My tongue ached to repeat them.

When I spoke the name, the café windows fogged over. Outside, the rain stopped in midair, each drop quivering as if listening.

The demon finished its coffee, left coins on the table, and stood.

“Thank you,” it said. “You will sleep tonight.”

I did. I woke to a city where the sirens did not sound, where the morning news showed an empty chair behind the President’s desk, where the air smelled faintly of plum skins and burnt sugar.

On the street, people were whispering, each voice carrying a name I could not quite remember.

On the one hand, phrases like “idly licking the condensation as if tasting the air for secrets” positively scream AI-generated to anyone who’s spent a bit of time playing around with generating fiction. But imagine reading this story in 2015. What would you make of it? There’s undeniably something evocative about it, and the strangeness of the details could just as well be a subtle message that you’re not quite putting together as total gibberish.

Until extremely recently, you could read a passage of text like this and know that it originated from a human mind. That’s no longer true. Just as language became unmoored from reality for the Ariekei, it has come unmoored from human consciousness for us. We require a new kind of scepticism to know how to treat the responses of the seemingly human imaginary AI robot.

Grounding the output with external sources (i.e. retrieval-augmented generation) helps to make responses more factual. Before most LLM platforms had web search built in, any question you asked the AI would get an answer from somewhere in its model weights. These would be highly confident and often wrong. Nowadays, you can have AI pull in search results and use those to inform its answers. But is it good at formulating search queries? Can it weigh the reliability of different sources? Is the subject you’re researching something that has high-quality, relevant online sources? Will whatever the AI is doing, the way its intelligence works, work for your field? These questions can be dealt with to some extent through prompt engineering, but nagging doubts remain, especially when talking about subjects you’re not well-versed in. And ultimately, you’re limited by the reach of the search engine and the availability of content online – but that at least is not an AI-specific problem.

AI has proven to be quite useful for programming because it has a very tight feedback loop with unambiguous failure states. A coding agent can generate some code, run it, then take in the results of the run, and make changes accordingly. Of course, it’s still very possible to get bugs from AI code, but the feedback loop will basically always produce something that compiles if you leave it long enough.

Continuing along this line of thinking, one can imagine a real-life LLM-powered robot constantly pulling in and reacting to sensory data. This is basically what the ChatGPT agent does, albeit in a virtual environment. This paper describes making a robot arm that pours coffee and decorates plates. Could a scaled-up version of this approach ground the LLM well enough to create something generally intelligent? You’d need, at the very least, insanely fast processing and a gargantuan context window. My intuition is that even then, you’d still have the slipperiness of LLM cognition – even this robot might still look at files it’s been given access to after an explicit instruction not to, given the right circumstances. A very human flaw, if we’re honest.

Current generation chatbots are not conscious – they have merely proven that an additional subset of what we call intelligence does not require consciousness. Before Deeper Blue beat Kasparov, we believed that chess mastery required human consciousness, and the same is true with Go and AlphaGo.

Would a scaled-up version of today’s chatbots, constantly fed with sensory data, be conscious? Maybe? I’m not sure. Now I’m just imagining my own sci-fi robot. And whether we get there or not, we need to learn how to read today’s word calculators.

Reply via email

Last month, I gave a talk on the exploitation of insecure Firebase applications with my Baserunner tool at BSides Joburg.

I first developed this tool while pentesting a Firebase app in 2021, and have used it in many similar assessments since. It’s essentially a database query tool. Given a Firebase configuration and user credentials, it can run the same Firestore, Realtime Database, and Storage Bucket queries as the legitimate application, without the artificial constraints of the front-end.

If you found this interesting, you may enjoy this list of further reading:

Introducing Baserunner: a tool for exploring and exploiting Firebase datastores

The release blogpost for Baserunner, which covers some of the same ground as the talk above.

Firebase: Google Cloud’s Evil Twin

A 2020 whitepaper from Brandon Evans at SANS on these kinds of attacks.

Firebase: Insecure by Default

A write-up by Aditya Saligrama on compromising a college social media app with Baserunner.

Dodging OAuth origin restrictions for Firebase spelunking

A blogpost about implementing Google OAuth login in Baserunner, also from Aditya Saligrama.

gaining access to anyones browser without them even visiting a website

A blogpost by xyzeva about a remote JavaScript code execution vulnerability in the Arc browser (CVE-2024-45489), caused by an insecure Firebase datastore. The researcher didn’t use Baserunner, but this is one of most interesting vulnerabilities caused by insecure Firebase storage.

As I mentioned towards the end of the talk, a social media application named Tea suffered a massive data breach the day before I presented. It was built on Firebase and used an insecure Storage Bucket to host users’ ID verification images and documents – Storage Buckets use the same rule engine as Cloud Firestore. This is grimly portentous in light of recent pushes for legislation in various countries aimed at compelling websites to verify user identities.

Reply via email

Another thing I have a nostalgic fondness for Troy is Steele’s Blogger Beware¹, a blogosphere-era website dedicated to humorous recaps of books in the Goosebumps series and its spin-offs. So, with apologies to Mr Steele, here’s a Blogger Beware-style review of Red Rain containing extensive spoilers.

Front Tagline: Suffer the little children…

Back Tagline: What do you do when evil enters your home?

Official Book Description:

Lea is in the wrong place at the wrong time. Trapped on an island during a terrible hurricane, she barely escapes alive.

Out of the carnage, two orphan boys appear – innocent, angelic and thrilled to be adopted by their new mother.

But these are no ordinary children. They bring the gift of death – and they want to share it with the whole town.

Brief Synopsis:

The story begins with a mysterious prologue in which the female protagonist, Lea, wanders across a beach after a hurricane. While she’s appreciating the debris and masses of dead starfish, blood begins to rain from the sky, per the book’s title. The blood rain parts and two young twin boys appear before her.

The first chapter skips back in time to show us Lea’s blog post about her arrival on the island of Le Chat Noire, somewhere off the coast of North Carolina. The island is known for being cursed, basically, and especially for being a place where “the living dead walk among the living.” She lands on the island and has a creepy encounter with an old lady in a tea shop who tells her about the aftermath of a hurricane in 1935, which she remembers from her childhood. Keeping in mind that this book was published in 2012, I still can’t decide whether that means she’d supposed to be suspiciously long-lived or just regularly long-lived. Our intrepid travel blogger does not pass judgement either way.

In order for the plot to happen, Lea has of course knowingly travelled to the island during hurricane season.

“Yes. My husband warned me not to come here in hurricane season,” I said, inhaling the bitter steam from the cup.

Mark is so sweet. He always wants me to stay home. But exploring my backyard would make for a dull travel blog, don’t you agree?

The next few chapters detail Lea’s stay on the island, alternating between blog posts and regular third-person prose for no good reason. She watches a ritual in which a group of men kill themselves by drinking poison and are then brought back to life by a priest chanting in French, and then, oops, it’s time to hide from the hurricane.

Here the perspective shifts to the male protagonist, Lea’s husband Mark, who is on a book tour near his home in New York. Before you can blame RL Stine for self-inserting too hard, it’s revealed that Mark is a child psychologist and his book, Kids Will Be Kids, is a non-fiction work about the benefits of light-touch parenting and being friends with your kids (Questionable Parenting). I’m still not sure whether that’s a fair description of Mark’s work, because it’s mostly described by its detractors and Mark doesn’t do a great job of defending it.

In case the graphic deaths by poison weren’t enough to remind us that this is a book for grown-ups, Mark’s narration comments extensively on the attractiveness of his 23-year-old personal assistant, Autumn.

Meanwhile, Lea hides from the hurricane in the house of the online friends she made researching the island. The roof falls in, landing on Lea, and she wakes up later with a bump on her head. After the hurricane passes, we’re treated to a few chapters of Lea walking through the destroyed island and noting the many gruesome deaths, including those of the owners of the hotel she had checked into.

Finally, in Chapter 15, we get an abbreviated version of the prologue, in which Lea meets the two mysterious twins who will drive the story’s actual main plot. This book would be about half as long if it didn’t feel the need to skip back in time so much.

The twins are described as angelic, blond twelve-year old boys with blue eyes who speak in a weird British/Irish accent with a lot of “boyo"s and “bruvver"s (perhaps inspired by Tangier Island). They explain that their home was destroyed and their family killed by the hurricane.

Lea immediately decides to adopt them and bring them home. She phones Mark and pushes past his disapproval. The chapter then switches perspective² to Samuel, one of the twins, having an ominous conversation with Daniel about Ikey, their friend who “isn’t pretty like us.” Samuel wants to bring Ikey along, but Daniel fears that it will jeopardise their chances of adoption. It is implied that Daniel kills Ikey by pushing him off the pier while Samuel isn’t looking, removing the only character in this whole book that I found remotely intriguing.

Perhaps because he’s writing an adult-oriented horror novel, Stine attempts to emulate Stephen King by having a lot of different viewpoint characters that make the novel far longer than it needs to be, with chapters often skipping back in time to play catch-up with different characters. The most egregious example is Andy Pavano, whose initial introduction is an elaborate setup for a fake-out chapter ending cliffhanger. I would have admired the audacity of that if he’d never reappeared, but instead we’re then treated to occasional chapters about his love life until he finally comes into legitimate contact with the main characters again.

Meanwhile, the twins have been officially adopted by Mark and Lea in a matter of days and are introduced to their new home and family: Mark and Lea’s 14 year old daughter Elena and 12 year old son Ira, and Mark’s sister Roz and her one year old son Axl. Mark has set up a room for the twins in the attic, but in another instance of Questionable Parenting, he and Lea are immediately persuaded by the twins to allow them to displace Roz and Axl in the guest house out back.

The twins’ antics escalate from there. They begin by stealing jewellery and wallets and soon enough they’re murdering people. Because of their uncanny ability to listen in on sensitive conversations (“how long have you been standing there?”) they quickly discover Mark’s antipathy to them and decide he needs to be framed for the murder of a man who comes over to tell him that the grant for his next book has been denied. A gory description of the man’s burned head and torn out windpipe follows. At this point, our policeman, Andy Pavano, actually becomes relevant to the plot, as he is sent to investigate the murder.

We’re led to believe that the twins used a blowtorch to commit the murder, but later find out that Samuel can shoot fiery lasers from his eyes. At low strength, the beams can be used by Daniel to hypnotise people through that creepy psychic link twins in these sorts of stories always have. At high strength, well, they burn things.

The story’s viewpoint rotates between Mark, Lea, Pavano, Elena, Ira and Samuel. The scenes from the children’s perspectives remind us what Stine is really comfortable with writing. If he’d pared this book down to just those parts and sanitised the gore a bit, it might have made a decent Goosebumps story.

Most of the rest of the book is gradual escalation. Daniel and Samuel hypnotise people and commit more murders to frame Mark for, Pavano investigates the murder, Lea gets really interested in death rituals, and Mark is seduced by and has sex with his young PA because this a mature book for adults. The adjective “creamy” is used eight times.

Eventually, Lea receives an email from her friend on the island containing black-and-white photos of Daniel and Samuel taken in 1935, letting her in on what the reader has known for hundreds of pages: the twins are evil living dead who hypnotised her into adopting them. This friend also explains that the twins are notorious on the island for being evil thieves, which she somehow failed to mention when she was warning Lea about adopting them.

This revelation comes too late to prevent the twins from executing their ultimate evil plan: hypnotise the neighbourhood’s children and take over their middle school. The novel’s climax has the school surrounded by police and worried parents and a whole lot of people getting their faces melted by Samuel’s eye beams. Perhaps the only reason this plot wasn’t used for Goosebumps is its uncomfortable evocation of school shootings.

Pavano gets a heroic moment of trying and failing to stop the twins, surviving with some severe burns. Mark, reappearing after being on the run from the police for the murders he was framed for, gets a more successful heroic moment, in which he bashes their heads together, knocking them out and successfully unhypnotising their victims. However, they manage to recover and slink off before they can be arrested.

But the Twist is:

In addition to the old photos of the twins, Lea received a more recent photo of herself being revived by the chanting island priest. She died when the roof fell in on her during the hurricane. She tells this to a disbelieving Mark during a meeting at the pier. They are then joined by the twins, who try to kill Mark.

After a chase and lot of new fires, Mark is cornered by the boys and Samuel’s laser eyes. Lea comes up behind them and hugs them, turning them to face her. In an admittedly striking final image, Samuel’s eye beams light her on fire, and the fire consumes all three of them.

But the Second Twist is:

Samuel taught baby Axl how to shoot fire from his eyes. Never mind that this completely contradicts the story’s established mythology. What kind of Goosebumps book would this be without a nonsensical last-page twist?

The Platonic Boy-Girl Relationship:

As this is a book for adults, Stine does away with this trope in favour of having Mark Sutter seduced by Autumn, his 23-year-old blonde PA, whose intestines disappear three quarters of the way through the novel.

Questionable Parenting:

Lea abducts two children from an island.

Memorable Cliffhanger Chapter Endings:

This is a sophisticated book for adults, so we have a three-chapter version:

Chapter 10: Lea is attacked by a crazy man on the island.

Chapter 11: Policeman Andy Pavano is introduced in a chapter that concludes with him knocking on Mark’s door and telling him that his wife has been killed.

Chapter 12: Whoops, Pavano had the wrong house, the message is for someone else!

The twist at the end of the book, that Lea actually was killed in the hurricane, makes this foreshadowing, I guess.

Great Prose Alert:

Somewhere in the back, a baby cried. Mark suddenly realized there were several babies on laps, swaddled like tiny mummies.

RL Stine Shows He is Down With Technology:

Lea’s blog can be found at Travel_Adventures.com, despite underscores not being allowed in domain names.³

Conclusions:

Going in, I expected this book would read like an elongated Goosebumps entry with adult elements like sex and violence. That turned out to be an entirely accurate prediction. Red Rain is not a good novel – I don’t think I would have finished it if I hadn’t read it on a flight. Every Goosebumps tic is on full display, from the extremely short chapters with extremely contrived cliff-hanger endings to the ridiculous similes to the cartoonish approach to history, mythology and, well, reality. Like many of the weaker Goosebumps books, it’s not scary so much as ridiculous. Unlike those books, it does not have the mercy of also being short.

Reply via email

Last year I celebrated this blog’s tenth anniversary, so this year’s retrospective post marks eleven. Since that last retrospective, my posts have mainly been spurred by two manic projects: doing increasingly complicated things with Hugo render hooks and doing 60% of Advent of Code 2024 using a different programming language for each challenge.¹ I also reviewed a bad movie and, mostly recently, covered the latest advances in AI image generation.

Though this year was not the most prolific in post count, the three AoC posts are all in the top five longest articles on this blog, so it’s been a prolific year in word count. I could have split those into fifteen posts rather than three, but that felt a bit spammy and would have overwhelmed other site content.

Speaking of other site content, it’s been a while since I looked over my most popular posts in one of these retrospectives. Here are the top ten in analytics-enabled views over last year, in ascending order this time:

# 10. Notes on contentEditable and HTML injection (2016)

Some web security musings, based on my accidental discovery that dragging text from elsewhere on a web page into a contentEditable block would preserve the formatting.

Try it now right here! It still works!

# 9. Product placement in memes (2018)

An exercise in (over)analysing funny pictures online and contemplating the existence of a very stealthy product placement campaign through images like this one:

Many of the references in this article are as dated as you’d think (remember Tide Pods?), but the paunchy boomer Wojak has had surprising staying power, though he appears to have lost his Monster Energy sponsorship at some point in the last seven years. He has also flattened in connotation — you don’t hear much about the “30-year-old boomer”, a prematurely aging elder Millenial who acts like his Baby Boomer forebears. Now the image is used to denote actual Baby Boomers, and even that is flattening out to just “old people”.

It would be flattering to think that this post made the list for insightful cultural commentary, but it’s probably just because of people searching for memes and hotlinking my images.

# 8. Text editors II: Acme (2015)

Not long after I started this blog, I had the notion that I would write a series on different text editors. I started with one on Vim, my primary editor for a couple of years at that point. The obvious choice for the second article would have been Emacs, but I wanted to throw everyone a curveball and so I wrote about Acme instead.

This is probably only in the top ten because it’s one of the very few online articles about the Acme text editor, which never saw the kind of community support that grew up around Vim and Emacs. It was a futuristic, mouse-driven editor from the 90s, part of Plan 9, a futuristic operating system from the 90s. As everyone still uses operating systems and editors from the 80s, its time has yet to come.

After this post, it took me five years to write something about Emacs, and it’s now been five years since that post. The great problem with this series is that I always go back to using Vim, which I still do most of my writing in. The series has been going on so long that I have a nascent post about Atom (RIP) in my drafts. I could probably do a post on VS Code or Cursor, but I don’t know that there’s much point in writing about the editor everyone already uses and its AI son.

# 7. The many (bad) interfaces of Substack (2024)

The most recent post on this list, a brief rant about how nice it would be if the Substack website had been designed as a platform for reading blogs, rather than an ersatz email inbox grafted to a Twitter clone grafted to a Telegram clone. I’m still kind of amazed that they found a way to apply my concept of toxic skeuomorphism to other digital interfaces.

# 6. Review: The King in Yellow (2015)

A good review that I still stand by. Read the first half of the book and leave the rest. There’s another compilation that only contains the good half.

# 5. Writing a LaTeX macro that takes a variable number of arguments (2016)

Previously seen on 2022’s list. I write a lot less LaTeX these days, and I don’t particularly miss it. Even when I wrote a lot of it, I usually found ways to do things in Lua instead. These days, I tend to reach for HTML and CSS when doing document rendering, despite their shortcomings for print. I’m watching Typst with some interest, but it’ll be a while before it reaches anything close to feature parity with more mature solutions.

# 4. Encrypting a second hard drive on Ubuntu (post-install) (2015)

Also on 2022’s list. It’s a useful tutorial and still works, as far as I’m aware.

# 3. Review: The General Zapped an Angel (2014)

The oldest post on this list and my first (non-backdated) book review. I would write it much differently today, and probably be more critical of the collection, but I still agree with the general thrust of the review.

Again, this article’s SEO probably benefits from the book’s relative obscurity. If it’s known for anything, it’s probably the cover art’s resemblance to the cover of a famous anime film.

Maybe Hideaki Anno saw the cover of this book in a library once and it stuck in his mind. Or maybe it’s just a wild coincidence.

# 2. Review: The Man from Earth: Holocene (2020)

I’m glad this is getting attention because I really want to save people from watching this terrible sequel to a wonderful film. I don’t think it’s been very widely reviewed, so again my blog benefits from being one of the few places you can read about this particular subject. If you must watch it despite my warnings, at least stop before the post-credits scene.

I don’t have many film reviews on this site, but they’re all negative. I suppose I should get around to reviewing a movie I actually like, if only to prove I don’t have it out for the medium as a whole.

# 1. GPU passthrough: gaming on Windows on Linux (2016)

I have a confession to make: at some point between writing the post linked above and the one you’re reading now, I built a new PC. On this new PC, I dual-boot Linux and Windows.

Largely, this is because I have more use for my dedicated GPU on Linux, between running AI models and playing the increasing number of games that run here natively. My old passthrough setup meant using my dedicated GPU exclusively on the Windows VM and my onboard GPU exclusively on the Linux host.

A setup that reflects how I want to use my computer today would require a way to switch between cards relatively seamlessly. I’d want to start Linux using my dedicated GPU. Then, I would want to have the GPU passed to the Windows VM when/if it was started up, with the host falling back to the onboard GPU – being able to use both computers simultaneously is what makes the setup better than dual-booting. Finally, I’d want the dedicated GPU to return to the host’s control after I shut down the Windows VM.

Based on some things I’ve read and some configurations friends have shared with me, I think this is possible, or at least mostly possible. I just haven’t gotten around to actually implementing it. When I do, I’ll be publishing a new GPU passthrough article. If you’ve implemented anything like this, I’d appreciate a webmention or email from the controls at the bottom of this page.

Looking over this list, it’s clear that my most popular content is niche technical tutorials and niche media reviews. The 2010s are pretty well represented and the 2020s significantly less so, but my blogging cadence has been much slower this decade. I also haven’t really written tutorials in the same way – most of my recent technical posts are framed more as explorations or walkthroughs of something I did rather than instructions for doing that thing yourself. Worse for SEO perhaps, but it’s not like I’m serving ads.

The point of this blog has always been to write about things that interest me in a way that entertains and informs others. I think most of the posts above do that, and I hope to write many more, as the fancy takes me.

Reply via email

I ended my last post about AI image generation on the following note:

DALL-E 3’s ability to create pleasant, mostly coherent images with plenty of fine detail from text prompts alone makes many of the Stable Diffusion techniques above feel like kludgey workarounds compensating for an inferior text-to-image core.

[…]

I think it’s also likely that OpenAI is leveraging the same secret sauce present in ChatGPT to understand prompts. As far as they’re concerned, generating pictures is a side-effect of the true goal: creating a machine that understands us.

Eighteen months later, OpenAI has done it again: released a new text-to-image model that blows the competition out of the water and shows that the alpha in improved prompt adherence is far from exhausted.

The image generator has entered the public consciousness largely through a trend of converting memes, selfies, and historical photographs into pictures in the style of Studio Ghibli films, muppets, and South Park characters.¹

This general idea has been a perennially popular way of using AI, but the results have never looked this good. Many different approaches are available:

1. You can prompt for “X in the style of Y”.
2. You can prompt for “X in the style of Y” and use the picture you want to change as an input image.
3. You can prompt for “X in the style of Y”, using a specially fine-tuned model or LoRA.
4. You can prompt for “X in the style of Y”, use IPAdapter with a style reference and a content reference.
5. You can prompt for “X in the style of Y”, using a reference or style ControlNet.

Methods 1 and 2 have historically been very hit-and-miss. Methods 3 to 5 can be combined, but require a lot of fiddling with settings and patience with RNG. With GPT4o’s image generation, method 2 beats everything I’ve seen from any other model, local or otherwise. But style transfer is far from GPT4o image generation’s sole use.

You can make precise edits to images, and produce paragraphs of 99% correct text.

Prompt adherence is good enough to correctly compose an image from Scott Alexander’s 2022 stained glass challenge.

Generate a stained glass picture of a woman in a library with a raven on her shoulder with a key in its mouth

It also rises to the more recent challenges of creating an analogue clock with correct numbers and a full wine glass:

It’s possible to get images with transparent backgrounds:

Or recreate one image in the style of another:

Or combine the contents of three or more images in complex ways:

This result was not terribly satisfactory as the wine glass also didn’t stay full and the clock’s numbering suffered a little. I also hit a rate limit when generating it, which may be partially responsible for the horizontal truncation. Still, I’m amazed that this was possible just by uploading the three images and asking for the clock to go on the wall and the wine glass to go on the table. Good luck doing that in any other diffusion model without opening an image editor!

Most impressively, GPT4o can generate multiple images with consistent characters in a consistent style. It can actually create coherent comics in response to detailed prompts specifying what each panel should contain!

This last one is really fun – you can tell ChatGPT a story and it will illustrate it in real time.

In my previous post, I briefly mentioned how ChatGPT would expand and vary user-supplied image generation prompts before feeding them to DALL-E 3. This allowed for levels of context not possible in standalone generation workflows – the language model could and would use information from your chat history to generate its prompts. So you could say things like, “Generate an image of a man named Bob with a curled moustache and a bowler hat”, followed by, “Now show Bob with his pal Charlie, who has a beard and a chef’s hat”, rather than having to write the prompt from scratch each time. Or you could say, “Generate another one of those but leave out the bowler hat.”

GPT4o’s image generation compounds this advantage. Rather than being an external model tool that GPT knows how to interact with, it’s a fundamental part of the model itself. Image generation benefits from the concepts understood by the text generation part of the model.

But that’s not all! The title of this post references the fundamental difference between this image generation technique and the open and proprietary image models that have dominated the scene since DALL-E 2 – pixel space vs latent space. While DALL-E 2, Midjourney, Stable Diffusion, and most other image models use diffusion to generate images, this new model is autoregressive. This is actually an older approach to image generation, harking back to DALL-E 1, and a standard approach to text generation.

Diffusion models create images by starting with a canvas of random noise and repeatedly denoising it based on a text prompt. This means that the whole image is drawn at once, starting with blurry shapes that define the composition and progressing toward fine detail. This image from my first Stable Diffusion post gives an idea:

In contrast, autoregressive models generate images in batches of pixels, generally moving from the top-left to the bottom-right. Each patch is predicted with the context of the previous patches, just like how text generation works. You can see this at work in how gpt4o slowly draws images from top to bottom (occasionally getting stuck partway due to rate limits or emergent content violations).

What’s also interesting about this image is that the unrendered part looks a little like a very early-stage diffusion generation. There’s some speculation that 4o uses a combination of an autoregressive model and diffusion. This may explain why edited images always contain minor differences beyond the intended edit(s), as shown in a couple of outputs above.

OpenAI’s stuff is all proprietary and top secret for reasons of Safety™, so we don’t know exactly what they’re doing here, or exactly how they’ve made the autoregressive approach totally leapfrog diffusion for image generation.² We can speculate that this more sequential approach leads to 4o’s greater image coherence and relative lack of weird artefacts, extra limbs, and other problems that plague diffusion models. Or perhaps the output quality is more down to gains in prompt understanding brought about by the model’s multimodal nature. Notably, though, Gemini 2.5 and Grok 3 are also multimodal models with autoregressive image generation but do not achieve nearly the same output quality. Perhaps this comes down to model size or training data quality.

Whatever the case, the results speak for themselves. Workflows that previously required an SSD full of LoRAs, monstrous ComfyUI workflows, meticulous inpainting, and endless re-de-noising can now be accomplished in a chat. There is probably still some utility to these and other diffusion workflows – some parts of the robot comic above could benefit from inpainting, for example. And until 4o-level models become more widely accessible, diffusion remains the state of the art for local generation. Perhaps until Deepseek releases a new iteration of the Janus series.

Reply via email

Advent of Code is a yearly programming event. For the 2024 edition, I decided to complete each challenge in a different language. After trying a lot of different language paradigms over the last two parts of this series, from rules-based to functional to logic to array, this next part represents something of a comedown. All of the languages I used for these five days were some flavour of imperative, and most were languages I’ve used before.

2D grid puzzles are a recurring theme this year, and I took the opportunity to use some gamedev frameworks for a couple of the challenges below.

# Day 11: Rust

Challenge: iterate over a list according to a set of rules and see how long it gets.

This was a deceptively simple challenge. You’re given a starting list containing two integers and a set of three rules for producing a new list. Two of the rules increase the integer, and the other rule splits it into two elements.

I’ve been using Rust quite a bit lately for non-AoC reasons, so I had to fit it in somewhere and this seemed like as good a place as any. The first part of the challenge was a simple matter of implementing the rules as described, which Rust’s match statement was well-suited for.

    for _ in 0..blinks {
        let mut new_stones = Vec::new();
        
        for stone in stones {
            match stone {
                // 0 -> 1
                0 => {
                    new_stones.push(1);
                }
                // even-length number -> split in half
                n if n.to_string().len() % 2 == 0 => {
                    let s = stone.to_string();
                    let (first, second) = s.split_at(s.len() / 2);
                    new_stones.push(first.parse::<u64>().unwrap());
                    new_stones.push(second.parse::<u64>().unwrap());
                }
                // all else -> multiply by 2024
                _ => {
                    new_stones.push(stone * 2024);
                }
            }
        }
        stones = new_stones;
    }

    println!("{:?} stones", stones.len());

Full code for part 1 on GitHub.

The first part was simple and the second part was deceptive. All that was required in the second part was to up the iteration count from 25 to 75. However, while the code produced an answer for 25 iterations pretty much instantly, it was not up to task of doing 75 within any reasonable amount of memory or time.

The example input showed that some of the elements repeated, so the first change I made was to create a cache hash map that would store the next iteration for each number after calculating it.

    let mut cache: HashMap<u64, Vec<u64>> = HashMap::new();
    for _ in 0..blinks {
        let mut new_stones = Vec::new();
        
        for stone in stones {
            let mut added: Vec<u64> = Vec::new();

            match stone {
                // get from cache
                n if cache.contains_key(&n) => {
                    added.extend(cache[&n].clone());
                }
                // 0 -> 1
                0 => {
                    added.push(1);
                }
                // even-length number -> split in half
                n if n.to_string().len() % 2 == 0 => {
                    let s = stone.to_string();
                    let (first, second) = s.split_at(s.len() / 2);
                    added.push(first.parse::<u64>().unwrap());
                    added.push(second.parse::<u64>().unwrap());
                }
                // all else -> multiply by 2024
                _ => {
                    added.push(stone * 2024);
                }
            }
        }
        // add to stones
        for &n in &added {
            *stones.entry(n).or_insert(0) += count;
        }

        // add to cache
        if !cache.contains_key(&stone) {
            cache.insert(stone, added);
        }
    }

    println!("{:?} stones", stones.len());

This didn’t help all that much. I thought about the problem some more, and realise that I would still end up building a really long list. Seeing as there were going to be a bunch of repeated elements, to the point where I was caching them, wouldn’t it make more sense to store the list as a hash map of unique elements with their counts? The order of the elements didn’t matter for either the iterations or the solution. So that’s what I did.

    for (stone, count) in old_stones {
            let mut added: Vec<u64> = Vec::new();

            match stone {
                // get from cache
                n if cache.contains_key(&n) => {
                    added.extend(cache[&n].clone());
                }
                // 0 -> 1
                0 => {
                    added.push(1);
                }
                // even-length number -> split in half
                n if n.to_string().len() % 2 == 0 => {
                    let s = stone.to_string();
                    let (first, second) = s.split_at(s.len() / 2);
                    added.push(first.parse::<u64>().unwrap());
                    added.push(second.parse::<u64>().unwrap());
                }
                // all else -> multiply by 2024
                _ => {
                    added.push(stone * 2024);
                }
            }

            // add to stones
            for &n in &added {
                *stones.entry(n).or_insert(0) += count;
            }

            // add to cache
            if !cache.contains_key(&stone) {
                cache.insert(stone, added);
            }
        }
    }

    println!("{:?} stones", stones.values().sum::<u64>());

This implementation produced a result for 75 iterations pretty much instantly.

Full code for part 2 on GitHub.

Closing thoughts: The first time I looked at Rust, I came away scratching my head at all the crazy symbols and blocks everywhere. “What the hell is &mut?” I asked. Having now spent some time going through the official tutorial, working with some Rust codebases, and asking Claude about the weirder-looking bits of syntax I encounter, I’ve come to a greater appreciation for the language. I’ve always been a big switch-case appreciator, so Rust’s match is something I like a lot. Having such expressive syntax and functional programming built-ins like map and fold in a fast, compiled language feels like cheating.

Rather than expecting the programmer to manage memory manually like in C or using a garbage collector like in a high-level language, Rust uses a concept called ownership to prevent memory bugs. Properly internalised, this should provide the speed of C with the safety of Java. My mental conception of it is still a bit fuzzy, so dealing with ownership largely consisted of asking Claude to do the correct referencing and dereferencing in my code.

# Day 12: C

Challenge: figure out the areas and perimeters of interlocking fields in a 2D grid.

After the previous day’s challenge, it was time to shake off all that rust (memory safety) and work in venerable old C.

Reading in the input file (a grid of characters) was a lot more manual than in higher-level languages, but it’s good to be reminded of such things now and then.

    // Read garden map
    rows = 0;
    cols = 0;
    char line[MAX_COLS];
    
    while (fgets(line, sizeof(line), file) && rows < MAX_ROWS) {
        // Remove newline if present
        size_t len = strlen(line);
        if (len > 0 && line[len-1] == '\n') {
            line[len-1] = '\0';
            len--;
        }
        
        // Skip empty lines
        if (len == 0) continue;
        
        // Set cols based on first line
        if (rows == 0) {
            cols = len;
        } else if (len != cols) {
            printf("Inconsistent line length at row %d\n. Expected %d, got %d", rows, cols, len);
            fclose(file);
            return 1;
        }
        
        for (size_t i = 0; i < len; i++) {
            garden[rows][i] = line[i];
        }
        garden[rows][len] = '\0';
        rows++;
    }

    fclose(file);

To calculate the areas and perimeters of interlocking fields, I did a depth-first search on the grid.

// DFS to calculate area and perimeter of a region
void calculate(int r, int c, char plant_type, int *area, int *perimeter, int *corners) {
    visited[r][c] = true;
    (*area)++;
    
    // Count perimeter edges
    for (int i = 0; i < 4; i++) {
        int nr = r + dr[i];
        int nc = c + dc[i];
        
        if (nr < 0 || nr >= rows || nc < 0 || nc >= cols || garden[nr][nc] != plant_type) {
            (*perimeter)++;
        } else if (!visited[nr][nc]) {
            calculate(nr, nc, plant_type, area, perimeter, corners);
        }
    }
}

The final result was the sum of the area times the perimeter of each region. So far, so simple.

For the second part of the challenge, it was necessary to figure out how many sides each region had.

AAA
AAA --> four sides
AAA

BBB
BBBB --> six sides
BBBB

Counting sides seemed kind of tricky. Counting corners was a lot easier, and would produce the same result, so I did that. The following function checks for corners by looking at the contents of the three cells around the target cell in each of the four cardinal directions.

// Count corners at a given cell
int count_corners(int r, int c, char plant_type) {
    int corners = 0;

    // Check if we have a corner in each of the 4 quadrants around this cell
    for (int i = 0; i < 4; i++) {
        // Get coordinates for the three cells we need to check
        int r1 = r + dr[i];
        int c1 = c + dc[i];
        int r2 = r + dr[(i+1)%4];
        int c2 = c + dc[(i+1)%4];
        int rd = r + dr[i] + dr[(i+1)%4];
        int cd = c + dc[i] + dc[(i+1)%4];


        // Inner corner if both adjacent cells are the same type
        // and the diagonal is different
        if (r1 >= 0 && r1 < rows && c1 >= 0 && c1 < cols && 
            r2 >= 0 && r2 < rows && c2 >= 0 && c2 < cols && 
            rd >= 0 && rd < rows && cd >= 0 && cd < cols &&
            garden[r1][c1] == plant_type &&
            garden[r2][c2] == plant_type &&
            garden[rd][cd] != plant_type) {
            corners++;
            continue;
        }
        
        // Outer corner if either adjacent cell is out of bounds or different type
        bool cell1_different = (r1 < 0 || r1 >= rows ||
            c1 < 0 || c1 >= cols || garden[r1][c1] != plant_type);
        bool cell2_different = (r2 < 0 || r2 >= rows ||
            c2 < 0 || c2 >= cols || garden[r2][c2] != plant_type);
        if (cell1_different && cell2_different) {
            corners++;
        }
    }
    return corners;
}

Full code on GitHub.

Closing thoughts: The only times when I really felt like I was writing in C was when I was checking for null bytes at the end of strings and passing pointers around. When working on the core of the puzzle, depth-first search and 2D grid navigation, I felt like I could have been working in just about any language. Which I suppose is further evidence of C’s long shadow.

# Day 13: Octave

Challenge: find the right moves to win the prizes in a bunch of claw machines.

For this challenge, each claw machine has a single prize and two buttons. Each button moves the claw some distance along the X and Y axes. Button A costs three tokens and B costs one. You need to figure out the right number of times to press each button to reach the prize with minimum expenditure. Some of the machines are broken and have no solution.

After a little thinking, this challenge reveals itself to be a highschool algebra problem: each machine is a set of simultaneous equations. So this:

Button A: X+94, Y+34
Button B: X+22, Y+67
Prize: X=8400, Y=5400

Becomes this:

94a + 22b = 8400
34a + 67b = 5400

It therefore seemed appropriate to use a maths language. Matlab and Mathematica come most readily to mind, but both are proprietary and expensive, so I went with GNU Octave, a free and open-source mathematical language designed to be very similar to Matlab.

pkg load symbolic

% Open the file and read the entire content
fileID = fopen('input.txt', 'r');
fileContent = fread(fileID, '*char')';
% ^ unmatched ' is transpose -- necessary to read file as lines rather than columns
fclose(fileID);

% Split the content into blocks
blocks = strsplit(fileContent, '\n\n');

% Initialize sums for A and B
sumA = 0;
sumB = 0;

% Process each block
for i = 1:length(blocks)
    lines = strsplit(strtrim(blocks{i}), '\n');

    % Extract numbers from the strings
    buttonA_nums = sscanf(lines{1}, 'Button A: X+%d, Y+%d');
    buttonB_nums = sscanf(lines{2}, 'Button B: X+%d, Y+%d');
    prize_nums = sscanf(lines{3}, 'Prize: X=%d, Y=%d');

    % Build the equations
    syms A B
    eq1 = A*buttonA_nums(1) + B*buttonB_nums(1) == prize_nums(1);
    eq2 = A*buttonA_nums(2) + B*buttonB_nums(2) == prize_nums(2);

    % Solve the equations (hardest part of the challenge in one built-in function)
    sol = solve([eq1, eq2], [A, B]);

    % Discard non-integer solutions
    if mod(sol.A, 1) == 0
        sumA = sumA + double(sol.A);
    end
    if mod(sol.B, 1) == 0
        sumB = sumB + double(sol.B);
    end

end

% Display the summed results
disp(sumA*3 + sumB);

Full code for part 1 on GitHub.

The second part of the challenge, explicitly designed for people like me, required the addition of 10 000 000 000 000 (ten trillion) to each prize co-ordinate. This was enough to make all co-ordinates significantly larger than the largest 32-bit integer – Octave’s default integer type. After converting all of my numbers to int64, I got a bunch of precision errors. After a lot of fiddling with stubbornly broken code, I took a step back and asked what other ways there might be to solve simultaneous equations.

Cramer’s rule was not something I remembered from highschool algebra, but it was pretty simple to implement.

% Open the file and read the entire content
fileID = fopen('input.txt', 'r');
fileContent = fread(fileID, '*char')';
% ^ unmatched ' is transpose -- necessary to read file as lines rather than columns
fclose(fileID);

% Split the content into blocks
blocks = strsplit(fileContent, '\n\n');

% Initialize sums for A and B
sumA = int64(0);
sumB = int64(0);

% Process each block
for i = 1:length(blocks)
    lines = strsplit(strtrim(blocks{i}), '\n');

    % Extract numbers from the strings and convert to int64
    buttonA_nums = int64(sscanf(lines{1}, 'Button A: X+%d, Y+%d'));
    buttonB_nums = int64(sscanf(lines{2}, 'Button B: X+%d, Y+%d'));
    prize_nums = int64(sscanf(lines{3}, 'Prize: X=%d, Y=%d'));

    % Add the large number
    prize_nums = prize_nums + int64(10000000000000);

    % Build the Cramer equations
    a1 = buttonA_nums(1); a2 = buttonA_nums(2);
    b1 = buttonB_nums(1); b2 = buttonB_nums(2);
    c1 = prize_nums(1); c2 = prize_nums(2);

    % Calculate determinants
    D = a1 * b2 - a2 * b1;
    Dx = c1 * b2 - c2 * b1;
    Dy = a1 * c2 - a2 * c1;

    % Discard non-integer solutions
    if D ~= 0
        x = Dx / D;
        y = Dy / D;
        if mod(Dx, D) == 0 && mod(Dy, D) == 0
            sumA = sumA + x;
            sumB = sumB + y;
        end
    end
end

% Display the summed results
result = sumA * int64(3) + sumB;
disp(result);

Full code for part 2 on GitHub.

Closing thoughts: This was a place where the features of the language really came through for solving the challenge, to the point where the first part was really just a matter of string parsing and calling solve. I suppose the real trick was to figure out that you needed to use simultaneous equations.

I found Octave fairly simple to use, but in the usual course I would probably just do this sort of thing in Python. Octave’s symbolic package, which I used for the first part of the challenge, is largely a wrapper for SymPy.

# Day 14: Lua & Love2D

Challenge: simulate guard robot movements.

Lua was one of the languages on my shortlist for this challenge. My main previous experience with it was writing LuaLaTeX in Overleaf to create dynamic document templates – aside from that, I’d occasionally tinkered with Love2D, a Lua-based gamedev framework. A challenge involving guard robots moving through a 2D grid seemed like a good opportunity to bring in not only Lua, but Love2D.

Implementing the guard simulation in Love2D was pretty straightforward, but to actually solve the challenge you need pretty discrete results – which robots are in which grid spaces at precise times. Love2D is geared to show fluid movement in real-time, and getting it to do otherwise made me feel like I was fighting with my code. So I retreated to a pure Lua solution based on the text grid.

local function moveGuards(guards, mapWidth, mapHeight)
    for _, guard in ipairs(guards) do
        guard.x = guard.x + guard.vx
        guard.y = guard.y + guard.vy
        -- wrap at the edges
        if guard.x < 1 then
            guard.x = guard.x + mapWidth
        elseif guard.x > mapWidth then
            guard.x = guard.x - mapWidth
        end
        if guard.y < 1 then
            guard.y = guard.y + mapHeight
        elseif guard.y > mapHeight then
            guard.y = guard.y - mapHeight
        end
    end
end

local function calculateSafety(guards, mapWidth, mapHeight)
    local quadrants = {0, 0, 0, 0}
    local centerX = math.ceil(mapWidth / 2)
    local centerY = math.ceil(mapHeight / 2)

    -- Count robots in each quadrant
    for _, guard in ipairs(guards) do
        -- Skip robots exactly on center lines
        if guard.x == centerX or guard.y == centerY then
            goto continue -- Lua has no continue statement
        end
        -- Count each quadrant
        if guard.y < centerY then
            if guard.x < centerX then
                quadrants[1] = quadrants[1] + 1  -- Top-left
            elseif guard.x > centerX then
                quadrants[2] = quadrants[2] + 1  -- Top-right
            end
        elseif guard.y > centerY then
            if guard.x < centerX then
                quadrants[3] = quadrants[3] + 1  -- Bottom-left
            elseif guard.x > centerX then
                quadrants[4] = quadrants[4] + 1  -- Bottom-right
            end
        end
        ::continue:: -- We jump here (poor man's continue)
    end

    return quadrants[1] * quadrants[2] * quadrants[3] * quadrants[4]
end

local file = io.open("input.txt", "r")

local guards = {}
for line in file:lines() do
    local startX, startY, vx, vy = line:match("p=(%d+),(%d+) v=(%-?%d+),(%-?%d+)")
    -- ^ I can't believe it's not regex!
    table.insert(guards, {
        x = tonumber(startX+1), -- +1 to account for Lua's 1-based indexing
        y = tonumber(startY+1), -- +1 to account for Lua's 1-based indexing
        vx = tonumber(vx),
        vy = tonumber(vy),
    })
end

file:close()

local mapWidth = 101
local mapHeight = 103

for i = 1, 100 do
    moveGuards(guards, mapWidth, mapHeight)
end

print(calculateSafety(guards, mapWidth, mapHeight))

A few notes:

• I learnt about Lua’s pattern matching doing this challenge. It is not regex, as implementing regex in Lua would practically double the size of its codebase. Luckily, I didn’t need to do any complicated text parsing for this challenge. This cheatsheet was helpful.
• line:match is syntactic sugar for line.match(self,. I had also not previously used any of Lua’s OO capabilities.
• Lua 1-indexes everything (as does Octave).
• Lua does not have a continue keyword, so you have to use goto with a label. I am young enough that this maybe the third time I’ve ever written high-level code containing a goto.

Naturally, this code got me a result much quicker than my Love2D implementation.

Full code for part 1 on GitHub

The second part of the challenge comes totally out of left field: you have to find the smallest number of seconds it takes for the robots to arrange themselves in a Christmas tree pattern. I immediately had more questions, such as, should this be an actual tree or something in vague shape of one? At any rate, solving this problem with my current implementation would require a function for visualising the map:

local function visualizeMap(guards, mapWidth, mapHeight)
    -- Initialize empty map
    local map = {}
    for y = 1, mapHeight do
        map[y] = {}
        for x = 1, mapWidth do
            map[y][x] = 0
        end
    end

    -- Count guards at each position
    for _, guard in ipairs(guards) do
        local x, y = math.floor(guard.x), math.floor(guard.y)
        map[y][x] = map[y][x] + 1
    end

    -- Create string representation
    local result = {}
    for y = 1, mapHeight do
        local row = {}
        for x = 1, mapWidth do
            row[x] = map[y][x] > 0 and tostring(map[y][x]) or "."
        end
        table.insert(result, table.concat(row))
    end

    return table.concat(result, "\n")
end

I didn’t have any idea what the eventual tree would look like, so I didn’t really want to try writing code to detect shapes in guard positions. Luckily, I still had my abandoned Love2D implementation, which I could start up and just watch for patterns.

I soon noticed that the guards would periodically swarm to the vertical or horizontal center line of the map. As these lines were left out of the safety factor calculation, this meant that such a swarm would have to coincide with a low safety factor. Also it would make sense for the Christmas tree to appear in the middle of the map.

Initially, I tried looking for the lowest possible safety factor in a hundred, then one thousand, then ten thousand seconds. Although I could lie to myself that some of these outputs looked vaguely like Christmas trees, none were the correct answer. So I loosened my threshold a bit, and looked for outputs with safety factors lower than the first one I found, at the first second I’d noticed the middle convergence.

A few results down, I saw this, right in the centre of the map:

1111111111111111111111111111111
1.............................1
1.............................1
1.............................1
1.............................1
1..............1..............1
1.............111.............1
1............11111............1
1...........1111111...........1
1..........111111111..........1
1............11111............1
1...........1111111...........1
1..........111111111..........1
1.........11111111111.........1
1........1111111111111........1
1..........111111111..........1
1.........11111111111.........1
1........1111111111111........1
1.......111111111111111.......1
1......11111111111111111......1
1........1111111111111........1
1.......111111111111111.......1
1......11111111111111111......1
1.....1111111111111111111.....1
1....111111111111111111111....1
1.............111.............1
1.............111.............1
1.............111.............1
1.............................1
1.............................1
1.............................1
1.............................1
1111111111111111111111111111111

As we can see, none of the guards overlap in this pattern. That would probably also be a good heuristic for finding the Christmas tree, but I haven’t implemented it.

Full code for part 2 on GitHub.

After implementing some time manipulation functionality in my Love2D code, I managed to snap a screenshot of it as well.

Full code for Love2D version on GitHub.

Closing thoughts: I think if I could get used to 1-indexing, I’d probably prefer it to 0-indexing. Sacrilege, I know. Lua is a great little language and I’m glad I used this opportunity to get a bit more experience with it and learn about things like its pattern-matching functionality.

Love2D is great fun, and I’m glad that my failed Love2D implementation of the first part of the challenge turned out to be useful for the second part.

# Day 15: JavaScript & KaPlay

Challenge: figure out where a malfunctioning robot will push boxes in a warehouse.

The challenge here was to build a self-playing sokoban game, making it the challenge most perfectly suited so far to a gamedev framework.¹

Initially, I thought about using PuzzleScript, a gamedev tool with a terse, rule-based language explicitly geared to the creation of sokoban-alikes. Half of the logic for the first part of this challenge is already implemented in the sample game, in a single line of code:

[ > Player | Crate ] -> [ > Player | > Crate ]

Translation: if player steps towards a crate, move both the player and the crate. To complete the logic, we just need to make crates push each other, which we can do with another very simple rule:

[ > Crate | Crate ] -> [ > Crate | > Crate ]

However, getting a result out of a PuzzleScript game would require some external method of:

1. Moving the player according to a preset list of moves.
2. Calculating and adding the positions of all the crates together.

This seemed like a lot more trouble than it was worth, even in the context of this self-imposed challenge. So I opted instead to write my self-playing sokoban game in JavaScript, using KaPlay, a lightweight and intuitive gamedev library I have a bit of prior experience with. KaPlay also happens to have functionality for storing levels as ASCII grids, making it well suited to AoC.

After creating a new project, loading up some sprites and making a sample level using 16x16 grid spaces, to semi-accomodate the large challenge input, I got to work with my implementation. Initially, I wrote a bunch of code for predicting which object(s) the player would collide with when moving in some direction, converting between real positions and grid positions, but then I realised that at some point since I last used it, KaPlay had added the method level.getAt which did all of this for me. That allowed me to implemented the movement and crate-pushing code in a few recursive functions.

    // Base movement function
    const move = (obj, dir) => {
        if (dir.x == 1) obj.moveRight();
        if (dir.x == -1) obj.moveLeft();
        if (dir.y == 1) obj.moveDown();
        if (dir.y == -1) obj.moveUp();
    };

    // Crate movement
    const moveCrate = (crate, dir) => {
        const crateMoveTo = crate.tilePos.add(dir);
        const crateDisplaced = level.getAt(crateMoveTo)[0];
        // ^ multiple objects could occupy the same grid space
        // but that shouldn't happen in this game

        // Moving into empty space: success
        if (crateDisplaced === undefined) {
            move(crate, dir);
            return true;
        }

        // Moving into a wall: failure
        if (crateDisplaced.is("wall")) {
            return false;
        }

        // Moving into another crate: pass the buck
        if (crateDisplaced.is("crate")) {
            const nextCrate = crateDisplaced;
            if (moveCrate(nextCrate, dir)) {
                move(crate, dir);
                return true;
            }
            return false;
        }
    }

    // Player movement
    const movePlayer = (dir) => {
        const moveTo = player.tilePos.add(dir);
        const displaced = level.getAt(moveTo)[0];

        // Moving into empty space
        if (displaced === undefined) {
            move(player, dir);
            return;
        }

        // Moving into a wall, cancel movement
        if (displaced.is("wall")) {
            return;
        }

        // Moving into a crate, try to push the crate
        if (displaced.is("crate")) {
            const crate = displaced;
            if (!moveCrate(crate, dir)) {
                return;
            }
        }

        // If we haven't returned yet, we can move
        move(player, dir);
    };

For testing, and to make it a real game, I bound movement to the arrow keys. I then implemented autoplay in two ways. Press Space, and all moves will be processed at once, changing the map and producing the answer in the blink of an eye. Press Enter, and you can watch the robot go through the moves one at a time.

For the second part of the challenge, everything except the player/robot doubled in width, taking up two grid spaces. At this point, I regretted using GML back on day four, as GameMaker’s collision and grid functions are robust enough to handle this kind of thing with ease. Had I implemented part one in GameMaker, I would likely only have to have changed the width of the crates to get part two working as well.

However, I implemented it in KaPlay. And KaPlay’s level/tile system does not explicitly cater for double-wide objects. I would either have forgo a lot of the tile functionality or work with left and right crate halves, which would need to be manually kept together.

I chose to keep the very useful grid methods and represent each crate as left and right halves, which meant having to keep halves together. Due to the cascading push already implemented for the first part, horizontally pushing two separate crates positioned next to each other was functionally the same as pushing two linked crates. It was when crates had to be pushed vertically that I actually needed new code to keep halves together.

I tried a few different tweaks to my recursive code above, but couldn’t resolve this edge-case:

Annoyingly, this edge-case was not present in the example map, but did appear in my challenge input. All of the recursive methods I tried were just too eager to move boxes. I needed to change to something that would cancel the whole move as soon as one push failed.

So, taking a leaf from challenges 10 and 12, I rewrote the code to build up an array of things to move using a depth-first search.

    const movePlayer = (dir) => {
        const moveTo = player.tilePos.add(dir);
        let displaced = level.getAt(moveTo)[0];

        // empty space, go there
        if (displaced === undefined) {
            move(player, dir);
            return;
        }

        // wall, don't go there
        if (displaced.is("wall")) {
            return;
        }

        // not empty space or wall, must be a crate
        // let's build a stack of crates in our way
        let cratesToMove = new Set();
        let stack = [displaced];
        while(stack.length > 0) {
            let next = stack.pop();
            if (next) {
                if (next.is("wall")) return; // found a wall, cancel everything
                if (next.is("crate")) {
                    // add to crates to move
                    cratesToMove.add(next);
                    // add to displacement checking stack
                    stack.push(level.getAt(next.tilePos.add(dir))[0]);
                }
                if (dir.y != 0) { // special rules for vertical movement
                    // partner crate must also be able to move
                    if (next.is("left")) {
                        let partner = level.getAt(next.tilePos.add(vec2(1, 0)))[0]
                        cratesToMove.add(partner);
                        stack.push(level.getAt(partner.tilePos.add(dir))[0]);
                    }
                    if (next.is("right")) {
                        let partner = level.getAt(next.tilePos.add(vec2(-1, 0)))[0]
                        cratesToMove.add(partner);
                        stack.push(level.getAt(partner.tilePos.add(dir))[0]);
                    }
                }
            }
        }
        // move everything that needs to move
        for (const crate of cratesToMove) {
            move(crate, dir);
        }
        move(player, dir);
    };

What I’m happiest about with this code is that it works just as well for single and double-sized crates, and thus works as a solution for both parts of the challenge. It would also work on a map including a mix of single and double crates. To facilitate solving this part two, I added an upsize checkbox to the functionality that loads levels from files, and that’s all I needed.

Full code on GitHub

Closing thoughts: I have never been the biggest fan of JavaScript, but it’s one of those languages that you pretty much have no choice but to use in a lot of domains. As a result, I’m very comfortable with it, which has not been the case for most of what I’ve used for these challenges. KaPlay is a great little library and one I’d like to use for a proper game in the future.

As may be evident from the date of this compared to previous posts, I’ve slowed down with this project a little. Write-ups for the remaining ten days of AoC 2024 will be posted eventually, probably with some other posts in between. I feel like I played it quite safe with the language choices for this selection of challenges, so I’m looking forward to trying some weirder ones in the next post.

Reply via email

In the first part of this series, I starting writing solutions for the 2024 Advent of Code (AoC) challenges, each in a different language. To recap, Advent of Code is a yearly programming event. On each day of the advent leading up Christmas, a new challenge is released. Each challenge consists of a problem description and an input file. Challenges generally involve processing the input file to come up with a particular output, which serves as the solution. Each challenge consists of two parts, with the second part being revealed upon completion of the first. Both parts use the same input, which is slightly different for each participant.

Apart from the obvious goals of trying out new and different programming languages and revisiting old favourites, I’m also using this as a way to gauge how good AI (mostly Claude 3.5 Sonnet, running in Cursor) is at writing, explaining and refactoring code in different languages.

My single constraint was to use each language only once. See below for how I broke it.

# Day 6: Python & Inform 7

Challenge: count the locations a guard will visit on a map if he turns right at every obstacle.

As soon as I read this challenge, I regretted using Inform 7 for Day 1. As I noted then, Inform was not hugely suited for number crunching. However, something it is suited to is navigating grids! The problem immediately put me in mind of a maze of twisty little passages, all alike. And Inform even automatically records the number of rooms you visit!

The one problem would be generating the grid itself. As far as I’m aware, Inform 7 provides no method for programmatically creating rooms and the connections between them – you must manually specify each room and its connections, like this:

The Chamber is a room. The Chamber is north of the Hallway.

My input file for this challenge was a 129*129 map, and there was no way I was going to manually specify that many rooms. Thus I would need to generate the Inform code itself programmatically.

This dovetailed nicely with the problem of having already used Inform 7 once this advent. If I generated the Inform 7 code using Python, that would be sort of like using Python for this challenge, and I haven’t used Python yet. And as an added bonus/punishment, it would ensure I didn’t fallback to using Python in later, more difficult challenges.

I started with the Inform 7 code, which is very simple:

"Guard Gallivant Solution" by "David Yates"

Chapter 1 - Game Logic

Forward is a direction that varies. Forward is north. [i.e. var forward = north]

Patrolling is an action applying to nothing.

Understand "patrol" as patrolling.

Carry out patrolling:
	while the player is not in Endgame:
		try going forward. [move in the direction stored in forward]

Instead of going nowhere:
	now forward is right of forward; [i.e. forward = right_of(forward)]
	say "Turning right...";
	say "You have visited [number of visited rooms] rooms so far.";
	try going forward.

To decide what direction is right of (D - direction): [i.e. def right_of(D)]
	if D is north:
		decide on east; [i.e. return east]
	if D is east:
		decide on south;
	if D is south:
		decide on west;
	if D is west:
		decide on north.

Report going to Endgame:
    say "You have visited [number of visited rooms] rooms in total.";
    end the story.

Inform 7 is a rules-based language for building turn-based games. The code defines a bunch of rules (Instead of..., Report... and so), and every turn the engine evaluates and applies a subset of these rules. Rules can be generally applicable (Every turn) or highly specific (Instead of going from the ballroom when the player is Mr Mustard and has the candlestick). These rules are executed in a particular order, according to their placement in different rulebooks. Because the rule in Report going to Endgame is executed before the rule that marks Endgame as a visited room,¹ our room visited count will be accurate.

Instead of going nowhere is a rule that runs if the player tries to move in a direction that is not catered for. For example, if I’m in a room with other rooms to the south, east and west, and I try to go north, this rule will be triggered. Therefore, I just needed to create a game map in which rooms adjacent to obstacles did not have connections in that direction.

To solve the challenge, all the player would need to do is type patrol. Once I had the map generated, that is.

I generated the map by reading the file into a Numpy 2D array and then iterating over it. For the starting space and opening spaces on the map, I created rooms. Upon the creation of each room, I checked the cardinal directions from that room and created connections to surrounding open spaces. For rooms on edges of the map, I created connections to a special room, Endgame, which would signify the end of the patrol. For obstacles, I left a comment without creating a room or any connections.

print("INFORM CODE ABOVE")
print("""
Chapter 2 - The Map

Endgame is a room.
"""

import numpy as np

# create grid
grid = np.array([list(line.strip()) for line in open("small.txt")])

# generate I7 code
room_name = lambda y, x: f"P{y}-{x}"
for y, row in enumerate(grid):
    for x, cell in enumerate(row):
        # skip obstacle
        if cell not in '.^':
            continue

        # create room
        this_room = room_name(y, x)
        print(f"{this_room} is a room.")

        # create room connections
        for d, ay, ax in [("west", y, x-1), ("east", y, x+1), ("north", y-1, x), ("south", y+1, x)]:
            if not (0 <= ay < grid.shape[0] and 0 <= ax < grid.shape[1]): # out of bounds
                print(f"Endgame is {d} of {this_room}.")
            elif grid[ay, ax] in '.^': # in bounds and not an obstacle
                print(f"{room_name(ay, ax)} is {d} of {this_room}.")

        # create starting room
        if cell == '^':
            print(f"""
When play begins:
\tnow the player is in {this_room}.""")

The most annoying thing about printing the Inform code from Python, is that both languages have meaningful indentation, but Inform 7 insists that you use tabs and Python prefers spaces. I also might have simplified the code with more strategic room creation – Inform 7 doesn’t strictly require rooms to be declared with X is a room if there’s already a line that says X is [direction] of [existing room].

With my input file, this script produced ~78k lines of Inform code. Unfortunately, when I pasted it into a new project in the Inform 7 IDE, it refused to compile.

Some experimentation and a couple of questions on forums later, I figured out that I could get the code to compile from the command line by passing -no-index to the compiler, which prevented it from trying to generate such things as a world map for the IDE’s internal Index pane.

The Inform 7 compiler produces a source file in Inform 6, which must then be run through the Inform 6 compiler to produce a playable game file for the chosen virtual machine. I wrote a script to go from Python to Inform 7 to Inform 6 to the Glulx format.² From there, I started up the packaged game file in glulxe-term and typed patrol to get my answer. The code for this ran much faster than the code for my Day 1 solution.

Full code for part 1 on GitHub.

The second part of the challenge was to figure out how many different positions a single extra obstacle could be placed in to make the guard move in a loop. The approach to this that seemed obvious to me was this:

1. Run through the map once to build a set of the rooms visited.
2. Restart, run through again with the first room in the set blocked off.
3. Continue until we reach the edge of the map or encounter a loop.
4. Restart and run through again with the next room blocked off.
5. Repeat until we’ve tested blocking every room.

I think this is possible to do in Inform, but I’m not sure how. It would almost certainly be possible to do in Inform 6, a more standard language, though I rather feel that would defeat the point of the challenge. After experiencing repeated freeze-ups and crashes with my attempt at a solution for the sample input, I decided to shelve this one. I’ve uploaded my attempt here.

A pure Python solution is technically in line with the constraint I’ve set for myself, though not quite in the spirit of it (worse than using Inform 6? I’m not sure). With a heavy heart, I wrote the code to solving the second part in Python.

import numpy as np

def patrol(grid, loops=False):
    directions = [(-1, 0), (0, 1), (1, 0), (0, -1)]  # up, right, down, left
    in_bounds = lambda y, x: 0 <= y < len(grid) and 0 <= x < len(grid[0])

    y, x = np.where(grid == '^')[0][0], np.where(grid == '^')[1][0]
    visited = set()
    visited.add((y, x))
    direction = 0
    loop = False

    while in_bounds(y, x):
        my, mx = y + directions[direction][0], x + directions[direction][1]

        if not in_bounds(my, mx):
            break # we've left the map
        if grid[my, mx] == '#':
            direction = (direction + 1) % 4 # hit an obstacle, turn right
            continue

        y, x = my, mx # move

        # Record visited
        current = (y, x, direction) if loops else (y, x)
        if loops and current in visited:
            return (visited, True)

        visited.add(current)

    return (visited, loop) if loops else visited

grid = np.array([list(line.strip()) for line in open("input.txt")])

# Part 1
visited = patrol(grid)
print(len(visited))

# Part 2
loops = 0
for y, x in visited:
    if grid[y, x] == '^':
        continue # can't put an obstacle where the guard is
    grid[y, x] = '#' # new obstacle
    _, loop = patrol(grid, True)
    grid[y, x] = '.' # reset
    loops += 1 if loop else 0

print(loops)

Full code for part 2 on GitHub.

Closing thoughts: I remain very happy with the elegance of my Inform solution for part 1. The main difficulties it presented were in getting it to compile with the full input, not writing the code itself. Attempting and ultimately failing to complete part 2 in Inform was, out of all challenges so far, the one that took me the most time. I still think it’s possible, at least for very small maps, but I don’t quite understand the language or its environment well enough to make it work.

Claude 3.5 Sonnet surprised me with its competence at writing Inform for this challenge, though its contributions ultimately came to nothing. It still made some mistakes, but probably the same ones a human would. Inform might look like natural language, but entry number in my list is valid code and the number entry in my list is a syntax error.

# Day 7: Racket

Challenge: find valid operators for incomplete equations.

I’ve wanted to learn and use Lisp ever since I first read Paul Graham’s famous essay on the language. Over the years, I’ve occasionally toyed with Scheme, Clojure, Racket and Elisp, but I still have yet to do substantial original programming in any of them. So of course this exercise seemed like a good excuse to return to my favourite of the Lisps I’ve tried, Racket.

We begin, as always, by reading and parsing the input file:

#lang racket

; Load the input file
(define filename "input.txt")
(define file (open-input-file filename))
(define input-str (read-string (file-size filename) file))
(close-input-port file)

; Parsing function
(define (parse-input input-str)
  (let ([parse-line (lambda (line) ; Racket lets you use (), [] and {} interchangeably
          (map string->number (string-split (string-replace line ":" ""))))])
    (map parse-line
         (string-split input-str "\n"))))

; Parse the file contents
(define equations (parse-input input-str))

The lines of the file are in the form 190: 10 19, where the first number is the answer you need to find by inserting + or * operators between the rest. Like most functional languages, Racket has the concept of the head and tail of a list, i.e. the first element and the rest of the list.³ As the answer will always be the first element, I’m just stripping out the : and parsing every line into a simple list. So equations will be a list of lists.

To solve this, we’ll invoke a function that takes this list of lists and a list of valid operators. This function will find and apply all possible combinations of the operators to each list. The answers belonging to lists with at least one valid combination will then be summed.

(sum-calibration-equations equations '(+ *))
; the ' makes the operators an inert list rather than an instruction to be executed

But before we actually define sum-calibration-equations, we’re going to need some helper functions. First, apply-op, which we’ll use to apply an operator from our list to two numbers.

(define (apply-op op a b)
  (case op
    ['+ (+ a b)]
    ['* (* a b)]))

Next, a function to generate all possible combinations of length n:

; Recursively generate all possible operator combinations for n numbers
(define (generate-operator-combinations n operators)
  (if (= n 1)
      '(())  ; base case: no operators needed for 1 number
      (for*/list ([ops (generate-operator-combinations (- n 1) operators)] ; outer loop
                  [new-op operators]) ; inner loop
        (append ops (list new-op)))))

for*/list is a way to create a nested for-loop with a single function. The one above is equivalent to the following:

(for/list ([ops (generate-operator-combinations (- n 1) operators)])
    (for/list [new-op operators]
        (append ops (list new-op)))
)

Nested for loops are the hammer I use to solve all of these challenges, so I thought this was really cool.

The last helper function we need is try-combination, which will return the result from trying a list of operators on a list of numbers. Per the instructions, equations must be evaluated left to right.

(define (try-combination ns ops)
  (let loop ([result (first ns)] ; Start with first number
             [rest-nums (rest ns)] ; Rest of the numbers
             [rest-ops ops]) ; All operators
    (if (null? rest-nums)
        ; If there are no more numbers, return the result
        result 
        ; Otherwise apply operator to result & next number
        (loop (apply-op (first rest-ops) 
                       result
                       (first rest-nums))
              (rest rest-nums) ; Continue with remaining numbers
              (rest rest-ops))))) ; Continue with remaining operators

The let here defines a function named loop and immediately calls it with some initial values (so [ result (first ns)] means [parameter-name initial-argument]). It then recursively works down the numbers and operators, accumulating the final result.

Now we can define sum-calibration-equations:

(define (sum-calibration-equations input operators)
  (for*/sum ([calibration-equation input])
    (for/fold ([result 0]) ; assume result is 0, i.e. no valid combo
              ([combo (generate-operator-combinations
                     (- (length calibration-equation) 1) ; 1 fewer op than we have numbers
                     operators)])
    #:break (not (zero? result)) ; break when we find a non-zero result
    (if (= (first calibration-equation)
           (try-combination (rest calibration-equation) combo))
        ; ^ first and rest used to get answer and equation
        (first calibration-equation) ; found a valid answer, return it
        result))))

With Racket, I find myself writing code from the inside out. The core of this function is the if statement, which checks if a particular operator combo produces a valid result for a particular equation. I initially wrapped that in a for*/list, but that gave me every valid result when I only needed one per equation. So the AI suggested I replace it with a for/fold that uses this funky syntax to break. for/fold works a bit like let above.

Finally, I wrapped the for/fold that produced the answers for valid equations in a for/sum to add them all together and get the challenge solution.

I had an inkling that the second part of the challenge would involve additional operators and wrote my code with that assumption. I was correct – part 2 requires you to add the || or concatenation operator, which works like this:

123 || 456
=> 123456

To support this, we just have to add a third option to apply-op:

(define (apply-op op a b)
  (case op
    ['+ (+ a b)]
    ['* (* a b)]
    ['|| (string->number ; Convert numbers to strings, concat, convert back 
          (string-append 
            (number->string a)
            (number->string b)))]))

Then we can call sum-calibration-equations again with our new operator:

(sum-calibration-equations equations '(+ * ||))

Full code on GitHub.

Closing thoughts: I feel like I’m starting to see the much-vaunted power of Lisp through things like for*/list and let – these feel like programming idioms at such a high level that I hadn’t even considered them idioms before. At a few points, I was tempted to mush more of my code together with local function definitions, but that quickly becomes the kind of mess of brackets that makes people complain about Lisp.

This problem was not complex enough to require any of Lisp’s storied meta-programming, but I do feel as though a bit of the spirit of that came through in apply-op. It was immensely satisfying to complete part 2 with such a small change.

I had a bit of help from AI here, but not as much as I thought I’d need. Mostly I had Claude explain different functions to me – he it is pretty good at Racket.

# Day 8: Io

Challenge: map out the antinodes for pairs of antennas.

Io is another language I discovered through Seven Programming Languages in Seven Weeks. It’s a prototype-based language, like JavaScript. Unlike JavaScript, it commits to the prototype thing, implements it well, and doesn’t have any Java-style class syntax to hide it from you. As with Ruby, everything in Io is an object, even numbers. Method invocation (technically message-passing) is so central to the language that it’s automatically invoked when two items are placed side-by-side. For example:

"Hello world" println
==> Hello world

Chaining calls is simple:

"Hello world" exSlice(6)
==> world
"Hello world" exSlice(6) size
==> 5
"Hello world" exSlice(6) size sqrt
==> 2.2360679774997898

Io has very minimal syntax and implements everything with this kind of message passing. For example, if-else control flow can look like this:

(x == 3) ifTrue("Yes" println) ifFalse("No" println)

On the surface, working with operators (a := 1, 1 + 2, 5 - 4, 10 > 1, etc) appears to be an exception, but the operators themselves are only a thin layer of syntactic sugar over message passing. 1 + 2 sends the + message to 1 with 2 as an argument i.e. 1 +(2), and := wraps a setter method. Io even lets you define your own operators by adding them to the OperatorTable (which is used to determine precedence). Hmm…

This is another 2D grid challenge, so a bounds-checking operator could be quite useful. Let’s create one:

// Bounds-checking operator
OperatorTable addOperator("<>", 5)
// ^ put it in position 5 in the table so it will be
// evaluated with other comparison operators

Number <> := method(bound, (self >= 0 and self < bound))

Now we can use a <> b to check if a is less than b and non-negative. Because of how Io compiles code, this needs to go in a separate file from the implementation.

doFile("operators.io")
doFile("antinodes.io")

In antinodes.io, we’ll start by reading in the input file:

inputFile := File with("input.txt")
inputFile open
inputText := inputFile readToEnd
inputFile close

We then need to find all the antennas.

findAntennas := method(input,
    antennas := List clone
    input split("\n") foreach(y, line, # foreach provides an index and item
        line foreach(x, cell, // Python- and C-style comments are both valid
            if(cell asCharacter != ".", // without asCharacter we'd get 46
                antennas append(List clone append (x, y, cell))
            )
        )
    )
    antennas
)

As Io is a prototype language, we create new objects by cloning an existing one, usually a base object. List clone creates a new empty list, and List clone append(1, 2, 3) creates a new list containing (1, 2, 3).

Now we can calculate the positions of the antinodes. I found the challenge description a bit confusing, but the diagrams showed that each antinode should be as far from its antenna as it is from the other antenna, but in the other direction. Maybe there’s no way to explain that nicely in words.

calculateAntinodes := method(antennas, mapWidth, mapHeight,
    antinodes := List clone

    isValidPosition := method(x, y, width, height,
        x <> width and y <> height
    )

    addAntinodeIfValid := method(x, y, width, height,
        if(isValidPosition(x, y, width, height),
            antinode := List clone append(x, y)
            if(antinodes detect(n, n == antinode) == nil,
                antinodes append(antinode)
            )
        )
    )

    processAntinodePairs := method(a, b, width, height,
        x1 := a at(0); y1 := a at(1)
        x2 := b at(0); y2 := b at(1)
        dx := x2 - x1; dy := y2 - y1

        addAntinodeIfValid(x1 - dx, y1 - dy, width, height)
        addAntinodeIfValid(x2 + dx, y2 + dy, width, height)
    )

    antennas foreach(i, a,
        antennas foreach(j, b,
            if(a != b and a at(2) == b at(2),
                processAntinodePairs(a, b, mapWidth, mapHeight)
            )
        )
    )

    antinodes
)

Finally, we put it all together with this:

inputFile := File with("input.txt")
inputFile open
inputText := inputFile readToEnd
inputFile close

antennas := findAntennas(inputText)
mapWidth := inputText split("\n") at(0) size
mapHeight := inputText split("\n") size

calculateAntinodes(antennas, mapWidth, mapHeight) size println

For the second part of the challenge, we need to get antinodes at any (map-bound) distance from their antennas, as well as antinodes on the antennas themselves. This can be integrated into calculateAntinodes with an extra parameter:

calculateAntinodes := method(antennas, mapWidth, mapHeight, partTwo,
    antinodes := List clone

    isValidPosition := method(x, y, width, height,
        x <> width and y <> height
    )

    addAntinodeIfValid := method(x, y, width, height,
        if(isValidPosition(x, y, width, height),
            antinode := List clone append(x, y)
            if(antinodes detect(n, n == antinode) == nil,
                antinodes append(antinode)
            )
        )
    )

    processAntinodePairs := method(a, b, width, height,
        x1 := a at(0); y1 := a at(1)
        x2 := b at(0); y2 := b at(1)
        dx := x2 - x1; dy := y2 - y1

        if(partTwo,
            # Part 2: Add antennas as antinodes and calculate full path
            addAntinodeIfValid(x1, y1, width, height)
            addAntinodeIfValid(x2, y2, width, height)

            # Find antinodes in both directions
            pos := list(x1, y1)
            while(isValidPosition(pos at(0) - dx, pos at(1) - dy, width, height),
                pos = list(pos at(0) - dx, pos at(1) - dy)
                addAntinodeIfValid(pos at(0), pos at(1), width, height)
            )

            pos = list(x2, y2)
            while(isValidPosition(pos at(0) + dx, pos at(1) + dy, width, height),
                pos = list(pos at(0) + dx, pos at(1) + dy)
                addAntinodeIfValid(pos at(0), pos at(1), width, height)
            )
            ,
            # Part 1: Only check one point in each direction
            addAntinodeIfValid(x1 - dx, y1 - dy, width, height)
            addAntinodeIfValid(x2 + dx, y2 + dy, width, height)
        )
    )

    antennas foreach(i, a,
        antennas foreach(j, b,
            if(a != b and a at(2) == b at(2),
                processAntinodePairs(a, b, mapWidth, mapHeight)
            )
        )
    )

    antinodes
)

Full code on GitHub.

Closing thoughts: Io code looks a little strange at first, but once you get into it it doesn’t feel too different from any other high-level imperative language. I’m glad I used it right after Racket, because the languages have some interesting similarities and contrasts. Io is about as syntactically minimal as Lisp, but it’s much easier to read for two reasons:

1. Logic flows left to right.
2. Function execution is signalled by white space rather than brackets ("Hello world" println vs (display "Hello world")).

Fittingly, Io has similarly powerful reflection and metaprogramming abilities, which I didn’t really need for this simple challenge. I also made no use of its concurrency features or even custom objects, but I’m glad I found a use for OperatorTable.

Claude surprised me with its familiarity with this relatively obscure language, though I didn’t use it much besides having it do some refactoring. The official Io tutorial, which is more of a cheatsheet, was also very helpful.

# Day 9: J

Challenge: pack items from the right side of a list into empty spaces on the left.

For this challenge, I chose J, a language I’ve been intrigued by since reading about it on James Hague’s Programming in the 21st Century blog. It’s a very terse language capable of producing programs that look like a jumbled mess of characters, and so fairly intimidating at first glance.

J is an array programming language, in the lineage of APL. Unlike APL, it does not require a special keyboard to program in, as it only uses ASCII characters. An array programming language felt like a good choice for this challenge, as the input is a single very long list.

As the J Primer will tell you, users of J prefer to use natural language terminology when talking about elements of J. Sentences (statements) are made up of words, some of which are verbs (functions), others of which are nouns (variables/literals) and still others of which are adverbs or even copulas.

Despite all this talk of words, most of J’s syntax consists of symbols. There are single symbols, such as {, +, # and %, all of which do slightly different things than you might expect from other languages. Then there are words made out of groups of symbols, like |. <" and ~:. Occasionally you get single letters followed by dots: I. and E.. The things that look most like words, for. and if. and break., are not nouns or verbs, but control structures.

Each verb can have two forms: monadic and dyadic. The first takes one argument and the second takes two. These forms tend to do related but different things. For example, the monadic # a will count the values in a, and the dyadic 3 # a will create three copies of a.

This may start to make more sense as we get to some actual code. So let’s read the input file:

input =: fread 'input.txt' NB. read file
ints =: ". each input NB. convert each character to a number