fargle

well written and interesting. although i really do love the technical deep dives.

i am fond of using the cargo-cult analogy, and invariably many people have not heard of it so the story is told and retold. i'm fairly happy that my usual descriptions of the phenomenon were much less inaccurate or exaggerated than they could have been; generally closer to the John Frum reality than the "pop-culture" one. not at all like mondo cane (which i was unaware of). for example, i've said something like "to this day, there is a cult in which members paint themselves USA 'uniforms' and march in military style with 'guns' made of sticks'" (which appears accurate). i completely missed, however, the pre-ww-ii "cargo cult" beliefs which add quite a different perspective.

unfortunately, i don't know if i quite agree with abandoning the metaphor. the literal Feynman quote is about science. we in engineering have co-opted the term and use it (when imho done correctly) in a Feynman sense. i describe it as an Feynman anecdote. but it is one with significant grains of historical truth.

i find the curated list of HN examples illuminating because it appears that 1/2 or more of them are using the analogy poorly, missing the point, or simply as a kind of slur. meta-cargo-cult if you will. it is as said: "is simply a lazy, meaningless attack". i agree that it is heavily misused.

but in the conclusion, this leads to an argument that i see as a bit of a false dichotomy. i don't agree that Feynman's central point was either "doing something that has no chance of working" or we (mis)use it as "works but isn't understood". when Feynman said "but it doesn't work" i think meant within the analogy it didn't work: the planes did not show up. i don't think that when applied to science or engineering it only applies to something that "doesn't work". i think it's very much more about the central fallacy at play: misunderstanding processes that are built to support the science as being the science itself. misunderstanding effects for causes. misunderstanding and generalizing specific observations where they don't apply.

i think Feynman's anecdote is close enough to the anthropological one and not really detailed enough to be considered wrong. it's factually true that john frum cultists do what they do. the reasons they do it aren't quite right in our stories, but clarifying all the anthropological history doesn't kill the analogy, it might even strengthen it.

to me, used correctly the analogy is describing a religious or cultish adherence to principles that are not understood, in the hopes of some desired affect happening. it's similar to affirming the consequent. the fact that real cargo cults developed prior to ww-ii in places affects the story telling, not that its a cult. the fact that it's dangerous and harmful to the adherents is a good point for the analogy. the fact that the cults developed partially as a result of decades colonial oppression and mistreatment is a better framing than "look at the dumb thing those ignorant savages did". the fact that the cult members are expending energy which harms them for reasons they do not understand is still the truth. i've certainly never been as glib as "US soldiers show up with their cargo and planes, the indigenous residents amusingly misunderstand the situation, and everyone carries on."

the points about it being insensitive are well taken, however. no doubt.

- certainly there's a large amount of misuse of the analogy. and these uses are misused whether it be relative to pedantically accurate anthropology, Feynman, or pop-culture variations. but people using an analogy wrong does not make the analogy wrong.

- i think it's fine to use an anecdote and an analogy to communicate an idea about a harmful phenomenon. the anecdote does not even need to be true at all. but in this case it isn't too far off, depending on the story telling. Feynman's short description doesn't seem as extreme as what is described as the "pop-culture" definition.

- it can certainly be told in a way that is very culturally insensitive. i think this could also be done in a more neutral manner, but it's something to be careful of for sure. certainly, sticking closer to the history would probably improve things, however this may be the achilles heel. (in other words, out of all the reasons for abandonment given, i'm most convinced by this one)

- the biggest issue, for me, left is this: what do you recommend replacing this with if we avoid it altogether? the imagery of religious behavior is a big part of what that analogy covers. and the ideas of observing something and then copying those behaviors to achieve a result without any real understanding.

anyhow, thank you for a very thought provoking article. i'm clearly not as good of a communicator as you are (or Feynman).

that is all true. but admins need to be aware of the reasons other groups desire to go around them. obviously they needed some patches on their database product.

OK, what's the easiest way to get it? option 1: call the IT admin and say "hey bud, can we get these patches and see if it fixes my thing?" or option #2 play some political long game to get sudo vi access via intense political pressure and then hack into the system to install said patches.

