[fgimian]

True, I REALLY hate camelCase though ... hahaha But seriously, I do need to spend more time on Nim and give it a fair chance on a project :)

Ultimately, I had to choose something to commit to for a while as there are just not enough hours for me to learn multiple new languages outside of work and with my various other hobbies.

But rest assured that Nim was absolutely a front-runner and I'm happy to update the post to reflect this.

[beagle3]

> True, I REALLY hate camelCase though ...

I do too, and that's exactly why you should use Nim. It is, perhaps, the only language in which the variables "camelCase", "camelcase" and "camel_case" are the same (though CamelCase isn't) -- so you don't have to follow braindead Java principles if you don't like them.

[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.

[smt88]

> "camelCase", "camelcase" and "camel_case" are the same (though CamelCase isn't)

I find this horrifying and think it probably reflects deep philosophical differences between myself and the creators of Nim. Languages shouldn't make assumptions and how to interpret my typos. They should tell me about the typo and suggest a possible fix.

[beagle3]

It's not about typos. Nim borrowed a lot from Pascal when it started life, and Pascal, like BASIC, Fortran, some LISPs, Excel, NTFS, HFS+ and many others, is case insensitive.

What you say is equivalent to "I want to be able to declare three independent variables called camelCase, camel_case and camelcase", and Nim says "no, you can't do that in the same scope" (which is a little more strict than pascal which says "you can have camel_case distinct from the other two, but those two are equivalent).

Experience shows that case sensitivity is harder to use in general[0]; "Although we resisted changing the Python implementation, our user testing data forced us to make ... Python case insensitive. Over 85% of our users made case errors and many continued to do so even after learning that case was significant." it's just that you're used to it; same with respect to int/int vs true division.

I'm feeling an almost dejavu to the early days of Python, when the standard response (which people still repeat sometimes, though rarely these days) was "what!?!? you mean spaces are significant!?!? that's horrible". But this is equivalent to saying "I want to be able to write code that behaves differently then it looks, such the C code:

    if (nuclear_launch_detected)
        notify_the_president();
        launch_strike(STRIKE_MODE_MUTUALLY_ASSURED_DESTRUCTION);

(The like of which make iPhones and Macs susceptible to eavesdropping for a long time). Python says, "Nah, you can't do that". It's opinionated, but experience shows it works better overall.

[0] page 5 of http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.908... - all of it is a fantastic read.

[smt88]

The reasoning may not be about typos, but the egonomics are. Also, following the tradition of those other systems doesn't make it better for Nim users. The context matters a lot.

And why are case errors a big deal in case-sensitive languages if they cause "undefined" errors or, better yet, are caught by static analysis?

(To your point about Python, I still think semantic whitespace is insane -- invisible code, as you implied -- and is a major reason I avoid Python when possible.)