Hacker News Reader

Comment by Varriount | Hacker News Reader

I agree that it's unusual (and likely scares off some), however it's not entirely case insensitive. First, dashes/hyphens (`-`) can't be part of identifiers. Second, the first character of an identifier is not case insensitive.

So:

FooBar != fooBar

FooBar == Foobar

Most of the developers in the community are ambivalent about it, because it rarely ever causes problems. If you end up misspelling an identifier, you're nearly always going to get a compile-time error due to static typing anyway.

View on HN

Only the first letter being case-sensitive is a major strike against readability, one of four major pillars. While I’m sure the Nim developers are probably used to it by now, it just seems like a bad design decision Nim is probably burdened with as the result of legacy/interoperabilty.

Even just reading your foobar example at a glance took a moment for me.

And case insensitivity is also generally frowned upon. To have a language with both sensitivity and insensitivity is the worst of all worlds with none of the benefits.

If you want to understand why at a deeper level I would recommend reading readability or the case insensitivity sections in any programming languages book. Personally, I enjoy Programming Languages, Principles and Practice (Louden & Lambert)

EDIT: Yes, I get it, it doesn't affect YOU. But it doesn't mean it doesn't affect other people. Non-english languages and/or speakers are an easy example. It also eliminates a whole class of human error, and maybe that only affects non-experienced juniors, but they exist too. There are other issues with symbols being case insensitive and string values being case sensitive. If you want a practical example a classic one is HttpsFtpConn vs. HttpSftpConn

As a powershell user I have never had an issue with case sensitivity at the language level as Sigils provide separation of concerns between language constructs (keywords/variables/types). You’re using an IDE with autocomplete most of the time and many other languages have linters/formatters.

All I have personally experienced of case sensitivity is an added layer of friction any time I go to use a REPL for Bash/Python/Javascript/etc or some awful ‘allowercasewords’ gets cemented in place barring a total refactor since you can’t correct files piecemeal.

And case sensitivity in the language doesn’t even help with case sensitivity at the OS level when you’re writing cross platform code =/

The theory says that it hinders readability but in practice it doesn't. Nim has a prescribed style and if you use the linter when compiling your code has a consistent style.

Like cardanome said, in practice it's awesome for FFI.

> Only the first letter being case-sensitive is a major strike against readability

…How? Do you find code more readable when there are two different names that differ only in the capitalization of a non-first letter?

Very good example. I didn't even know about first letter sensitivity and the rest insensitivities. That's real big problem.

Also since nim is very ninche and used by very little perscentage of the world they haven't encounter much of production scale coding. Well that may be reason nim never get pass weekend hobby projects..

You can also enable --styleCheck:usages, which warns about casing inconsistencies in your code. (So it catches mistyping FooBar as FooBAr.) Then the only difference from other languages remains that you can't use weird casing differences for separate symbols, e.g. you can't name two separate variables fooBar and foo_bar, which you wouldn't normally do anyway.

Ha this always happens with case insensitivity. It's case insensitive.... except for some situations you need to now remember. I believe PHP has this issue too.

It isn't a good look that they made the same mistakes as PHP.

Nim has a good reason to do it: library interop. You can use a third party library that for some reason uses snake case, but you want to follow the camel case that NEP recomends. You just do it, and your codebase is all in the same style. In fact, it the third party library updates their case, it doesn't break Nim code that depends on it (that happened for example to Python Selenium, when they went from camelCase inherited from Java to snake_case recomended in PEP8, forcing all dependent code to update).

I personally don't like that you can have "is_OK" and "isok" and "is_ok" in the same code as three valid different things. Or having "GL_FLOAT" and "GLFloat".

Both options come with tradeoffs. Don't jump so quickly into "that is a mistake" and allow the devs the benefit of the doubt. There is only one rule you need to remember in Nim: only the first character case matters.

That's not a good reason. Why not just standardise the entire ecosystem on the same style? If you think that sounds infeasible, consider that Rust, Go and even Python have done this with no problem.

Show me how Rust, Go and Python automatically rename a foreign library types and functions to match your language style.

The bindings generator that produces the FFI glue code does it so everything comes out in native style.

That sound very close to "Rust is useless: why not just code in C without memory bugs?"

As menctioned, a few years ago Selenium had its methods in camelCase. If your code used Selenium, it had to be camelCase and snake_case mixed. When Selenium standarized, it forced everyone to switch to snake_case.

Nim puts great effort in FFI. It means you can easily use C libraries, using their names, even if the case doesn't match, and your code is still coherent. Look at the sample code in https://www.py4j.org/index.html : why do they end with "random.nextInt(10)" in their Python code? Didn't Python had this solved? Not saying that this is the end of the world, but the Nim way is not a mistake either.

Because an important feature and focus is that nim compiles to c and makes it easy to just import and use c libraries. So many of the 3rd party libs mentioned are NOT technically part of its ecosystem. There is at least one thread on the nim forum that extensively explains the reasoning behind the decision in much better detail and pretty thoroughly debunks this “problem”

Python literally has modules in its standard library that violate the PEP8 naming conventions.

That's is even more unexpected.

FooBar != fooBar

FooBar == Foobar

That could cause a lot of head ache in large code base ..

Reply on news.ycombinator.com