The bit in the middle where it decides to make its control loop be pure P(roportional), presumably dropping the I and D parts, is interesting to me. Seems like a poor choice.
I try to fly about once a week, I’ve never really tried to self analyze what my inputs are for what I do. My hunch is that there’s quite a bit of I(ntegral) damping I do to avoid over correcting, but also quite a bit of D(erivative) adjustments I do, especially on approach, in order to “skate to the puck”. Density going to have to take it up with some flight buddies. OR maybe those with drone software control loop experience can weigh in?
In some circumstances, yes (usually when the system itself acts as an integrator somehow). Aircraft controls do not strike me as a system where this is sensible (trimming an aircraft is basically an integral control process).
(d'oh, should have read the specific context: in the case mentioned, it is where the system acts as an integrator (pitch -> altitude), and so pure P control is pretty reasonable)
> All of this article, both the good (critique of the status quo ante) and the bad (entirely too believing of LLM boosterism) are missing (or not stressing enough) the most important point, which is that the actual programming is not the hard part. Figuring out what exactly needs programmed is the hard part.
HARD AGREE. But…
Taken as just such, one might conclude that we should spend less time writing software and more time in design or planning or requirement gathering or spec generating.
What I’ve learned is that the painful process of discovery usually requires a large contribution of doing.
A wise early mentor in my career told me “it usually takes around three times to get it right”. I’ve always taken that as “get failing” and “be willing to burn the disk packs” [https://wiki.c2.com/?BurnTheDiskpacks]
Indeed! I got to about 20 with A-B-C but it somehow became harder after those. The multitude of C-something is obvious but I didn't realize there's so many A* languages (apl, ada, agda, alice, algol, applescript, apex, ampl, assembly..)
Our small team has a lot of commit messages like this. For a while, we had a guy on the team who had come from a site that expected more. The pet peeve he brought along was that commit messages end with a period (my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences). When I look at that period of development, I see lots of messages like “stuff changed.” And “more stuff changed.” And then it goes back to just “stuff changed” around the time they moved on.
> my guess is that someone at their previous work place had reasoned that forcing periods encouraged developers to actually write meaningful sentences
I have actually seen proper capitalization and correct conventional-commit types to correlate very well with the author being intentional and the patch being of good quality.
e.g.
- (a) chore: update some_module to include new_func
- (b) feat: Add new_func to handle XYZ case
Where:
(a) is not a chore, as it changes functionality, is uncapitalized and is so low-signal I can probably write a 10 line script to reliably generate similar titles.
(b) is using the correct "feat" commit type, capitalized and describe what this is for. I expect the body to explain "why", as well, and not to reiterate the "how" in natural language.
This is just my experience, but I've seen commit messages where people actually put in some effort to usually come with a good patch, and vice-versa.
Mac OS has become what would happen if Harley Davidson merged with Volvo Truck and some high up said that to "reduce costs" and "homogenize the brand", the design groups needed to be merged and put forward a unified design. If I was less lazy, I'd have a !AI thing whip me up a mashup drawing.
> When you eat a strawberry do you feel like an impostor for not growing it yourself?
I don’t think this is the right question. What you posit is a consumption dilemma. It’s a valid question, but it focuses on what values we might arbitrarily ascribe to how we source what we consume.
The OPs dilemma is more akin to giving a cutting board for Christmas that you bought vs handmade. Or some other. I think these cases of how we present what it appears we created is the dilemma OP is facing.
Multiple economic write ups have concluded that Reagan’s “stick it to the upstart guy” cost us tax payers way more than it would if they’d just acceded and maybe even thrown in a gracious bonus to say thanks.
Larger sociology say the intangible cost to labor balance laws actually were much more.
Reagan’s trickle down (great euphemism for “piss on”) movement was the beginning of the demise of the GOP IMO. Disclaimed: I voted both times for him and many GOP followers.
It’s also the only industry that is legally allowed to practice ageism. You have to start before or up to 31 years of age. You’re out at age 56. This figures into how the benefits are structured.
Certainly not all departments, but many fire departments have an upper hiring limit for new hires. Above that age you can only be hired as a "lateral" (transfer hire from another department).
I would guess they’re better at python and SQL than Haskell because the available training data for python and SQL is orders of magnitude more than Haskell.
I try to fly about once a week, I’ve never really tried to self analyze what my inputs are for what I do. My hunch is that there’s quite a bit of I(ntegral) damping I do to avoid over correcting, but also quite a bit of D(erivative) adjustments I do, especially on approach, in order to “skate to the puck”. Density going to have to take it up with some flight buddies. OR maybe those with drone software control loop experience can weigh in?
reply