An operating system (and likely computer architecture) designed for the problems of the 2020s, as opposed to the problems of the 1970s.

I wrote a proof-of-concept structural editor for Fennel: https://git.sr.ht/~technomancy/anarres

It’s usable but cumbersome at this point. I spent a lot of time adding a terminal-based frontend in addition to the love2d one, but I found that since I already have 95% of the benefit of structural editing inside Emacs, plus a ton of stuff I’d never get in my own structural editor (like magit, eshell, ERC) it was really hard to force myself to use my structural editor to write itself and click into the dogfooding magic cycle.

Then once Fennel got a really good LSP server it was basically all over; I realized while it would be much easier to write those features from scratch in a structural editor than in a conventional one, it’s still much harder than just using what other people wrote.

An RFC 5545 (iCal) RRULES reference implementation that is lovingly commented and written in a style I would actually call good.

Too many implementations are obscure in that they don’t obviously map to the standard or are built with constructs that are overly language-specific (usually in the name of ergonomics or performance).

This is sad, because nearly every enterprise software I’ve ever worked on has wanted to implement some user-facing scheduling interface that is beyond what Cron-like rules could give you, but the RRULES libraries I’ve used (across several languages) have varied greatly in quality, and are extremely difficult to follow along with for the purposes of debugging your own code.

This is also sad because there are many interesting algorithms implied by the standard that, so far as I’ve seen, simply don’t have a reference implementation or even an explanation for why they work. (c.f. formulas for determining the ISO date-week of a day-of-year ordinal, and how that formula might be mapped to weeks beginning with a day other than Monday). So a body of knowledge is being lost to time in closed-source repos, under-maintained and under-commented open source repos all cargo-cult copying each other (note how many implementations introduce a function called pymod to emulate the sign-preserving behavior of python’s modulus operator, indicating a lineage to python’s dateutil library, the original being probably the best in the lineage for readability but suffers too from a lack of explanatory comments outside of its public interface), and linkrot.

I’ve been working on one myself (this time in golang) off and on for a few years, but it’s slow going since I have a 4 year old and a job that absorbs most of my creative coding capacity, and the fact that nearly every step of the way is about 10% programming and 90% historical deep dive on Dominical calendars or something.

Next Generation Shell. The scope is huge. I’m 11 years into it. I’m at around half. Could use help but I suck at attracting contributors. I’m still on the project and plan to continue.

https://github.com/ngs-lang/ngs

A real, modern and user-friendly Make replacement. A build system that makes no assumptions about what you want or what kind of thing you’re making with it, one defined by rules and rule dependencies rather than some notion of “libraries” and “compile flags”, one where a rule to query pkg-config to set your compile flags is just as easy and well behaved as a rule to run cc, with no intermediate configuration step. One with strong, builtin, support for complex path and string manipulations, and where piping the output of one rule into the input of another is first class. One with easy to read and easy to write syntax. And one where out of source builds are just as easy to write as in-source builds.

There are so many things framed as being a “next gen make” that just don’t actually fill Make’s niche. I don’t even really like Make’s niche, but it’s absurd that Make is still all we have for it.

My holy grail is a programming system / game engine where I get all of the following built-in to the environment:

• Live code updates (ideally, multiple versions of a function can exist at once and have their outputs compared)
• Time travel (such that I can see a bug, rewind the state of the game to a good state, fix the bug, then continue playing)
• Coroutines (manually building state machines for scripted logic that needs to take place over multiple frames is pointlessly masochistic IMO)
• Save games without writing explicit serializers, that are stable in the face of code or asset changes

Some of these goals conflict with each other in deep, possibly unsolvable ways, but that doesn’t stop me from continuing to turn designs over in my head. I don’t know that it’s doable without building my own programming language and runtime.

Oh, do I have those! Just a few:

1. Formally verified routing protocol stack. Ada/SPARK is a perfect language for those things. It “just” needs a lot of time to actually get it done.
2. Getting Pigdeon back and having all my chats across protocols in one place — limited by the fact that messaging protocols all want to lock you into the “official app” much harder than ICQ ever did…
3. Better editing and auto-export of orchestral parts from full scores. [1]

