That's true, but my stance frankly wouldn't change if they also thought Google and Apple needed to spend the rest of their existence as a charity case. My point is more that it's a silly measure of damages, since this behavior is table stakes in the FAANG echelons. It's like saying that we should reject Open Source contributions by Google and Amazon because they pay their engineers with money made off exploitative server deals. It's a reach.
I don't really understand your point. Company A is corrupt, the company B and C are corrupt too (and D, E, F,...). We have 3 corrupt companies. Why would here be any problem saying that company A is corrupt? Or from another perspective, why would be A less corrupt if B and C are doing the same thing?
Open Source contributions are there for three reasons. Either the license requires it (Google Fuchsia is a step into avoiding this and keep next generation hardware close source), it is a public relations stunt or they want other software developers work for them for free (which is also lowering the wages for their developers).
Never ever mistake any company that has public stocks doing anything else but earning money for the stock owners. As they didn't buy the stocks to support charity but to earn money, which is the greatest reason why their products are worse deal for their customers on y2y basis.
Which is the exact thing that addresses your objection. People, in general, are unable to downregulate their appetite on their own in order to "just eat less". Ozempic does it for them.
Honestly, I question the whole idea that failing to "eat less" is a personal problem. Historically, we jumped into obesity epidemic straight from the time when food was scarce and not very nutrient-rich. Ability to manage caloric intake in times of abundance may not be something humans have in general, as long periods of abundance didn't happen until 100 years ago.
> Ability to manage caloric intake in times of abundance may not be something humans have in general
Even in the USA, a country that is not just wealthy but also culturally obesity-friendly, the majority of people are not obese. In less obesity-friendly regions, such as Europe, only a small part of the population is obese.
Most people do manage their caloric intake. And of those who don't, many may still be able to, but simply choose not to.
It seems that humans in general do have the ability to manage caloric intake, but many don't use it.
I do think it's a personal problem. (But we should still work together as a society to help those who fail to help themselves.)
> Overeating calorie dense junk food isn’t the same thing as overeating carrot sticks and you rarely hear about problems coming from the latter.
Perhaps that's because "overeating carrot sticks" is a strong indicator of being in danger of starvation? People just don't overeat this kind of food if they have tastier, more calorie-dense food available.
If parasites were widespread amongst human beings, would those infected humans have incentive to study them?
We are likely biased and can't imagine how we are biased because of the infection! Yet the over-under for an individual is clear: try the medication and find out!
>> would those infected humans have incentive to study them?
Plenty of diseases get us and most of us don't have an incentive to study what we know is statistically likely to kill us :<< . Which I think is a shame.
Many of these arguements are moot – because for any top-down function definition technique, the How to Design Programs recipe covers virtually all the bases.
Between a signature, purpose statement and examples, you've declared most of what documentation provides short of a longer contextual statement of the functions role in a codebase.
I wouldn't focus on the fact that the examples are on single functions. Libraries and frameworks are about API design and not individual atoms, and writing your documentation ahead of time is about crystalizing the API vision you have in your head.
One may have accidentally glossed over a critical design decision and this process can surface that.
Greenspan's tenth law is that every language ends up with a half baked Common Lisp implementation. This is apparently true, with the stipulo that these implementations end up fully baked over time. This is true since functional programming languages are commonly research languages which mean industry languages catch up.
reply