Are there objective advantages in a language being "case sensitive" or not?

The main advantage of case sensitive is to increase the set of possible symbols (names). The main impact on traditional languages is the creation of an implicit relationship between a type and an instance of this type. Another less employed (Prolog, Erlang) is the possibility of giving differentiated semantic treatment depending on capitalization. Finally, there are practical issues involving the compilation and management of the runtime , in which the implementation of a language case sensitive is simpler.

The main advantage of case insensitive is the ease of memorization of language symbols, and the consequent reduction of errors related to incorrect capitalization.

Types vs. instances

In natural language, a name has the function of representing only a concept. There are bumps (e.g. fruit sleeve or shirt sleeve), but they are rare and ambiguity is usually removed by context. In formal language (e.g. controlled vocabulary, taxonomy, thesaurus , ontology) the uniqueness of names is mandatory, and this applies especially to computer programs - where ambiguity would be a hindrance to automated text processing.

However, ambiguity is not always bad: in the presence of context , using the same name to represent distinct - but related - things not only does little harm but is also useful. If I say "dog" this refers to a type of animal. If I say "a dog" I speak of a specimen of that same animal. If I say "the dog" it is not only any specimen of this animal, but a specific one, which may have already been mentioned before or is unique given the context (e.g. if there is only one dog in a set of animals). This facilitates communication.

Similarly, conciseness is sought in programming, since it is a measure of expressiveness of language. However, this conciseness must always be weighed against the clarity of the code ("programs are made for humans to read and only incidentally for computers to run"). In the absence of these semantic "shortcuts", we look for other ways to make the name of something refer to a concept:

• sigils ($foo is a scalar, @foo is an array);
• Hungarian notation (iSize is an integer, szLastName is a NULL-terminated string);
• naming conventions (IFoo is an interface, _foo is a private field).
• etc.

These conventions are in general implicit, but ultimately fulfill the role of assisting in communicating code semantics to human readers. And a similar convention, quite similar to the natural language case mentioned above, is to use the same name to refer to a type and an instance of that type:

cachorro = new Cachorro();

In a language case insensitive , it would be necessary to use another name, and most likely the programmer would choose something like:

oCachorro = new Cachorro();
cachorro1 = new Cachorro();

Which makes the code less readable. And by the way, this tendency of programmers to use the same name for class and object is evident when the class has the same name as a reserved word. See if this sounds familiar:

clazz = new Class();

Choosing names is difficult. Someone could insist " now, but just give a different name to the variable, type rex = new Cachorro()", but in practice this makes it difficult to understanding. Even if the programmer sticks to a particular style of coding (class starts with uppercase, variable with Lowercase, constant is all uppercase) he loses this implicit semantic Association of the type with the instance. Or at the very least it is forced to adopt a different convention, such as those exemplified above.

Differentiated semantics