[1] Sure, MuseScore and LilyPond do a decent job. Decent is not great, though. I’d really love to be able to mark some phrases as “cue notes for ” rather than maintain them by hand, for example. Multi-measure rests that have rehearsal letter inside can also be very dodgy and require hand editing to ensure that the trombonist (or whoever) who’s waiting 128 measures until her solo actually knows where people are when the conductor says “let’s play from the letter K” when that letter is at measure 64 of those.

I think “git” is our white whale. We know that there are better designs and solutions, yet we are stuck in a local optimum, unable to improve.

It’s a learning barrier for newer generations of coders around the world.

My current project stems from a significant disdain for most programming languages.

I’ve been working on an open-ended space game named Nebula, starting and re-starting work several times since 2011. In 2016, after being fed up with existing programming languages and ecosystems, I aspired to build my own. It’s now been 8 years, and a minimum of 18 different languages later.

The upside is that this nearly decade-long yak shave may finally be coming to an end. Maybe I’ll get back to the stars before 2030. I wouldn’t trade this journey for anything, though. I wouldn’t be the programmer I am without going through it.

It’s more of a game design white whale, but also curriculum, interface, and language design:

I want to make a game where the player learns a magic system involving some serious programming concepts, particularly abstracting beyond a low level machine. Been working on this in varying levels of intensity since 2008 at least, I’ve mostly only accumulated a long list of negative properties, most recently written up as Triangulating a Game Design. Recently I’ve approached it through puzzle game rules and solvers, last month I made this prototype, but I think this may also be a dead end.

It’s at least led to some other interesting ideas: Fitting Words started off as an attempt at a spellcasting system for it, PrograMaze was about putting the player inside the code, both turned out tricky in puzzle-y ways. Tree editor sketches tiramisu (newer video), ecola, and In the Round were about trying to make editing feel game-y.

(Every decade or so I’ll rewrite my NES-on-N64 emulator in a different assembler, but at least that gets to a playable state.)

I want to generate GPU drivers from datasheets.

A HTML+CSS+JS+Electron solution for building apps, but done well.

It seems like OS manufacturers failed to conclude on a single approach, so H+C+J+E had to born. Now we know what we want to achieve, I’d create a solution from scratch and leave the 30 years of ballast behind.

For me it’s making topographic maps from height data with smooth height lines. Pretty much every tool out there samples points at some regular interval (e.g. marching squares) so you can see line segments in many cases. I want smooth lines (mathematical curve segments) but my math skills are not good enough. Yet!

A more modern IdleRPG that runs in Slack or Discord.

Your character just automatically wanders around a map, occasionally fighting randomly generated monsters. Your interaction with the character is giving them a spot on the map to walk towards, or just telling them to wander randomly. Maybe picking a “side”, so that players can fight or aid each other if they randomly encounter each other.

But I could never quite figure out a game loop that both runs through the automated “bot-haviors” of the players, as well as accepting actual commands for them. And I’m too lazy to read up on how to do this, or ask anyone else, so the project has been started-and-abandoned at least five times now, across three different languages.

For me it’s a thing i’ve been daydreaming about for years, just can’t quite get the design right.

I experience a lot of anxiety around “tasks” and “project management” , but i’ve found it all necessary to remember to get things done. The part that really bugs me ends up being around timelines, time estimation, etc.

When i did some research i learned about polychronic time based cultures and it really clicked with me.

I really want to build some sort of software for project management that is tuned to a polychronic thinker. Some thoughts i had at times were more “context” based tasks then time based or scheduled - perhaps ranking of things more by priority. There is a huge “team” dimension to this that im trying to figure out. It would be interesting to blend other peoples priorities on a particular task or step in a project to help me (as the project “doer”) to understand how it fits into their priorities - this is sort of an inversion of how a lot of PM software works.

Anyway its still all just random thoughts. Just somethign i think about from time to time and try to piece out.

I experimented a bit in making a program to replace both the terminal and the shell. I’m tired of having to interact with my computer like they did in the 60s when I know things like SmallTalk existed.

This would have a client-server architetture with json/s-expr sent over the wire representing the UI. The main thing I want are: statically compiled server for easy installation and built-in web frontend as client (for this I was using golang and initially a (p)react spa for the frontend but I may reconsider)

