on breakpoint

Writing Code vs. Writing Prose

Thu, 02 Oct 2025 00:00:00 +0000

Writing Code vs. Writing Prose

Programming languages were developed because natural language isn’t adequate to communicate instructions to computers. Unlike natural language, programming languages have strong composability: you can take a line of code and start putting things into it or removing things from it to drastically change its meaning. Doing that with natural language is also possible, but not the extent that it is with a programming language. With code, operations can be stacked, complex behavior (which would take dozens of sentences to explain properly in natural language) can be represented with a couple of lines of code, and special notation/syntax is developed to aid readability.

Because code is so malleable, you can take a poorly-written codebase and improve it little by little, incrementally, until you’re left with something which is pretty decent. You can’t really do the same with prose. You can make slight adjustments, but you can’t convert a terrible book into a great one by revising it repeatedly. Sometimes the whole point of good prose is to have good flow and that flow is often ruined by heavy editing.

Code differs from natural language in that code is used to control a computer. Natural language is used to communicate to another human. Thinking in a language that’s been designed to control computers isn’t natural for the human brain, that’s why programmers use tight feedback loops and iterative improvement to get things right. Thinking in natural language is (hopefully) natural for humans, that’s why converting your stream of thought directly into words, without too much alteration, leads to beautiful prose. To communicate effectively you need a sense of flow and emotional sensitivity that you just can’t improve by increasing the number of iterations.

Another difference is that, with software, you have proxies for measuring how well you’re doing. For a functional requirement (like adding a new feature, e.g.), you usually have a clear indicator of success: the feature either works or it doesn’t. For a non-functional requirement, you have benchmarks you can run to test resource usage, latency, frames per second, or some other metrics that you might find relevant. Writers don’t have such proxies. There’s no definitive way of knowing if your writing will resonate with anyone out there.

As a writer, you take pride in your style and ability to challenge convention. And while programmers can develop taste and personal style, that’s not exactly a hard requirement for writing good code.

Just like there are different kinds of writing, there are also different kinds of programming. But, what often ends up happening is that organizations tend to want to unify these differences so they don’t rely on certain programmers if they ever decide to leave. During review, code is often analyzed and systemically checked against a set of conventions: a colleague can tell you exactly what you need to do improve your code with regards to what’s considered good code within that organization. On the other hand, an editor can give you pointers, but they won’t be able to write for you and, with the exception of straightforward mistakes, they won’t be able to provide definitive suggestions.

There are similarities, of course. One thing that code- and prose-writing have in common is that both activities can be used as a means of exploration, not just as means to an end. Writers often write to organize their ideas and perhaps generate new ideas in the process of writing, because the act of putting thoughts into words acts a useful test for assessing one’s understating of the topic at hand. Programmers often write throwaway code to test out certain assumptions before investing weeks of work with a specific approach.

I’ve been thinking about these differences lately because I’ve noticed that I have a tendency to treat my prose like code. When I write a blog article, I always think that I can improve it on the next sitting. I think of drafts as unfinished projects that can always be tweaked. But, what I’ve found is that if I come up with something that just isn’t good enough, no amount of tweaking will do the job. At that point, starting from scratch and rethinking the entire thing is usually the right thing to do.

Ideas for Tooling in Education

Sat, 28 Jun 2025 00:00:00 +0000

Ideas for Tooling in Education

I’ve found that some of the most useful writing on AI is that of the kind that goes “Here’s how I use AI/LLMs/ChatGPT as an X” where X is usually a programmer or a researcher of some kind. Simon Willison, for example, has a series called How I use LLMs and ChatGPT that gives you a decent picture of where AI is actually useful, instead of having to take someone’s word for it.

Most of my AI use revolves around learning. Ever since these models started getting better at reasoning and finding references, I’ve noticed that I tend to keep a tab open with a chatbot in it as I’m ingesting new information. New tools for education seem to always be either overly-hyped by early adopters or underappreciated by sceptics. I think that’s a testament to how hard learning is: most new technology is usually effective at getting learners excited/motivated to learn more about something, but traditional tools – like just reading a book, for example – are still the most effective ways to internalize new information.

Why Learning is Hard

One of the reasons why teaching – and presenting information in general – is hard is that you’re often presenting information to different kinds of people with different backgrounds, different amounts of context, and with varying levels of intelligence and comprehension. As an educator, you’re often explaining at a pace that is too slow for some, and too fast for others. At other times, you’re presenting information that is too deep for those who only want a shallow understanding of the topic, or too brief for those who want to know the details.

