4 ms·

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 programmer

by sigg3 3y ago

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.

ggm 3y ago
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.
- tyingq 3y ago
  >It remained in the "getty" process for some time, well into the {Free,Net,Open}BSD era. Still there in agetty: https://github.com/util-linux/util-linux/blob/master/term-utils/agetty.c#L2320 https://github.com/util-linux/util-linux/blob/master/term-ut... And, I imagine in other getty implementations.
- whartung 3y ago
  Well CP/M was a mixed bag. It was case sensitive and the command line upshifted everything. However programs like MS-BASIC would allow you to create files with lower case names that were then unmanageable from the command line.
coldtea 3y ago
And sadly the same (case insesitivity, not shouting) is the case in Nim today, iirc
- michaelsbradley 3y ago
  Nim is partially case-insensitive: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality 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.
  - michaelcampbell 3y ago
    I don't, and I'm ok with that; means I can learn more. I have played with nim for a bit though, and this rule I just don't care for.
    - michaelsbradley 3y ago
      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.
noobermin 3y ago
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.
- layer8 3y ago
  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).
  - noobermin 3y ago
    >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.
    - layer8 3y ago
      > and this is the case because of C 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.
- deleted 3y ago
  [deleted]

by sigg3 3y ago

ggm 3y ago

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.

tyingq 3y ago
>It remained in the "getty" process for some time, well into the {Free,Net,Open}BSD era. Still there in agetty: https://github.com/util-linux/util-linux/blob/master/term-utils/agetty.c#L2320 https://github.com/util-linux/util-linux/blob/master/term-ut... And, I imagine in other getty implementations.
whartung 3y ago
Well CP/M was a mixed bag. It was case sensitive and the command line upshifted everything. However programs like MS-BASIC would allow you to create files with lower case names that were then unmanageable from the command line.

coldtea 3y ago

And sadly the same (case insesitivity, not shouting) is the case in Nim today, iirc

michaelsbradley 3y ago
Nim is partially case-insensitive: https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality 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.
- michaelcampbell 3y ago
  I don't, and I'm ok with that; means I can learn more. I have played with nim for a bit though, and this rule I just don't care for.
  - michaelsbradley 3y ago
    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.

noobermin 3y ago

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.

layer8 3y ago
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).
- noobermin 3y ago
  >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.
  - layer8 3y ago
    > and this is the case because of C 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.
deleted 3y ago
[deleted]