It’s interesting because we all share this space of malleable software but come from all different angles and land in different places in that Venn Diagram of communities and aesthetics.
That’s something we’ve given quite a bit of thought, esp since we live in a precarious situation.
From the onset of the Hundred Rabbits project, we talked about how some projects might die with us, similarly to how Joy died with Manfred von Thun. One thing we considered was that everything had to be open-source, so that if we disappear at sea, the project would remain available. So we couldn’t use the Pico-8 model of closed source.
An other thing was that the codebase had to be one of the source of truth, and for that it had to be readable, so even tho we love to write in a super terse coding style, the sources had to be readable so that they could be ported and reimplement. So we couldn’t use the Decker Iversonian coding style, we settled for a standard clang format and documented everything from the perspective of the would be implementer.
One last point is that Uxn was frozen back in 2023. So the toolchain can’t keep rolling over to new devkits(SDL3, API changes..) so we can’t be subject to language layer changes underneath us(Lua 5.5), we had to be completely independent, and so we couldn’t use the Love2D model.
I’m sure there are rigidity vectors that we haven’t thought of, reading your last posts gave me lots of ideas about malleability, thanks for putting it all together.
5 Likes
That is really illuminating even when I’ve been following you for a while.
One nit: I believe LÖVE still uses Lua 5.1 so shouldn’t be affected by Lua 5.5 or later.
LÖVE does make incompatible changes from time to time. However, old versions of LÖVE are archived and available if an app declares which version it needs. In my projects I have some bespoke support for declaring ranges of LÖVE versions.
1 Like
What are LÖVE’s dependencies other than Lua? Is there anything critical, that could disappear by decree of Big Tech, or by a single person disappearing at sea?
Meta-question: Is dependency risk assessment already an established field of work?
1 Like
I don’t think so. They’re all fairly basic to the different OSs it runs on. But this is the right question to ask and there can never be a final answer.
I think the mobile support is most precarious. LÖVE 11.5 on Android is 7MB, but LÖVE 12 is shaping up to be 50+MB last I checked. I think that’s a sign mobile OSs are forcing them to stretch unnaturally.
It’s in games (like Chess and Diplomacy), game theory, history, military history (like Clausewitz and John Boyd), business strategy (like Wardley Maps), logistics. That’s about all I can think of.
Above all it requires a great imagination to anticipate all the things that might go wrong. I don’t think you can think about this abstractly, like “how can one survive in a hostile environment.” Every environment is unique and the number of possible environments is infinite. You get no points for surviving in environments outside your own. You are where you are. (This thought triggered great claustrophobia in me when I really grappled with it.) Perhaps the best teachers for this stuff are animals. I like watching coyotes near my house, and am a disciple of a Black-backed Jackal in the Namib Desert, but house cats too can teach a lot.
3 Likes
There’s a bunch, obviously SDL3 being the most fragile/rolling one but not susceptible to one developer disappearing at sea, but I think harfbuzz might be at risk as there’s only a handful of donation funded developers who maintain it, and it is COMPLEX, too complex to be reimplemented by just about anyone. I can’t see the future, but if I had to guess, it might be one that is hard for developers to replace the old ones for.
It used to be more discussed than is now.
2 Likes
Harfbuzz is an interesting suggestion. At least LÖVE is easy to build, so there’s an element of graceful degradation. You can drop a library and lose only its functionality.
That doesn’t work for SDL, though. I’ve been building a very conventional Lisp interpreter to try to replace 600k lines of LÖVE with 5k lines of C. But it still depends on SDL. 
Yes, that is the key exposure here.
2 Likes
Ah! Neat, I see now, so you’re hooking up the tiny-lisp runtime to a graphical front-end! 
At least replacing SDL is not too difficult, the SDL bindings(not the font stuff or audio stuff) are pretty standard, they’re comparable to X11, wayland and HTML5 canvas enough that porting from one to the next, if your code is just 5k it won’t be too much work I think(hopefully you never have to).
I’m excited to see what you make with that. I feel like the thread took a Collapse Computing turn.
Recently I was helping someone add SVG support to their project, and I just could NOT believe how large the codebase was, looking at that massive archive gave me vertigo more than any other project I’ve come across in the past. It made me wonder if this could ever be rewritten from the ground up, if it’s even human feasible.
3 Likes
Looks like I’ve had a blind spot regarding SDL throughout. Here’s a Wardley Map I made in mid-2023 which makes no mention of SDL. So thanks for pointing it out!
2 Likes
Oh, one other factoid: I recently did some experiments and it looks like using SDL directly is no more power-efficient than LÖVE. Do you find that as well? Is the x11 version of uxn less drain on your battery?
Yeah, I found the same thing, for reasons(maybe I’m keeping the high precision timer needlessly hot or something), but X11 is A LOT less memory and energy demanding on my thinkpad. It’s one of the reasons I moved away and tried X11 in the first place. I couldn’t figure out why it was spinning to much, but it might still be something I’m doing wrong with SDL2..
1 Like
I had always filed away (mentally) SDL as “basic, stable, not a problem”. Just because it’s relatively low-level. Not a good assumption, as I am discovering now!
@eliot
moving the discussion on dependencies here.
Nix has tools to find build and runtime dependencies and probably more.
