Julia and Nim user here. I just want to add that multipe dispatch in Nim was only ditched for methods, which are functions (or procs, in Nim lingo) that belong to a specific object. Sort of class methods in C++.
While multiple dispatch is not Nim’s main feature, it is still possible to achieve some of its behaviour with plain procs. Check these two simple examples:
Moreover, by using the compile time when statement, it is quite possible to dispatch anything.
OK, well, in the context of scientific computing you sometimes even want such a distinction (cf. upper case letters for matrices and lower case for vectors/scalars).
But as I said, it’s not a show-stopper in my opinion 
Not sure if you’d consider Object Pascal modern (of which Delphi is the most famous implementation, but most people today use Free Pascal/Lazarus), but the original Nim compiler was implemented in it and Nim borrows a lot of ideas from the language, including case insensitivity.
I wish scientists were more inclinded to use descriptive names.
But very often, there is no description to make; f is short for “function”, A means “matrix”, x means “x component of a position” or “unknown value of whatever sort”. And they go into large mathematical expressions, with sins and sqrts and ^2.
Making descriptive names often means “make expressions harder to read for no good reason.”
I guess a lot of things that look weird to outsiders can feel natural to the users of a language, or at least not bothersome enough to make a breaking change. Personally I find Python-style indentation syntax equally alien. But if Nim users like it, them I am happy for them
That can certainly be the case for generic functions that don’t care about the contents of the collections they are working with, which might be appropriate if someone is designing their own collection type and implementing broadcast, filter, et al. The same would apply to generic algorithms.
Once the meaning of the elements in the collection is known, it’s time to start using names related to that meaning.
Usually, I try to use descriptive names for things in the module scope, while I use non-descript mathematical abbreviations for local names inside functions.
This way I can easily tell if a name is local to the function or if it is from a module. Local names can be understood by viewing the code locally and seeing how it is defined… not much further description needed. Module scope names need more descriptive names because the code is in a different place.
Also, using shorter local variable names allows me to fit more code on the screen, seeing more at once.
Valid concern, but this is not how it works: N is different than n, etc, the first letter doesnt count: the main usage is that
a_b == aB etc
and if you think about it … having abC be different var than aBc is a typo waiting to happen, so i think its ok
but still: i and I are different
you can probably simulate multiple dispatch with a good macro, also the plan is to maybe keep a version of it, but not use it by default , as for most nim usecases simpler static dispatch is much faster
this is not true:
x is different than X
x_y is the same as xY etc, but the first letter matters
Otherwise you’re right that the lang is influenced by those, good lang history 
other influences are probably python, oberon, lisp etc
Yeah, my comment about the awesomeness of case-insensitivity was not clear. I have not programmed that much in Nim, but used Pascal a awful lot: that was the time when this feature grew on me.
yes, just correcting because it is an important difference: nim itself usually uses x for variables and X for type
pascal was huge in my country as well, i think some schools still might teach it!
Eventually, yes. In my experience, descriptive names make a big difference in the amount of time it takes me to understand complex functions. Descriptive names are less important in short definitions.
I love the irony of this thread
What about leading and trailing underscore? And what about unicode?
The algorithm is here
https://nim-lang.org/docs/manual.html#lexical-analysis-identifier-equality
(also linked above)
But apparently toLowerAscii only works for A-Z, so it is unclear what happens if there is anything else in the string. An error?
no leading and trailing underscores iirc: which i think is good. I guess your usecase is x` ?
it seems unicode idents are fine, but i only tested with cyrilic
otherwise the char is not converted, so aЯ remains != aя