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