3 ms·

I’ve found utility in removing code. I feel that doing the job with the fewest lines of code, is best. I also believe in focused/pure scope. If I write a type

I’ve found utility in removing code. I feel that doing the job with the fewest lines of code, is best. I also believe in focused/pure scope. If I write a type or API to do a job, then it should do that job, and only that job. If I want to add functionality that is out-of-scope, then I’ll often write another type, instead of adding it to the existing one. Making this type of decision is always fraught. But, like in all things, it depends. Sometimes, reducing the overhead of things like setup and testing is a good reason to not introduce a whole new resource, but I should make it a point to document the reason for the incongruity. This is especially true, when designing user interface. I’ve found that, usually (not all the time, though), less is more. Josef Albers is known (amongst other things), for the quote “Sometimes, in design, one plus one is three or more.”.

fransje26 4mo ago
> I’ve found utility in removing code. > I feel that doing the job with the fewest lines of code, is best. And that is one of my gripes with AI models and code. They are so, so verbose. It's a nightmare. "Why don't you let AI implement that small feature, it will be faster.", they would ask. Well, because if do, it will completely pollute my carefully crafted interface that I kept small, simple and understandable for easier maintenance and extension. And yes, I might spare a few hours by having _it_ work for me. But then I need to spend a more hours to clean-up the code noise and complexification. Sorry for having polluted the conversation by bringing AI in, when for once, ironically, it was not about AI.. I needed to vent, while fully approving of your take.
- trollbridge 4mo ago
  I evaluate how good models are now by how good they are at removing code. It’s fairly simple (assuming the test harness and agents.md are well written): do iterations of trying to remove code, ensure it passes, then have a human review it. Less code to review that way.
- ChrisMarshallNY 4mo ago
  I just had to rewrite a screen written by an LLM. It started, by giving me a 2,500-line (about 50% documentation) viewcontroller that ate so much memory that the app would jetsam after the user just did a couple of things. I then, spent about a week, tracking down memory issues, until we narrowed it down to the MapKit cache. All this time, the LLM was making the code scarier and scarier. It was exactly what I would expect from an inexperienced (but smart) engineer, panicking, and adding more and more cruft. The LLM ended up suggesting fixes that didn’t work that well, and made the UI janky. Also, it was terrifyingly delicate. I don't think it would have survived one feature request. By now, the viewcontroller was over 4,000 lines. I asked the LLM to refactor for redundancy, quality, and size. It removed all the documentation and logging, reducing the size back to about 2,500 lines (about 1% documentation). Yay. Except all of the bush-league threading and awful workaround shit was still in there, but now impossible to understand. At this point, I gave up, threw out the LLM code, and rewrote the viewcontroller from scratch. Took a day and a half. I figured out how to force MapKit to flush its cache (2 lines of code). It's a well-known issue, and the solution was the first StackOverflow answer that showed up in the search. It’s currently about 1,400 lines (about 50% is documentation), and works great. Lesson learned.
  - fransje26 4mo ago
    > It removed all the documentation and logging, reducing the size to about 2,500 lines. [..] but now impossible to understand. Nice. Lol. > At this point, I gave up, threw out the LLM code, and rewrote the code. It’s currently about 1,400 lines (about 50% is documentation), and works great. I've had similar experiences. But I must be "holding it wrong", judging by all the other articles on HN..
  - dpark 4mo ago
    I get the impression that your takeaway is not to use LLMs, but I think your takeaway should be to give them more oversight. The way you describe this, it sounds like you went pure vibe coding. > I asked the LLM to refactor for redundancy, quality, and size. What did you expect when you asked it to make it smaller? I’ve had good success with LLM refactoring. But the refactoring has never been “go make this better and smaller”. It’s “go do this specific thing to reduce redundancy” or maybe “give me a list of ways to improve the code redundancy” and then iterate with the LLM to improve the ideas and execute on the right ones. I don’t think you can just vibe code your way out of a vibe coded mess.
