[oldmanjay]

> That said, it is still expected to use a consistent style within your codebase.

One of the fundamental truths I've learned over my decades of designing software for consumption by other developers is if you enable them to do the stupid thing, they will do the stupid thing. Expectations aren't really anything meaningful without enforcement.

[beagle3]

> if you enable them to do the stupid thing, they will do the stupid thing

Yes, that's generally true, but I think irrelevant to this specific question.

Most languages do not enforce a naming convention. Yet, Java projects almost always follow the same (horrible IMHO) standard, Python program almost always follow one of two standards (underscore_lowercase for everything, or the same with CamelCase for classes), C programs follows one of 20.

Even though Java & Go programmers can do the stupid thing in this specific instance, they generally don't, even without enforcement.

A C/C++ project usually has a salad of coding conventions, because each of the different libraries (e.g. Qt, GSL, libc/libm) has a different one - regardless of how conformant developers are to their official style guide.

Nim actually has an advantage in this respect: It allows you to maintain a uniform style in your codebase, even though it is expected to call out to different styled ones; though I agree a "nim --verify_style=blah_blah" would have been a useful option.

Personally, I think that's misguided - if you're using a library, it is better to use the original style (whatever it is) so you don't have to translate back-and-forth from examples, forum discussions, etc. But to each his own.

[mercurial]

There is a difference between "enforcing a style convention" and "treating different style conventions as equivalent". The first is much preferable to the second (eg, you could easily enforce lowercase_with_underscore for identifiers and CamlCase for types).

Treating different conventions as equivalent, though, is an excellent of ending with code that looks visually different (library A can still use Capitalized_with_underscore identifiers everywhere while library B relies on lowercase everywhere, same with Bob and Alice working in the same codebase) but is the source of surprising behaviours.

If you want to enforce style conventions, either make them mandatory at the language level or write gofmt. The Nim "solution" is one of the things that kept me from even wanting to spend two hours checking it out.

[beagle3]

It's been awhile since I've used Pascal, and I'm not yet on the Nim bandwagon - but when I did use pascal (and I did for a few years), the case insensitivity was not, in fact, a source of surprising behaviours. I have no idea what you're talking about.

It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name). Nim just feels like taking this a little farther - making '_' the lower case version of no character. Not at all a big jump from Pascal, and pascal is not confusing.

In fact, experiments teaching Python to non-programmers indicated that the two biggest confusing issues were case sensitivity and integer division[0].

> The Nim "solution" is one of the things that kept me from even wanting to spend two hours checking it out.

That sentiment is very often expressed by people coming from C/C++/Java about Python's indentation (What? Whitespace is significant to semantics? That's awful!). And you know what? I know not of one person who actually tried Python and actually had a problem.

[0] http://www.alice.org/ - can't find the rational description now; but I was following its development, and IIRC those were the two biggest stumbling blocks in Python (which were therefore changed in Alice)

[mercurial]

> It is not really confusing that you can't have both MoveFilesEx and MoveFileSex in the same scope (and that you can refer to a variable or procedure by a either name).

This "feature" makes it just as annoying as dealing with, eg, PHP, where the same codebase may feature NULL or null. It encourages inconsistency.

> Nim just feels like taking this a little farther - making '_' the lower case version of no character.

Yes, because making grep (and search functions from code editors and IDEs) useless is a fantastic idea :(

> That sentiment is very often expressed by people coming from C/C++/Java about Python's indentation (What? Whitespace is significant to semantics? That's awful!).

I have no issue with Python's indentation (apart from the fact that reindenting badly indented Python is not fun). That's a different problem. Whitespace is a different solution, but not particularly confusing.

> In fact, experiments teaching Python to non-programmers indicated that the two biggest confusing issues were case sensitivity and integer division[0].

I feel that basing the design of a language based on the use-cases of non-programmers, for something they will likely not consider an issue after two weeks, at the expense of code maintainability is a mistake.

[beagle3]

> This "feature" makes it just as annoying as dealing with, eg, PHP, where the same codebase may feature NULL or null. It encourages inconsistency.

This is not a problem in practice, after two weeks. Seriously - Pascal has fallen out of favor, but there are large pascal codebases that demonstrate this point. NIL, NiL, nIl, nil are all accepted as the null pointer. It really isn't a problem in practice, not even remotely.

> Yes, because making grep (and search functions from code editors and IDEs) useless is a fantastic idea :(

No, grep is not useless, though it isn't quite as useful (just as much as #define makes grep less potent in C/C++). nimgrep fills some of the void.

> I feel that basing the design of a language based on the use-cases of non-programmers, for something they will likely not consider an issue after two weeks, at the expense of code maintainability is a mistake.

The Alice study was just an example BASIC and Pascal (and its predecessors) were designed in the late '60s and early '70s and feature case insensitivity. Nim follows Pascal, not Alica.

It looks like you are really upset with choices because of some theoretical objection. I have not really used Nim, but I have used both BASIC and Pascal very extensively. Case sensitivity and alternate spellings are NOT problems in practice, even though you try very hard to imagine that they are.

[mercurial]

> It looks like you are really upset with choices because of some theoretical objection. I have not really used Nim, but I have used both BASIC and Pascal very extensively. Case sensitivity and alternate spellings are NOT problems in practice, even though you try very hard to imagine that they are.

I'm not upset, I happen to think that these choices add complexity and promote inconsistency for little practical gain.

> This is not a problem in practice, after two weeks. Seriously - Pascal has fallen out of favor, but there are large pascal codebases that demonstrate this point. NIL, NiL, nIl, nil are all accepted as the null pointer. It really isn't a problem in practice, not even remotely.

If you want to enforce a consistent style, it's one more obstacle in your way. And considering how often projects end up with little technical lead and no enforcement of style whatsoever, I'd rather avoid that.

> No, grep is not useless, though it isn't quite as useful (just as much as #define makes grep less potent in C/C++).

It makes it useless to find an identifier, which means useless 90% of the time I want to use it on a codebase.

> nimgrep fills some of the void.

See? More complexity for no appreciable benefit. A much saner approach would be to implement a compiler warning for this kind of thing.