This issue of pace is certainly more common in lectures and video materials than in text (i.e., textbooks, lecture notes, papers). Text allows the reader to consume the information at their own pace. So, someone who has plenty of context regarding the material at hand might just skim through the text. Whereas, someone who hasn’t been familiarized with the terminology yet, or hasn’t gone through the necessary prerequisites to understand the material at hand, can read through the text more slowly, possibly rereading multiple times.

The problem with traditional text formats regarding the former case is that the learner still has to spend energy and time skimming through the text – even if very little to no information is being retrieved. In the process, the learner could miss important information that they would have wanted to pay attention to otherwise. Skimming could also make the reader feel disengaged or bored.

The problem with the latter case (i.e., slowing down the pace or rereading when something is too challenging) is that it doesn’t always work. The alternatives in this case often are: (1) reading something that’s adjacent to what we’re trying to learn, (2) reading a textbook on the same topic that’s less technical or easier to approach for our current level of understanding, (3) working through exercises, or (4) changing the learning medium (e.g., going from text to video). After going through some of these options, one could go back to tackling the topic at hand more prepared than before.

LLMs offer something that’s pretty tangible when it comes to solving this issue of pace and verbosity in learning. The ability to go through some text, find something you don’t quite understand, and then have the LLM explain that for you is not only useful in the sense that you get more information, but it also means that you now have a knob to control how much time and energy you want to invest in one topic. You control the depth, verbosity, language, examples, and tone used to explain a topic.

Knobs for verbosity and depth

Future tools that aim to utilize AI for learning should try to offer high granularity when it comes to controlling these knobs. With just these two variables – verbosity and depth – you get to generate four kinds of text:

Low verbosity, low depth. A quick and non-detailed explanation of something. Useful for those who don’t want to invest a lot of time on the topic and don’t care about the details.
Low verbosity, high depth. A concise explanation of something. Useful for those that already have plenty of context about the topic at hand and prefer to get a compact explanation. Examples of this type of text would include research papers, mathematical proofs, definitions that rely on specific notation or symbolic language, and algorithms explain through pseudocode.
High verbosity, low depth. A wordy explanation of something that’s not packed with insightful information. Useful for those who want a gentle introduction to a topic, or for those who just enjoy reading. Examples could include self-help books, the For Dummies reference books, and introductory articles.
High verbosity, high depth. Lengthy explanation of something that’s complex. Textbooks could be a good example of this category.

LLMs with high context windows have already gotten better at ingesting large amount of information and summarizing it into fewer paragraphs [0]. Similarly, extracting more information from tightly-packed sentences works pretty well too. You do this by picking a sentence that’s too dense – or assumes prior knowledge which you don’t have – and then feeding it to an LLM to slowly build up understanding, validating your understanding incrementally by asking questions and having the LLM prompt you for answers.

Personalized learning

Controlling verbosity and depth is already a form of personalized learning because you get to choose the material which is attuned towards your intended time-investment and effort. But, LLMs can still do better at personalizing the learning experience by allowing you to generate material that’s suited to your current level of understanding, learning style, and background.

You can decide if, instead of using fictional or over-simplified “textbook examples,” you want to read about actual real-world applications of the thing you’re reading – or you can do the opposite: you may decide that you don’t want to get bogged down into the implementation details of something and ask for a simplified example, instead.

You could use your current knowledge and prompt the LLM to find differences between the information you currently have and the one you want to obtain. (This is why books like “Java for C++ programmers” exist, for example.) This makes it easier to form new connections, increasing the likelihood that you remember the information at hand.

You can test your current understanding by posing a question which would showcase whether your mental model is accurate. There’s no societal pressure about being wrong. If your current understanding is incorrect, you get to test it before building on top of a flawed mental model.

You should also be able to control the kinds of sources the LLM should ingest information from. Filtering sources that you don’t find to be trustworthy.

You can go from not understanding a sentence to gathering information incrementally by alternating between the levels of depth to adapt to the level of effort that you’re willing to put in to internalize that information.

This closely resembles having a personal tutor. You get many of the benefits of having a real tutor (see Bloom’s 2 sigma problem), but this one has more energy and patience and won’t judge you like a normal tutor would. The downside being that LLMs cannot replicate the captivating energy of a really good tutor, nor can they replicate a personality that has a consistent philosophy with strong opinions on certain matters. They’re often very dull so they’re probably better off being used as tools for enhancing learning rather than replacing conventional methods.

If you are interested to learn more about how we can use AI to improve education, check out Andy Matuschak’s How might we learn? presentation. The process of learning something new is often too messy to fit into a well-organized flow. The reason why Andy’s work in this problem is compelling to me is that he’s been able to pinpoint some of the most common pain points in the learning process – like the conflict between implicit and guided learning, memory retention, social connection – and has offered tractable solutions.

