Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Measuring the sloppiness of code

earendil.com

Post reply on HN
Print view View original

101–110 of 247 posts

Re: Measuring the sloppiness of code

#101

Post by neptvn »

It's a nice article that basically (rage)baits the readers before they realize the author actually disagrees with the premise of coding being solved. So here goes, my higher-level rant on "solving" something with AI.

I strongly dislike all the "X is solved" narratives. What does it mean for something to be solved? A math problem (or any kind of problem), a riddle, a mystery, a dispute. Those are all instances of a particular situation that requires a "solution", but new situations will always come up. I understand that by "cancer/coding/X is solved" in this new age of (gen)AI that means the ability to streamline or speed up the "solution finding" procedure, but even that presupposes a fixed, static, fully deterministic space of the things we are trying to "solve".

Even cancer cannot be fully solved - Demis Hassabis slowly started drifting away from using the word "diseases can be solved" because they can't be eliminated - we can only speed up the process for finding a cure for any particular disease, be it existing or new and/or evolving.

Is bridge-building solved? Architecture? Why are architects still employed? Is solving "civil engineering" or designing an optimally running machine a thing to be solved? What are we trying to do when we talk about "progress with AI"? Even when the "recursively-self-improving-AIs" and "perfect" robots do arrive, we're still bound to work with them, and they'll have to evolve to find new solutions to new problems.

To be clear, I work with and rely on LLMs every day, from coding custom RAG architectures with CC and Pi to research and agentic data science. These bombastic conversations, however need to quiet down a bit so we can get back to work :)

Re: Measuring the sloppiness of code

#102

Post by ndriscoll »

shimman wrote: post #75
Retric wrote: post #53

Earlier quoted context omitted.

Many people were and still are simply terrible developers. Hand those people an LLM and they don’t suddenly become competent, but they do start slinging more code.

Nah, you're still blaming workers and not leadership. If leadership is okay with not training workers (something American corporations would do in the distant past) then it's not fair to continue to blame workers when leadership is clearly aware of the problem and would rather pocket the money than help workers. These companies pay management more than workers for a reason, if you can't even admit that they are to bl…

We're talking about professionals here. People who (at least in the US) often make several multiples of the median worker. Competence is assumed, and every company I've been at has had programs to pay for additional school if the employee wants it. IIRC at least one had an explicit book allowance, and I don't doubt that I could expense books right now if I asked. Do surgeons and lawyers complain so regularly that management doesn't train them? Or are software engineers just this desperate to be seen as "not a real professional"?

Who even is supposed to be training us? We're supposed to be the experts. Unless you mean mentorship, which is also generally already a thing at any company that has more than a handful of engineers.

Re: Measuring the sloppiness of code

#103

Post by Dlemlo »

Varelion wrote: post #86
Dlemlo wrote: post #78

Earlier quoted context omitted.

So they still might do but in parallel the software engineering market in china and india is collapsing.

Source?

Lots of chatter online, i have seen a few videos on this tpic on YT.

https://www.hays-china.cn/en/press-release/content/%E4%B8%AD...

Re: Measuring the sloppiness of code

#104

Post by bla3 »

Supermancho wrote: post #66
danbruc wrote: post #19

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience curre…

> Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability My experience is a little different. For higher abstraction languages the output is largely acceptable in my work. I always consider that LLMs don't know what I don't tell them and they have limited context to work from. Coding issues I often identify: * Efficiency. Marginal…

This sounds roughly right to me, except for "maintainability". In my experience, agents really don't like deleting code unless you explicitly ask for it. If you're not careful, you end up with new better implementations of things but with the old implementation still around in perpetuity. Humans do this too of course.

Re: Measuring the sloppiness of code

#105

Post by Dlemlo »

danbruc wrote: post #100
Dlemlo wrote: post #46

Earlier quoted context omitted.

I have seen so much production code with garbage code and massive bugs, the industry doesn't care for 'real'.

They care in principle, for the most part bad code makes changes and extensions slow to implement and causes unnecessary production issues which costs time and money. But there is always the tension between implementing something quickly now and being able to implement things quickly in the future and unfortunately the preference is almost always quickly now despite everyone knowing that this is the way more expensiv…

Not even in principle. Like how often you had to fight a product manager to do this or that.

"Does that code work?" "yes" "so lets ship it" "but its not good" "but it works right?"

Re: Measuring the sloppiness of code

#106

Post by einrealist »

danbruc wrote: post #19

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience curre…

And there is another problem: LLMs generating too much code, code that is doing more than was asked. And that cannot be fixed by tests. Usually, we create tests for wanted behavior and expected exceptions. But we don't create tests for undesired behavior.

Re: Measuring the sloppiness of code

#107

Post by jplusequalt »

FloorEgg wrote: post #38
softwaredoug wrote: post #22

Earlier quoted context omitted.

I don't doubt that. But humans still need to be responsible for understanding what they're shipping. And IMO you get your best understanding by actually writing some code. Even if you don't actually ship what you wrote.

> But humans still need to be responsible for understanding what they're shipping I don't necessarily disagree. That said... Why? I've been grappling with this myself. There is an easy/obvious answer, but I wonder how stable/permanent it is. If you feel strongly about this, are you willing to unpack your judgement?

>Why?

We are overly reliant on technology today. I don't see this trend slowing down in the future.

I think that a world where everyone is reliant on technology, and nobody understands how it works is a nightmare.

Re: Measuring the sloppiness of code

#109

Post by sceptic123 »

_s_a_m_ wrote: post #59
echelon wrote: post #29

Earlier quoted context omitted.

And all of these things will be solved one by one. It's astounding to me that people can see coding get solved and not think every single one of these tasks won't be solved too. Why do you not think these things aren't going to be completely automated? What makes these tasks special? Fable and Astra can one-shot video games with compelling novel game loops. They can do systems programming, distributed systems, roboti…

[flagged]

[flagged]

Re: Measuring the sloppiness of code

#110

Post by gchamonlive »

danbruc wrote: post #19

Coding is not solved, correctness is not a feature, it is the bare minimum. If your code does not do what it is supposed to do, you could as well have no code at all. Efficiency, security, maintainability, reliability, readability, understandability, extensibility, maintainability, observability, portability, ... this is what high quality coding is about, not that it works, that is a given. And in my experience curre…

It's not solved, I agree. But if we pretend it is we can prepare for when it actually becomes solved, if ever, and measuring sloppiness is a worthy pursuit even if we never "solve code".
Post reply on HN