[skocznymroczny]

I'd consider it even worse. I like consistency in my codebases. Good luck grepping for variable, when half of the folks will use variable_name, the other half will use variableName and the last half will do variablename.

[beagle3]

Nim includes "nimgrep", so I have good luck grepping for a variable, and it is supported in most common editors with a nim package. Nim also includes "nimsuggest", which provides intellisense - also available in most common editors.

And if you really insist, it is quite easy to write a simple program that will unify the styles for you. In practice, it's not a problem.

In this respect, Nim inherits pascal's case insensitivity, and just adds a few minor and arguably useful details (underscores are ignored, case of first letter preserved). It was never a problem for Pascal (or BASIC, or Excel, or NTFS or HFS+) and it's not a problem in Nim.

And being an early Python advocate and evangelist, I feel history is rhyming again .. ."What? You use significant spaces ? That's so stupid, and bound to make everything fail. Yes, some people still dislike significant indentation, but by and large, experience shows that it's not inferior[0] to token block delimiters, and in some ways it is superior.

[0] as long as tabs are a syntax error ....

[dom96]

And what do you do when a library you need doesn't use the same style as your code base? Let me guess: you end up adding an inconsistency into your codebase.

This is what style insensitivity is meant to fix. In reality, you are able to tell what style a code base uses almost immediately and grep accordingly.

[mcbits]

People still grep for variables in $current_millennium? I have to agree with the other comment about tooling being an important factor in language selection.

[renox]

I believe that Nim comes with its own grep to allow this.