- Significant whitespace, but tabs are forbidden
- No block comments, save for `discard """ ... """`
- Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)Here's the reasoning: https://github.com/Araq/Nim/wiki/Whitespace-FAQ#tabs-vs-spac...
If you still want tabs you can add this at the top of your files and they work:
#! replace("\t", " ")
This changed recently, now the first letter is considered case sensitive: http://nim-lang.org/manual.html#identifier-equality
Honestly, there are less drastic solutions to these problems. Some languages (forgot which) simply forbid mixing tabs and spaces when the tab size makes the code ambiguous. And their C example will generate an "ambiguous else" warning in D, which you can disambiguate by adding braces.
In the language design stages who in the world thought this would be a good idea? Even PHP doesn't do that.
foo_bar = blah
foobar = blah
fooBar = blah
That's someone you really don't want to be coding anywhere near, because it leads to really, really confusing code. So nim is just enforcing not being able to do it it as a language.
go format is a much better solution to the same problem.
We use "special tools" for every other language (Visual Studios, Eclipse, etc).. Calling a language feature, which give programmers style freedom, a "tortured lexical structure" is not an objective argument. Especially since we have a tool (nimgrep) which addresses the issue and takes < minute to learn. Once Nim has better IDE support, no one will be grepping in the first place.
Sure, I can use nimgrep, but I can't use _my_ grep, _my_ freetext indexer, _my_ editing constructs, and so on. I'm not going to make my environment, which works fine for almost all programming languages, bend over backwards to support your special snowflake of a language.
I'd rather just use something else.
Please, be serious.
> but I can't use _my_ grep, _my_ freetext indexer, _my_ editing constructs
Oh, but you can! These are _your_ tools, you can easily extend them by either scripting or modifying source, no problems there. Really, how much of a problem is adding a switch for underscore insensitivity to your program? Because I assume case insensitivity you had already coded.
Oh, unless by "_your_ grep" you meant a tool that someone else wrote and you're using without any real understanding of how it works and without required skill or knowledge to modify it. Right, this can happen, you're a busy man, have many obligations and no time at all to fiddle with grep. I understand.
But that also makes you completely outside of a target group of early adopters of new programming languages. So maybe stop commenting on them?
The best case for usability is that this "feature" never used, which makes it an odd design choice. The worst case is that the feature is used frequently, there is no clear language norm, visually scanning for variables is harder, search and replace requires dedicated tools, and subtle bugs abound. Far better (in my personal opinion) to make identifiers case sensitive and enforce consistency with style guidelines and code "prettifiers".
The current Nim approach is being called cs:partial (case sensitive partial) and makes the first letter case sensitive but all others insensitive. This like an awkward compromise, and needlessly complicated. The best proposal I've seen suggests making "_x" equivalant to "X" (underscore is an alias for "next letter is capital"). But I don't see it as better than case insensitive plus strong code conventions.
For a new language, I feel like one could have just forced one style unto the users, but that's just me talking.
Many of the so-called 4th generation languages (i.e. business shits derived from Cobol with DB support bolted in) are totally crazy in this sense. Not only are identifiers often case insensitive, they can also be abbreviated!
Yet people make massive amounts of money with them.
I believe a different syntax for those will be added soon: https://github.com/Araq/Nim/issues/1535