There’s a plethora of “Cursor for X” type of applications popping up everyday. Yet, I haven’t seen anything that compelling that integrates the current LLM capabilities with “the learning experience.” I think any solution offered in this area should also try to promote itself as a another tool in the student’s toolbox, rather than as a new experience that’s going to revolutionize or, even worse, replace traditional learning.

[0] What I’m talking about here is still normative: I would like for the depth and verbosity knobs to be reliable, but that’s not always the case. Some models are particularly verbose and instructing them otherwise sometimes results in missing information, rather than conciseness. Another issue where these models fail sometimes is when you want something very specific. Sometimes the amount of effort it takes to get that specific thing often outweighs the effort that you would have otherwise spent on just looking at a more comprehensive source of information like a book or a paper.

Terminal User Interfaces

Sun, 25 May 2025 00:00:00 +0000

Terminal User Interfaces

Terminal user interfaces (TUIs) have been experiencing something of a revival lately. For example, this repository lists more than 350 projects, almost 300 of which have over 1000 stars and have received a commit within the last year. This data doesn’t really tell us whether these projects are any good, of course, but it does show the sentiment: TUIs are back in style.

It’s been interesting to see a new wave of users adopting these tools for day-to-day work. The keyword here being “new” because I’m not talking about the usual TUI-users: the first being those who refuse to leave the comfort of their terminal; and the second being those enthusiastic Linux users who like to post screenshots of their desktops on the Internet. Instead, I’m talking about users who just want to get their work done and move on with their day.

Even big corporations have started shipping small TUI utilities instead of just doing the obvious thing (that, of course, being: shipping a browser in the form of an Electron app because that’s what we do in 2025).

Looking at how user interfaces have evolved over the years, you can see that the TUI model for representing interactive UI elements via text was pretty common before it became apparent that interactive elements like menus, buttons, windows, icons, modals, and input fields could be better represented via a visual medium that wasn’t limited by what a terminal could render. The graphical model was more powerful because it could render UI elements more expressively. This not only made some interfaces easier to use, but it allowed for different types of user interfaces that couldn’t have been conceived of in the terminal. It made programs that were trying to solve inherently complex problems (think Photoshop, Figma, Unreal Engine) possible by adding support for rendering high-quality assets (images, videos, and 3D objects), smooth animations, and better operating system integration (notifications, file pickers, and other native OS features) with graphical richness and high performance. So TUIs remained a niche, used primarily by more technical users who had just become too accustomed with their old tools.

One would expect that, with computers as powerful as the ones we have today, interactive programs based on something as primitive as text would be completely replaced. But I keep seeing new frameworks and libraries that are supposed to make TUI development easier. (BubbleTea, Textual, and Ratatui are a few examples.) Talk on GitHub and other programming communities is a good indication of popularity, but not necessarily of quality. This could just be another one of those things that programmers are very hyped to talk about, and not something that’s going to have any significant impact on how we use computers. Yet, it looks like this type of interface is now popular among a new set of users (different from the two user personas I mentioned above) and I was curious to know why.

Before thinking about what it is that people are getting from these kinds of interfaces, I thought I’d first take a look at my own workflow to understand what these tools have been doing for me. Since I’m quite fond of spending time on the terminal myself, I find TUIs to be great for certain use cases. Looking at my own day-to-day workflow, I can outline these benefits:

an interface for computers that can’t render GUI applications,
an interface for controlling another computer (remotely using SSH) with better interactivity when compared to using a sequence of commands,
fast,
lightweight,
lots of keybindings,
more customizable, and
rendered on a terminal.

The first two points are only relevant for certain use cases and are not relevant for everyday use. So, I suspect that they’re not a primary motivator for using a TUI for most users.

Regarding all the other points (except for the last one): yes, they’re relevant, but they’re not necessarily exclusive to TUIs. There’s no reason why a good graphical program can’t provide comparable speed, efficient use of resources, lots of customizability, or a plentiful number of keyboard shortcuts – in fact, you can argue that it could even do a better job in all regards. However, in practice, it is often true that for many use cases (think programs for managing files, inspecting system resources, listening to music, managing databases), TUI-based programs do a better job of providing these features than their GUI counterparts.

So then why is it that TUIs are often better in these regards when there’s nothing inherent to this model that makes it more suitable for making these kinds of programs? I suspect that the lack of keybindings has something to do with the expectations that most users have when they’re interfacing with a GUI application – namely that they don’t expect a graphical program to be used with an extensive amount of keyboard shortcuts. This could be why most GUIs don’t tend to emphasize this feature as much as the TUI counterparts do [0].

