Everyone is caught up in focusing on LLMs instead of thinking about why smaller software is dramatically easier to write.
Writing toy software is a joy
281–290 of 318 posts
Re: Writing toy software is a joy
#282I really like the idea purposed here but none of these projects are even remotely interesting to me. It's moments like this when I start to question whether or not I'm losing my love of programming.
Perhaps. I scanned the list and most of them sound like interesting projects that I would like to tackle at some point (or that I have tackled in the past for "fun"). Honestly, I think I was in your same position until recently, then I had some time off work thanks to the newborn and decided to start a "simple" coding project. Since it was purely for fun and to challenge myself, I decided to try and avoid bringing in…
Definitely a possibility
Re: Writing toy software is a joy
#283Absolutely love this article, couldn't agree with this more.
Re: Writing toy software is a joy
#284Earlier quoted context omitted.
I dunno. Working on a bike you want to use to ride to work could be stressful if it is your only bike, you need it to get to work, and your manager will be really mad if you don’t show up to work one day. If there was any slip available it wouldn’t be so bad. Actually, I really like this analogy because 1) We can’t really work on non-trivial fixes for our cars because they are too complex 2) We’ve totally structured…
> 1) We can’t really work on non-trivial fixes for our cars because they are too complex Learning how to fix my own cars is something I’ll always be grateful for. They’re not that complex. Most of it is just bolts and a diagram reference. Sure, if you crack a piston cylinder you just need a new engine, that isn’t really fixable. Brakes/rotors/calipers, it is almost criminal what you pay a shop for in lieu of doing it…
But,
1) the electronics often are what breaks
2) even if you are good at working on cars, bikes are really, really easy to fix in comparison (I mean, it is a silly comparison).
Of course, they do different things and the thing the car does is much more complex. So it isn’t really a fair comparison. But the fact remains!
Re: Writing toy software is a joy
#285[dead]
Re: Writing toy software is a joy
#286Earlier quoted context omitted.
I hear a lot of people talk about LLMs writing the "boilerplate" and wonder why they haven't abstracted that away in the first place. Maybe my brain has been permanently altered by hacking Lisp.
I hear you. But removing boilerplate via abstraction (Lisp) is very different from generating it on demand (LLMs). The former is obviously qualitatively better. But it requires up front design, implementation testing etc. The latter is qualitatively insufficient, but it gets you there with very little effort plus some manual fixes.
But LLMs can help with the former too.
Re: Writing toy software is a joy
#287Earlier quoted context omitted.
I do this. But the killer usecase for me is writing all boilerplate and implementing some half-working stuff keeps my attention on the issue which makes me able to complete more complex things. A recent example is when I implemented a (Kubernetes) CSI driver that makes /nix available in a container so you can run an empty image and skip a lot of infra to manage. I talked to it a bit and eventually it wrote a Nix deri…
I hear a lot of people talk about LLMs writing the "boilerplate" and wonder why they haven't abstracted that away in the first place. Maybe my brain has been permanently altered by hacking Lisp.
The problem with Lisp (or at least Clojure) is that abstracting away the boilerplate requires you to correctly identify the boilerplate.
It’s nontrivial to structure your entire AST so that the parts you abstract away are the parts you’re not going to need direct access to three months later. And I never really figured out, or saw anyone else figure out, how to do that in a way which establishes a clear pattern for the rest of your team to follow.
Especially when it comes to that last part, I’ve found pragmatic OOP with functional elements, like Ruby, or task-specific FP, like Elm, to be more useful than Clojure at work or various Lisps for hobby projects. Because patterns for identifying boilerplate are built in. Personal opinion, of course.
Re: Writing toy software is a joy
#288Earlier quoted context omitted.
I do this. But the killer usecase for me is writing all boilerplate and implementing some half-working stuff keeps my attention on the issue which makes me able to complete more complex things. A recent example is when I implemented a (Kubernetes) CSI driver that makes /nix available in a container so you can run an empty image and skip a lot of infra to manage. I talked to it a bit and eventually it wrote a Nix deri…
i’ve stopped writing “real” code for the most part, i just bang out some pseudo code like: read all files in directory ending in .tmpl render these as go templates if any with kind: deployment add annotation blah: bar publish to local kubeapi using sa account foo and tell it to translate it to x lang. so i control the logic, it handles the syntax. asking it to solve problems for you never seems to really work, but it…
yeah, that’s what works for me also. LLMs are a nightmare for debugging but a breeze for this.
another good use case: have it read a ton of code and summarize it. if you’re dealing with a new (to you) area in a legacy application, and trying to fix a problem in how it interacts with a complex open-source library, have the LLM read them both and summarize how they work. (while fact-checking it along the way.)
Re: Writing toy software is a joy
#289Earlier quoted context omitted.
You'd be surprised. A number of fairly technical people who are just not that familiar with ML I know got confused by this and believed the models were actually being tuned daily. I don't think that's universally understood at all. That has actual practical implications and isn't just pedantry. People might like some model and avoid better dialog engines like perplexity believing they'd have to switch.
I meant "everyone" in the context of HN ;)
sorry but you’re underestimating the number of people who come here, and the range of backgrounds (and interests) they have
Re: Writing toy software is a joy
#290> Perhaps you’re a user of LLMs. I get it, they’re neat tools. They’re useful for certain kinds of learning. But I might suggest resisting the temptation to use them for projects like this. Knowledge is not supposed to be fed to you on a plate Am I the only one using LLMs as if they were a search engine? So before LLMs I was searching on Google things like "pros cons mysql mongodb". I would read the official document…
> Now with LLMs, I simply prompt the same with a little bit more of context "pros and cons of using mysql vs mongodb when storing photos. Link references". In near future, companies will probably be able to pay lots of money to have their products come up better in the comparison. LLMs are smart enough to make the result seem "organic" -- all verifiable information will be true and supported by references, it will on…
This is already the case, SEO content, sponsored comparison sites, influencer marketing, it's all about subtle framing. LLMs just supercharge the problem by making it easier and cheaper to scale.
The real issue isn't that LLMs lie, it's that they emphasize certain truths over others, shaping perception without saying anything factually incorrect. That makes them harder to detect than traditional ads or SEO spam.
Open-source LLMs and transparency in prompt+context will help a bit, but long-term, we probably need something like reputation scores for LLM output, tied to models, data sources, or even the prompt authors.