Patrick Dubroy, co-creator of the Ohm parsing toolkit, writes on software design, programming languages, and sustainable code.
Commenters like the term "cold-blooded software" and his hierarchy of needs for code, and cite him for HTMX and computing sketches.
I prefer this version http://dubroy.com/blog/a-hierarchy-of-needs-for-code/
I don't think either is spot-on, but it is a good way to visualize and remind yourself of what is important in your project.
Even the projects themselves have their own hierarchy. Do I care that the one-off crud app the boss asked for to update some reference tables ever reaches the "Enlightened Phase"? Probably not. I don't think I would get any "Actualization" from that.
But that browser based game I am writing at home? Or a library my colleagues are going to use at work? Or some crud app that is going to be used extensively by people everyday? Then I think it is worth it to look at those projects from the point of view presented here.
Hi HN! I'm the main author of the Ohm Editor, and co-creator and primary maintainer of Ohm itself.
Ohm is a user-friendly parsing toolkit for JavaScript/TypeScript. You can find out more at https://ohmjs.org.
Anyone interested in the editor might like to check out a blog post I wrote about it a few years ago called "Visualizing Packrat Parsing" (https://dubroy.com/blog/visualizing-packrat-parsing/)
Some people also might be interested our book WebAssembly from the Ground Up (https://wasmgroundup.com): you can learn Wasm by building a simple compiler in JavaScript, using Ohm.
I was thinking about the issue of nested code the other day -- isn't it (mostly) an editing environment problem? I mean, if my IDE can detect that a method is pure, couldn't it do a little magic (e.g. provide a different coloured background, some dotted boxes, etc.) and show me the inlined code right there? It doesn't seem wise to architect your codebase around the deficiencies in your tools, since one is (hopefully) going to long outlive the other.
Related:
[1]: https://dubroy.com/blog/method-length-are-short-methods-actually-worse/
> I'm still unclear what the standard method for managing these is.
If only this was just a documentation issue. Alas, the reason is that there is no standard method. Here's a short practical article on how to install Python packages and get on with your life: http://dubroy.com/blog/so-you-want-to-install-a-python-package/. For a longer historical perspective of this whole clusterfuck check out http://lucumr.pocoo.org/2012/6/22/hate-hate-hate-everywhere/
For sure. This is the number one reason I am switching as many projects as I can to HTMX.
https://dubroy.com/blog/cold-blooded-software/
Sibling comments say in so many words, it's no big deal bro, just update. But it is a big deal over time if you have dozens of cold-blooded projects to deal with.
https://vorpus.org/blog/notes-on-structured-concurrency-or-go-statement-considered-harmful/
https://dubroy.com/blog/handling-user-input-with-structured-concurrency/
The first one is particularly good. Both of those have links to more topics.