It appears that you don't understand Erlang syntax. Go back and read these two chapters [0][1] of Learn You Some Erlang, and revisit the article.
Seriously? Making case not merely distinct but semantically significant is a deal breaker for me.
(Does that at least work for all Unicode characters that support case distinction? If we start an identifier with a Δ, is that a variable name, as opposed to starting with δ?)
> It appears that you don't understand Erlang syntax.
Yet I formed a correct hypothesis: the meaning does hinge on the case of X.
I only formed this hypothesis because I'm jaded.
The designer of a non-clusterfuck syntax would be offended by such a cynical hypothesis. ("How can you even think I made case semantically significant in a symbol?")
I was hoping someone would tell me exactly that and set me straight about how it really works. Like maybe that X and bar are assumed to be declared somehow or whatever.
In short, it all goes back to Prolog, the language used to write the (first versions of) Erlang's first compiler. Prolog has bequeathed quite a bit of its syntax to Erlang and also chunks of its semantics, for instance the pattern matching (although arguably that may be a trait inherited from its functional lineage instead, or maybe Prolog borrowed it from LISP, or possibly it was just convergent evolution).
In any case, in Prolog any term that begins with a capital letter or the underscore, '_', is a variable. A single underscore is a "don't-care" variable. There is a very good reason to syntactically distinguish variables from non-variables like this. Note that I said "any term" earlier, rather than "any identifier". In Prolog, variables are never stand-alone identifiers[1], instead they are arguments of predicates. That's because Prolog variables represent logic variables, rather than computer science variables. By "logic" here I mean mathematical logic, as one may find in textbooks. In this sense, logic variables are not meant as references to memory locations (though in Prolog it's very convenient to see them as such, at times). Instead, they represent unbound terms, terms whose value we do not know until a certain point in our calculation, or indeed computation. Once the value of a variable is known, it stays the same until the end of computation (it's immutable) and we speak of the variable as being "ground" or "bound to the value".
Now, first-order logic predicates, and therefore Prolog predicates, are written in clausal form as:
F(t1, t2, ... tn)
Where "F" is a ground term and t1,...,tn any number of terms, each of which is either a ground term or a variable (ie, unbound). So we need a way to tell ground terms from variables. In textbooks, the convention is to denote variables with lowercase letters and ground terms in uppercase. In Prolog it's the other way around, probably because of some concern over overuse of the Shift key in old-style keyboards.
The alternative of course would be some kind of annotation of the varible, with an additional term. For example, we could use the functors "ground" and "variable". This would make for hairy syntax though; look at our example predicate from above:
ground f(variable t1, variable t2, ground t3)
That syntax would just make it harder to see what's going on. Instead:
f(T1, T2, t3)
- makes it perfectly clear that T1, T2 are variables and t3 is a ground term. [Edit: where "predicates", in Prolog, read "functions" for Erlang. In Erlang also there are no stand-along variables declared, or referenced, outside of functions so the same hairy syntax would have to be adopted to distinguish them].
... And that is how Erlang got its uppercased variables.
________________________
[1] So in Prolog, as in first-order logic, one cannot declare variables separate from predicates. You don't start a program by laying out a bunch of variables and their types etc. Variables live between parentheses, as parts of terms, never anywhere else.
Well OK, you can also do this:
f(T1, T2, t3):-
t3(T1)
,T2
...
Erlang was designed and first written back in the 1980's, so characters that fall within the latin1 encoding are the only acceptable characters in atom and variable names. However, UTF-8 source files are fully supported, as is Unicode in lists and binaries. There is a proposal to make Unicode characters accepted for atom and variable names, but it hasn't been accepted yet, as the details are (as you allude to) tricky. [0]
> The designer of a non-clusterfuck syntax would be offended by [the conclusion that I came to].
I can't agree with that. Initially, I thought that the case-significance was strange, but -as I used the language- I quickly found that the ability to distinguish at a glance between an atom and non-atom type is very valuable. These are things that you don't understand until you learn about the language, and maybe actually use it some.
Erlang's syntax is strange, but not even within ICBM distance to being a clusterfuck. Frankly, Python's significant whitespace has caused me far more lost hours than any strangeness in Erlang's syntax.
> I only formed this hypothesis because I'm jaded.
Heh. I expect that the fact that you've likely seen many imperative and some functional languages in your day, and that Erlang is -despite its syntax quirks- a language that is rather well designed and makes sense once you look at it for a few minutes, has far more to do with it than your disaffectedness. :) [1]
From your other comment:
> I promise you, I will not write another word anywhere about Erlang.
That's a pity. Erlang is rather quite good at what it's designed to do, and a real pleasure to use. Many folks report that Elixir is at least as rewarding to work with.
[0] http://www.erlang.org/eeps/eep-0040.html
[1] As an aside, I note that in your opening comment, you mention that the syntax is "incomprehensible rubbish", but yet you correctly determined a pertinent feature of the language syntax in very little time at all. This kinda puts the lie to your claims of incomprehensibility. ;)