adolph 4mo ago
> removing code Cue link to Negative 2,000 LoC [0]: He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. 0. https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html
noopprod 4mo ago
I think when somebody trains code golfing LLMs with reinforcement learning they will inadvertently be smarter

fransje26 4mo ago

> I’ve found utility in removing code. > I feel that doing the job with the fewest lines of code, is best. And that is one of my gripes with AI models and code. They are so, so verbose. It's a nightmare. "Why don't you let AI implement that small feature, it will be faster.", they would ask. Well, because if do, it will completely pollute my carefully crafted interface that I kept small, simple and understandable for easier maintenance and extension. And yes, I might spare a few hours by having _it_ work for me. But then I need to spend a more hours to clean-up the code noise and complexification. Sorry for having polluted the conversation by bringing AI in, when for once, ironically, it was not about AI.. I needed to vent, while fully approving of your take.

trollbridge 4mo ago
I evaluate how good models are now by how good they are at removing code. It’s fairly simple (assuming the test harness and agents.md are well written): do iterations of trying to remove code, ensure it passes, then have a human review it. Less code to review that way.
ChrisMarshallNY 4mo ago
I just had to rewrite a screen written by an LLM. It started, by giving me a 2,500-line (about 50% documentation) viewcontroller that ate so much memory that the app would jetsam after the user just did a couple of things. I then, spent about a week, tracking down memory issues, until we narrowed it down to the MapKit cache. All this time, the LLM was making the code scarier and scarier. It was exactly what I would expect from an inexperienced (but smart) engineer, panicking, and adding more and more cruft. The LLM ended up suggesting fixes that didn’t work that well, and made the UI janky. Also, it was terrifyingly delicate. I don't think it would have survived one feature request. By now, the viewcontroller was over 4,000 lines. I asked the LLM to refactor for redundancy, quality, and size. It removed all the documentation and logging, reducing the size back to about 2,500 lines (about 1% documentation). Yay. Except all of the bush-league threading and awful workaround shit was still in there, but now impossible to understand. At this point, I gave up, threw out the LLM code, and rewrote the viewcontroller from scratch. Took a day and a half. I figured out how to force MapKit to flush its cache (2 lines of code). It's a well-known issue, and the solution was the first StackOverflow answer that showed up in the search. It’s currently about 1,400 lines (about 50% is documentation), and works great. Lesson learned.
- fransje26 4mo ago
  > It removed all the documentation and logging, reducing the size to about 2,500 lines. [..] but now impossible to understand. Nice. Lol. > At this point, I gave up, threw out the LLM code, and rewrote the code. It’s currently about 1,400 lines (about 50% is documentation), and works great. I've had similar experiences. But I must be "holding it wrong", judging by all the other articles on HN..
- dpark 4mo ago
  I get the impression that your takeaway is not to use LLMs, but I think your takeaway should be to give them more oversight. The way you describe this, it sounds like you went pure vibe coding. > I asked the LLM to refactor for redundancy, quality, and size. What did you expect when you asked it to make it smaller? I’ve had good success with LLM refactoring. But the refactoring has never been “go make this better and smaller”. It’s “go do this specific thing to reduce redundancy” or maybe “give me a list of ways to improve the code redundancy” and then iterate with the LLM to improve the ideas and execute on the right ones. I don’t think you can just vibe code your way out of a vibe coded mess.

adolph 4mo ago

> removing code Cue link to Negative 2,000 LoC [0]: He recently was working on optimizing Quickdraw's region calculation machinery, and had completely rewritten the region engine using a simpler, more general algorithm which, after some tweaking, made region operations almost six times faster. As a by-product, the rewrite also saved around 2,000 lines of code. He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2000. 0. https://www.folklore.org/Negative_2000_Lines_Of_Code.html https://www.folklore.org/Negative_2000_Lines_Of_Code.html

noopprod 4mo ago

I think when somebody trains code golfing LLMs with reinforcement learning they will inadvertently be smarter