[citycide]

I think it's hugely underrated. I agree that it really is a fun language to use and as someone who came to it from a web dev perspective with no prior system level experience I had no trouble at all being productive in it (I built four internal Windows GUI apps with it).

But there's also some things that make people nervous -- like case & style insensitive names (ie. `read_file` is equivalent to `readFile`) -- that are almost never an actual issue.

Having that be more widely understood would do a lot of favors for Nim, and once the language hits a stable 1.0 I could see it getting a lot more attention.

[dilap]

> But there's also some things that make people nervous -- like case & style insensitive names (ie. `read_file` is equivalent to `readFile`) -- that are almost never an actual issue.

Gahhh, why would you do this? It just seems like it'd be a nightmare to use grep to understand your codebase.

[citycide]

This is exactly my point when I say it needs to be better understood: you wouldn't do it within a single project, but if you've got a third party library that exposes a `read_file` method you can use it as `readFile` meaning your own code base is more consistent.

In other words, you're not limited by the design decisions of another developer (or language, as nimmer pointed out).

[dilap]

Thanks, that's interesting. I see the justification for it, at least.

I don't know if the whole world is magically living with much more orderly developers than I have had the pleasure to work with, but I guarantee you that if I were using such a project at work, we'd end up with the same variable being referenced different ways.

I really wouldn't be able to grep for variables with confidence.

(Cf. Carmack: Everything that compiles will ultimately end up in your code. In the context of exploring static analysis tools, which were finding lots of errors.)

I do like the idea for uniformity though, but it seems like maybe better to restrict it -- define project-based 'style-rules', and automatically translate when moving between domains.

So foo_bar inside package A must be accessed as FooBar inside package B.

[jitl]

These style issues are trivial to enforce at commit time (pre-commit hook) and build time with a linter. It’s easy to enforce the order you desire upon your developers.

[dilap]

does such a linter actually exist, or is this the mathematicians trivial, "it is not required to discover something new to do it"?

[arc776]

> I guarantee you that if I were using such a project at work, we'd end up with the same variable being referenced different ways.

Luckily this is trivial to resolve as the compiler reports ambiguous variables as errors and you can then prefix by module name if required.

[dilap]

Hmm, maybe I misunderstood the feature.

If I have a variable declared as fooBar, and somewhere else in the code someone refers to it as fooBAr, does that compile, or is it an error?

[dom96]

It compiles, but is definitely considered bad style.

[sshine]

What if an external C library defines readFile and read_file and you want to refer to read_file as readFile?

If you explicitly rename your functions as you import them, that should have more predictable behavior.

Still, it's a nice sentiment.

[dom96]

What sane C library would do such a crazy thing though? :)

[The_suffocated]

Being case insensitive is a PITA for implementing any numerical algorithm you read from a paper. Most mathematical symbols are single-letter, and quite often both capital letter and its small letter counterpart are used in the same paper.

[rlp]

The first letter of a Nim identifier is case sensitive, it's just the rest that aren't.

[The_suffocated]

You are right. I didn't notice that before.

[nimmer]

I use Nim a lot and I've never seen libraries that mix different styles. I use grep without issues.

Style insensitivity is useful when wrapping C libraries.

[SolitudeSF]

specifically for this nim ships with its version of grep - nimgrep