Inferior customization could be a consequence of user expectations as well. Most users typically expect GUIs to just work and don’t put as much emphasis on customizing their experience, so, again, programmers writing graphical applications probably don’t emphasize this feature as much as programmers writing terminal tools do, so the consequence of that is that we get fewer GUIs with support for very granular configuration options. TUI users, on the other hand, I think are typically more inclined to modify the program to suit their personal preferences – this could include changing the color scheme, icons, fonts, and the actions onto which keyboard shortcuts are mapped to.

Related to user expectations, it’s worth pointing out that there’s a cultural difference between the two paradigms [1]. The fact that TUIs are harder to use for beginners means that the userbase is composed of power users and development is meant to cater to the needs of those power users, and thus features are much more sophisticated than they would have been otherwise.

These reasons are relevant, but they’re not really describing something that’s inherent to this model. Yes, the average TUI user appreciates these benefits (performance, low resource use, customization, etc.) more than the average GUI user does, and sometimes there tends to be a difference in terms of cultural mindset between the two userbases, but that’s more to do with coincidental reasons rather than inherent qualities. At the end of the day, a TUI will be running inside of a terminal window. Even if that program is being rendered on a GPU-rendered terminal emulator, it’s still a program inside of a window, so these benefits aren’t exclusive to TUIs.

It turns out that there is an inherent advantage that this model has, and it’s precisely that which limits in the first place: the terminal. (This is the last point, mentioned on the list above.) People who live on their terminals prefer to keep most of their everyday programs inside the terminal because it acts a layer, an operating system of sorts, for them to work on top of [2]. Having everything in your terminal means that you get to use one set of keybindings for creating and switching through tabs, splitting panes, running scripts, and more.

It also means that, visually, the contextual switch that occurs when you go from one program to the other (e.g., from your editor to your file manager) is minimal because (1) you can have them both use the same color scheme, (2) they both look similar because they’re limited by what can be drawn on the terminal, and (3) have similar keybindings for similar behavior because terminal-based programs tend to follow common conventions more than their GUI counterparts (think, for example, how ubiquitous Vim keybindings are).

It’s been interesting to see more and more stuff moving onto the terminal. For decades people have been saying that text is too primitive as an interface; in fact, some might have you think that text isn’t good enough even for developing software (see attempts at visual programming). Yet, text is still such a powerful way of defining interaction that its use has not only persisted, but grown. Windows – which for years tried to promote graphical interfaces for everything and had very poor terminals – finally “admitted defeat” by making the Windows Terminal in 2019. The main form of interaction with LLMs, as of right now, is via text. I would also like to believe that this is a counter-reaction to how normalized it has become to ship Electron apps. And it feels great when your music player takes 46 MiB of memory instead of 1 GiB.

One thing that I don’t feel too comfortable with is when I look at everything that’s been happening with Neovim: it often feels like people are just mapping GUI patterns onto the terminal and I’m not always sure if I like it. Sometimes it feels like it defeats the purpose. One would hope that we don’t start using a primitive system like text as a base for building complex user interfaces like we did with the web where we started building gigantic web applications on top of a system that was meant to be used for making [hypertext] documents.

Still, I’m happy that we now have great terminals like WezTerm, Kitty, and Ghostty that are both feature-rich and fast. My workflow has changed so much during the last few years and I keep finding new gems in the terminal world.

[0] To clarify, there are plenty of GUI applications that have an extensive set of keybindings, it’s just that most of them can’t be or weren’t meant to be used via the keyboard exclusively.

[1] And I didn’t list this as a benefit because I’m still unsure whether it really is a benefit – considering that it’s debatable whether the pros outweigh the cons.

[2] A common, misguided belief is that these users prefer the terminal because of the aesthetics or because it acts as a form of virtue signaling, which may very well be the case for some, and might have been for me too when I was a more impressionable programmer; but, I think there are pragmatic reasons why the terminal interface works so well for programmers.

Ahoy

Thu, 15 May 2025 00:00:00 +0000

Ahoy

Ahoy, fellow hacker!

You’ve found my home on the Internet. Here you should expect to read about programming, design, engineering, and anything else that piques my interest.

I’ve seen so many programming blogs starting off with an enthusiastic post about the blog’s meticulously-crafted infrastructure, using the latest static-site generator written in the author’s language of choice, and then that post being one of the only entries in the blog. I’ll refrain from that type of post for now with the hopes of not falling into the same trap – though, I must admit, it is tempting.

Now

Mon, 01 Jan 0001 00:00:00 +0000

Now

Last updated: December 8, 2025.

Working on pathsurfer.
Making a game engine from scratch.

(This is my /now page, inspired by nownownow.com.)