if you have to do option #2, then it's the FAULT of the IT system: people follow the path of least resistance. if there was so much hassle having a support organization actually help you such that it was actually easier to do it yourself and fighting (and winning) some political fight with the other dept. to get there, you tell me what's wrong with that support org?

this is why DevOps is an improvement.

you're trying to point at the auditors as being the dicks? nope. any engineer in the company can be equally responsible for configuration management. wanna bet that the IT dept. has no process to allow other engineers to update configuration? or that they won't do it on your behalf in a timely fashion? simply delegate the patch configuration management of the DB to the DBAs and send the auditors to see the experts. there's a good chance they'd take the responsibility seriously and do a better job of it than you.

yes. most very large corps. that like to keep patent portfolios will encourage engineers to patent (assigned to the co. of course) anything slightly creative or unusual. or sometimes anything at all that sounds slightly technical.

the engineer gets his name on the patent and maybe a bit of prestige. the org gets another (sometimes bad) patent in the portfolio.

skimming the patent https://patents.google.com/patent/US4135240A/en it seems actually pretty well drafted and pretty good (patentable).

they only needed a backdoor root because you're a gatekeeping dick and they wanted to get their job done without having to "deal" with your shit.

OMG. they applied unapproved patches! to the product they were responsible for making work.

that's pretty low effort, so not really. but cool. win-win.

> Also no matter how complicated and subtle you think your [thing] is, true experts will tell you it's wrong and you instead copy their apparently over-engineered, hard to understand [thing]

not unique at all to makefiles, probably not even in the top ten [things] that "true" experts like to "help" with

can't upvote this enough. the only (minor) issue i see is the checkout -b shortcut feature is unnecessary and could be confusing if learned before a canonical approach that emphasizes that those are two things - checking something out to the working tree and creating a named branch pointing at it.

other than that, contrary to sibling comments, no the rest of checkout is fine. yes it has guardrails that are perhaps not 100% consistent, but i don't think they every could be. but guardrails or not, when you say `git checkout <versionish>` it trys to checkout the <versionish> version to the working tree. it's highly intuitive that `git checkout <versionish> <filename>` it doesn't do the whole tree, but only that file (excellent for reverting a single file).

i don't want git checkout to be called git switch or any other nonsense. git checkout checks out a version and that is terminology common with just about every cm tool ever.

git reset is a hot mess. the blog post should be about that mess, not checkout.

i've seen that exact image posted semi-regularly on various reddit and facebook groups. (it's one of 500 things i hate about those sites. but for some communities that's where the information lives, that's where marketplace lives, etc., so i'm stuck with it)

these kind of things are intentionally wrong "puzzles" that are designed to get hundreds of people mad and post rebuttals to "drive engagement" or whatever. the pictures of a wheel with sledgehammers and chains and jacks with lugnuts plainly still in place and a post "how can i get this off it's stuck and i've tried everything". sigh... it's just another form of trolling.

sure enough, notice the sibling comments here. how many nice people took the time to patiently explain the fallacy(ies) for the 1000th time. then the pedants who correct the grammar/math/etc. in the 98% correct explanations. then the "true believers"/trolls who don't get it and argue back. and so on.

https://xkcd.com/386/

i think you got the wrong eponymous law, pournelle's iron law of bureaucracy (which i see happening all the time, btw.) has nothing to do with this issue.

i'll bite. care to expand? is this a riff on copy-pasta or spaghetti code or what?

calling this "Makefile" effect is a terrible disservice. one could as easily call it "PHP" effect, "YAML" effect, etc. pick whichever language you'd personally like to denigrate.

there is nothing that makes makefiles inherently more or less susceptible to this. if it's more common, it's because people don't want to take the time doing more solid engineering and clean design for something like a ci/cd config or a makefile, being viewed as ancillary or less important. and so they often don't want to learn the language, so monkey-see-monkey-do.

as sibling comments state, this is better called cargo cult or maybe copy-pasta. and i've seen it with any language c, c++, python, scripts, config files, anything. i even see it in chat gpt answers because it's regurgitating someone else copy pasta.

