Not always a great thing. Features like implicit syntax rewriting macros or case-insensitive variable names are... interesting experiments in a language, but ultimately not good ideas.
I’ve tried the language a few times over the years, and each time the compiler was just as buggy.
Lots of corner cases to worry about with features, like generators working only if the code that invokes them can entirely be inlined.
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;
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.").
* Simplifies refactoring tools.
* Encourages a consistent style in the ecosystem from the beginning.
* Not needing specialized tooling to grep for an identifier in a codebase.
* Being able to Google a particular function name.
* Consistency in identifier naming when looking at a stacktrace.
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.
ADT are case objects: they are widely used.
https://nim-lang.org/docs/tut2.html#object-oriented-programm...
There are some macros for easier generation: https://github.com/andreaferretti/patty#constructing-variant...
There are pattern matching libs: pattern matching is implemented on top of metaprogramming.
General pattern matching:
the original https://github.com/andreaferretti/patty https://github.com/alehander42/gara (disclaimer: my lib)
patty and gara should eventually combine into a single lib: including probably the current gara matching DSL(inspired by patty) and patty's variant DSL in the same place.
AST pattern matching:
optimized for macros, nice error reporting https://github.com/krux02/ast-pattern-matching
I'm not 100% sure, but I would guess yes.
> Do you see this eventually becoming part of the language?
I can answer this with some confidence: no. Nim is designed to have a small but very extensible core via metaprogramming. This is why we encourage users to write such macros. They may end up in our stdlib eventually but it's unlikely they'll be part of the language.
However it should be possible for sum types/enums: `case` already does it