> Beside that, for many problems, a garbage collector eliminates a large amount of defects (including the ones stated in the article)
Languages with garbage collection are generally considered "memory safe". GP was talking about choosing a language that requires manual memory management, but doesn't have something like rust's lifetimes to catch things like use-after-free.
Even when I vacationed in Bayern (Bavaria), a lot of people switched to English when they realized that my German wasn't that good. Which was frustrating, because I wanted to practice speaking with native speakers.
Although, there were also people who only spoke German.
It is also often more expensive than Amazon, which is I think is largely due to Anazon's anti-competetive, and possibly illegal "most favored nation" terms, but as a consumer it does discourage avoiding Amazon (which is why Amazon has those terms).
I agree that acronyms can be overused, especially in marketing.
However, a big part of why Tech, software, computer science, etc. have a lot of acronyms is because there are a lot of new, often abstract things to name, and acronyms are an easy and straightforward way to create a reasonably unique and short name for a new thing. And I don't think anyone would really want to write out all of "hypertext transfer protocol" instead of http. And imagine if every url looked like "hypertext-transfer-protocol://world-wide-web.example.commercial/index.hypertext-text-markup-language". And if it had been given some other name, say "hyperprot" would that be any more meaningful than http?
Re: acronyms in English vs spanish.
I wonder if this is related to how human communication has a constant rate of information transfer. From what I understand, spanish is spoken faster, (more syllables per second) but has less information per syllable. One way that english is able to convey more information with less syllables is the use of acronyms and other abbreviations. And this is especially true for professional jargon that you use a lot to speak with colleagues at your job.
> You don’t see Kant writing TCI instead of “The Categorical Imperative” or Rousseau writing TSC instead of “The Social Contract”. You usually see the creation of concepts (Biopolitics by Foucault, Zeitgeist by Herder, Orientalism by Said) or the use of nominalization.
I don't think any of those terms are much better than acronyms. Maybe the name gives you a vague idea of what they refer to, but like many acronyms they are labels for complex ideas that you can't really understand just by knowing what it is called. And these terms can be, and are used for "in-group signalling" in much the same way as acronyms.
Finally, tech is not at all unique in its abundant use of acronyms. I don't know about in other languages but at least in English, Math, Physics, and astronomy also make heavy use of acronyms (ODE, PDE, QED, LCD, AGN, LASER, QCD, SI, CGS, AU, BEC, etc.) And from what I've observed medical and sales professionals also use a lot of acronyms.
There could be an interaction with the diet though. For example, what if the nutrient in eggs that prevents Alzheimer's is something that also occurs in meat?
Also, it seems likely that among this population many of those who don't or rarely consume eggs are vegan or almost vegan, so it might be more accurate to say that veganism is correlated with Alzheimer's.
Post is a natural monopoly, at a national scale. It is much more efficient to have a single centralized service doing all mail delivery than several competing services doing the same.
It isn't completely non-rivalrous, but the marginal cost of delivering a parcel diminishes as the number of parcels delivered in an area goes up.
Sure, it's not perfect, but I'm doubtful privatizing it would make it any better. And on the list of things I want fixed in the US, it is far from the top.
If you use an LTS version of Ubuntu (or Red Hat etc.), you are going to have older versions of software. That's just how it works. And is kind of the point of LTS. If you want more recent versions, use a rolling release or a more recent (non-LTS) version of Ubuntu (or whatever). The latest version of podman is going to depend on recent versions of the kernel and systemd, etc. and isn't going to work well on an older distro with older versions of those dependencies.
The purpose of quadlets is when you want good integration with systemd.
The better equivalent of docker compose is podman kube, which does use a single file. And it isn't bespoke, it uses the same format as kunernetes.
And if you prefer the docker compose format, podman-compose is available as a separate tool.
And FWIW docker compose is a separate tool from docker itself as well (and needs to be installed separately on several linux distros). And can actually work with podman instead of docker.
From the responses I've gotten from my representatives when I've written them, my impression is they care a lot more about their corporate sponsors and the party line than they do about their constituents.
> Red Hat's UX designers heavily contributed to GNOME
Well, IMHO Gnome has worse UX than other linux environments like KDE, Niri witn Dank Materials Shell, etc. That is obviously a matter of opinion, but I don't think you necessarily need a large budget to get decent UX for an open source project.
Code review doesn't have a single purpose. Finding code that is hard to maintain is one of those, and and an important one, but certainly not the only one, and I'm not sure it is even the most important one. Other purposes include:
- a safety check to ensure that if a developer (or AI) goes rogue, it is more difficult to merge malicious code
- a second perspective from someone who isn't as close to the problem and might see a better way to do things, or problems that the original developer missed
- in some cases having someone more familiar with other parts of the system look at it who can tell if it won't interact well with something else
- ensuring there is at least one other person familiar with the code
- a learning opportunity. The author can learn from feedback from the review, and the reviewer can learn from the code in the change. Especially important when the author and reviwer have differing seniority. When I mentor a new employee, I add them as a reviewer to all my PRs so they can see how I do things, and review all their PRs so I can provide guidance. And sometimes I even learn things from them!
- yes, catching bugs, although this should not be the primary mechanism for that, and I agree is not the most important reason. It is especially important for security and performance bugs though, as those are harder to catch with automated testing.