Kartik Agaram is that your blog? akkartik.name/post/programming-2024
I'd love to hear what you and others think of it. This was a summary and conclusion to a series of my posts here in #devlog-together.
Yes some parts resonated with me. It reminded me of my own notes which I kept private. Looking forward to find a opportunity to exchange on these ideas.
Interesting notes!
First reaction: the title says "how" but not "what". I think the two go together by necessity. If you first decide, in the abstract, how you want to program, you end up constraining what you can program. Which is fine, of course, if you are aware of it and give priority to methodology. And I like reading about such approaches because my own is almost the opposite: start from what and then figuring out how .
Another surprise for me is the focus on "a program", meaning a relatively autonomous unit of software. In the context of situated software, which I am also a big fan of, this looks like an unwelcome constraint. My own tendency at the moment is the opposite: build extensions/plugins to frameworks such as Glamorous Toolkit (or my own Common Lisp inspector framework) to profit from their affordances and keep the problem-specific code small. But then, this means accepting large dependencies. In terms of durability, a "program" is probably the better bet.
The nine-point synthesis is very interesting. Points 1-3 agree with my own experience. Also 5 and 6. Point 4 is one reason why I like building on a framework: it makes experimentation cheaper (see point 7!). At the cost of durability. Tough trade-off.
Point 9 reminds me of Gilbert Simondon's "The mode of existence of technical objects". He considers a technical object mature when it no longer resembles independent parts bolted together. A single design taking into account everything all at once.