Preliminary note: I do not subscribe to the "github is my resume" idea. First, I don't think all the world should put their OSS eggs in one basket. And then, what I write in my Copious Free Time™ is substantially different from what I write at work.

At work, I like to do a thorough system design, documentation, test cases, well-documented interfaces, all the works. That is also where I put most of my programming energy, so there is not so much left when I get home. The software I write at work is also not Open Source, because reasons — mainly because it would require too much extra work to make it usable for any other scenario than the specific one it is written for.

At play, I just want to try out a few ideas, or have a small tool for certain need, and all that for fun. It is no big fun writing documentation or a test suite when there is no one else going to use it, so don't judge me for the lack of it. Or do it, just as you like.

Update: In between I have a few things on GitLab. My main repositories, though, will still be on my own site.


Some of the programs I wrote for fun or some purpose.

Simple name service lookup tool. Originally implemented in 1992, it held up suprisingly well when I reworked it in November 2013 to use the newer IPv6-capable name service API.
Replacement for the calc utility below, finally with RPN. Written in Common Lisp, it runs with Clisp and SBCL. Due to its use of the Readline library, Clisp is very convenient for interactive use. As my first "real" program in Common Lisp, it has probably lots of room for improvement. Public domain.
A Perl script with a simple read-eval-print loop to evaluate Perl expressions, intended as a calculator tool. I have used this for a few years, although I actually wanted something with RPN syntax. Public Domain.
A Perl script to export the music of an iTunes playlist as files, e. g. to copy the music files of your favourite playlist to an USB stick. First export the playlist from iTunes as a text file, then call

export-playlist-music playlist-file target-directory

Tested on the Macintosh only; assumes CR line endings in the playlist file. Preserves the Artist/Album directory structure. Does not copy files that are already present with the correct size.
Version 1 [ni 2010-01-27].
A program to have access to TCP sockets from the shell. Begun to fill a gap in 1992, it is still maintained, and in use by some. Today it can even use IPv6.
Emacs Lisp
A collection of Emacs Lisp code I wrote mostly on the University.
Tcl hacks
Some small Tcl hacks, also quite old.

Lisp Interpreters

This is going to be a Lisp in Kotlin. While I am not the biggest fan of JVM-based things because you'll always have to schlep that runtime around (I know there is the native option, but it doesn't have everything AFAICS), I am curious. So far Kotlin is remarkably similar to Swift, such that I can take Swift code, do a few replacements like s/func/fun/ and things, and then let the compiler show me where it still needs work. This works even with bigger parts like the reader and eval. So I have a working REPL already, only it isn't much fun yet with nothing more than +, -, *, / as builtin functions. Work in progress as of February 2024.
Out of curiosity I started to try a Lisp in Swift. Turned out I really like the language apart from a few quirks, and I got pretty far with the interpreter. Turned out, though, the library, meaning Apple's Foundation API and whatever, is horrendeously complex in the sense of "make simple things a pain in the ass", worse than Java for simple things like reading and writing files. That goes a long way to spoil the fun. Abandoned.
Pyle 2
After the first Python Lambda Experiment (see below), this is the second. This is a cleaner and more elaborate approach, not as minimal, with more builtin functions, but some are still done in Lisp. This one was clearly more serious, so I started to port the regression test suite from lingo (see further below) to this. In the end I was frustrated by two things, dependency hell in both Python and Lisp code (for both of which I did not find a clean solution) and the slowness of Python. This made me start considering other, faster implementation languages. [2020-2021]
Python Lambda Experiment, a Lisp interpreter in Python; I started this while learning Python, but not so much to learn Python, but rather because I was curious to see how its capabilities would apply to this problem. It is intended to be minimal in terms of builtin functions, but fully extensible with macros, and the rest implemented in Lisp itself. Not completed; had problems to get the macros to work (different problem than in lingo). [2017]
A Lisp in Perl — because we can! Writing a Lisp interpreter not in a language I am currently learning, but relatively familiar with shifts the "how do I do this" decision-making from "... at all" to "... in the most convenient and/or elegant and/or best of all ways". That doesn't make it necessarily easier. Still, I get to learn new things about Perl all the time. has, despite the different implementation language, much in common with the lingo implementation (below), but I tried to make it simpler. Fewer data types, so no files, vectors, tables, sockets. Because of that, in parts, I made faster progress and soon reached the point where I wanted to try something new (for me): Lexical scope. I had always wanted to do that, but thought it would be difficult and was afraid looking up bindings in nested environments would be slow. It turned out that it was neither difficult nor slow, not in and not in lingo. (In between mostly abandoned again in favour of continuing work on lingo.) [2015]
A small Lisp interpreter written in Go, intended mostly for myself to get some more practice in Go and to toy around with a simple Lisp interpreter. It is still work in progress, and mostly undocumented. While it will, like the others, probably never be finished in any sense of the word, it is the most complete of all the Lisp interpreters I have written so far. Has in between taken over some features from, in particular lexical scope. In between, it has macros! [started 2012]
Hic Sunt Lambas
Another Lisp interpreter, in C this time. Originally I wanted to write one in Lua, to finally learn that language a bit, but then it started to pour out of me in C. I would like to say "work in progress", but actually it is just unfinished and abandoned now. Main issue is the garbage collector, which is a bit overeager and collects things it shouldn't. [2010]
Lisp implemented in Java. More a proof-of-concept and just-for-fun thing than a really usable programming environment. With recursion and higher-order functions it can rightfully claim to be a Lisp dialect, though. [2006, mostly]
When we studied computer science at the TU Berlin, Bernd Machenschalk and I took a course with the task to write a small Lisp interpreter in Modula II (see here). We were a bit unsatisfied with some of the specs, but we completed that assigment anyway (and learned a lot doing that). Afterwards we felt the need to have one that was truly our own, so we wrote this. [1991]