Anna Liberty

Friction is an Anti-Feature

2026-07-07T00:00:00+00:00

Writing is hard. I want to express my thoughts in a way that is helpful for other people, but also makes me proud. I want to be correct. I want to be informed. I don't want my writing to contain blatant errors caused by poor editing.

This pressure adds inherent friction. So I reduce that friction. I write in Markdown, which is comfortable for me. I use a simple static site generator that gets out of my way. I push updates directly a repository which is built and published automatically. This is complicated for some people, but is comfortable for me.

I think others are in a similar place. While some people are comfortable throwing their words out there, others are concerned about their thoughts being perfect. More friction is the last thing we need.

For Philip, adding friction brings him to balance. For me, reducing it does.

LLM Statement

2026-06-30T00:00:00+00:00

I do not use LLMs or other "Generative AI" for prose or code, nor do I accept it from others as open source contributions.
I do not discuss my prose or code with LLMs.
I do not consult LLMs for projects, contributions, assignments, research, or anything else.
As far as possible and practicable, I have disabled LLM-integration in my tools and replaced tools that don't let me do so.
Requests for me to use LLMs or read content generated by LLMs will be met with disappointment and gentle refusal.
I want to use my skills and engage with other people in the process.

For programming, I write code myself, or generate it deterministically from higher-level instructions.
For writing, I use my brain and write it myself, revising it as needed.
For proofreading, I ask my friends.
For searching, I use domain-specific search tools and specific websites.
For learning, I seek out books, tutorials, and other educational material made by people.
For extra support, I ask experts in forums, chatrooms, or via email.

CC0</a>: This work has been marked as dedicated to the public domain.

Ambiguity in Natural Programming

2026-06-27T00:00:00+00:00

I am once again thinking about programming in natural language.
For most programming languages, you can parse them according to strict grammars that eliminate their ambiguity. These can get ugly, especially for languages like C++ where one symbol can mean many different things depending on its context, but the code is, in theory, able to be parsed.
One of the biggest barriers for programming in natural languages, however, are their inherent ambiguity. Natural languages were optimized for efficiency and convenience in communicating between people. They were not designed for clearly communicating with machines.
This means that computer programs that try to understand natural language must do so stochastically. It is likely that the text means this. It is possible that a text means that. It's impossible to work with certainty, even if we had a language model with perfect knowledge of a language and the surrounding cultures.
One answer is to embrace the probabilistic nature of language and use Large Language Models (LLMs) for natural language programming. After all, they can already write code that seems statistically likely based on natural language prompts. This approach embraces the chaos.
The other answer is to describe a strict subset of a language and use that. Instead of trying to let the computer understand the entirety of what a user is saying, make the user explain it in language the computer will understand. This is still a computer language, but something more like the user's native language. This approach clings to rigidity.
Neither of these options are ideal, in my opinion. LLMs require a large amount of resources to use, shackling access to natural language programming to those who can pay to rent from large corporations or can afford an expensive GPU while costs are rising. Another computer language might ease new programmers into the concepts of programming, but they are still forced to describe their problems in a rigid language that punishes straying from its parser.
I'd like to propose a combination of the two. A language model that parses natural language but checks back in with the user to see if it has understood. This can be done by converting high-ambiguity sentences to low-ambiguity ones when appropriate and storing the latter as source. When the interpretation program is confused, it can check back in with the user to ask what they meant.
There are a few important differences between this and programming with an LLM. First, the source is unambiguous natural language, not prompts. This means we can retain deterministic pipelines and reproducible builds. Second, the language model needs to parse, not generate. This should mean that we can use models that are less expensive to run, opening it up to be used more wildly.
The goal is understandability</a>. A system that produces consistent output based on given input is more understandable than one that doesn't.
In summary, there would be three main layers:

Natural language (parsed by a language model)</li>
Computer language (subset of a natural language)</li>
Language-agnostic IR</li> </ul>
The computer language is still considered the "source code". It is a common-ground understanding between both the user and the machine. It is expected that such a programming environment convert between the natural language to the computer language live to provide immediate feedback.
Once this is done, the computer language can be compiled into a language-agnostic IR that can then be compiled or interpreted. I say language-agnostic because the top-level natural language should be any language the user desires.
I haven't made a proof of concept yet, because this is outside of the realm of my current expertise. The current state of Natural Language Processing (NLP) is focused on LLMs and generating text, not interpreting it. I don't know if there are robust solutions for machines to understand human text beyond simply transforming it directly.
If anyone reading this has any suggestions or knows of any existing research in this area, please contact me! I'd love to hear your thoughts.

