Here, this is standardized, and if a local subscription service provider wants to pull money from my account I explicitly grant them permission to do that, which I can revoke at a later point.
> What might not be clear about this is that a struct loses runtime information. If you want to iterate a map, that's easy: call for (key, val) in map { .... If you want to iterate a struct ... get fucked? write a proc-macro?
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};
}
The combination of high dynamicity at compile-time with low-effort switching between compile-time and run-time contexts makes this not too bad.
I've given up on Audacity because it hasn't kept up technically with how a typical home studio Linux system does audio, and looking at the change log it seems like they haven't addressed any of the problems I have with it in version 4.
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.
If you watch the admittedly long video from Tantacrul about what it took to get from 3.0 to 4.0 he talks about that. They had a lot of tech debt that made it impossible to update the audio engine. He talked about the new engine being the roadmap for 4.1.
I saw the Tantacrul video back when it was released. I think that's when I went ahead and bought myself a personal Reaper license. My thought then was: wtf are their priorities like if they'll focus on a complete overhaul of the admittedly basic but functional interface over broken recording and playback of audio?
There were a bunch of minor versions between 3.0 and 4.0 made up of fundamental refactor work to establish separation of concerns. As I understand it from the call graphs he shared, the problem was that the UI was reaching deep into the audio code directly instead of using a clear API boundary to separate concerns and route commands and change state. So fundamentally while the UI worked, it also was deeply entwined with the audio engine and changing any of the audio back-end basically broke things downstream in unexpected places and couldn't be swapped without deep UI work anyway. So, if you're going to have to rewrite your UI layer to disentangle it from your back-end anyway why not also bring it up to speed? Let me repeat that to be clearer: The UI had to be changed internally in fundamental ways to do any work on the audio back-end and they chose to also uplift the design and UX while making it easier to replace the audio engine in a future commit.
Because they have 10 people working on it and they can't boil the ocean with that kinds of resources. If you try to do all the things at once, then you get nothing actually to the finish line. You'll be getting what you want in the next point release.
I don't think you understand the problem they were facing. If they rewrite the backend it would also REQUIRE rewriting the frontend because of how entangled they were. Whereas rewriting the frontend did not require changing the backend as dramatically. So their choices were:
1. Rewrite the whole thing, all at once, ship nothing for a long time.
2. Rewrite the frontend, ship changes incrementally, then move onto the backend once it's been excised from the tangled mess.
I think you may be underestimating how important playing back and recording audio is for an application built for that purpose.
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.
Wow. I ran into a subset of a few weeks back when all I was trying to do was record from a specific microphone connected to my laptop. I thought I just didn't know what I was doing! I gave up after 20 minutes of fiddling and used something else that saw the microphone immediately.
The humorous LLM-generated blurb Google frequently places before the useful search results once referred me to Grokipedia, an LLM-generated repository of vibe-facts seemingly created more to illustrate some reactionary point than to actually serve a practically useful purpose to anyone.
> The "67 cents" part though is misleading imho. You can't extrapolate from there and think that investing say $100 will get you a lot better results.
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 remember the "onboarding experience" essentially being losing over and over again and learning from my mistakes, getting a little further or trying a new approach altogether on each new attempt. Maybe it's an acquired taste but by the time I started playing Dwarf Fortress, I was not only already used to that, but thoroughly enjoying it as a core mechanic of games like Rogue, NetHack and Ancient Domains of Mystery.
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.
Some games are not fun to anyone, that is what I'm talking about for fun in generality. Games must be fun for someone, at least some number of people, to be called a good game. Some games get there with a good onboarding and some do it despite that as I said.
Sure, maybe someone may enjoy Dwarf Fortress despite that, but as I recalled from my own experience, it wasn't despite it that I enjoyed getting into Dwarf Fortress, but in large part because of it.
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.
Sidenote, but what's with the ref=mdubakov.me query parameter attached to every link? Are there benefits of this over the "Referer" HTTP header other than trying to skirt around my configuration choice not to share my browsing history?
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.
Including the making of the posts
into nice rectangular portions of
each thirty three characters wide ?
Not including the double space at
the beginning of each line or any
of the punctuation character ends .
reply