The main thing I want is having nested ssh connections as nested windows (i find this extremely intuitive as ssh is just a portal to somewhere). Now I’m doing some experiments about how to represent the UI minding that some pieces of the UI can be on different machines

I think this is solvable but may need far more time than I expect, surely more problems will rise up later like what language to use for scripting

(yeah I don’t use Emacs and I know I should start just using that but we can dream)

I wanted to make a multiplayer simcity, where each player would control a different company/sector of the country: water, electricity, transport, the mayor. I drafted some ideas, but it’s way too much work for just one person, and I need the time to get money for food :)

An interactive interface for OS instrumentation, monitoring and control. Basically something that would expose the information you normally get from procfs and sysfs, but in an interactive, graphical format. Something that would allow you to, say:

1. Right-click on a program’s window, select “Process Info”; and that gives you another window, with the kind of information you could get from /proc/<pid>. This is the easy part. Now come the cool parts; you could:
2. Say, click “debug” on one of its pages under “memory”, and that opens a kernel debugger session to examine that process’ page table entries.
3. Use that interface to adjust “swapiness” for those pages; or dump them; or install alerts; or get a handle to those pages, so that you can use it for scripting (e.g. to intercept system calls that reference these pages).
4. Install various quotas on that process. Open a “quota window” with various categories, like “interactive processes” or “background daemons” and just be able to drag-and-drop processes into any of these; then right-click a process in those categories, select “make this permanent”, and the process gets those quotas forever after boot.

Or things like getting a list of IRQ vectors, and installing various instrumentation probes on them, or even point the thing at a file with IRQ handling code and tell it here, install this handler.

Many of these things have been tried before, in various forms, but few of them have been tried together on modern systems. For many of them, the real problem is that I don’t know what a good graphical interface would look like. And obviously there’s a lot of OS glue layer code. I don’t think this is something I can realistically implement by myself, for a modern system, even if I’d be working on it full-time. But it’s a cool thing to dream about.

I have a few of these, and they’re all mostly doable but I don’t have the perseverance to see them through.

The one that I’m feeling pretty confident I’ll finish is X11 bindings for OCaml, which I’d like to use to write a window manager in the style of XMonad. I’d also like to integrate the wm with wlroots to make it possible to have a window management “core” that could be shared between X11 and Wayland, but that’s a stretch goal :)

Another is a “system” “scripting” language that would target the Linux kernel and would have no dependencies, not even libc. The language would be an ML-like with a syntax that would kind of look like she’ll commands. It would supposedly replace /bin/sh, so it’d have a REPL and it’d reimplement the functionality of the coreutils. Stretch goal would be to use that instead of shell in a NixOS fork. I haven’t even started working on this one.

A Common Lisp implementation with a runtime supporting green threads (think Erlang or Go). I never figured out how to finish because I never really started, and I get headaches thinking about bootstrapping or the future GC. One day maybe.

I’ve got a few.

The biggest one is creating a “new Arduino”, but with lua using a web-based IDE served straight from the (at least to start) ESP32 so it’s entirely self-contained and has no dependencies to install. I’ve pretty much only got false starts to show for it. I feel like it’s a project that has a ‘activation energy’ that is just a bit too far out of my reach. Part of my problem is that I’m just not satisfied with the existing parts I could build it out if, mostly NodeMCU which was unfortunately made when Node.js was popular and it decided to copy all the callback hell problems instead of just using coroutines.

Others (in decreasing order of white-whale-ish-ness):

• A ground-up re-implementation of OpenSCAD, but using curves instead of polygons. (That can also be built to WASM w/o emscripten.)
• A new router OS in the same vein as VyOS, but with a more flexible/responsive configuration language. (And a build system that doesn’t require root on a specific version of debian.)
• A p2p-real-time-synced ‘application database’ for writing applications w/o any server dependency.
• A ‘react-native’ but for GTK that lets me write GTK applications in Rust without the impedeance mismatch of the GObject system.

In general my biggest problem is that I just don’t have the mental bandwidth for projects like these while working full time (especially, like right now, while repeatedly beating by head against the SNMP RFCs while writing a new SNMP implementation in Rust).

