Live data from Hacker News

Writing toy software is a joy

blog.jsbarretto.com

261–270 of 318 posts

Re: Writing toy software is a joy

#261
post #151

Earlier quoted context omitted.

This was already a problem in a world without LLMs. Reputation is the only human mechanism that mitigates this.

Technology is a catalyser. It has a knack of turning things from "already a problem" to "now a catastrophe".

"To err is human, but to really foul things up you need a computer." -Paul Ehrlich

Re: Writing toy software is a joy

#262

Earlier 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.

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.

Re: Writing toy software is a joy

#263
post #3

Toy Software is a lot like working on your bike/car/boat/whatever. Working on your bike is fun. Working on the bike you need to ride to work tomorrow is stressful. I miss writing toy software. It’s fun. But inevitably I want to use said software and that’s where the trouble starts. You find all the bugs and none of the time to fix them.

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 yourself. Spark plugs are super easy. Even things like taking the intake manifold off a direct-inject car to replace the fuel injectors isn’t terribly hard.

What has made cars complex is all the electronics that tie into it. The mechanics of an ICE car are mostly about the same.

Re: Writing toy software is a joy

#264
>An ECS framework, 1-2 weeks

That gave me a good chuckle. Yeah look, you can change your data layout to be in more of an ECS format, make some optimizations and call it a day; but in reality you're still going to be pretty far from the real thing.

I can say this because I've been working on one for some months now, of course I'm going for a production build and also to turn it into a Unity asset that's worthy of being sold, so it's going to require a lot more effort. The goal of mine is to ensure that its extremely simple to use (which Units DOTS totally fails at) while still being as efficient as possible.

Some notable things I've had to do for this project:

- I have a tool releasing on the Unity asset store (currently being vetted) that performs optimization for you, e.g. you give it a variable such as an int, a range of let's say 1..1024; then it'll automatically time your code while searching for the best sample in the range. I needed to create this for the next item, which is

- My C# Thread tool which runs managed threaded code for you. It creates no garbage so and uses the above optimizer on three different variables so as to find the best amount of threads, calls and inner loop sizes to use for your code. Because of that it can run managed code almost as fast as Burst/Jobs (whereas they use their own compiler and optimize code instead of using Mono). It can even beat Burst on small to medium workloads as long as the code inside doesn't contain some efficiency that Burst can natively fix.

- Then of course there are other things an ECS needs like pathfinding, unit collision avoidance etc. For these I have both CPU and GPU solutions since CPU only really works up to about 10k entities at a decent framerate.

So yeah, I don't recommend trying it; it's probably a total waste of time.

Re: Writing toy software is a joy

#265

Earlier 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.

There’s necessary complexity like error handling, authz, some observability things, etc. which can’t be trivially abstracted away and needs to be present and adjusted for each capability/feature.

Re: Writing toy software is a joy

#266
I share the same feeling. Programming can be an entertaining and joyful activity where enthusiasts don't really need to worry about creating something useful that will be shared with others.

It's like cooking a beautiful and tasty gourmet recipe that serves only one.

Re: Writing toy software is a joy

#267

I share the same feeling. Programming can be an entertaining and joyful activity where enthusiasts don't really need to worry about creating something useful that will be shared with others. It's like cooking a beautiful and tasty gourmet recipe that serves only one.

gustavo!!! your website was the first thing i thought of as i was reading this blog post. im a huge fan of your teaching style. thank you for everything you do! :-]

Re: Writing toy software is a joy

#268
post #39

> 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…

> Am I the only one using LLMs as if they were a search engine?

Google agree with you and now at the top there is a AI generated answer, clearly labeled as AI generated, and it cites the sources. I was trying to escape AI, but I have to recognize the implementation by Google is quite good.

Re: Writing toy software is a joy

#269

Earlier quoted context omitted.

Yes, I think that is understood by everyone

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 ;)

Re: Writing toy software is a joy

#270
As a toy project I can recommend re-creating the core functionality of Git. Its basic functionality beautifully simple.

Checking out Linus’ first commit of Git and comparing it with my own solution was also very interesting (and humbling).

If anyone is interested, here’s my toy Git implementation in Go https://github.com/emanueldonalds/shit

Post reply on HN