I have relatives in Ukraine that don't have a burning desire to fight, but it is a bit more reasonable to go fight when you're being shelled by some other country.
As for my Russian friends, they do not want to fight in this war because
a) most ppl in western russia have some sort of familiar ties to Ukraine and are baffled by the whole nazi storyline
b) people just straight up don't wanna go die in a war in a foreign country they have nothing to do with.
I'm actually with you. I don't have romanticism towards small book sellers and would personally be okay with Amazon dominating that industry.
If I had a small bookstore, I would turn it into a private members club and charge an annual members fee, serve coffee and cocktails, invest heavily in ambiance---overstuff chairs, etc. Key distinction would just be the books and the option to buy said books. (I know bars that have books already exist).
Code can have ambiguous scope too, except the compiler has a decision making process that you might not fully understand. (Closures are famous for this problem).
In the English you can recognize the ambiguous parse and reject it.
The meaning of code is defined by rules. The only ambiguity exists in human understanding of code.
Natural language doesn't have such rules. My example above isn't an example of incorrect English, there isn't a correct interpretation. The grammar is correct and both interpretations are correct.
Indeed. And if well written, the majority of the code shouldn't need comments. For example, well-chosen descriptive identifier names can make code fairly self-documenting.
The comments then should then be reserved for the cases where it is not obvious why or how something is done, or for assumptions that can't be expressed through code (type system or similar).
So instead of having the following
// set i equal to five
i = 5;
either skip the comment, or, since 5 might seem arbitrary, comment why 5:
nope
this is variation of 'don't write obvious comments to your code'. Useful comments can include the 'whys', links to design docs/decisions, references to other part of source code. Here we see the case of commenting everything for the sake of commenting. Without adding any additional knowledge/insights.
> X does something that is commonly done, in a different way than Y. This means X is useless
It's still not clear how this explanation is supposed to be sufficient to explain the conclusion.
If a comment is collapsed in an IDE and you spend 1 click/key combo to expand it, versus some key combination to pull up the TLDR, the difference is what?
Comments being embedded IN code could be a thing of the past. No PR necessary to maintain them. Sounds like an improvement to me.