5 ms·

> Another thing that's driving me crazy is case insensitivity. I would never willfully choose a language with case insensitive identifiers. It's driving me

by kbp 8y ago

> Another thing that's driving me crazy is case insensitivity. I would never willfully choose a language with case insensitive identifiers. It's driving me nuts. What about it annoys you? Do you often define a lot of variables whose names differ only by case, in languages that let you? Common Lisp normally behaves as though it were case insensitive, and I've never found that to be a pain point.

Shivetya 8y ago
I never understood the falsification with case insensitive languages, to me it was yet another way to trip up a team effort let alone working with many related sources. however my view is jaded by working mostly on minis and our languages were always this way. the focus was on concise naming and logic and to me just adding another method for a typo to nail me does not benefit a language. so can someone tell me the reason why?
jstimpfle 8y ago
In fact I often use the "Thing thing" approach to variable declaration and I think I like it. It's an easy way for me to avoid thinking about taxonomy. But it's not that important. If it wasn't possible I could invent different names. What really irks me is that in case-insensitive languages, codebases naturally start to use all kinds of variations of casing, to refer to the same variable. It really trips me up when reading code. It's also difficult when writing code since I tend to remember variable names in a very visual way. (Same reason why I dislike the case-insensitive Windows filesystems). There simply isn't any good reason not to always use the same case for any variable throughout a project. Beyond that it's also aesthetically not pleasing, from an engineering viewpoint. Case-insensitive comparison is much more complicated than simply comparing strings as arrays of bytes. Historically, I think the reason why case-insensitive languages exist is simply that at the time they were invented (at least in the case of Pascal), many systems couldn't input lowercase characters.
- clouddrover 8y ago
  > I often use the "Thing thing" approach to variable declaration The Pascal way would be to use the "T" convention for the name of the type. So "thing : TThing".
  - jstimpfle 8y ago
    Yes, but it's one extra verbose character, and it's also not a waterproof systematic. E.g., the type "THat" would clash with the variable "that". Instead I want the simple, obvious, and reliable thing: string comparison is comparison of byte arrays. No problems.
    - clouddrover 8y ago
      Case insensitivity is simply not a practical problem. The "THat" versus "that" scenario won't compile and is trivial to address.
      - jstimpfle 8y ago
        My point is that the systematic is an inferior workaround to the obvious case-sensitive approach that would be simpler to implement, simpler to explain, and wouldn't have any of these problems to begin with. It's completely pointless. Maybe people who somehow don't differentiate between 'T' and 't', and are not visually remembering persons, don't have this problem. But for me, and for computers, they are different characters.
- kbp 8y ago
  > In fact I often use the "Thing thing" approach to variable declaration and I think I like it. It's an easy way for me to avoid thinking about taxonomy. But it's not that important. If it wasn't possible I could invent different names. There's no reason that types and variables need to live in the same namespace. The language can know what it's expecting at a certain point. Putting them in different namespaces, like Lisp does, lets you re-use the same name for types and variables even with matching case, and is more waterproof with regards to clashes than a case convention. > There simply isn't any good reason not to always use the same case for any variable throughout a project. I agree, but I also feel that there isn't any good reason to have multiple distinct objects in the same namespace whose names differ only by case. It just seems like a recipe for confusion. When I'm quickly iterating on something, it's nice being able to be lazy and inconsistent with capitalisation. Standardising that in a codebase is important, but it's more of a job for a linter, I think.
  - jstimpfle 8y ago
    Yes, C has that too. It has different namespaces for struct, union, and enum. And I like the clarity of the explicit namespace prefixes at each place of reference. But I tend to not rely on that distinction, since C++ has only a single namespace. And as soon as we go to more dynamic languages, where types can also be variables, it all breaks down.
    - kbp 8y ago
      I was just saying that there's no good reason to have different variables with names that only differ by case; the example you gave where you do like that has a better solution in multiple namespaces.
  - ckok 8y ago
    Problem there is that it would disallow Type.Staticmember or Type(value) kind of casts, which do exist in most Pascal languages.
kazinator 8y ago
REAMS OF UPPER CASE is what is annoying! You should almost never use it in programming, unless you mean it. I've never written Common Lisp code in upper case, other than copying and pasting from REPL output. Allowing upper case to simply denote lower case any time you want basically PANDERS TO THE MORONS WHO SHOUT LIKE THIS in internet forums. Supporting case insensitivity in a modern setting requires carrying a large table of Unicode data about all of the world's scripts that exhibit case. Which scripts exhibit case is controversial. Are Japanese hiragana and katakana in a case relationship? Should れつ (retsu) and レツ (RETSU, sort of) be the same symbol or not? Programmers used to case distinctions see FOO, Foo and foo as completely different; there is no issue there. Literate non-programmers should also see them as different. "Pat" is a name, "pat" is a verb. Mathematics uses case distinction. If you're writing a summation notation with Σ, you can't just switch to σ. You can't switch 3 + 4i to 3 + 4I just because you feel like it. Basically, case insensitivity is for illiterate morons with no background in mathematics. Why it appears in classical programming languages is because 1950's and 1960's hardware didn't support large enough character sets to have both upper and lower case. Even some consumer grade microcomputers in the late 1970's and early 1980's lacked lower case, like Apple II's. The Unix TTY system still supports folding to upper case! Try this at your Linux bash prompt: $ stty olcuc # output: lower case to upper case the reverse conversion is available on input. Thus, old programming languages were written in upper case, but with increasing support for lower case in character sets and hardware, programmers wanted to use those same languages in lower case. A pragmatic solution was to support it both ways: allow lower case for new programs, but also upper case for backward compatibility with existing code. So it wasn't illiteracy; there was a technical reason. The technical reason doesn't exist any more, and so repeating this in new designs is just illiteracy. If you're making a new language today, you have no existing code in upper case that has to work.

