This gave me a chuckle:
> [case insensitivity... so] both beGIN and BEGIN are interpreted the same way. This was also characteristic of the time, as programmers programmed their computers by shouting.
> [case insensitivity... so] both beGIN and BEGIN are interpreted the same way. This was also characteristic of the time, as programmers programmed their computers by shouting.
One thing people discovered eventually - case-sensitivity is language-specific. It is easy so long as you assume everything is in English and 7-bit US-ASCII, but once you move beyond that assumption, it becomes significantly more complex. An easy way to avoid all that complexity is to not do it.
People also forget about the related notion of accent-insensitivity - again, if all you support is English, you can ignore that, since English hardly uses accents
and this is the case because of C, which was my point. The fact that OS'es are written in C and thus have a C libraries and APIs is why you must respect C's rules for identifier names.
Also, yes compilers for other languages essentially name-mangle anyway, that's how (modern) fortran which is case sensitive and C++ which isn't (but tacks on a bunch of things to function identifiers) work. But the point about naming conventions or recommendations still stands, like a lot of things it is a fact of history favoring C, not that there is anything inherently better about it.
I believe it was already the case prior to C with assembly, and really because originally only one case (uppercase) was available. C just didn't change anything about the case-sensitivity of linking.
C is case sensitive, but it's also not seen as very modern language these days, so I'm not sure I understand your argument.
I think case-insensitivity is seen as rustic because it's a remnant of the times when some systems simply did not have a notion of case and everything was uppercase all the time. Modern systems handle case just fine so having several character strings being distinct in terms of byte values but equal in the way the language interprets them seems clunky and error prone (because it is).
Modern systems tend to support international character sets (UTF-8, etc.), where the idea of 'case' makes things more complicated than ASCII; and probably more trouble than it's worth. Even if we stick with latin characters, are 'uppercase' and '𝖀𝓟ℙ𝗘ℝℂ𝙰𝒮𝓔' the same identifier?
It remained in the "getty" process for some time, well into the {Free,Net,Open}BSD era.
CP/M and the like were pretty forgiving of commands being shouted too.
some languages (IMP, maybe others) used %reserved-word% formatting so you could do things pretty much how you wanted and then the system would know what was instructions.
Still there in agetty: https://github.com/util-linux/util-linux/blob/master/term-ut... And, I imagine in other getty implementations.
However programs like MS-BASIC would allow you to create files with lower case names that were then unmanageable from the command line.
https://nim-lang.org/docs/manual.html#lexical-analysis-ident...
Sadly, not every developer understands why that’s a good or bad design, i.e. the global pool of developer talent is partially stupid.
I have played with nim for a bit though, and this rule I just don't care for.
My reply above was tongue-in-cheek, maybe a bit too edgy. The person I was replying to characterized the language feature as "sad", and that's just silly. Even if it's an aspect of the language one doesn't appreciate, it's no more "sad" than e.g. Clojure involving a lot of parentheses or Haskell promoting monads. Likewise, no one is stupid or partially so for not liking or understanding Nim's partial case-insensitivity.