In most languages any difference between capitalized or non-capitalized symbols is purely conventional. But nothing prevents - and I am of the opinion that it would be a major breakthrough - that the compiler "forces" this convention (as suggested in Victor Stafusa's answer). This not only creates consistency but can increase expressiveness, as happens for example in the Prolog language.

Prolog (and other languages inspired by it, such as Erlang) makes case-sensitive and - in the specific case of the first letter of the name - gives a differentiated semantic treatment for the same: foo is an "atom" (constant) and Foo is a variable. This sounds like a silly detail, but in my experience with this language the gain in expressiveness is huge.

As an example, some modern languages have a feature called destructuring assignment / bind, such as Python:

for chave,valor in dicionario.items():

If Python supported unification such as Prolog, it would be possible to do at the same time a destructuring bind, a check of types and even a filtering in a single expression:

# Assumindo uma estrutura de dados Cachorro(nome, raca, idade)

for chave,Cachorro(nome, MALTES, sqrt(4)) in dicionario.items():
    print(nome)

# que seria equivalente a:

for chave,valor in dicionario.items():
    if isinstance(valor, Cachorro):
        nome = valor.nome
        if valor.raca == MALTES: # Assumindo que MALTES é uma constante global
            if valor.idade == sqrt(4):
                print(nome)

If the language was case insensitive, on the other hand, such unification would not be possible. How would the compiler know that:

• is not to call Cachorro(...) as a function, but sqrt(...) yes;
• nome is a variable, which should take as a value the first field of the instance being iterated;
• already MALTES is a constant, which must be compared with the second field of the instance being iterated?

Note that all this could be done as sigils, quotes (ex.: Lisp), etc., but notice how the code gets "clean" without the visual pollution of special symbols everywhere.

(P.S. one more example "relatable" is the case with regular expressions: \w takes a character class, \W negates that class. If regexes were case insensitive you would have to "spend" one more symbol, making the language a slightly less dense.)

Memorization and mis capitalization

It is already difficult to memorize the names of all classes, functions, etc of an API, in order to be productive in it without having to go back every hour to consult a reference. If the use of capitalization is not very consistent , one ends up having to memorize it too, and this is not something to be underestimated: our brains are good at memorizing concepts (and the Oriental ones are even better than the westerners), but not so much to memorize symbols and spellings:

• if you try to memorize "housewife", most likely your brain will store this as a sequence of sounds (ˈdɔ nɑ d ˈ ˈk.sə).
• an oriental could memorize this as an image, which is even easier (婦).
• a programmer would also have to worry about how to write it:
  • dona de casa? No, because identifiers cannot have more than one word;
  • dona-de-casa? No, because - is an operator;
  • dona_de_casa? Could be... or would it be donaDeCasa?
  • DonaDeCasa? DONA_DE_CASA? Let me See, Am I dealing with a variable, class or constant?

If a language follows a rigid capitalization Convention, and especially if the compiler imposes these rules (as also discussed in Victor's answer) then the problem is not so great. But when you start using acronyms The thing gets more complicated:

• IDCachorro or IdCachorro?
• UTF8Regex, Utf8Regex, UTF8RegEx or Utf8RegEx?

Unless the compiler knows what a ID is, that there is something called UTF8, which regex means REGular EXpression, etc, nothing prevents a programmer from defining something perfectly valid within the coding style of a language, and another programmer does not know how to spell it...

Frustration with this situation has been one of the most presented arguments in favor of the case-insensitive . For consistency, there are those who defend case-preserving, case-insensitive, which in my understanding means "it does not matter the capitalization, but after a symbol is declared for the first time it requires that it always be spelled in the same way". Personally, I see this as the worst of both worlds: you lose all the advantages of case sensitive, but you keep forcing the programmer to memorize the spelling of the name... (or would it be mine incorrect interpretation of this concept?)

Anyway, there is at least one definite advantage to case insensitive: if the API has defined RegEx and the programmer has written Regex, it won't treat both as distinct things. If the language requires every variable/type/etc to be declared, and doesn't allow it to be declared more than once, that's fine (otherwise you'd be simply swapping false negatives for false positives). It facilitates the process of learning the language and its APIs, in exchange for a reduction in the set of usable names.

Practical questions

Finally, there are the practical implications of adopting one way or another. Much of it has already been described both in Victor's answer and in my answer to the related question : the greater effort on the part of the compiler / interpreter to normalize the names (in relation to Unicode), convert them to a unique form and perform the interning. But more important than this complexity when implementing (which by the way is the function of the computer itself, to make human life easier, even if the compiler designer has to try harder for this) is the question of localization, in which the same program can have a different interpretation if capitalization changes are an integral part of its compilation process.

By way of example, in a language case insensitive How would a compiler in Turkish locale treat names like MAİL and maıl? And how would an "international" compiler treat them? The expectation of the Turkish programmer would be met or thwarted by any of the compilers, and which one? As a user of systems that do not always treat Unicode well, I know how these details can fill the bag and make anger pass. If I had to worry about them also when developing (in which my attention is all "spent" on the problem in hands) I think I would end up rejecting language that did not deal with this very well...

Conclusion

The tradeoffs seems to me to be basically the following:

• ease of memorization (case insensitive) vs. semantic expressiveness ( case sensitive);
• false positives (case insensitive) vs. false negatives (case sensitive) when determining whether two names refer to the same thing.

And the other characteristics of the language have influence on these factors, sometimes improving on one side and worsening on the other. Ex.: if Python became case insensitive it would increase the number of collisions of variable names, and if to counterbalance this the declaration of variables would become mandatory (ex.: var RegEx) it would reduce the conciseness.