I'm torn. I _love_ Araq's attitude on this. He's right that languages should reject similar identifiers, or flag them, or consider them the same. It's bad coding.
However, I'm not looking for the perfect language. A major strength of **Nim** is the easy foreign-function-interface, and this reduces that strength. (People want examples. Ok. So far, I've only see conflicts between identifiers and MACROS.) > So basically it would break a lot to change it now. Which makes me say: > Meh... I don't like it, I don't want it, I don't need it, but I have to > accept it, because it will not change. To me it is merely a bad design > decision after all. It would take similar effort to fix the few problems in the Nim std library as it takes _me_ to fix the problems each time I run `c2nim`. For existing libraries, allow a compiler flag to use "partial casing". Or, do what GoLang does: Provide a **NimFix** like **gofix** to standardize the casing. Or add an option to nim-pretty. There is also a deeper issue here. The main concern I here at work about **Nim** is not something small like indentation or the default `import *`; it's the absence of a major company like Google or Oracle behind it. Minimally, a language needs to be actively developed by multiple coders. Python famously has a BDFL, but Guido only settles arguments. At some point, a language has to move to committee (unfortunately). The most important thing for **Nim** right now is simplicity. We need Araq to concentrate on deciding which language features are too complicated to support. Partial casing is a small amount of code, but it's needlessly complex and divisive. Drop it; eliminate some arguments and some real problems; then get back to deciding on a simpler version of "concepts" versus something like "traits". Simplify, simplify, simplify. I won't give up on **Nim** personally, but within my company I might have to pivot away from FFI-biased languages (since integration with other languages is just a hard problem) toward something less controversial, like Julia or Kotlin.
