boomlinde

What's this new approach they're trying?

I'm thinking their lives must be absolutely dreadful for this constant fear of being left behind.

That you used an LLM to "confirm" the bug is an example of such non-information. The reproduction testcase and/or the reproduction steps and description of the expected outcome confirm the bug.

"[...] without ever reading a single line of code" begs to differ.

How do you know that it's verifying that the system under test exhibits the properties you desire without either understanding or making blind assumptions about the code it generates to build a fuzzer or a property test? It seems to me that you have just shifted the problem of verification elsewhere and introduced another potential source of error.

    sin(phase + modulator * modulation index)

> CPU timing, chipset behaviour, ISA and PCI buses, graphics chipsets, sound devices, and disk controllers all matter to getting period software to behave properly.

Why don't your chatbots just write clear, well documented code?

As far as specifications for changes go, the diff itself is as good a spec as it gets. It unambiguously describes the exact change that was made. The prompt you give a chatbot to make that change is IMO something else. Maybe it's more fair to call that a specification of the work you wanted it to perform.

The reason is that the commit message log serves as an overview of the changes commited. That's what humans use it for, anyway: to get an idea of what happened since they last pulled, to help give an idea of where a regression might have been introduced and so on, at a glance. To that end, brevity is very useful.

My understanding is that chatbots used to perform such tasks will also benefit from brevity.

I remind you that the belief you are defending is that an increase in the number of bugs produced per some unit of implementation "implies that testing and validation has gotten worse", not the general idea that you can or should improve software quality by improving testing and validation.

If we adopt the realistic perspective that the testing and validation process can only catch some fraction of bugs, then an increase in the number of bugs produced in the implementation stage is bad irrespective of what that fraction is. You can improve the testing and validation process so as to minimize the fraction of bugs that get past QA, but when you multiply that by the number of bugs produced in implementation you will be worse off if you produce 7 bugs per month during implementation than if you produce 5 bugs, regardless of whether you can also improve the testing and validation process. You will on average, over time, have fewer bugs in production if you produce fewer bugs during implementation given any testing and validation process that isn't completely fool proof.

It does by, attributing a change in quality to a "testing and validation problem".

If there is a change in programming methodology, as far as we know no change in testing and validation methodology and at the same time an increase in the production of bugs, it's not reasonable to attribute that increased error rate to testing and validation getting worse.

It's like adding spinning saw blades to the fronts of cars and then attributing the increased fatality rates to pedestrians not wearing safety reflectors.

With that in mind, writing bad code is bad.

Yes, which you didn't respond to until now.

> And that’s far too broad in my opinion.

Similarly, it's far too broad to say that it's "much less error prone" to use a more general allocation strategy. Clearly we both make unspoken assumptions, but in the context of this discussion on Zig, where you initially responded to an example written in Zig, I think you actually understood what I meant.

I also disagree that this is "the focus" of Zig. Technically speaking it seems like a rather minor design choice for the standard library.

Zig doesn't force or even tends to prefer one way or another. If I want unassuming heap allocations that can be reclaimed in any order, there's an allocator for that. If I want an arena to discard at the end of something like a request or a video frame, there's an allocator for that. If I want to use a fixed backing buffer for the allocations, there's an allocator for that.

The point is that the standard library doesn't assume one or the other, which seems good if the problem is that "real world software just isn't that simple" in the more general sense that there's no one-size-fits-all allocation strategy.