Returning to Zig

2026-06-10T00:00:00+00:00

Zig is rising in popularity. It hasn't yet seized the space occupied by even Rust or Go, much less C, but it has been adopted by a few major projects and countless smaller ones. As such, it's becoming an important language for the future. having been interested in Zig for several years, I decided to check back in on the language and see how I feel about it today.

A Pragmatic Approach to LLMs

2026-06-08T00:00:00+00:00

I don't vibecode. I don't use LLMs willingly. Every line of code I write is my own or generated deterministically through a process I fully understand. Considering the world is divided over LLMs these days, I wanted to share my particular perspective on why I chose the path I have, as well as some of the places I do think LLMs are appropriate.

Ditch LinkedIn. Make a Website

2026-06-05T00:00:00+00:00

I have never been an active user of LinkedIn. I created an account a couple of months ago after a professor told me I should have a presence there. I was skeptical, but decided it was important enough to have access to any opportunities and connections I would have otherwise be missing.
I no longer have access to my account. I recently tried to log in and was met with a friendly greeting.

Scheme is a Hoot

2026-05-21T00:00:00+00:00

Lately I've been spending time learning Scheme and using it to implement the concepts I'm learning in my physics classes as time permits. One of the most exciting things I've been doing with this is getting my Scheme to compile to the Web thanks to Hoot.
One of the biggest challenges has been the fact that Hoot is unstable. It's currently at version 0.9.0. The documentation is decent, but it could be better. The error messages can be cryptic. But it's a massive accomplishment to see Scheme code running on the Web via WASM. It's even more incredible to know that it's running on a stack the team created themselves, not relying on Emscripten.
My initial understanding of Hoot was that it could compile any Guile program to the Web. I quickly learned that I was mistaken when my code wouldn't compile. I then ported my code to use the Hoot versions of all of the functions, causing my code to be unable to run independently from Hoot. I then realized that Hoot actually supported more of Guile than I thought. I just had to manually import a lot of the stuff I previously took for granted.
Now I have set up my code to run on native Guile and on WASM via Hoot, with tests automatically running in both to make sure everything's set up correctly for both environments. It's a bit of a pain, but it works now. Most of my code is agnostic to whether it's running with the system's Guile interpreter or if it's been compiled to WASM and being run in the browser. I think that's amazing.
Currently, most of the work I've done has been on the backend. Working on getting this whole setup to work at all has been a hassle. I've also been working on getting the more fundamental physics logic working, which is especially difficult as a someone new to Scheme. But I've been making progress, and I've published a small prototype on a new page on my website</a> and have published the source code</a>.
In the future I'm curious to see if it's reasonable to compile Zig + Scheme programs to the Web with Hoot. I'm starting to feel more and more that Zig + Scheme is the perfect combination and I want to do more experimentation in that direction. That may be too complicated! I don't know yet. There's a lot for me to learn in the WASM world, and that's a large part of the fun.
This has been an insightful exploration into the depths of Scheme. I can't wait to do even more.

Is it time to use Zig?

2026-04-16T00:00:00+00:00

Is it time for me to finally start writing Zig? I used to use it (and make minor contributions) years ago but got demoralized by constantly rewriting my code with updates.
But it seems like a solid language and one that will only increase in prevalence in the coming years.

Teaching Kids Forth

2026-04-14T00:00:00+00:00

Forth is uncommonly used to teach programming to kids. Scripting languages like Python and visual environments like Scratch are far more popular options. But when I got the opportunity to introduce middle and high school students to programming, I chose the stack-oriented concatenative language from 1970.
I was ecstatic about this opportunity. I'm passionate about giving people just a bit more control over the potential locked up in the devices they carry with them every day. When people know more about computers in general and about making their own software in particular, whole worlds open up. This gave me the chance to pry the door to that world open for people who likely would have never discovered it otherwise.

Learning Special Relativity

2026-04-13T00:00:00+00:00

The number of ah-ha! moments I've had when learning about special relativity is incredible (at the cost of the constant pain of "how on earth is this possible").
I knew how to do Lorentz transformations before and even wrote some code to represent them, but now I'm finally building an intuition for special relativity instead of primarily relying on the equations.
Can't wait for general relativity to mess it up once again!

Towards Understandable Software

2026-03-07T00:00:00+00:00

Programming sucks. Code sucks. It's hard to read, hard to test, and hard to maintain. Only a handful of people can understand any particular software project. These are major problems. I'm here to explain how we can fix them.