It will run locally in a web browser, it’s open source and if I recall correctly the authors provide a downloadable way to serve it from your local machine.
The page doesn’t say it, but this is why adding redundant safety systems and defense in depth stops working after a while - such systems end up running with (acceptable, unobserved) “holes” after a while - the more complex the system, the harder it is to perceive the holes, until one day they line up and become very obvious indeed.
Even if you’re not interested in making your own music with Strudel, this site is worth a visit for the showcase. A lot of folks are making a lot of interesting music with it!
Palladium magazine is published by The American Governance Foundation. I couldn’t find out much about it by Googling, does anybody know what its deal is?
UXN / Varvara (a project by these folks) is something really special https://100r.co/site/uxn.html - an approach to creating intelligible software by applying strict complexity constraints, sort of like Viewpoint Research’s STEPS project, but with more concrete goals and an even smaller and simpler basis.
I ran the interview team for TripleByte FastTrack early on (I’m not part of or in touch with the otherbranch folks) and I’m excited to see something like it return! The program was good at uncovering different sorts of engineering excellence. We could identify and attest for folks who were particularly fluent coders, or particularly deep systems folks, or particularly excellent debuggers, and then match them with shops that needed the sorts of things those people could do well. If the otherbranch process is like early TripleByte I’d encourage folks to give it a try because they’ll have a shot at landing jobs that are better fits for their skills and interests (in addition to just saving a bunch of time during the search!)
Software tools backed by businesses that target enterprises have very strong pressures towards obscurity, complexity, and generally optimizing for institutional goals and away from development experience and effectiveness. As tools that get developer adoption move up market they get worse and worse for the folks building with them.
Something this article leaves out is that mostly, when people are given better tools, they don’t just produce more widgets per unit time: often instead they build different (more complex, better) widgets. When I was in school I read a study about this - a design shop had N draftsmen, they introduced CAD tools anticipating reducing the staff, and when researchers went back to the shop they had the same staff, but they were designing things that wouldn’t have been practical or possible before.
There are a bunch of common workloads (including i’m guessing HN itself) where the trade offs for distributed databases make them a lot harder to use well, or where distributed databases don’t make sense.
I think the poster means that adding null is a big, substantial change to the interface - if you have a function that used to not make sense with a null argument, and then it suddenly does make sense with a null, then the function has changed in a way observable to callers.