if it's a problem, it's a problem of discipline.

when i was much younger, i had bought my first car which was well over 20 years old. a gigantic boat of an early 1970's ford. pretty much the family truckster. it had the four round headlights. outer two are low/high beams and inner two are high beams only. so when you had high beams on it was all four high-beams.

now, myself and my young wife were on a vacation and it was late, like midnight and i was trying to find a hotel for the night in a small town. i got pulled over.

the reason? i "blinded" a police officer because i had the high-beams on. i hadn't realized it. he pointed to a dim little red light on the dash (i didn't know what that was). even with 4 high-beams on and my young eyes, it was still a struggle to see in the dark night.

the officer laughed at me trying to turn them off. nope - that's the windshield wipers. that's the thing to tilt the wheel and so on. he said: "did you happen to notice that big switch thing on the floorboard?" (i had not). "push it with your foot" and then "have a good night" as he chuckled and disappeared.

that was a long time ago, but who else remembers real high-beams and floor switches? or even knows that was a thing?

i'm a rabbit-holer. follow the chain of interesting links from one article to the next over and over to see where i get to with hardly any backtracking. after about 5-6 links it's pretty random. after about 20 who knows where you'll end up.

low information article, perhaps one or two sentences that address that "why", a poorly framed milquetoast word salad basically ascribing it to risk posture.

it's not risk posture, and it's not muskly engineering genius either. it is culture.

i'm not sure space-x is 100% healthy, but they're clearly getting things done. what is crystal clear is that nasa culture, and that of it's major contractors like boeing, is terminally ill.

you need good engineers, not mediocre bureaucrats, and you need to pay market salaries and have an acceptable work culture to hire and retain those engineers long enough to become experienced.

exactly. if too much money was a problem, there's a trivial solution.

so i'm guessing the problem isn't really that bad, eh?

"When he couldn’t put his double major in English and history to use"

"I’m sick of partying. I did that already."

