> [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 is only seen as "rustic" because C is case insensitive. Somehow, case insensitivity is seen as a modern thing but at the same time everyone recommends not choosing identifiers which are close to each other apart from case in style guidelines.
> Case insensitivity is only seen as "rustic" because C is case insensitive
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
Case insensitively is nowadays tied to how (static and dynamic) linking works. Youโd either (a) have to use a case-insensitive and thus nonstandard linker, or (b) have to uniformly normalize identifiers before linking, making the normalized identifiers less readable, or (c) have to normalize identifiers based on the casing used for an objectโs main definition, which means that changing only the case of that definition still breaks compatibility, so not quite case-insensitive after all, or (d) have at least FFI identifiers be case-sensitive (and use a custom linking runtime for intra-language identifiers).
>nowadays tied to how (static and dynamic) linking works
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.
>Case insensitivity is only seen as "rustic" because C is case insensitive.
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?
For anyone young enough not to have used an ASR-33 or similar, the UNIX login: process would assume you were on uppercase only and "work" if you logged in as your username/password in uppercase. Guess it was an extra round or two of password hashing against the salt.
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.
Sure, that's fair. I didn't care for it during much of the first year I started working with Nim. Once I began wrapping C libs and working with Nim libs whose conventions differ from my preferences, the rationale (explained in the manual) for Nim's partial case-insensitivity "clicked" for me and I eventually embraced it. But I can see it remaining a sore point for some folks.
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.