5 ms·

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. Nim'

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. 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. (That philosophy extends far beyond naming conventions.) What this avoids is being stuck with antiquated standard libraries that continue to do things contrary to the language's standards for the sake of backward compatibility (arg Python!) and 3rd party libraries where someone chose a different standard because that's their preference (arg Python! JavaScript! Literally every language!). 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. Your code is inconsistent because someone else's code was inconsistent - that's simply not a problem in Nim. Could Nim have forced everyone to snake_case naming structures for everything from the start? Well, sure, but then the people that have never actually written code in Nim would be whining about that convention instead and we'd be in the same place. After having actually used Nim, my opinion, and I would venture to say the opinion of most, is that its identity rules were a good decision for the developers who actually write Nim code.

patrick451 5y ago
> 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.
IshKebab 5y ago
> 3rd party libraries where someone chose a different standard because that's their preference C & C++ don't have a standard style but Python and JavaScript definitely do. And Rust and Go and I would guess most projects. Find me a popular library in one of those languages that doesn't use the standard style.
goodpoint 5y ago
> then the people that have never actually written code in Nim would be whining about that convention Spot on. I wrote plenty of Nim and the style-insensitivity is a feature and not a bug. Not allowing the use of 3 different variables named userName, user_name and username only encourages readable and robust code.

patrick451 5y ago

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

IshKebab 5y ago

> 3rd party libraries where someone chose a different standard because that's their preference C & C++ don't have a standard style but Python and JavaScript definitely do. And Rust and Go and I would guess most projects. Find me a popular library in one of those languages that doesn't use the standard style.

goodpoint 5y ago

> then the people that have never actually written code in Nim would be whining about that convention Spot on. I wrote plenty of Nim and the style-insensitivity is a feature and not a bug. Not allowing the use of 3 different variables named userName, user_name and username only encourages readable and robust code.