The relationship between dairy/meat and inflammation is more nuanced than that. While some studies show associations with inflammatory markers, others find neutral or even anti-inflammatory effects depending on the type (e.g., grass-fed vs grain-fed, fermented vs non-fermented dairy) and individual metabolic context.
You're right that ratios matter enormously, but optimal ratios vary significantly by individual - genetics, activity level, metabolic health, and existing conditions all play roles. The overconsumption concern is valid for processed meats and in the context of sedentary lifestyles with excess calories, but the picture is less clear for whole-food animal proteins in balanced diets.
The real issue might be less about meat/dairy per se and more about displacement of other beneficial foods (fiber, polyphenols, etc) and overall dietary patterns. Many Americans do overconsume calories generally, but some subpopulations (elderly, athletes, those on restricted diets) may actually benefit from more protein.
> When C code is run in machines capable of failing with gruesome death, its unsafeness may indeed result in gruesome death.
And yet, it never does. It's been powering those types of machines likely longer than you have been alive, and the one exception I can think of where lives were lost, the experts found that the development process was at fault, not the language.
If it was as bad as you make out, we'd have many many many occurrences of this starting in the 80s. We don't.
How was this flamebait? It is an example of how bad programming choices/assumptions/guardrails costs lives, a counterargument to the statement of 'And yet, it never does'. Splitting hairs if the language is C or assembly is missing the spirit of the argument, as both those languages share the linguistic footguns that made this horrible situation happen (but hey, it _was_ the 80s and choices of languages was limited!). Though, even allowing the "well ackuacally" cop-out argument, it is trivial to find examples of code in C causing failures due to out-of-bounds usage of memory; these bugs are found constantly (and reported here, on HN!). Now, you would need to argue, "well _none_ of those programs are used in life-saving tech" or "well _none_ of those failures would, could, or did cause injury", to which I call shenanigans. The link drop was meant to do just that.
Politics and leadership is a responsibility. By avoiding it, you're setting a bad example. Once you know how an organization works, you should help lead it.
If we consider a family, you're essentially saying you'll only "do the work": brush teeth, feed kids, clean up, but not take on any responsibilities for the actual goals of the family. Not pushing to have your kids learn things, just executing somebody else's ideas, driving them to sports; not improving the living situation by perhaps investigating if you should get a bigger car. Nothing leading, only executing the ideas of your spouse.
I exaggerate of course, but there is something there.
You say that as if politics is optional. It isn't, decisions need to be made and politics is the process of making those decisions: who decides, and why.
In academia, for example, there is less politics because the publishing system sort of becomes the decision process. You apply with your ideas in the form of papers, the referees decide if your ideas are good enough (and demonstrated well enough) for the wider audience to even get to see. Then some politics, a popularity contest. But crucially this system famously leads to a LOT of resources being wasted, good research that never goes anywhere because nobody cares about it, or bad research that does nothing but everyone cares (cold fusion).
Politics is just a name for how we decide things. And yes, it sucks, but that's because we suck.
With this understanding of academia, you are perfectly suited to doing software development for them, because if you think there is "less politics" in academia, you are being foolish.
Academia is notorious for politics, especially around tenure and grants, scholarships, etc.
Publication politics are just a small part of that, but even there, working out which name goes in what order of the authorship of the paper is political.
Academia is not more notorious for politics than a corporate job, in my opinion. I've done both. Academia tries its very best to be meritocratic if anything. There is of course some degree of politics, it is inevitable, which was the point I was trying to make.
Completely insane, who doesn't get to have coffee breaks without manager permission? Surely any org that treats its employees as adults would not have this problem.
I'll be honest, this code is easier to read for me without the comments. Also sorting feels like it's going to be slower than having some kind of set structure? You don't need ordering, just collocation of duplicates. If not or if it's a wash, that is also a good thing to comment. Also I'm not sure about the semantics of Go but it seems this mutates the argument AND returns a value, something I consider dangerous.
Otherwise I agree, people have a weird hang up about short variable names. Somehow not a problem in mathematics...
There's probably a better example. The point is sometimes the What needs explanation, and finding a better What isn't practical.
I have slightly unorthodox opinions about short variables. I used to hate them. Then I posted a question on one of the PL design forums - it might have been Reddit r/programminglanguages - why is there are history of single letter names for type variables? ie T, U, etc for generics. The answer I got back, was, sometimes you want code to focus on structure rather than identities. That stuck with me, because it helped me understand why so much C code (including Linux) code uses similar naming practices. Names can lie, and sometimes expressing the structure is the absolute critical thing.
Back when I programmed in Haskell, I also had a similar question about the extremely terse variable names that pop up everywhere. I'd wonder, why is this "x" and "xs" instead of "item" and "items" or "businessName" and "businessNames" or whatever. Eventually I found this (paraphrased) answer that made it all click:
The specificity or abstractness of a (variable) name relates to the values that it can hold. So when you have a very abstract function whose inputs can be of almost any type, naming those inputs in an overly-specific manner is an exact inverse of the failure of giving an overly generic to name highly constrained parameter.
All this said, I do agree with your original take on the comments. I much prefer having human-readable explanations inline with anyhow non-trivial code. If nothing else, they really make it easier to correctly fix the code if a bug is found much later.
(Author here) thanks! Even as an experienced Rust developer, this is a lot of syntax which is part of what makes it archaic I think.
As usual with Rust most of it is due to inherent complexity: for example, when you deal with raw pointers, you need to specify if they are const or mut, and you must have a syntax that’s not &, and not too wordy: so * is a good choice (might be changed to &raw in the future!). And if you want to say that something is generic and the generic parameter is a pointer… you just end up with a lot of syntax.
You're right that ratios matter enormously, but optimal ratios vary significantly by individual - genetics, activity level, metabolic health, and existing conditions all play roles. The overconsumption concern is valid for processed meats and in the context of sedentary lifestyles with excess calories, but the picture is less clear for whole-food animal proteins in balanced diets.
The real issue might be less about meat/dairy per se and more about displacement of other beneficial foods (fiber, polyphenols, etc) and overall dietary patterns. Many Americans do overconsume calories generally, but some subpopulations (elderly, athletes, those on restricted diets) may actually benefit from more protein.
reply