I think a vote would be fine. Ballot box stuffing is possible, but probably
identifiable via sheer numbers since the Nim community is so small unless the
vote gets HackerNews'd or Slashdotted. I also agree that the people who matter
most would never participate in such a vote because they've already dismissed
Nim for being "too creative" on the identifier front.
Wording matters a lot, too, as in any survey. I'd wager that there would be
almost zero "yes" answers to a "would you stop using Nim if it became fully
sensitive?" question. Also, a "do you know at least one developer who never
tried Nim because one of the first things they heard about was its 'weird'
ident rules?" would probably get an average of >50% yes's. Developers in very
niche internet languages are not always the most social creatures or my
estimate would be higher.
Personally, I like identifier _sensitivity_. I think things that look different
to a person should be treated as different by the system, especially a system
used by programmers who know one wrong character somewhere breaks a program.
Ease of use studies about filesystems by non-programmers are at best weakly
relevant - and anyway often there is a wrinkle of "creation time casing" and a
"reference time casing". Studies in text also show using ALL CAPS ALL THE TIME
makes characters most easy to distinguish, but programmers tend to not want to
do that.
In physics and math (where the underlying syntax of adjacency implies
multiplication) single character variable names like F=ma and subscripting
prevail. The handwritten/specialty script nature of those fields then pushes
users to use _more fonts_ and italics and bold face and so on, and you often
see textbook authors declare their style conventions. In general, more terse
languages without a lot of syntactic noise (like Nim) benefit more from shorter
identifiers which in turn benefit more from sensitivity. Speaking in voice
about "cap A" is as easy as "A zero".
Giving more picky people flexibility to define their own conventions seems good
to me, and to me that means sensitivity not the current rules. Less picky or
more overall consistency-oriented people will just go with the flow and imitate
Nim standard library conventions. Many will always go for camelCase since they
know they'll have a lot of stdlib calls and the stdlib does that and so they'll
want their own code to match that "larger world convention". C programmers
imitating C stdlib and Java the Java APIs and C++ or POSIX programmers the
POSIX apis and so on drive all this enormously. So, the core Nim community can
probably get most of what they want just by controlling the style used by the
stdlib.
Also, one has to pick which battles one fights! _Injudicious_ choice of
characters will _always_ be a problem. In typical fonts for Latin script
languages the upper- and lowercase versions of a letter "visually collide" for
about 50% of the 26 letters. For another 50% there is a lot of visual
ambiguity, like the similarity of O/0, 1/l { big-Oh vs zero and one vs
lowercase-ell }. Colon and semi-colon, commas and periods are often really hard
to see much difference in but make the world of difference. To my knowledge, no
one suggests in any seriousness that Nim should forbid big-Oh or little-ell
from identifiers or that writing Nim should require a certain font because
otherwise it's hard to tell what means what. Sometimes you have to just rely on
users of any language to not choose to write deliberately confusing things or
use programming-hostile fonts.
However, it is perfectly fine ( _fantastic_ , even!) if the compiler has one or
several warning systems (that can be easily turned off by a flag) for _ALL
SORTS_ of confusing scenarios that "encourage" clarity/simplicity. People "in
the thick of it" can have the warning be active. People more in their own
closed world or with habits/inclinations/fonts that make certain mistakes less
likely can turn it off. Problem solved. Besides naming convention issues,
uneven spacing around operators is a good example. There's a warning for that
in place now. Another example without a current warning in place would be
spaces of leading indentation -- 1 spaces vs 2 vs 3 vs 4 vs 8 -- all currently
treated the same by Nim. A shift from indents of 1 to 8 is probably some kind
of bug or at least a highly erratic formatting style. The compiler warning
could even take some limit where a change of indent shift by <=N was ok and
warn only for changes bigger than that.
