Skip to content

Comment on JIT Compiling Code in 5μsparent

Comments

I cringe at the quality of what it generates.

Besides all the other mentioned points, I think a good remaining less-discussed point is that quality in software has always been in the eye of the beholder. You may very well see the AI output as low quality, I may not, and its not necessarily clear who is right or wrong, because there was always little precedent in objectively evaluating code quality.

This is a long standing issue, and was never resolved before AI happened, and the coming of AI has not really changed things, except that AI is under a magnifying glass obviously. How do we objectively measure the quality of code? There's some general consensus on things, but surprisingly little is true professional agreed upon consensus.

If I can make up a figure, I would guess 95% of software engineering quality rhetoric, and craftmanship advice, is just strongly held opinions.

This is not something I can prove, but if I look at the (still ongoing.....) debates on very basic ideas like clean code, and the reactions from also-great programmers like Carmack, Blow & Muratori, it is clear to me that there is little consensus on even the fundamentals of software design.

If all these people can produce excellent working software while disagreeing on these fundamentals (of quality), it means we do not yet understand what the fundamentals are.

You're talking about different measures / types of quality.

Anyone who thinks AI is good with writing code that is hard to write for the operator, not due to lack of basic software engineering know how but complexity of the domain, either has access to models beyond what is available to the public or is completely lost.

I see what you mean.

You could read it as quality in the operational correctness sense, but just as well in the software architectural design sense. My comment indeed applies to only one of those.

However, why judge correctness as a "cringe on quality", rather than just objectively saying its producing errors. This is why my response is in the software direction.

He’s the obviously and exactly saying code quality is not objective fact. And replying with a fallacy link is just embarrassing.

The entire argument is one of Relativism, there is a whole lot of disciplines where there is a huge subjective element, consider journalism and literature in general, but that doesn't mean we can not have a conversation about quality of work in these fields.

Software is no different. So when someone claims that "you can't question the quality of AI output because quality of software is [partly] subjective", they're appealing to subjectivism. This position is generally held by the incompetent to entirely dismiss any question of craftsmanship or quality.

No, you're missing the point. I'm not saying software quality is relative, I'm saying that most current debate on what people think is quality software, is subjective nonsense.

I've also never claimed that "you can't question the quality of AI output because quality of software is [partly] subjective". I'm not sure how you got there. I am simply saying that "quality" is an ill defined term and this is why we might see so much divergence when discussing AI code "quality".

You can absolutely evaluate code quality objectively, e.g performance, bugs, crashes.

Okay, I misunderstood your point. What you're saying seems pretty reasonable to me.

You and vouwfietsman can't know what kind of code asdfsa32 is rejecting.

What if it was rejected on an objective basis? You can't know, so you have to err on the side of caution, but you didn't.

So it's not embarrassing at all. In fact, it is more embarrassing to double down without knowing more.

It's a fallacy because you can always say that the choice of an objective metric was subjective, so everything is subjective.

If I can make up a figure, I would guess 95% of software engineering quality rhetoric, and craftmanship advice, is just strongly held opinions.

Absolutely, at the end of the day the only metrics that matter are performance and code validity. A lot of the "this code is awful" arguments I hear just boil down to "this code is stylistically awful" and never talk about it's performance.

AboutSource Built by g1lg1l

Hackerly is an independent reader for Hacker News, built on the public HN API. Not affiliated with Y Combinator.