joeatwork

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!

I think this is part of a lighter weight Kubernetes alternative.

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.

This movie is a lot of fun, and a great window into its moment.

I have managed to make a lot of these mistakes, and they’re lead to scary outages and bummers. This is a pretty great article.

Getting recursive functions into ALGOL turns out to have been a controversial move that made for a fun story: https://vanemden.wordpress.com/2014/06/18/how-recursion-got-...

An alternative query language for PostgreSQL would be a wonderful thing! But it isn’t clear that’s what this is.

This isn’t an open source project (which isn’t a bad thing! Just a non-obvious thing if you don’t scroll down their whole readme)

If I’m reading this correctly, the Frink language has similar features (and also seems darn useful!) https://frinklang.org/

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’m not seeing “require” in this document. It looks like the document is proposing education and funding for memory safe projects here.

slow clap

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.

_why offered a vision of computing, art and delight that we could maybe use more of nowadays. For more reference see “This Hack Was Not Properly Planned” here: https://web.archive.org/web/20080512050317/http:/hackety.org...

You should read this if you’re a programmer or someone who makes things. It’s fun and silly, but also makes an important point - the stuff you build is giving somebody power, and if that somebody isn’t some form of everybody, then maybe you’re not doing more good than harm.

If this project interests you but is a bit more minimal than you need, the Janet language is a slightly-less but still pretty lightweight embeddable Lisp with a strong library and community: https://janet-lang.org/

This one, in Italian, is really exciting! Thank you so much for making it!

This is magical! Thank you!

I think it checks every box except “minimize the number of functions exposed”. Also, if your reasons for minimizing number of functions is about usability and complexity, then many functions that are all easily understood at once (and easy for the compiler to type check) might not substantially fail there either.

I wish there were more books in this mold (reimplementing interesting or foundational systems in ways intended for humans to read and understand). I feel the like systems that would admit this sort of thing are important systems. I’d love to see this done with (for example) a Smalltalk image and interpreter, or a simplified network stack.

I know it isn’t really appropriate to the spirit of the article, but it seems like in this case there is a right answer, and it’s “Fully separate object types” - it’s explicit, prevents errors, is complete, and while it requires a lot of typing to implement it doesn’t require much complexity.

I’ve been messing with Janet for a few (maybe 10?) days and I’ve already found a few uses for sh/$ scripts and peg grammar- it hasn’t quite replaced awk for me yet but it’s getting there.

The intention is to do all of your development in containers, in whatever environment you choose, and then deploy the containers into production on a Flatcar cluster.

Indeed - MySQL was fast, freely available, lightweight, and “good enough” (and continually getting better) in an era when the commercial competitors were ultraheavy, evil or broken (and often all three). Pour one out for a real one.