whether or not you are right about the impact of policy choices, you still can't ignore personal responsibility as well. if you party your way through school to get a useless degree, then double down for a law degree you don't (or can't) use for unspecified reasons, i don't see how any policy is going to have a different outcome.

the idea that if all you did was get a college degree, didn't matter in what, and you were on "easy street" hasn't been true for at least 30 years before he graduated, probably never was.

i think you miss my point. trump is obviously further right than either biden, kamala.

whatever the relative left-ness of those choices where, it was obviously so much so too far left for about 2million+ people who, to be gracious, decided to hold their noses.

so i'm left completely flumoxed why it's not blindingly obvious. at least at this point in time, those candidates' platforms seriously missed the mark. if those folks that were centrist-ish enough to even consider "holding their noses" to vote for trump, i can't imagine how they'd be supportive of anything even further to the left of the choices they had available and fairly rejected.

how would moving further left capture those voters? (those willing to vote trump, perhaps marginally)

i know it's not just right vs. left, but in this case all the other things seem to either be trump disadvanges (personality) or about the same for both of the two poles. nobody in the whole election seemed to be able to string a coherent sentence together, for example.

> You're asking for a lot of evidence on what's overall the opinions of an entire country

we literally just had a referendum on that. moving further left from 2016-2020-2024 lost voters. how pissed off do people have to be to have that result? that implies, very strongly, to me that there is a huge segment in the center-left to center-right that is really irritated right now. not bernie's group for sure. although he seems more center compared to the "squad". you should thank them for that.

the center.

you know, the existence of which just changed the course of the latest election...

> The centrist Dems always blame those further left, not themselves. They did it in 2016 and this year too.

well, unless there is an big untapped electorate even further left, that would make a lot of sense actually, wouldn't it?

agree mostly, although i'd quibble at saying: "So it is not really that they cannot code". i'd certainly say that being able to open an editor and pound out a functioning 20 line program from scratch is a requisite skill for saying you can code.

"Whether or not you want that to be a deal-killer" - exactly. as annoying as these stupid tests are, at least they tell you something. it's surprising how much so.

f-18 is built by boeing for the last 30 years

no agenda? no outcome? i'm not going!

the very last paragraph contains a quote:

> At most, he would have been stopped, detained, presumably given a summons of some sort, they would have taken the bike and it would have been over. That was it. Was that worth killing over?

instead of asking that, the question should be "was it worth dying over?".

an Enum of Arrays would be an enum where each enumerator was a product of each possible enumerator. there would be N^M enumerators where N is the length of the array and M is the number of enumerators. for example, if the original type was enum { red, green } then the enum of array[3] would have to be an enum containing the 8 enumerators:

    { red-red-red, red-red-green, red-green-red, red-green-green ... green-green-green }

so that's essentially completely useless. i think the exact same problem would occur with array-of-tagged-union to tagged-union-to-array "transformation".

you can't just say "hey: arrays and structs and unions are words and if you can do array of struct and struct of array and enum is also a similar word, then why not enum-of-array?".

while tfa talks about "batches" of items with the same tag, and the advantages therein, that isn't something captured by the example given, at least without extending the EoA to a variable sized array of EoA and something else to track the number of items in a "run" (as in RLE).

this is better thought of as a data-structure problem than a type theory.

100% certain that Kim Jung Un, and to a large extent Iran, don't understand, care about, respect, or have any interest in "Nash equilibrium" or game theory. nor are they worried about their countrymen, their own survival (they are gods, you see) it's a delusional echo chamber. Putin is probably much more rational, and also much more dangerous, but the same considerations apply. if he needed justification (spoiler: he doesn't), it would be done, and not with a paper like this.

> Is the author vying for a seat at the right hand of the devil?

certainly not, that's extremely uncharitable. the paper could be better understood as a warning for the rest of us not to rely on a simple theory of MAD to assume "safety" when it comes to things like tactical nukes and escalation. don't blame the messenger for the way the math works out. however, i also think the implicit assumption of rational (vs. ego based) decision making is flawed anyway.

    The main point drawn on the findings of this paper is that the current cycle of escalation, globally, between nuclear powers simply
    needs to be stopped. The risks of it spiraling out of control, and/or creating a world where nuclear weapons would be used regularly
    in wars, lowering the threshold of the world drifting into a nuclear holocaust considerably, are just too great. The world needs,
    and majority of its populace wants, peace now more than ever.

    I hope modern leaders heed their voice and the warning presented in this paper.

submodules may or may not be annoying to use in a particular use case, but they work perfectly (in that they do what they do, not necessarily what you want/expect)

from your comment, it sounds like you might not have the exact mental model of how they are expected to work?

> then notice that the submodule lags behind the remote git repo

the version of the submodule is staked to an exact commit hash in the main (outer) git repo. the use case is that the submodule should not "float" or change - if you check out a particular commit in the main repo, it will always point to this same submodule commit

if you change the main repo branch, etc. you additionally have to ask to sync up the submodule for that new commit. i use:

    git submodule update --init

instead, if you want to update the submodule to a new commit (e.g. to latest master branch), you have to enter the submodule, checkout the branch and pull. then in the main repo, you will add the submodule and commit it to link to the new submodule commit.

so that can be annoying of course. but i find it works extremely well for submodules that are dependencies that you want staked to an exact version.

what i said was "a superset of IP with a different packet format and wider fields"

well, yes obviously you need more bits. what you don't need is all the other changes.

> I really hope you stop respond in to people with nonsense before you look at the packet structure yourself.

don't be condescending.

> address space extension in a way that doesn't break backwards compatibility.

i didn't say it wouldn't break backward compatibility - you're moving the goal posts. what i said was "a superset of IP with a different packet format and wider fields"

> arm-chair protocol engineers

don't be condescending. i've likely been designing protocols for longer than you think.

> Remember, you need to be specific how you would add the change and how it would keep backwards compatibility.

if all you had to do to deal with IPv6 was bigger addresses and a slightly different wire format, it wouldn't have had the barrier to adoption. don't design an entirely different protocol. the wire format is the least of the problems.