> Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas.
I'm not too familiar with the specifics of Nim, but how are case-insensitive variable names a bad idea, except that notion is so unfamiliar to programmers?
Flipped around, if a language were to be designed today in a vacuum, what is the argument in favor of case-sensitivity in variable names?
My feeling is that we take case-sensitivity for granted because the vast majority of languages inherited that behavior from history's lineage of great programming languages. But re-evaluated without that history, case-sensitivity seems only to create potential confusion at best and opportunities for trolling and obfuscation at worst. Today's use case to indicate scope, mutability, or permissions is an artifact of this history. As programmers, we know how to read something like this in Java, but if we were able to completely erase our historical knowledge and consider language design without that baggage, this seems like bad language design:
// Local variable square is instantiated equal to
// SQUARE constant in class Square.
Square square = Square.SQUARE;
I'm not sure what alternative syntax we'd have today if we had never adopted case sensitivity in names to begin with, but my hunch is I would prefer it even if it involved more typing (e.g., prefix or suffix symbols).
Admittedly, a statically analyzed language will have most case typographical mistakes found and corrected at compile time, so they are a lesser annoyance than case-sensitivity in other contexts (such as filenames or column names in database tables). Generally speaking, I would be in favor of a hard break to drop case-sensitivity across the board, but I'll put that on the same list as adopting the metric system in the US (titled: "LOL, good luck.").
How? we would just have case insensitive refactoring tools.
> Encourages a consistent style in the ecosystem from the beginning.
Python, C, Java, etc are case sensitive langs, and it's possible to define function names in all upper-case and do all kind of inconsistent styling. Python has pep8 for a reason.
> Not needing specialized tooling to grep for an identifier in a codebase.
If all langs were case-insensitive, all those tools would be case-insensitive by default (or we would all know the right combination of flags to make them behave).
> Being able to Google a particular function name.
Is google case sensitive? In any case the lang would define a preferred style, like all case-sensitive lang do anyway.
> Consistency in identifier naming when looking at a stacktrace.
Same as above.
Parent said "if a language were to be designed today in a vacuum", I don't think any of your arguments hold.
You might think so, but Nim had to backtrack some on case insensitivity because it removes a very useful way to distinguish between types and things of that type ... so now the first character of a symbol is case-sensitive and the rest is not. If starting from scratch, as you suggest, I think most people would go for complete case sensitivity instead of Nim's now partial sensitivity. And the OP is also referring to Nim's "interesting experiment" of being agnostic between snake_case and CamelCase ... SnakeCase and Camel_case are matching symbols ... but notice how the case-sensitivity kind of kills the whole notion of agnosticism about snake_case. It's experience with this experiment that makes it pretty clear that it was not a good idea.
I'm not too familiar with the specifics of Nim, but how are case-insensitive variable names a bad idea, except that notion is so unfamiliar to programmers?
Flipped around, if a language were to be designed today in a vacuum, what is the argument in favor of case-sensitivity in variable names?
My feeling is that we take case-sensitivity for granted because the vast majority of languages inherited that behavior from history's lineage of great programming languages. But re-evaluated without that history, case-sensitivity seems only to create potential confusion at best and opportunities for trolling and obfuscation at worst. Today's use case to indicate scope, mutability, or permissions is an artifact of this history. As programmers, we know how to read something like this in Java, but if we were able to completely erase our historical knowledge and consider language design without that baggage, this seems like bad language design:
I'm not sure what alternative syntax we'd have today if we had never adopted case sensitivity in names to begin with, but my hunch is I would prefer it even if it involved more typing (e.g., prefix or suffix symbols).Admittedly, a statically analyzed language will have most case typographical mistakes found and corrected at compile time, so they are a lesser annoyance than case-sensitivity in other contexts (such as filenames or column names in database tables). Generally speaking, I would be in favor of a hard break to drop case-sensitivity across the board, but I'll put that on the same list as adopting the metric system in the US (titled: "LOL, good luck.").