Comment by tomtomtom777
6 hours ago
I agree, and like to add,
> It is hands down good for code which is laborious or tedious to write, but once done, obviously correct or incorrect (with low effort inspection).
The problem here is, that it fills in gaps that shouldn't be there in the first place. Good code isn't laborious. Good code is small. We learn to avoid unnecessary abstractions. We learn to minimize "plumbing" such that the resulting code contains little more than clear and readable instructions of what you intend for the computer to do.
The perfect code is just as clear as the design document in describing the intentions, only using a computer language.
If someone is gaining super speeds by providing AI clear design documents compared to coding themselves, maybe they aren't coding the way they should.
The quote that I heard (I think on HN) was, "If we had AIs to write XML for us then we never would have invented json."
My biggest LLM success resulted in something operationally correct but was something that I would never want to try to modify. The LLM also had an increasingly difficult time adding features.
Meanwhile my biggest 'manual' successes have resulted in something that was operationally correct, quick to modify, and refuses to compile if you mess anything up.
This doesn't sound correct. We have computers write binary for us. We still make protocols which are optimizations for binary representation.. not because it's a pain to write.. but because there's some second order effect that we care about (storage / transfer costs, etc).
And a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more, and talking about how much better it was than things like JSON.
The only thing I think I learned from some of those exchanges was that xslt adherents are approximately as vocal as lisp adherents.
> a recent HN article had a bunch of comments lamenting that nobody ever uses XML any more
I still use it from time to time for config files that a developer has to write. I find it easier to read that JSON, and it supports comments. Also, the distinction between attributes and children is often really nice to have. You can shoehorn that into JSON of course, but native XML does it better.
Obviously, I would never use it for data interchange (e.g. SOAP) anymore.
1 reply →
Dunno. GUI / TUI code? "Here's a function that serialises object X to CSV, make a (de)serialiser to SQLite with tests". "And now to MS-SQL" pretty please".
I don't how much scope realistically there is for writing these kinds of code nicely.