Edit: Comparing my response to others, my problem might just be too many projects…. Anyone have tips for getting myself to want to do fewer different things?

Mine is this: I want to find a point somewhere in the metaprogramming design space between Lisp macros and full fexprs that feels right in my brain. Yes, I have read the 1998 paper by Mitchell Wand that shows that this is more like a Kraken than a white whale.

To me, the big problem here is modules. If macros are second-class objects, and modules can define and contain macros, then modules must also be second-class objects. Then we’ve bisected the language into two, which - in an otherwise uniform Lispish substrate - feels deeply unsatisfying. It’d be much nicer to have first-class modules that can be manipulated using all the usual language constructs.

But if modules are first-class, then either they can’t contain macros, or macros become first-class too. If we choose to have macros kept outside modules, then either we get two separate module systems (see above), or we get a clunky interface/implementation split that starts feeling an awful lot like a Robust Enterprise Language and less like a language for exploratory hackery. If macros are first-class, then they become fexprs - and then (see Wand’s paper “the theory of fexprs is trivial”) we have entered a world of pain where nothing means anything and compilation doesn’t work.

I’ve tried making an interface/implementation split, but I wasn’t happy with it. I’ve tried using partial evaluation to reduce the fexpr-like objects away iff they can be resolved at compile time, but this made distribution a complete pain. My last idea was having two distinct types for bindings - one that can expand fexprs or call functions, and one that can only call functions. The latter would be the default, and the former would have to be introduced explicitly and statically / syntactically visibly, so trying to call a fexpr in a function’s place would be a type error. I never really got to work on that, though.

My white whale is a programming language and I have notes and fragments going back to 2006, mostly based on an article in Computer Language from 1985 (of which there is no other information about, even online). The main feature is a lack of key words, but not as mathematically oriented as APL. There are symbols for looping, conditionals, type and variable definitions (in which I include functions) and returning values. Other syntactic features I’ve played with over the years include:

1. multiple return values
2. type inference
3. annotations (such as read-only, write-only, non-cachable (volatile), inline, etc)
4. design-by-contract
5. lambda functions

There is no concrete implementation—all my notes are about defining the syntax, and so far, I haven’t come up with a syntax that I like (mostly around function declarations and type annotations). I keep hacking away at the syntax, hoping for a breakthrough.

I’ve mostly avoided them. Mostly the project is a “nice idea, might try some time” and I forget about it because there is little importance, or “I’ll screw around with it a little bit, and I prove to myself that it could work/I can make it work” but I lose interest in finishing because the “can I do it” was by far the most important motivation, or “This is important/want to work on this and it is also beneficial for this and that and that and …”, with the multiple motivations it usually keeps me going well, and I’ll finish it.

The last thing I “lost interest” in, 5 or so years ago, was a git transport that would expose refs in p2p communication. Creating a transport that hooks into git was surprisingly easy. I got git to push over a communication channel from one p2p-client to another, then I lost interest. I had proven to myself that it would work. (idea: “push” is registering a ref to be available on p2p, “fetch” to take from another client (as you’d expect), p2p comm to perform the discovery of refs) DHT, networking (mostly), etc. wouldn’t be a big deal, obviously everything is more intricate and takes more time if you need to implement it. NAT hole punching, figuring out the limitations wrt IPv4 connections would be huge annoyance, probably, which wasn’t at all appealing. I got back to projects I thought more important and liked more.

A C compiler.

I like where tcc was going - if compile performance is fast enough, even if the resulting code isn’t super optimized, it changes the way we’d think about the problem. C could be closer to JavaScript, where an add-on is distributed as source and JIT compiled near instantaneously.

I’ve wanted to build a new relational database for a while, not for the intricacies of the inner workings but for the design side of the interface. I’ve only ever really tolerated SQL and all the shortcomings of pasting plaintext string literals (or, even worse, gluing them together) inside another programming language. ORMs can be great but they have issues too and the root of those issues is leaky abstractions and complexity of optimisations happening at various different layers.

I want an LLVM for databases on which I can build many different query languages, one being SQL but another being a proper machine-API not an English-based language that doesn’t fit with today’s software architectures.

I’ll do it one day… I’ve just got to learn a lot!

