Development log of a life-long coder

Minimal dev environment, part 5

In part 4 of my quest to find a minimal (but comfortable) development environment, I upgraded from a Raspberry Pi B to an old netbook. But now I'm back to tinkering with the Pi.


Why am I back to using an ancient single-board computer (with a 700 MHz, 32-bit ARM CPU and 512 MB of RAM)? Because I think I can do better this time.

On my previous attempt, I was writing code in C and TypeScript because, frankly, those were the languages I was most familiar (and content) with. Sadly, parsing and analyzing those languages is nontrivial, and I noticed that syntax highlighting and (especially) static analysis were so computationally expensive, that Vim would start to crawl. I could literally watch lines of text appearing like typewriter.

So, have I found a magical new language server that runs snappily on an original Pi? No. But kind of.

A faster integrated development environment

Of course, to get faster syntax highlighting and whatnot, I had to change a few things--namely everything.

Out goes Vim, in comes Emacs. I know that sounds like a bad trade-off for performance, but bear with me.

Out go C and TypeScript, and in comes Common Lisp.

Emacs is not known for speed, but, when working with Lisp, it gets to cheat a bit. Lisp's syntax is trivial, so parsing is very fast. Additionally, auto-complete is essentially baked into the "read, evaluate, and print" loop of Lisp development, and Emacs+SLIME adds formatting too.

It does take a while to startup, but once it's running, Emacs with SLIME and SBCL is surprisingly usable on my cute little hardware relic. I played around with some Lisp code and started making plans to write the finale to this series. I'd done it! I'd found a minimal, yet productive, development environment that could run on an endangered architecture!

Or not

Unfortunately, when I went to try compiling Lem (a Common Lisp-based editor), I encountered a strange error message from Bordeaux Threads (the de facto threading library for Common Lisp). The error breadcrumbs eventually led me to an inconvenient truth: SBCL doesn't support multithreading on 32-bit ARM. Cue sad face emoji.

I tried installing CLISP, but the Debian build of CLISP also didn't appear to support threads. Same for ECL. I could maybe recompile one or both of those, but I haven't gone down that road because I suspect they will eventually be too slow (CLISP during execution and ECL during compilation).

Or not?

Of course, I don't really need multithreading for some of my projects, so I didn't give up at this point. I happily solved a few Project Euler problems using Common Lisp, in Emacs. I'll admit that the editor was a bit slow when running in (with the Ratpoison window manager). Without, editor performance was great, although that breaks some key combinations, has limited mouse support, and the font is frankly a bit too small on my monitor.

But I eventually ran into an insurmountable annoyance...

So we meet again, modern web

The modern web is just the worst, and the most recent brick wall I slammed into is: captchas (specifically Project Euler's captcha, which requires JavaScript).

On my Pi, I generally try to stick to a terminal-mode browser like w3m because it's fast and uses very little memory. If I need graphics, I move to Dillo or NetSurf. If I need JavaScript, I use Midori, but it is painfully slow on my Pi. And don't even ask about Firefox--it couldn't even load its own landing page on my Pi!

Having to use a JavaScript-enabled browser on a woefully underpowered device just absolutely killed my enthusiasm for minimalist development. Too many sites require JavaScript, and being effectively locked out of a large chunk of the web is too annoying for me at the moment.

Oh well, at least I tried.