by kbp 8y ago

Shivetya 8y ago

I never understood the falsification with case insensitive languages, to me it was yet another way to trip up a team effort let alone working with many related sources. however my view is jaded by working mostly on minis and our languages were always this way. the focus was on concise naming and logic and to me just adding another method for a typo to nail me does not benefit a language. so can someone tell me the reason why?

jstimpfle 8y ago

In fact I often use the "Thing thing" approach to variable declaration and I think I like it. It's an easy way for me to avoid thinking about taxonomy. But it's not that important. If it wasn't possible I could invent different names. What really irks me is that in case-insensitive languages, codebases naturally start to use all kinds of variations of casing, to refer to the same variable. It really trips me up when reading code. It's also difficult when writing code since I tend to remember variable names in a very visual way. (Same reason why I dislike the case-insensitive Windows filesystems). There simply isn't any good reason not to always use the same case for any variable throughout a project. Beyond that it's also aesthetically not pleasing, from an engineering viewpoint. Case-insensitive comparison is much more complicated than simply comparing strings as arrays of bytes. Historically, I think the reason why case-insensitive languages exist is simply that at the time they were invented (at least in the case of Pascal), many systems couldn't input lowercase characters.

clouddrover 8y ago
> I often use the "Thing thing" approach to variable declaration The Pascal way would be to use the "T" convention for the name of the type. So "thing : TThing".
- jstimpfle 8y ago
  Yes, but it's one extra verbose character, and it's also not a waterproof systematic. E.g., the type "THat" would clash with the variable "that". Instead I want the simple, obvious, and reliable thing: string comparison is comparison of byte arrays. No problems.
  - clouddrover 8y ago
    Case insensitivity is simply not a practical problem. The "THat" versus "that" scenario won't compile and is trivial to address.
    - jstimpfle 8y ago
      My point is that the systematic is an inferior workaround to the obvious case-sensitive approach that would be simpler to implement, simpler to explain, and wouldn't have any of these problems to begin with. It's completely pointless. Maybe people who somehow don't differentiate between 'T' and 't', and are not visually remembering persons, don't have this problem. But for me, and for computers, they are different characters.
kbp 8y ago
> In fact I often use the "Thing thing" approach to variable declaration and I think I like it. It's an easy way for me to avoid thinking about taxonomy. But it's not that important. If it wasn't possible I could invent different names. There's no reason that types and variables need to live in the same namespace. The language can know what it's expecting at a certain point. Putting them in different namespaces, like Lisp does, lets you re-use the same name for types and variables even with matching case, and is more waterproof with regards to clashes than a case convention. > There simply isn't any good reason not to always use the same case for any variable throughout a project. I agree, but I also feel that there isn't any good reason to have multiple distinct objects in the same namespace whose names differ only by case. It just seems like a recipe for confusion. When I'm quickly iterating on something, it's nice being able to be lazy and inconsistent with capitalisation. Standardising that in a codebase is important, but it's more of a job for a linter, I think.
- jstimpfle 8y ago
  Yes, C has that too. It has different namespaces for struct, union, and enum. And I like the clarity of the explicit namespace prefixes at each place of reference. But I tend to not rely on that distinction, since C++ has only a single namespace. And as soon as we go to more dynamic languages, where types can also be variables, it all breaks down.
  - kbp 8y ago
    I was just saying that there's no good reason to have different variables with names that only differ by case; the example you gave where you do like that has a better solution in multiple namespaces.
- ckok 8y ago
  Problem there is that it would disallow Type.Staticmember or Type(value) kind of casts, which do exist in most Pascal languages.

kazinator 8y ago

REAMS OF UPPER CASE is what is annoying! You should almost never use it in programming, unless you mean it. I've never written Common Lisp code in upper case, other than copying and pasting from REPL output. Allowing upper case to simply denote lower case any time you want basically PANDERS TO THE MORONS WHO SHOUT LIKE THIS in internet forums. Supporting case insensitivity in a modern setting requires carrying a large table of Unicode data about all of the world's scripts that exhibit case. Which scripts exhibit case is controversial. Are Japanese hiragana and katakana in a case relationship? Should れつ (retsu) and レツ (RETSU, sort of) be the same symbol or not? Programmers used to case distinctions see FOO, Foo and foo as completely different; there is no issue there. Literate non-programmers should also see them as different. "Pat" is a name, "pat" is a verb. Mathematics uses case distinction. If you're writing a summation notation with Σ, you can't just switch to σ. You can't switch 3 + 4i to 3 + 4I just because you feel like it. Basically, case insensitivity is for illiterate morons with no background in mathematics. Why it appears in classical programming languages is because 1950's and 1960's hardware didn't support large enough character sets to have both upper and lower case. Even some consumer grade microcomputers in the late 1970's and early 1980's lacked lower case, like Apple II's. The Unix TTY system still supports folding to upper case! Try this at your Linux bash prompt: $ stty olcuc # output: lower case to upper case the reverse conversion is available on input. Thus, old programming languages were written in upper case, but with increasing support for lower case in character sets and hardware, programmers wanted to use those same languages in lower case. A pragmatic solution was to support it both ways: allow lower case for new programs, but also upper case for backward compatibility with existing code. So it wasn't illiteracy; there was a technical reason. The technical reason doesn't exist any more, and so repeating this in new designs is just illiteracy. If you're making a new language today, you have no existing code in upper case that has to work.