I have several ideas in the ham radio space that I think could be done, but aren’t quite my cup of tea:

1. A CW decoder using dilated convnets + RNN, or transformers, or something. Speech recognition has come an incredibly long way in the past 20 years. Beepybeep recognition hasn’t really gone anywhere at all. It should be possible to at least get in the same ballpark as a trained ear by now. The hardest part here is probably the training corpus.

2. A thingy that listens to a mistuned SSB signal and tells you how many hertz to tune up or down to make it sound right. Together with CAT control, the result could be an “auto-tune” button. Analytically, it should be possible by using the cepstral properties of the human voice (i.e. that it’s harmonically rich and not just noise). Mistuning will shift and truncate the spectrum, but it will affect the cepstrum quite a bit less. Under certain assumptions, the cepstrum will tell you what the spectrum “should be”, and then you look at what you’ve actually got and find the shift that maximizes the correlation.

3. A replacement for the APRS “SmartBeaconing” algorithm. The idea of SmartBeaconing is that you can gain efficiency over beaconing at a fixed time interval by beaconing infrequently when not moving or moving in a straight line at a constant speed (so that your current position is not far from the dead-reckoning position obtained using your last known position and velocity), and beaconing more often when you deviate from that track. But the way it actually does it is weird and crude. I’m not sure if it can legitimately be explained by the limitations of 1990s embedded systems or if it’s just dumb. It uses linear interpolation between two reference speeds to come up with a basic beacon interval, and it decides whether to shorten that interval by literally multiplying the number of degrees you’ve turned by your current speed and seeing if that exceeds some threshold (sine was too hard?).

I think there’s an answer that’s better and simpler at the same time, and it looks pretty close to this: Let current_time, current_pos, and current_vel be what they sound like, and beacon_time, beacon_pos, and beacon_vel be the values the last time you sent a beacon. For tunables, let w be around 0.2, dt be around 30 seconds, and thres be around 5-10 km or a vehicle, lower for a person.

time_since_beacon = current_time - beacon_time
if time_since_beacon < min_interval:
    continue
if time_since_beacon >= max_interval:
    beacon
    continue

beacon_extrapolated = beacon_pos + (time_since_beacon + dt) * beacon_vel
current_extrapolated = current_pos + dt * current_vel
deadreckoning_error = |current_extrapolated - beacon_extrapolated|
traveled = |current_pos - beacon_pos|
total = (1-a) * deadreckoning_error + a * traveled

if (total > thres)
    beacon

The a factor encourages beaconing when you cover a distance of about thres/a even if your velocity doesn’t change at all, because you’ve probably entered or left a repeater coverage area by then. The dt factor encourages “corner pinning”, i.e. putting a point down where you turned a corner instead of “cutting off” the corner by waiting for you to travel in a new direction for a while. But setting it too high will cause way too much sensitivity to velocity changes. thres is simply the amount of error allowable.

Something I think is totally feasible, but that I just don’t have the time and energy for: turning KDE Connect into a Linux version of Apple’s Continuity. This partially means things like fixing up the currently-half finished Bluetooth transport (this is particularly useful because it means that KDE Connect devices can bootstrap each other onto the same WiFi network, to then use as the primary transport), or making KDE Connect devices automatically gossip about other paired devices they know about, so for n devices you don’t have to set up n! connections.

But it also means making KDE Connect less of an app and more of a platform capability. A simple example: .desktop files could have a key that specifies the corresponding Android application ID, which KDE Connect could then use to prevent duplicate notifications from showing up (one from the desktop app and one mirrored from the Android app). A more advanced platform capability would provide full-blown APIs for communicating with the phone app when connected. Back before Signal dropped SMS support, one of their stated reasons for not allowing you to send SMS messages in the desktop app was the increased server load syncing these messages would cause. A mobile <-> desktop communication API like I’m describing here would help this kind of problem enormously. Or, imagine handing off your Jellyfin music session seamlessly to your mobile device, without involving the server at all. The possibilities are endless.

It’s hard because I’m unfamiliar with the codebase and the technologies KDE Connect uses. It will eventually be hard because Google doesn’t document all the APIs for this kind of stuff on Android, and probably (I haven’t checked) full on locks them away so only Google Play Services can use it. (But the APIs are there.) I also haven’t talked to upstream about any of this.

