Hacker News Reader

Comment by derbOac | Hacker News Reader

I was hoping case sensitivity would be implemented but it seems like it was too controversial. I'm thinking at this point there might be too much resistance.

View on HN

Case sensitivity is worse in every way IMO. Look at Nim's implementation of UFCS, which means `foo(bar) == bar.foo`. This means only one possible `foo` that takes type of `bar` can be invoked. There's no ambiguity if `foo` is a method, a proc, or a field - if there were, you'd get a compile time error.

Similarly, case insensitivity, of course, means `foo == fOO == fOo == foO`. Reducing these to one identifier means less ambiguity to the programmer and encourages either using sensible names that can't easily be confused, and/or unambiguous mechanisms like the type system designed for this purpose.

Say you have a constant for 'light enabled' Instead of naming it `lEn`, it's better to use `type LightState = enum disabled, enabled` and write `light.set enabled` for so many reasons. Same goes for pretty much everything. It's worth noting as well that the language is very good at resolving overloads by type, so if you have your own object and create a `len` for it, it's not going to get confused with the string `len` or even a `lEn` constant. Even if you have a `lEn` and `len` that are used in the same context with the same types (why though), you can qualify it anyway with `module1.lEn` or `module2.len`.

The language has so many easy tools to make things more explicit and easier to read at the same time. Ultimately, case sensitivity only really ends up encouraging bad naming practice without adding anything back.

The `--styleCheck:error` flag can be passed to make everything follow NEP1 style guide [0]. `--styleCheck:usages` can also be passed to instead make identifiers follow their original naming (Basically turning off style insensitivity)

- [0]: https://nim-lang.org/docs/nep1.html

John Carmack has a take on it;

https://twitter.com/ID_AA_Carmack/status/1592560938208710659...

I think I agree with Carmack on this. I'm hyper aware of case now, but this was probably the major cause of errors for me when learning (didn't help that tooling was less good then, so there were no linters pointing out my errors).

I guess for me it's one of those things I got tripped up on initially but came to appreciate later. It taught me how to be more precise about characters and reasoning about them in code.

There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it.

Personally this preciseness is just a distraction, but it sounds like you have learned from the constraints and can now take the training wheels off again.

Very curious about those cases, yet to find one myself that was not because of a bad design decision. Though I am also very big on the idea of `ambiguous grammar, rigorous implementation`, for natural language too. (Toki Pona is a somewhat extreme example but the contextual grammar, and holistic minimalism is fascinating)

Not to make it longer than needs to be; But take the example code in this readme: https://github.com/guzba/mummy

Being able to quickly script this without thinking about cases or style on the first pass is a really lovely way of reducing friction imho.

> There's also cases where case sensitivity should matter in naming in my experience, and it's not possible without it.

I'm really curious, do you have any examples? I can't think of any that wouldn't be better served by using the type system.

I've come to increasingly accept it over time? I mean, I'd really like it if my_function() and myFunction() just weren't allowed in the same section of code but if you allow the user to have both it's probably better that they refer to the same function than different functions.

It is a strange feature but it does have a good underlying idea.

Why would having two functions, named makeFile and make_file in the same program ever be a good idea?

Think of it as less of a language syntax feature and more of a code style enforcement paradigm.

Good lsp support makes it mostly fine imo.

Imo it goes beyond that. You have folks from Java etc. coming over with their camel-case as well as python folks with snake-case. Now despite both of them writing in their own styles, their code can interact, because when the java-programmer gives you a `validateObject` procedure from their package, the python developer can just use it as `validate_object`.

Not being forced into other people's style choices is a really nice boon to me.

It's not so much that anybody thinks that mix is a good idea, but it's just what happens immediately in any C/C++ codebase if you're using any nontrivial combination of libraries at all. The feature is about providing consistency, not ignoring it.

My_function vs myFunction Is fine but do_me vs dome start to differ and do_me vs d_ome vs dom_e start to make things very much different.

That's the real problem

Rarely a problem. Why would you have two procedures named do_me and dome with the exact same signature?

Because the other procedure does something with some dome?

Then is should be named doSomethingWithDome.

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

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.

I didn't know this existed. There's a lot I like about Nim, but total rejection of tab indentation, and now this style insensitivity thing, mean that for me personally, Nim will just stay an interesting language I see on HN from time to time.

I am not a fan of case insensitivity either. But it must be easy to write a case insensitive grep. I wager that a nim grep would already exist.

I do agree that this is a red flag decision.

https://nim-lang.org/docs/nimgrep.html

If you use choosenim to install Nim several executables get built/downloaded along with the compiler:

   $ pwd && ls
   /Users/me/.nimble/bin
   choosenim  nim  nim-gdb  nimble  nimgrep  nimpretty  nimsuggest  testament

https://github.com/dom96/choosenim#readme

The partial case-insensitivity thing is not new, it's been part of Nim for a long time, maybe since its very beginning but I'm not sure about that.

https://nim-lang.org/docs/manual.html#lexical-analysis-ident...

It's one of those things that, as a Nim hobbyist programmer, I think is a neat feature to have, but I could see being a big hesitation for use in professional environments.

Given that you tend to use linters in those environments as well and that you can turn it off anyway, I'd disagree on that one. There are other factors that would make me hesitate in a professional environment much more, such as community size and talentpool.

Why?

Reply on news.ycombinator.com