What programming/technical projects have you been working on?

Thinking about the best way to set-up a dead-man switch.

I am creating a pdf file to my partner that contains crucial information in the (hopefully far in the future) event of of my death. It will include all kinds of things. Passwords, financial information, insurance info, who to call to handle xyz, how to revert our house from a smart home back to something that does not require my maintenance, etc..

Making and hosting the pdf is easy, filling it with the right information is hard but I should manage, but figuring out how to get this pdf in the hands of my partner as soon as possible after my demise is tricky...

Ideally it should get to her as fast as possible but without triggering whilst I am still alive. It also obviously contains sensitive information that must remain secure.

I could host it on my server and setup some automation to send it via email whenever I don't perform some action within x hours, but that is sure to be triggered by mistake at some point. Also it seems incredibly unreliable. Tech stacks fail, and if the pdf is not delivered, the whole thing is moot.

So far I got no good solutions.

In an effort to keep learning things regularly, now that I'm out of uni, I've been following a tutorial by Austin Henley on making a compiler from scratch in Python. I studied this in class last year, but it was very confusing! The theory part was poorly explained and was presented to us at a time where I was struggling with everything else in the curriculum, and the practical part had us writing a compiler in C, a language I dislike, using Lex and Bison, of which the workings confused me more than the actual code.

I worked on it monday and today in the afternoon and I've reached the part about the parser. So far, this has been a lot easier to understand than my classes, so I am glad. I've noticed the code presented in the tutorial seems like it'd be hard to maintain : the lexer gets tokens using a long line of elif blocks, and I'm wondering if I could do something better. Perhaps that's a great thing. Makes me want to code more things.

Something I'd like to do after I'm done is a big hat trick : write a compiler in C# that would put out Bash code. I've found I could solve a lot of my personal computing problems with some Bash scripts, but I don't like Bash and can never remember its specifics compared to general use languages. If I did a project like this, I'd be able to learn C#, learn more about Bash, learn more about compilers, have something cool to put on a portfolio and get a personalized tool for my daily use. Would be nice!

I've been working on a Lisp with a graphical canvas attached.

No, wait, wait. Come back!

I have this theory that individual people use computers for basically 3 things:

• A better paper in some ways. You can erase things without leaving marks on paper. You get perfect, mass-produced penmanship, lines, circles, etc. You get all the colors without needing to lug a lot of specialized stationery around. (Now there are also drawbacks. Limited desktop size, so you can't easily put two pieces of paper next to each other without halving their size.) Still, can often be very useful.
• A better library in some ways. 2 books don't weigh more than 1 in your backpack. (And neither do 2 million!) Now, there are also drawbacks. You're limited to what's made its way to soft copy, and that creates certain forms of blindness. Still, can often be very useful.
• A portal that breaks the tyranny of Distance. You can find people like you, who share your interests, wherever they are. You can talk to them, work with them. Now, there are also drawbacks. You interact with them through fingertips and a flat image and often tinny audio. You can't be fully embodied with them in a shared 3D space. Still, can often be very useful.

These are all incredible super powers in many ways, and that's why we spend so much time with these new devices. But our devices are also immature. They break constantly. They're vectors for parasites and malware that can also now break the tyranny of Distance and infect us from far away. It seems to me what we need is parsimony. To do more with less. And that's what I've been doing. For the past 10 years it seems I've been focused on the first use case, of a better paper, trying to provide it everywhere with as little code as possible. My current solution depends on 600k lines of code on top of your OS. Not too bad, considering the competition is often millions of lines of code!

But I'm also constantly looking for ways to shrink those 600k lines of code. And I've particularly had an eye on Lisp. Because if you're willing to put up with those toenail clippings of parentheses, it's actually the shortest known way to get to a safe high-level language that provides a nice programming experience. 10 years ago I actually started out building a Lisp, but it failed because as you might expect I didn't know what I was doing and it was dog slow. It turns out interpreted Lisps are tiny but slow. And adding a compiler obviates Lisp's advantage in code size. And so I eventually ended up at Lua, because it provides a nice performant compiled language in 12k lines of code.

But recently I ran across tinylisp and it brought up my old questions again. Back when I built my Lisp I also put in a bunch of features. Maybe an interpreted Lisp doesn't actually have to be slow if I focus on the bare bones?! Particularly on modern computers which are so fast to begin with.

And so I'm back hacking on Lisp after all these years. I have a graphical canvas attached to a Lisp REPL in under 2k lines of code which is a big enough improvement over 600k lines that I'm willing to chew through some glass for it. (It also depends on SDL3 but so does LÖVE, so the comparison is still valid.)

Imagine that! 2k unchanging lines of unsafe C, under tight quarantine, and now you can have 80% of the benefits of the better paper that is so much of the promise of computers.

(It's not going to be fast enough for games or anything, those use cases are Out of Scope.)