An OS with very little code that works on all common hardware.

I know device drivers are hard. But I’m willing to throw away performance. I wish there was a timeless set of low-performance device drivers that anyone could consistently run.

(I spent some time struggling with this but it’s not my skillset.)

I’ve had a lot of thoughts about designing things where you are always moving forward. Post-mortem debugging tools that let you patch in the right fix inline, interactive REST endpoints where you can write up the implementations as things come in (think Darklang’s functionality in the past), etc.

My daydream, though, is a PL that has the sort of functional pragmatics of clojure (pure data structures by default), a syntax more like Python, a structural type system like TS/Purescript with enough dependent type power to support some interactive proofs. I should have my cake and eat it too!

And a final thing is basically just an Omnifocus clone that is focused around listing tasks and then registering dependencies to those tasks, so I can see what tasks are unlocked at a specific moment. I want the power of Omnifocus but with a UI that is much more about moving forward, instead of having to futz around with projects and the like.

I’ve been working for nearly four years on a hardware/software combination system I’ve codenamed Basic Box. It was initially inspired by the boot-to-BASIC REPL environments of the 70s and 80s, but has morphed into more of a platform for understanding how computers and computation work in general, for kids and adults alike.

Thus far the components have included writing a bare metal Raspberry Pi kernel, firmware for a Pi Pico, drivers for displays and amps, designing and prototyping a handheld device, writing curriculum, building prototype HATs, and writing a programming language and interpreter with low-level inline assembly language capability.

Yeah, that’s all. Just that.

It’s a product, not a piece of hardware, but also potentially a kit. It’s taken me so long, and it seems like every time I get into another component of it, there is more to learn and it challenges the limits of my understanding of topics.

I really hope to have something to show for it all soon. But I’ve been saying that since 2020.

