boomlinde

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.

I don't see how the example would benefit at all from having that information at run-time when it exists at compile-time. The problem with Rust specifically I think is that it's a relative PITA to get to the information that exists at compile-time in this case. In Zig, you'd just iterate over the fields using the same language you use for run-time code.

    const fields = std.meta.fields(@TypeOf(instance));
    inline for (fields) |field| {
        const name = field.name;
        const value = @field(instance, name);
        std.debug.print("{s}: {any}", .{name, value};
    }

So, if you're going to have to rewrite your back-end to disentangle it from your UI layer anyway why not also bring it up to speed?

This was already a widely adopted piece of software. It was my go-to for light audio work like trimming a sample, for being free and easy to use for exactly that.

You'd think, well, it supports JACK, so you're gold on both JACK and Pipewire, but they only do this in an extremely annoying way. It doesn't create a persistent JACK client. Only when you start playback or recording does it temporarily create a JACK client which disappears when playback or recording stops taking any connections you've made to it with it. The temporary JACK client then must autoconnect to a sink or source, for whatever reason that is neither a limitation of PW nor JACK.

So you'll undo this jank with an automatic connection manager, right? You'll configure it to immediately disconnect from whatever Audacity decided to connect to and automatically connect it to the source you want to record. Well, they've given the short-lived JACK client the brilliant and informative name "PortAudio", which is of course shared by other applications using portaudio. Even more brilliantly, the I/O ports are given new names on each new client!

Some while ago I started Audacity up (having forgotten that it's broken) and got invited to a user survey. There was no concern at all in the survey about the thing that Audacity fundamentally does. Do I want it to be a DAW? Do I want to be able to buy plugins within it? Do I want AI features?

Merely being asked these questions while their broken JACK implementation persists pissed me off. I want it to record and play back audio first of all. Audacity 4 looks like it's in the bizarre situation where it kind of looks like a well-designed DAW but behaves like it doesn't care about audio.

So are you wrong in saying generally that it's "despite its terrible onboarding, not because of it", or am I coping by lying? Mind you, Dwarf Fortress is preceded by a whole genre of more traditional Rogue-like games that made losing hundreds or thousands of times for a lack of knowledge of the games' systems before you figured them out a fundamental part of their appeal, so I'm not exactly alone in this.

Nothing about saying that it cost 67 cents implies that it will. Knowing only that it costs 67 cents you also have no reasonable basis for extrapolation. It doesn't indicate a trend whatsoever.

I don't believe in the concept of "fun in general" in the sense you imply here. I've played very successful games that have evidently achieved popular appeal but that nonetheless turn me off because they're the absolute opposite of Dwarf Fortress: carefully manufactured designs of intentional experiences that you are guided through at every step. Some people really like that, some will want to be thrown in the wilderness with no clue, some want something in-between. Different strokes for different folks.

Then you're inventing a phonetic alphabet that happens to look like the English alphabet. That's what makes discussions like this are pointless. No one has established a phonetic definition of "le" or "el", which is the only basis according to which one can decide which is phonetically more appropriate.

  Deliberate distractions
  from the functional end
  goal benefit other arts
  just as well, promoting
  lateral thinking. Brian
  Eno made a card deck of
  "oblique strategies" to
  help you out of blocks.

I imagine that GP's reasoning is that in writing "missile", the consonant is followed by a vowel, while phonetically the vowel is followed by a consonant.

The issue is further compounded by the fact that there's more than one common pronunciation of "missile".

I am refuting that statement by showing that not allowing dynamic executable code is not enough. It is irrelevant to that end that you can mitigate ROP by other means.

The implications of the crash depends entirely on the implementation of the process it crashes. If I use ffmpeg as a library it'll crash my process upon processing the offending file. How is my process designed? How is every process that uses ffmpeg designed? You don't know, therefore you can't say that it's a "self-dos" in every case even if you know that it is in some cases.

Maybe I am clever enough to have read up on the history of ffmpeg vulnerabilities before deployment to an attacker-facing service and have designed a solution where a crash has minimal implications, but maybe I'm not, and haven't. It's beside the point.