Hacker News Reader

Comment by matthiaswh | Hacker News Reader

It's apparent from the RFC discussion that there is no consensus on the topic. With little (proven) tangible benefit of making the change, and a large potential for backlash within the small existing community, I'm not certain it's worth the risk for Nim to make this move.

https://github.com/nim-lang/RFCs/issues/456

View on HN

Anyone who wants to use grep will just keep ignoring nim. Case insensitivity is pretty silly, and underscore insensitivy is just really silly.

The way that modern languages force a single style is great, and it's a big strike against nim, which is an otherwise nice language.

Ironically they reject tabs and require space indentation. Something something the complexity of supporting both. Yet we have style insensitivity..

To be fair, you can tell your IDE to just turn tabs into spaces and call it a day, that's an issue for all of 5 minutes.

What you can't do is tell your IDE to interpret camel-case as snake-case if you want (or vice versa), just because this package you really need uses camel-case and you want to use snake-case.

That actually makes whitespace syntax in Nim much better. Can't recall the number of times I copied Python code snippets and had to track down lurking tabs.

You can't mix tabs and spaces in the same file since Python 3, which completely solves this problem without imposing one or the other choice on the users.

As someone who has never explored nim but was was just about to follow the link, you have effectively convinced me to not bother. I can imagine the arguments for case insensitivity (not agree with them but I could live with them for certain tradeoffs), I can't find a place in my brain where "underscore insensitivity" could have existed as a concept before reading those words.

You should still try it. It's a pretty decent language that builds fast and runs fast. I think of it as a slightly better Go.

Just treat Nim as style-sensitive and you'll probably never run into a problem with it. Seriously.

I had this gripe about it as well, but then I learned that you can force style in your own projects with a switch.

As someone who has been writing nim for many years now, using grep, rg, and various other search tools I can say that I've never had any issues with finding things I wanted. This is just one of those imagined issues that your realize doesn't exist when you actually try to do it.

Thank you, I have tried it, and it was frustrating.

Agree to disagree. I don't want to force my users to use snake-case just because I use camel-case and vice versa.

There's options to turn it off, options to turn it into a warning when you have style issues so you can make them consistent and it prevents similar names that shouldn't exist in the first place by causing compiler errors (if you have is_ok you should not have isOk in the same scope, what are you doing). It is just not a big deal, at all. And as stated, it is not hard to ensure consistency within your codebase by heeding compiler warnings/errors.

Its not an actual issue, it is the projected experience of another language and/or IDE/ tooling. Fyi the newest GitHub ignore case. But I have been using grep with nim code daily and it was not an issue.

Oh yes, just like you can never find anything in Google because it's case insensitive.

> It's apparent from the RFC discussion that there is no consensus on the topic.

That's your take? I can see a couple of actual nim users complaining, the rest are some randos that tried to derail any productive discussion with "I have an old C library that uses three different styles for init, how would I bind it to Nim?" and although a bunch of workarounds exist, they were too loud and stubborn. For me it showed that most nimmers prefer style insensitivity as an option, although they don't use it in the same project.

Reply on news.ycombinator.com