1) of course balanced critiques are necessary, but

2) sometimes you can come to a conclusion after considering all the pros and cons, and in those cases, you should definitely say so and not equivocate.

IMO that's obviously what Dijkstra did. I don't think he just had some axe to grind against `goto` for his own personal reasons. During my career I've encountered my own share of practices that I think are overused and misunderstood, and I don't need to say what they are (and thus hopefully I'll avoid a flame war), but if you've been at it for more than a few years, then I'm guessing you have some similar opinions.

I actually have nothing against "considered harmful" essays as a whole, and I often learn something from them. That said, of course you shouldn't overstate your position, which would be intellectually dishonest. For most of the problematic practices I've encountered during my career, there are some valid use cases, and it's more that they're misunderstood and misapplied that would warrant calling them out.

Anyway, I hope I've made my point.

The author of the article definitely seems to think LLMs are what enables this to happen, but I personally am much more skeptical of that. I think what it really needs is bringing engineering back into software, not just throwing LLMs at it and calling it a day.

edit: Sorry, to clarify, this was a function involving trigonometry but not simply vanilla sine or cosine. However, angular values being represented in radians did help in the same way I described in the parent post.

I expect many systems that use trigonometry would sometimes use small-angle approximations either for efficiency or to bootstrap to the general case. It'd be natural to use Taylor series here, i.e.:

    cos(x) = 1 - x^2/2 + ...
    sin(x) = x - x^3/6 + ...

    cos(2 pi t) = 1 - (2 pi t)^2/2 + ...
    sin(2 pi t) = (2 pi t) - (2 pi t)^3/6 + ...

Closely related to this, if you ever need the derivative of a function that does trig (e.g., in numerical optimization), you may as well use radians because if you don't, any extra factors you apply will appear in the expressions for the derivatives and you'll have to deal with them there anyway.

Basically for that reason, it's pretty clear that trigonometry in terms of radians is the "correct" convention mathematically speaking (away from computers), since derivatives of the radian-based trig functions are so easy to express. Given that, if we have to pick one convention...isn't it less confusing to use the same thing everywhere? That said, there are interfaces that provide both versions, and since as the article points out there are cases where the turn-based versions can be more efficient, that's probably the right way to go.

> But rejecting code not for technical reasons (of which there are often many for vibecoded code) but for ideological reasons is unfortunate. [...] Such a policy — that contributing to a project because of the circumstances of the contribution’s creation, and not due to its quality — is directly contradictory to the spirit of free software.

Okay, what is FLOSS? Software published under free and open-source licenses. It's literally the definition of the concept, and thus a FLOSS project cannot accept contributions for which such licensing is impossible, regardless of technical quality. For example, a FLOSS project can't accept code copied out of a nonfree project, or copied from a project with an incompatible license. The provenance of the code has always been central to the whole endeavor.

When LLMs enter the picture, there are at least two problems.

1) LLMs were trained largely on copyrighted works, and it's unclear if the models themselves or their outputs should be considered to be derivative of their training data.

2) It's possible that LLM outputs can't be copyrighted at all, not as FLOSS or under any other license.

I won't try to get into the many arguments and opinions on both sides regarding those issues, but suffice to say they're contentious enough that, regardless of where an individual maintainer's opinion may fall, IMO it's definitely not wrong to refuse to accept LLM-generated code just to avoid needing to resolve them.

The "spirit of FLOSS" was never primarily about the technical quality of code, but about the freedom to use, study, modify, and redistribute software, although technical quality also benefits in some ways from the FLOSS ethos. I actually do care deeply about technical quality as well, so I have to mention that many of us have serious doubts about the overall effects of LLMs on software quality in the long term. Even if individual maintainers can maintain high standards for their projects, IMO promoting LLMs still creates long-term downward pressure on software quality that comes back to harm everyone.

Uh, this isn't true, though? I squash commits all the time locally before I publish them. There can be many reasons for that, but at the end of the day, I'm not obligated to share my messy revision history with the world. In the most extreme case, the first commit on one of my projects spans multiple years of development because it was forked from another project that's now pretty irrelevant to it. On the other hand, I've received pull requests that were a couple dozen lines and were definitely LLM-authored.

As sort of a counterpoint to the author's goals, IMO the community should extend the benefit of the doubt to writers and artists who explicitly say they don't use AI, because it's just really hard to prove that you're not using AI. Trying to force any kind of system will inevitably affect the quality of what you make, and the art community should not want that.

(You don't have to mention LLMs every time you use them because sometimes the credit really doesn't matter.)

> But for the first reason, I’d challenge the notion of sharing credit with a tool, let alone feeling like a cheat for using one.

That's the main reason LLMs aren't "just a tool."

> Credit and accountability are two sides of the same coin. A tool can only take as much credit as it can be held accountable for, so crediting it inadvertently dilutes your own accountability for the work.

Huh? No, credit and accountability are pretty orthogonal. I use tons of open-source tools, and everyone agrees that the respective authors get credit for what they made, but only I am accountable for my use of them. In fact, all open-source licenses spell this out explicitly.

The barrier is low, but the benefit is negligible or even negative. You're outsourcing your creative process to some mega-corporation. What you get back from it might be interesting to you, but it won't be to a lot of other people except maybe as a novelty, because it's from the same megacorp that sells its services to everyone else. I know some people seem to genuinely enjoy the outputs of the AI models now, but the novelty hasn't worn off yet.

Also, congratulations, you get to live with the stigma of being an AI slop pusher. And if you try to pass the work off as your own, good luck hiding the truth for the rest of your life, because you'll never regain trust if people find out.