A case sensitive filesystem doesn't require you to hit shift either if you just call the directory "programs". Also, there are many ways to save your pinky from moving the huge distance to the shift-key other than an arbitrary restriction on all file names in the file system..
What are the advantages of using a case-sensitive file system? I cannot imagine a situation when you need to create two files that differ only in letter case. This also would make program that create such files not portable.
The primary advantage for me is simplicity. Case insensitive file systems are complicated when you start dealing with non-ASCII characters and different software implementing the case rules with subtle differences. With case sensitive file systems you know exactly what you get.
If you're going to move to non-ASCII characters, what about Unicode combining characters, do you have to care if your file named é is a single accented e or a pair of e-and-combining-accent before you can move it?
If you shouldn't have to care, if there should be a layer of Unicode normalization happening, why is that okay but case normalisation is not okay? If you do have to care, then you no longer "know exactly what you get".
> If you do have to care, then you no longer "know exactly what you get".
You do know you get exactly what you put in, whether that is é (U+00E9) or é (U+0065 U+0301). When you reference files created by yourself, this is not a problem as realistically speaking, your input method will only have a convenient way of forming one of these, and it will consistently generate the same one every time. When you reference files created by someone else, this may be a problem but no more than e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i): from the user's perspective, the problem is pretty much avoided by selecting the file using tab completion, TUIs, GUIs, whatever you use.
> e.g. the distinction between file.txt (lowercase L) and fiIe.txt (uppercase i)...
Just want to remind a little but extremely important thing: There's absolutely no guarantees that upper("i") is I. There's at least one language breaks that convention, and you won't believe how a big headache is that.
https://prnt.sc/257kxxa lowercase l and uppercase I are quite distinct. If you're going to select all your filenames with autocomplete, then why argue restrict me to case sensitive filenames?
Windows NTFS is sometimes described as case-preserving, case-insensitive; i.e. if you name a file "Test" it will stay in that case, but if you ask for "test" it will find the file "Test". I don't know whether that happens in Win32 or NTFS, but it seems like best of both worlds; I don't want "case insensitive" where it could show me the name in a different case than I entered.
I don't override the font, either HN or FireFox or Windows is picking a serif font. I assume you didn't explicitly choose a font where different things look the same, but if it rendered 'a' and 'Z' the same glyph, you wouldn't say that was a problem with the English alphabet or with case sensitivity, or anything other than bad font design, right?
You showed a screenshot earlier, I know what they look like for you. :) I don't override the font either. HN specifies a CSS font family "Verdana, Geneva, sans-serif", where Verdana is installed by default on Windows but is not a full sans-serif font, so it's a somewhat odd choice by HN. As for the English alphabet, I didn't say there was a problem with it, just that you cannot reliably tell just from looking at letters which letters they are. In practice it is not an issue.
Frankly, the use case where I make a file to send to a customer "Example Ltd DNS details" and want to open it from a command line happens to me infinitely more often than the use case where I have a file called "fiIe.txt" and want to open it from a command line.
It sounds to me like the author had a severe anxiety attack for the first time. And just throwing out a wild guess that they possibly had recently experimented with ayahuasca or some other form of DMT.
This seems such a weird study. Names are important, but not so much as what is being named. In one sense, names become easy given a properly abstracted design. Further, it’s not names so much that are paramount to program comprehension, but more the quality of the design. With a bad design that doesn’t properly separate concerns it won’t be possible to come up with good names because functions/data structures will represent multiple concerns. Any time names are controversial it probably indicates a design problem, even for unique/complex abstractions, there is usually a name which everyone agrees is the perfect name for a thing..
This example is not good for talking about naming as there is no proper design which would have a function like this. In any proper design there would always be a separate function for each of the concerns.
I would argue the friends spin is probably more reliable, depending on the friend of course, as at least they would not be motivated by ratings or money and probably are not intentionally trying to cultivate any certain biased viewpoint in you.
This is absolutely false. Exposure to a higher number of viruses might increase probably of an infection, but a single virus can certainly lead to a full blown infection in an individual.
There seems to be some evidence that a higher infectious dose will not only increase the probability of an infection, but also its severity.
(This makes sense in a simple thought model where the virus starts replicating once it "hits" you, and then your immune system needs N days to ramp up and attack it back. The bigger the initial load, the more the immune system will have to fight back once it's operational. - Not saying that's how it is, just that this is a simple model to make plausible what appears to be empirically seen.)
It's a probabilistic process. 1 virion of any virus can infect a host, but for some viruses that probability will be vanishingly small while in others it will just be regular small.
