Isn't having self-explanatory commands one of the strenght of LaTeX? What makes you think that expl3 commands are not self-explanatory? I mean, \carlatex_if_selfexplanatory:NNnnTF looks very self explanatory to me, compared to \carlatex@ifselfexplanatory.
– ManuelNov 7 '17 at 10:14

This is the first time I have heard anyone describe LaTeX macro names as self-explanatory. See my rant on the topic.
– AdityaNov 7 '17 at 16:37

1

The question in the title seems very different from the question(s) in the body. The body raises various quite significant issues about differences between naming conventions in LaTeX3 and LaTeX2e — subtle and complex things which really do affect usability of a language. But the specific difference mentioned in the title — the choice of underscores vs. camelcase for making multi-word phrases into command names — is a pretty trivial one, which doesn’t affect usability much at all so long as one convention or the other is followed reasonably consistently.
– Peter LeFanu LumsdaineNov 8 '17 at 15:47

expl3 couldn't use @ as it could to easily clash with existing commands and packages and from the other possible non-letters (!,?, *,+,...) imho underscores are not a bad choice: When you get used to it you can read many commands like sentences. \cs_set_eq = commands set equal, \tl_if_exist, \regex_extract_once.

The :NN-syntax

One problem when reading (La)TeX code is that it is very difficult to see how many arguments a command has (if any). This makes it difficult to understand the processing of a command and to debug errors due to missing or wrong argument. A command like e.g. \@sect takes 6 arguments but you have to go back to the definition to see this. With the :NN-syntax you have a much better overview.

Is it also partly because (La)TeX doesn't give you very nice error messages when you leave out missing arguments, too (unlike programming languages like C/etc. where you have stronger separation of commands/procedure calls)?
– JABNov 7 '17 at 17:35

The function you mention has a name consisting of three parts: cs, set and eq.

cs is the “module name”: the function deals with functions (for definitions and things alike); cs stands for “control sequence”, probably it's not the best name, but it's too late for changing it.

set is the main action type; in this module there are basically three action types: new, set and gset: the first one is for globally defining new functions, checking that the name is not already used; the second and third ones do a definition or redefinition with no check, the difference is that set acts locally (in the scope of the current group), whereas gset does the definition or redefinition globally.

eq is how the definition is performed and stands for “equal”.

Thus the name can be read as “locally define a function to be a copy of some already existing one.

Next comes the “signature“, in this case :NN, which means that the function \cs_set_eq:NN should be followed by two unbraced function names.

Not only it makes visual syntax checking straighforward, but it is internally used for defining variants. We can compare it with what is available with other tools, standard LaTeX and etoolbox:

\let\foo\baz
\letcs\foo{baz}
\cslet{foo}\baz
\csletcs{foo}{baz}

All four perform the same task; of course, the three commands provided by etoolbox are used when one or both names need to be constructed from arguments to other macros. With expl3 we have the c argument type to denote a control sequence whose name should be formed by the token in a braced argument (internally using, of course \csname...\endcsname):

but this is not very clear and when embedded in some larger set of macros is easy to get wrong and introduce weird bugs.

L3 version you just want a the variant assignment that takes two names as braced groups instead of two tokens so:

\cs_set_eq:cc{oldmacro}{newmacro}

these variant forms are either provided or can be easily generated for any command that ends in :NN you can specify a cc variant or a :Nx variant (where the second argument is edef-expanded first) etc.

The choice of _ rather than camel casing is less structural it's a design choice, but camel casing works less well as you can not stop camel cased commands being used mid document, but _ is set up like @ in plain tex and latex2e, as only a letter in code sections.

@CarLaTeX (a) Frank had already chosen _ before I started using this syntax in 1992. (b) it was intentionally different so humans notice it is different and (c) so you don't get accidental clashes with old code and (d) \cs_set_eq is in fact more readable as words than \cs@set@eq especially as 2e code sometimes uses @ as a word separator sometimes as a vowel replacement \css@t@q and sometimes tacked on the end \csseteq@@
– David CarlisleNov 7 '17 at 7:52

You should not compare to user code like \let\command\original but to some internals. You seem worried as if you might need to use those commands on a daily basis. That is internal code. The same way we have internal code right now that you might be afraid of too.

This is the code that makes primes work as you expect: f'(x) and f'''(x) work because of this

With expl3 it seems much more self-explanatory (although you might need to learn a bit). In fact I think this kind of code makes internals much more accessible.

PS: I haven't checked if the code is right, and it doesn't compile, as it does make use of some commands that are not defined, but the idea is to show that it actually shows a bit more of what's happening than those \pr@@@t and \pr@@@s.

@clemens I thought of it similar to \c_math_superscript_token, then \.._symbol could be another “type”. But yes, I was just showing an example, it doesn't compile, and it's far from what has to be done with unicode fonts. And I used also commands that haven't yet been decided by the LaTeX3 team.
– ManuelNov 7 '17 at 11:10

1

In that case it is a variable and some scope descriptor is missing, e.g., \l_math_prime_symbol
– clemensNov 7 '17 at 17:02