What Writing 2K+ Lines of Brainfuck Taught Me

By Artyom Bologov

Programming in Brainfuck is fun. No, that's not the tears of pain streaming down my face. I write Brainfuck almost professionally. At least I founded BF Enterprise Solutions. Some of the products I made:

So I had my share of blood, sweat, and tears. Here's what I've got from it.

Patience

Some of my projects are big enough to do something useful. They are also big enough to have enough chaos in them. In case you make a typo in the code, they work. They don't miscompile, they don't fail type checking. Mostly because it's Brainfuck and there's no type checking.

So yes, they work... In a slightly broken way. Some inputs simply cause infinite loops. Some inputs make the program stop responding. Some inputs happen... even if the program requires no input! Okay, that last one was an exaggeration. But still, the point stands: broken code doesn't break immediately.

See commit 6f0b33b for the example of several typos that broke recursive bracket evaluation in meta.bf.

Debugging is simple: just run the program in the memory-displaying interpreter. And step through every command tracking what happens to the memory. Yes, every single command. Even if the program is half a thousand lines long.

I am a much more patient person now that I wrote my share of Brainfuck. I will automatically qualify as Embedded Software Engineer. Debugging a running hardware is nothing compared to debugging opaque Brainfuck programs.

Mental Debugging

I must admit that stepping through every command is deadly. It's often impossible or too long. Yes, I had half an hour long session of one pass through the buggy program. And there are several such sessions one needs to find and fix the bug. So the only adaptation strategy I got is stepping through the code in my head.

Many C programmers write screenfuls of code without trying it out. Compiler often starts screaming. A lot. Panicky. But the more code one writes, the less compiler warnings they get.

So again, I'm a better C (or any compiled language really) programmer now. I can compile and run arbitrarily complex code mentally. And debug it too.

Data Over Algorithms

I'm often lying awake at night and iterating on Brainfuck code in my head. Some algorithm I can improve, or some data layout that my programs can benefit from. Especially when that relates for string/array algorithms from str.bf, like swap.bf optimization commit e067d73.

Data layouts are extremely important. A good data layout might eliminate a lot of copying loops and minimize memory use. It's also a good way to reason about programs. That's why bf.doc has an extremely detailed section on memory layout notation.

Any sufficiently big library or algorithm needs a good data layout. Much like the conventional wisdom: good data structure eliminates the need for smart algorithms. So yes, I'm prepared for practical programming: I am focused on data instead of code.

Thinking Beyond von Neumann Architecture

A lot of programming wisdom is specific to byte-churning von Neumann architecture. The pinnacle of programming excellence is using bit hacks. It looks like a random ASCII soup, but it works miracles!

Brainfuck has no bit hacks, because its execution model is arithmetic. Implementing boolean operations is actually hard in Brainfuck. Once you start programming in Brainfuck, your brain rewires itself. You have an alternative to von Neumann bithack-driven programming. You're free now.

Should You Try Brainfuck Too?

Yes, you should. It's an illuminating experience. While I'm not sure if it's good for your mental health, it's fun at least.

So go ahead, hack up your own OS.bf and learn your own lessons from programming in the best programming language out there!

Or just star some of my projects and get horrified from their code 😃

Leave feedback! (via email)