Small Programs and Languages

Page started: 2025-06-02 Page published: 2026-07-28 My Implementing a Forth article got some great feedback, particularly around the subject of tiny Forth implementations. (And it was an excuse to list some of the tiniest Forths I’ve seen.) I know I’m not alone in seeing the appeal of tiny Forths, tiny languages, tiny programs, and just small stuff in general. What’s up with that, anyway? The appeal of tiny programs Tiny programs are approachable. If I see that something is 200 lines of code, I’m much more likely to read it than if it’s 2,000 or 20,000 lines. What’s more, if it’s a program that does something interesting in 20 lines when I was expecting 2,000, then I’m going to be very, very interested to read those 20 lines! When I was researching DOM diffing libraries prior to creating RetroV, one of the repos I looked at was ijk by Luke Jackson. I was pretty used to looking at fat JavaScript libraries at that point, so when I cracked open the source file for ijk, I was really surprised. Here’s the source: index.js (githubusercontent.com). Just 25 lines! I was instantly intrigued. More recently, one of the responses to my aforementioned Forth article was Philippe Brochard with a 46 byte "Forth". 46 bytes! It’s so small, I can just put the hexdump right here: 50b8 8e00 31d8 e8ff 0017 003c 0575 00ea 5000 3c00 7401 eb02 e8ee 0005 0588 eb47 b8e6 0200 d231 14cd e480 7580 c3f4 Sure, very few people jump at a chance to read raw machine code. But that’s exactly my point. Something this small doesn’t feel so scary, right? I mean, 46 bytes. If you put the effort into it, you know you can figure out how it works eventually. This next one almost serves as a counter-example because the code is so dense and frightening, but I can’t help mentioning it anyway. One of my favorite software stories is Roger K.W. Hui’s Appendix A "Incunabulum" from An Implementation of J in which he describes Arthur Whitney writing an array-based language interpreter, "…​on one page and in one afternoon — an interpreter fragment on the AT&T 3B1 computer. I studied this interpreter for about a week for its organization and programming style…​" Hui can list the entire interpreter in the appendix because it’s just that single page, 122 lines of incredibly cryptic C, which you can view here: I haven’t personally tackled that puzzle yet, but it’s in my unwritten list of dense computer things that I would print out and take with me if I suddenly found myself cast out of society and forced to …