The ultimate goal is to maximize utility for the end user; everything else exists in service of it, and that’s my north star for making software.
I applaud and thank the developer that lives up to this standard, but I know I don't and I think there are valid reasons to have commitments in software other than the end user. Two notable ones for me:
Professionally I write software to feed my family. I do advocate for end users, more than most!But when push comes to shove I'd be lying if I said I had more loyalty to the consumers of the crud app I get paid to work on than to my family and therefore the company that pays me (within limits).
Perhaps more interestingly, outside of work my north star is "is the work gratifying to me?", that can be artistically, aesthetically, or intellectually. That almost always lines up with what I believe to be the interests of my end user, but I have to admit both the possibility that I'm just wrong about what maximizes utility for my end users (indeed there have been plenty of cases where I have asserted I know what users need better than the users self-describing their needs, anyone who builds a product knows this is necessary but there's an undeniable hubris to it) and that if there are a few pet issues where even if you actually proved to me beyond reasonable doubt that, say, an animated hamburger menu somehow was the design decision that maximized user utility, I'd still exert authorial control and and deprive users of that utility because at the end of the day I believe I have a right to assert my aesthetic preferences in the face of all opposition in my own creative output
And then outside the trade-offs, it's not always that you can define true «end users»… How to treat making a part of software user-hostile to make sure the user doesn't use it to do absurd stuff damaging users of their work?
(I have been in the discussions of building something specifically to be there to make sure some specific extremely highly Goodhart-able reporting — with a pretty large splash damage radius for this Goodhart-ing — is forever «not yet» working despite any wishes of the user of the software)
Even if a tool is not "lovable", like a screwdriver, it's still very reliable for a very long time. My Phillips head screwdriver permanently has its Phillips head. It's not as if 1% of the time when I take it out of the toolbox to find it has a flat head, and I have to try again by returning it to the toolbox. And I'm not subject to endless variations of handle designs. I just get to use the tool I bought until it breaks.
The article mentions "software you can love" and links to https://softwareyoucan.love/. I'm riffing on my interpretation of that concept, and comparing software to physical objects.
A custom guitar, for example, is first carefully crafted then makes its way to an owner who will cherish it, both for the craftmanship and for how the instrument actually plays. https://softwareyoucan.love/ feels like it skews more to this side of the analogy.
But there are also many tools that are completely mundane, lacking craftsmanship or charm (not "loveable"), yet perform so well that we take them for granted. Like screwdrivers.
Similarly, a kitchen knife is just a knife, but I still have my favourite kitchen knife at home that I use for basically everything. I think you can definitely "love" (for want of a better word) well-made, dependable simple tools.
It doesn’t matter if your blockchain has no bugs, if it’s a rugpull
You could even fit all three into this: making your /s/blockchain/thing/ more efficient does not matter if you introduce new bugs, but that only matters if it’s not a rug pull!
I noted that there is no requirement that software be written solely by a human. It's interesting to me at least, since Kristoff is (AFAIK) a core developer on Ziglang.
I'd like to think that I can create software using AI-assisted development that fits these requirements.
For me there is this duality. I enjoy hand-writing code. I also enjoy finishing things. Sometimes they fight.
I am sorry for bringing AI into this. But it's hard to put aside given:
This post is not really about which tools are better or worse for achieving the goal, it's about motives: your end goal should be making useful software and not overfit any of the sub-goals, nor think that all that matters is your developer experience.
I mentioned the (insane) memory-safety blog post that was shared here yesterday because to me that is an example of overfitting, but Rust can be a great tool for achieving the ultimate goal if it feels good in your hand.
If you think that AI helps you writing software, then use it, but make sure to evaluate the end outcome against the ultimate goal, and nothing else.
I guess there's a reason this is published on Loris' personal blog, not on ziglang.org.
Just because you're with a project which has a clear stance towards LLM based code doesn't mean everyone in the project shares this stance for this, or all projects.
This isn't specific to Loris in general, but it makes sense to evaluate such a decision on a case-by-case basis.
It's interesting. Until very recently, nobody had thought to label their software as being built without massive amounts of theft from artists and engineers or without massive environmental damage.
Lanny | 20 hours ago
I applaud and thank the developer that lives up to this standard, but I know I don't and I think there are valid reasons to have commitments in software other than the end user. Two notable ones for me:
k749gtnc9l3w | 14 hours ago
And then outside the trade-offs, it's not always that you can define true «end users»… How to treat making a part of software user-hostile to make sure the user doesn't use it to do absurd stuff damaging users of their work?
(I have been in the discussions of building something specifically to be there to make sure some specific extremely highly Goodhart-able reporting — with a pretty large splash damage radius for this Goodhart-ing — is forever «not yet» working despite any wishes of the user of the software)
lightandlight | a day ago
I have a similar approach.
Even if a tool is not "lovable", like a screwdriver, it's still very reliable for a very long time. My Phillips head screwdriver permanently has its Phillips head. It's not as if 1% of the time when I take it out of the toolbox to find it has a flat head, and I have to try again by returning it to the toolbox. And I'm not subject to endless variations of handle designs. I just get to use the tool I bought until it breaks.
I want more software to be like that.
avh-on1 | 15 hours ago
What do you mean by "tools that are not loveable, like screwdrivers"?
lightandlight | 12 hours ago
The article mentions "software you can love" and links to https://softwareyoucan.love/. I'm riffing on my interpretation of that concept, and comparing software to physical objects.
A custom guitar, for example, is first carefully crafted then makes its way to an owner who will cherish it, both for the craftmanship and for how the instrument actually plays. https://softwareyoucan.love/ feels like it skews more to this side of the analogy.
But there are also many tools that are completely mundane, lacking craftsmanship or charm (not "loveable"), yet perform so well that we take them for granted. Like screwdrivers.
[OP] kristoff | 11 hours ago
I think that limited scope, highly effective software can be loved by its users. Think about how much passion people put in their pocket multi-tools.
Johz | 10 hours ago
Similarly, a kitchen knife is just a knife, but I still have my favourite kitchen knife at home that I use for basically everything. I think you can definitely "love" (for want of a better word) well-made, dependable simple tools.
k749gtnc9l3w | 14 hours ago
I am not sure how fixing all the bugs without eventual scope-freezing is supposed to work
alterae | 20 hours ago
and this post is how i learn tiger style has a website now
ohrv | 17 hours ago
You could even fit all three into this: making your /s/blockchain/thing/ more efficient does not matter if you introduce new bugs, but that only matters if it’s not a rug pull!
deevus | 19 hours ago
I noted that there is no requirement that software be written solely by a human. It's interesting to me at least, since Kristoff is (AFAIK) a core developer on Ziglang.
I'd like to think that I can create software using AI-assisted development that fits these requirements.
For me there is this duality. I enjoy hand-writing code. I also enjoy finishing things. Sometimes they fight.
I am sorry for bringing AI into this. But it's hard to put aside given:
Aks | 14 hours ago
I'd say the point 3 implicitly says against those tools. All they seem to make is unmaintainable spaghetti.
[OP] kristoff | 11 hours ago
This post is not really about which tools are better or worse for achieving the goal, it's about motives: your end goal should be making useful software and not overfit any of the sub-goals, nor think that all that matters is your developer experience.
I mentioned the (insane) memory-safety blog post that was shared here yesterday because to me that is an example of overfitting, but Rust can be a great tool for achieving the ultimate goal if it feels good in your hand.
If you think that AI helps you writing software, then use it, but make sure to evaluate the end outcome against the ultimate goal, and nothing else.
deevus | 9 hours ago
Thanks for the considered reply.
xq | 13 hours ago
I guess there's a reason this is published on Loris' personal blog, not on ziglang.org.
Just because you're with a project which has a clear stance towards LLM based code doesn't mean everyone in the project shares this stance for this, or all projects.
This isn't specific to Loris in general, but it makes sense to evaluate such a decision on a case-by-case basis.
orib | 3 hours ago
It's interesting. Until very recently, nobody had thought to label their software as being built without massive amounts of theft from artists and engineers or without massive environmental damage.
It's a shame that this has changed.
singpolyma | 9 hours ago
"AI assisted" development is created by a human so I'm not sure exactly what you're getting at.