I had an operating system with a parameter of a scalar process id, which in our parlance was spelled pidTarget. The documentation folk 'corrected' it in the manual to pIdTarget, which would mean a pointer to a target id.

Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler.

This is a reasonable concern, but after having used Nim for a couple of years I have never run into this as an actual issue. The benefit of being able to keep your entire program in one casing style outweighs these concerns. For that is the purpose of this style insensitivity, to allow you to use a library using snake_case in a project using camelCase and the other way around. And after having used Python with mixed case libraries I must say it is a good solution.

Now back to your concern of identifiers being read in different ways meaning different things. Once you know that this will be an issue you tend to think about it when naming your variables, and so it tends to not really be an issue. The thing is that once you get used to it you know that `pidTarget` and `pIdTarget` is the same thing, so you either relax you expectations, or you don't construct your names with this ambiguity. And besides, a "pointer to a target id" and a "scalar process id" probably don't share the same type, so the compiler should be catching that anyways if you ever used it wrong.

The big issue for me is it interferes with code search tools. I like being able to use ripgrep to find all uses of an identifier. That becomes hard with style insensitivity.

That is also a valid concern, with nimsuggest (and soon nimlsp) you will be able to easily find every instance in your editor (as well as rename them). For searching through files however nimgrep is probably your best bet, but that might break up your workflow. In my experience this hasn't been that much of an issue. Typically you write all your identifiers in the same style always, so most of the time you'll find what you need with just a simple grep.

well, yes, that's why nimgrep exists.

grep -i solves the case issue, and grep/ripgrep probably _should_ have a feature to ignore _ ; in which case you will be able to use them - but until then, nimgrep will do that work.

It seems crazy to me that people are so annoyed that their libraries have different style that we have to have additional tooling to make code search simple for the end-user.

You don't _need_ additional tooling. You can get by with just searching as normal, it's not as if people's code bases are filled with random conventions or random case variations...

style insensitivity WILL lead to typos that don't get caught. Someone will change the casing somewhere. Therefore you must always search with style insensitivity in mind.

Most people use completion anyways and it prevents this problem. Also, you can lint the code.

Styles are religions, including - in some organizations - the threat of excommunication if you don’t practice the one style.

I don’t know how atheistic style looks, but Nim is style agnostic - everyone can practice their religion and they all get along. C, Python, and the real world - not so much.

"Not hard to make up any number of examples where spacing or capitalization matter for good reason. They matter to humans; its just silly to make them not matter to the compiler."

This one point is always worth considering when deciding on user-facing portions of technology.

That's bad naming, if those had the same type, that would lead to subtle hard to track bug because a dev used one pid instead of pId.

Not in any typed language. Its instantly called out as an error.

But it's so hard to read: I admit a good IDE might help, but maybe it's not bad to prevent this on lang level.

that's why I said if those had the same type ;)

Common lisp also ignores case (sort of..it's a little bit more complicated). I've never found it to be a problem - apart from the compiler always uppercases my symbols when it reports to me, it feels a bit like being shouted at.

Forgot to add.. in common lisp everything is kebab-cased which makes case a lot less significant. Not sure what happens in Nim?

kebab-case? Is that even a thing?

It's actually easier on the hands than using `_`. As on a standard (us, uk, chinese, etc.) keyboard underscore requires a shift-press whereas minus/hyphen requires a single press. It's a small change but you'd be surprised how much of a difference it makes, given that tokens are a significant amount of all writing when programming.

Not to mention, in my opinion it's more aesthetically pleasing, but that's just me :)

Sure, Lisps allow many more characters in the identifiers, including all traditional operators (makes sense, since the "operators" are just functions and they had to be defined somehow in the first place...) You get functions named like add-message! create-response/text bytes->string/utf-8 and so on. Kebab case refers to identifiers with words separated with minus sign, like some-class-member-doing-something etc. Some infix languages borrowed this, like Dylan and LiveScript, among others.

Common Lisp actually lets you use any string for an identifier if you wrap it in pipes, though you have to be a bit careful of casing in that case. Still for so many characters on the keyboard it's not needed to wrap which is so convenient as you illustrate.

    (let ((|hello world| 3)
          (|HELLO world| 4)
          (|こんにちは (jp)| 5)
          (|pi\|pe| 'piped)
          (|newlines
            work
            too| 6))
      (list |hello world| |HELLO world|
            |こんにちは (jp)| |pi\|pe|
            |newlines
            work
            too|))
    
    ; --> (3 4 5 PIPED 6)

Not as common, as it clashes with using '-' for subtraction, but as that's never been a problem for Lisp, it's quite common there. Perl6 went that way, too, despite having infix syntax. But hey, it's Perl, we're used to syntactical warts.

Ah.. I had wondered why it wasn't used in most other languages. Now, of course it seems obvious.

> looks-like-this

http://wiki.c2.com/?KebabCase

Sure it is. Think of what it looks like, and think of a skewer with kebabs on it ...

Search HN (box at bottom of page) for Perl6 and you will find many articles with references to kebab-case.

As mhd said, it's used in Lisp too.

I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix. Upper/lower case add a new dimension to name things that are related but different.

But is not a deal breaker for me. If the language doesn't let me I can use `ii` or `i2` or whatever.

> I have written code to traverse matrices in which I use indices `I` and `J` to iterate over submatrices and indices `i` and `j` to iterate over individual values in a submatrix.

Please notice that the first letter in Nim is case-sensitive, so `I` != `i`, and you can continue use your conventions.

And before some new comment starts bashing that, I think this is a must so you can differentiate your types, written in PascalCase, from your variables, written in camelCase.

A better rule would be a unique definition of: - "myVar" - "myvar" - "my_var" - etc inside a scope, once you define the first.

yeah but if you do that and the language lets you get away with it... ugh

I did not know this about Nim and does also seem quite a big turn off and a bit of a WTF decision

I have never coded any Nim, just read about it though :)

I've never used Nim either (mostly C/Perl6/Clojure), but all I hear when this gets brought up is that I would finally be able to use a consistent style for all code I write, regardless of whether or not I personally implemented everything I'm using.

thinking more about it...

I guess the intention is NOT to let you carelessly use Myvar, MyVar and myvar willy-nilly in your code, as I had first imagined

I assume the intention is to PREVENT you from deliberately defining those names as different vars, which would be confusing

So, on reflection, maybe it is not such a WTF