> I wish this tired, boring argument didn't derail every conversation that remotely mentions Nim. See: literally every past HN post with "Nim" in the title. Th

> I wish this tired, boring argument didn't derail every conversation that remotely mentions Nim. See: literally every past HN post with "Nim" in the title. This is a serious design flaw. It absolutely should be front and center when Nim is discussed. > Nim's underlying, perhaps understated philosophy is that it lets you write code the way you want to write code. If you like snake case, use it. If you want camel case, sure. Write your code base how you want to write it, keep it internally consistent if you want, or don't. Nim doesn't really care. I want to write code where "myFoo != my_foo". Evidently, nim doesn't allow that, so this argument seems pretty hollow. > Now you're stuck with screaming linters or random `# noqa` lines stuffed in your code, and that one variable that you're using from a library sticks out like a sore thumb. This is because we have crappy linters. If a linter can't tell that an identifier is camel case because it is third party, it's a bad linter. > Could Nim have forced everyone to snake_case naming structures for everything from the start? This would have been preferable to this madness.