Wow what a treat, previously unreleased tolkien satire on one of my own hobby-horses. Put in an order with my local bookstore, so excited to read this!
I had a similar experience yesterday. Was working on some async stream extensions. Wrote a couple proofs of concept to benchmark, and picked one based on the results. I almost never use LLMs to write code, but out of curiosity, asked whatever the newest claude is to make it with all the real prod requirements, and it spit out over 400 lines of code, lots of spaghetti, with strange flow and a lot of weird decisions. Wrote it myself with all the same functionality in right around 170 lines.
Also had a similar experience in the past weeks reviewing PRs written with LLMs by other engineers in languages they don't know well, one in rust and one in bash. Both required a lot of rounds of revision and a couple of pairing sessions to get to a point where we got rid of the extraneous bits and made it read normally. I'm glad the tool gave these engineers the confidence to work in areas they wouldn't normally have felt comfortable contributing to, but man do I hate the code that it writes.
The article didn’t claim that “last wins” is in and of itself an issue, but that the differences between who wins between parsers across services/languages can cause issues. Their position was that everyone should standardize on “last wins,” since that is the most common.
The problem of trying to ensure that each parser behaves the same for all input is twofold:
- JSON and XML specifications are complex, lots of quirks. So not feasible.
- Does not solve the fundamental issue of the processing layer not using the same data that is verified in the verification layer.
Note: the processing layer parses the original input bytes, while the verification layer verifies a struct that is parsed using another parser.
Doesn’t seem vibe coded to me. The crates aren’t unreasonable: data structures, parser, formatter, repl, “util,” some proc macros (which have to be in a separate crate in rust), and a VM.
For folks who seek a rule of thumb, I’ve found SPoT (single point of truth) a better maxim than DRY: there should be ideally one place where business logic is defined. Other stuff can be duplicated as needed and it isn’t inherently a bad thing.
To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting.
Of course no rule of thumb applies in all cases, and the sense for that is hard to teach.
> To modulate DRY, I try to emphasize the “rule of three”: up to three duplicates of some copy/paste code is fine, and after that we should think about abstracting
Just for fun, this more or less already exists as another acronym: WET. Write Everything Twice
It basically just means exactly what you said. Don't bother DRYing your code until you find yourself writing it for the third time.
And to those who feel the OCD and fear of forgetting coming over by writing twice, put TODOs on both spots; so that when the third time comes, you can find the other two easily. If you are the backlogging type, put JIRA reference with the TODOs to make finding even easier.
> I’ve found SPoT (single point of truth) a better maxim than DRY
I totally agree. For example having 5 variables that are all the same value but mean very different things is good. Combining them to one variable would be "DRY" but would defeat separations of concern. With variables its obvious but the same applies to more complex concepts like functions, classes, programs to a degree.
It's fine to share code across abstractions but you gotta make sure that it doesn't end up tying these things too much together just for the cause of DRY.
The benefit of (some) DSLs is that they make invalid states unrepresentable, which isn't possible with the entire surface-area of a programming language at your (or the LLM's) disposal.
Regardless of the business need for near instantaneous consistency of the data globally (i.e. quota management settings are global), data replication needs to be propagated incrementally with sufficient time to validate and detect issues.
This reads to me like someone finally won an argument they’d been having for some time.
reply