Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language.
That being said, this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.
That being said, this is a very well written tutorial. Might be a nice format to use in other basic language tutorials.
This is a great feature when interfacing directly with C libraries. You can declare the names as they are in the original library, which is best for debugging and reference. They can be a variety of styles, but in your code you can refer to them all with camelCase so you have a consistent style in your own code.
I've never had any problem with it. It just works, and if you don't want to use it, it's not going to be an issue.
Author of the tutorial here. Thank you very much for your kind words!
> Significant whitespace and case- and underscore insensitivity. That's pushing too many of my buttons for one language.
Coming from Python, I had no problem with the significant whitespace. I like it more than curly braces everywhere.
Case- and underscore- insensitivity were something I initially really didn't like. What were they thinking? Are they out of their minds?
After using Nim for a year, I must say I didn't experience any problem with it so far. All the code I have written, all the code from others I have read uses camelCase (which is a recommended, but not enforced, case). So basically, even though people have an option to use snake_case (or any other), the large majority of users use only the one style.
As for style insensitivity: it allows you to keep your code base consistent. Ever had to use a library that used snake_case in your own camelCase codebase? Well, with Nim you can just use camelCase everywhere.
Is that really desirable? I posit that if you have a codebase that breaks if fooBar and foobar refer to the same variable, it's already broken!
This is not criticism; I prefer Nim's mostly-case-and-underscore-insensitive approach, but I think this is a pitfall that should be acknowledged and taken into account (which is quite easy to do given the included nimgrep).
Perhaps it makes sense to have an optional warning in case a name is inconsistently spelled inside the same compilation unit.
There are already formatter tools that check for that.
Also, any editor with completion will suggest the right form every time preventing the bug.
Most languages seem to have a convention that all practitioners follow, which is ideal I think, but this might be second best.