More recently, I started working on an R&D wiki-like site (see also https://lobste.rs/s/i8qnvf/repurposing_hugo_as_wiki) that aims to “work in the open” and be a resource to others with similar interests, since I plan on the whole thing being open source and open hardware anyway.

If I had to do it again, I would’ve started in the open in 2020, which is much more typical of my working style, but at the time I didn’t fully grasp the scope of what it would become, nor was I sure that open source hardware was the way to go.

I have moved teams or been laid off days after starting to implement proper metrics collection for observability. Only one of those products did I start from scratch, and started it before I was wise to the ways of o11y, baking it in from the start is the way to go.

I’ve got some tools in the toolkit now that I can get started pretty quickly but man… working on the fifth time it’s happened in the last 6 years as I move to a new team this week.

Years ago, I developed a basic package manager for Apache NiFi. I always wanted to return to that, but I don’t use NiFi for anything right now.

Implementing sha256 as a circuit, and then checking if a large neural network can predict any of the output bits based on the input.

A simple format for writing recurring tasks, like cron but for humans.

“I want this task to activate 7 days after it was completed”. I don’t want it to repeat every 7 days, I want the timer to start after the task was completed previously.

vCard for the 21st century. Basically a structured format for information about people and organisations, like various names, addresses, phone numbers, photos, etc. I’ve got the barest shell of this in acard, but it would need a whole lot of work to be usable.

A while ago, I was making a list of video game releases I’m looking forward in Airtable, and I though it would be pretty easy to fill the release dates automatically in the parallel universe where semantic web is a thing.

All I need to make it happen is:

• something like airtable that understand rdf and lets me write sparql queries for some columns
• a way to query the steam api using sparql

These are things that are fairly doable (at a prototype level), and it gives me a glimpse of a parallel world where sparql is easy and powerful. But I’m always demotivated by the fact that once I’m done with the prototype, I’ll just need a team of 8 people for 2 years to make it usable.

https://github.com/kghose/groho

A script driven simulator for space flight in the solar system.

A martial arts simulator, for finding the very best moves and techniques across all styles.

I want to write a kubernetes scheduler that doesn’t suck. Sadly, this is a vastly overpolluted field and it’s very very hard to do.

A homoiconic editor for structured diagrams. Something like Eclipse’s EMF + GEF, but starting with a graphical view instead of text.

The bottom layer would be metamodel diagram that you use to define the structure and constraints of the next level diagram.

In 2005 I created coworks, concurrent objects in Java. We used it in quite a few systems, fx. at Aldo Shoes main logistics hub in Montreal. Later it became coworks.net when we switched to .Net/C#

Around 2015 I created pyworks.(https://pypi.org/project/pyworks/) a python version of concurrent objects, but partly due to the GIL it did not make much sense to have a thread per concurrent objects. So it has been sitting there waiting for the GIL to be removed. A bit of a pathetic excuse I know, but my white whale :-)

an integrity protected web app shell. The bootstrap code would be minimal but allows loading a fully integrity-checked web app using ServiceWorkers and Subresource Integrity. I have started this project at least three times.

A general library that has a variety of helper classes for FIRST Robotics Competition teams’ robot code. There’s a lot of boilerplate that teams copy from year to year (and from each other, since closed-source code/designs can’t be reused), but is out of scope for the general framework. Sadly, Java packaging is a bit of a mess and the framework’s packaging system isn’t really built for use cases like this.

In the past year or two for me, it’s been designing a library (or building a system into a new programming language) for performing calculations on values of different units, without requiring that the user only use predefined units. The user of the system would only need to explicitly define relationships between units and the system would handle conversions as needed. Ideally it would include a way to define singular/plural names for units and handle complex units. I imagine it could be useful in a high level programming language or even just a handy app like Soulver.

The trouble I keep running into pathfinding between two compatible units of differing exponents, like trying to add a value of unit Newton with a value of unit kilogram¹ * yard¹ * second⁻¹ * hour⁻¹: because Newton is convertible to kg¹ * m¹ * s⁻², yard is convertible to meter, and hour is convertible to second, then the system should be able to succeed in finding a common unit. Maybe there’s an algorithm out there that I just haven’t found yet.

Some examples using pseudo-code for the language containing this unit system:

// cannot add or subtract mismatched units

5 apples + 3 oranges

// can multiply or divide mismatched units

3 feet / 2 minutes

// specify relationships between units to allow addition/subtraction
//   and to collapse units correctly during multiplication/division
// also can define singular variations on the unit for convenience

define inches = { 12 * feet }
singular feet = foot
6 inches + 4 feet // 4.5 feet or 54 inches 
3 inches * 4 feet // 1 foot²

// specify complex relations referencing multiple units with a variety of exponents
def newtons = { kg * m / (s * s) } // (in this case, kg¹ * m¹ * s⁻²)
x = 10 kg * 2 m / (4 seconds * 1 seconds) // 5 newtons

My threshold for “nah, not gonna waste time on that” is pretty low I think.

But over 10 years ago I wanted to have some semi-intelligent chat bot agent system that I’d just give some (natural language and precomposed) commands and it would do things or give me infos. But preferably not a simple “this is a shell alias that just queries site X with parameter Y”. Never happened. Also I knew full well that was something on the scale of Wolfram Alpha, but more general. Pretty sure it was also before Siri and Alexa, I think those would be a better comparison than current LLMs.

Oh, and I think this would be totally doable today but I lost interest.

I’m not stumped by it, I haven’t found time to make it a priority, but I really want pre-commit from pythonland to exist in something like Rust and also remove its dependence on git repos to get at the executable. Then, to be able to seamlessly extend this to CI builds for feature branches or PRs without needing to duplicate your work in a Jenkinsfile or similar.

I occasionally work on something that smells a little bit like Ansible, but is based on Bash scripts, and would require very minimal learning curve if a person was already comforable with Bash. I’ve gone through a couple iterations already and I like the general direction it’s heading. But it might require a few more iterations.

It’s less of a “thing” that I’m iterating on, and more of a pattern.

A better “make”. I’ve built half a dozen prototypes, with my latest iteration getting close to what I want, before coming full circle and writing a tool that is the command-line equivalent of a single make rule. I like the simplicity, but it’s still not quite what I want.

A massively parallel mutation testing framework for Elixir.

In practice, the level of compiler hacking is beyond my skills/time, and mutation operators are also not easy to design, because you can very easily introduce non-termination.

[Comment removed by author]