Or gets_hit_done one.

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.

Why is it crazy? I've wanted this feature recently in other languages. Just because someone else wrote FunctionName doesn't mean that I want to write it that way.

Case insenstive search solves the matching problem adequately. You could also do underscore-insensitive searching.

Why is it a problem, or crazy? It's a natural extension of being insensitive to whitespace and formatting. If you like your code to look_like_this, fine. Someone else PrefersThis. It can all interoperate. I think that's great. Leave style to each person's preference.

> Also, it's specifically the kind of semantic indentation found in Python, not (to such a degree) the kind typically found in Haskell. It's easy to find examples: Almost every edit that moves code around takes higher cognitive load than the equivalent done in a language where blocks are explicitly delimited.

I disagree. Moving code around in Java or C++, pure brace languages, has at least as much cognitive load as Python does, and as most languages do. Are the variables referenced defined in the new scope? do break/continue still function as expected? Are exceptions properly handled and propogated?

The indentation is usually the least of one's worries when moving code around; and at the very least, Python (and I assume Nim, though I hardly have any experience with it) guarantees that the visual and logical code hierarchies match; The fact that they might not is a constant cognitive load in curly brace languages (and a source of bugs if you ignore it).

> Go ahead and tell us what benefits and detriments you're already aware of, having thought about the question, and I'll tell you if you've missed anything.

Just a second, let me put on my Eiffel/Ada hat for this question.

The contract between a caller and callee is a potentially complex thing; it specifies not only which arguments can be mutated (if at all), but also how their abstract state before and after relate to each other or what other visible side effects may be produced. I refer you to the Eiffel and Ada language specifications for possible ways to specify such contracts, invariants, and pre- and postconditions. Common convention is that functions that return a value do not have visible side-effects at all (the Ada '83 rationale specifically found limitations that disallowed all side effects at the language level too limiting). See: Command-query separation. Adhering to CQS, queries do not mutate arguments, and commands are expected to; hence, you need to know the specific contracts for commands and how they affect their arguments, but can rely on query arguments not changing.

More generally, mutability of arguments is just one aspect of a contract; importantly, in order to be able to optimize or change the internal representation of an object, we may desire the option of having mutability of the concrete state even where the abstract state remains immutable (e.g. splay trees or self-organizing lists, arguments that have internal caches, etc.). Languages that force a knowledge of immutability of the concrete state at the call site can thus violate principles of modularity in that they limit how the implementation may change.

Declarations of immutability of only the location of the variable at the call site (as with out/ref parameters in C#) are of even more limited value; while they guard against some clerical errors, it is not clear that this protection justifies the additional syntactic footprint.

Back to Nim: The simple solution to ensure that a variable is not being modified by the callee, if you desire that, is to use a "let" rather than a "var" declaration. In fact, using "let" for values that you do not intend to change further and only use "var" variables where they are expected to be mutated throughout a procedure is already idiomatic Nim [1] and should guard against the majority of related clerical errors of this kind.

[1] https://github.com/Araq/Nim/wiki/Style-Guide-for-Nim-Code

> I've been learning Rust, which requires notation at the call site that you're passing a mutable reference, and thus far, I quite prefer it; I had been concerned that it might be "too much typing", but it's proven to be rare and unobtrusive.

I'm so glad Rust made this design choice, because it means that a programmer can see very quickly where borrows are happening and understand where and where not new borrows could be inserted.

Take this example:

    struct Widget {
        name: String
    }
    
    fn jabberwock_the_widget(w: &mut Widget) {
        w.name.push_str(" (modified)");
    }
    
    fn main() {
        let jimbo = Widget { 
            name: "Jimbo".to_string() 
        };
        let name = &jimbo.name;
        jabberwock_the_widget(&mut jimbo);
    }

If that call were just `jabberwock_the_widget(jimbo)`, and I didn't have `jabberwock_the_widget`'s signature at hand, I would have to run the code through a compiler to see that there is an illegal mutable borrow on jimbo. With mutable borrows written so explicitly, it's clear at the call site that it can't happen with the existing borrow on the widget's 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.

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.