add tag
I am a very novice user of LaTeX compared to the experienced members present on this site. I have often seen some fuming conversations on the new LaTeX3 updates in [this]( chat room. After reading those chats I always feel that common users (like me) really know nothing about what's really happening in the community. Fortunately we have members from the L3 team as well as some critiques of the new changes. It would be good if these two sides articulate what's going on behind the scenes and pros and cons of it. Also should a common user really worry about these changes or not? It would be great if l3 experts show small examples of what actually can be done with expl3 which was not possible earlier.
Top Answer
I didn't want to write an answer but this appears to be too long for a comment (can't see the bottom of it anymore...).

I fully agree with [Skillmon]( here. My advice to the OP, if you have enough time:

1. Read the TeXbook and program some things in TeX. At this point, you should understand the difficulties this entails (basic data structures, parsing of “text,” flow control, floating point computations that exceed 16383.99999...). In many cases, the life saver is an e-TeX or pdfTeX primitive, if not LuaTeX entirely—all of which aren't part of Knuth's TeX, thus outside the scope of the TeXbook.

2. Look at how LaTeX2e makes this easier: not much. Some *packages* can help a little bit (`etoolbox`, `xifthen`, `intcalc` and a few other packages from Heiko Oberdiek; the PGF bundle...). Apart from PGF, it's all scattered. Even PGF is scattered in some places (think about usage of the `fpu` in `pgfmath`, when trying to do smart things with `pgfplots`: it's always doable but can be tricky).

3. Read [expl3.pdf](, skim through [l3styleguide.pdf](, except section 2, which is for people using `l3doc` for literate TeX programming; and finally, read the parts of [interface3.pdf]( that you need for a given task. There you'll see many high-level functions easy to use and *cooperating* with each other, some unified programming environment. For instance, when `\regex_extract_once:nnNTF` extracts match groups for a regular expression, it uses a `seq` variable to store the matched tokens and the groups. `seq` variables are standard `expl3` sequences, so if you had already learnt to work with them, it's very easy to use the result of `\regex_extract_once:nnNTF` (you have `\seq_get_left:NN` to retrieve the first element and store it in a macro aka `tl` var, `\seq_pop_left:NN` to do the same and remove the element, `\seq_item:Nn` to expandably get the *n*th item in the input stream, where *n* is an arbitrary *integer expression* as described in the `l3int` chapter of the same [interface3.pdf](, e.g., `5 +
 4 * \l_my_int - ( 3 + 4 * 5 )` with standard priority rules, etc.). It's all like that, unity. 

4. Don't fear wasting time learning TeX programming before `expl3`: TeX is such a strange beast, that knowing its essential rules is probably a must in order to make sense of the `expl3` docs. (I think it helps a lot to understand the difference between expansion and execution(*), the effect of grouping, the difference between local and global assignments, to realize that `x` expansion is what `\edef` does, `e` expansion is what `\expanded` does, `\exp_not:n` is `\unexpanded`, `f` expansion is what you would obtain after `\romannumeral0`, `o` expansion is what you would do with an `\expandafter`, that TeX always expands tokens recursively when processing a `\csname`, reading a ⟨number⟩, a ⟨dimen⟩ or a ⟨glue⟩, etc).

The problem with the TeXbook for this kind of learning is that its goal is not to teach TeX programming, rather typesetting using TeX for trained professionals. It does teach a lot that is useful for programming, but in order to really understand the points made by the author, you may need to read some things very carefully, twice or more, and sometimes use a search engine or experiment by yourself to understand things better.

I'm definitely not an `expl3` expert, but an example of some task that `expl3` makes easy to perform efficiently could be: “[How to count *n* things?](”. My solution there uses very natural `expl3` tools to:

  - incrementally build a mapping from each of the obtained values to the number of times it was obtained (I use a “property list,” aka `l3prop`);
  - create a sequence of “ordered pairs” of the form `{n}{count}` from it, and very simply sort it using the first component of each ordered pair as a sorting criterion (one could as easily sort it according to the second component, since `\seq_sort:Nn`'s second argument tells how two elements compare to each other, and `\seq_sort:Nn` doesn't assume anything about the elements of the sequence);
  - iterate over the sorted sequence to build a `tl` var—a simple macro—that contains the interesting data (frequencies obtained by dividing each *count* by the number of samples), properly formatted for direct use inside the table we wanted to produce.
Another thing that is highly non-trivial to do without `expl3`, IMHO: what the `l3regex` module can do: it is much more than a “simple” regular expression engine, which pdfTeX's `\pdfmatch` primitive provides (and would already be quite difficult to implement with Knuth's TeX). `l3regex` has been designed to handle the particular nature of TeX's input: not a stream of characters, but a stream of tokens, namely:

  - explicit character tokens with a character and a category code attached;
  - control sequence tokens.
`l3regex` regular expressions allow one to match against precise tokens, not just character codes. That is why the syntax is a bit more complicated than for traditional regexps, which many people already find difficult. But if you understand the nature of TeX's input stream after the tokenization stage, are used to regular expressions in other languages (Perl, Python, sed, Bash, C++...) and read the `l3regex` documentation which has many examples, it should all make sense!

For instance, regexps make it trivial to parse a date in (YY)YY-MM-DD HH:MM:SS format. As an example of the power of regexps, let's make this more complicated and define a single regular expression that can validate, in a single call:

  - a date in (YY)YY-MM-DD format (“ISO” style, except I believe actual ISO 8601 mandates four-digit years);
  - a date in MM/DD/(YY)YY format (“US” style);
  - a date in either of these formats followed by at least one space, then by a time in HH:MM(:SS) format.
Of course, parenthesized things are optional in this informal description. I won't verify that hours are < 24, minutes < 60, etc. to avoid making the thing too long (it is already a bit...). All the rest is verified. With the `l3regex` functions, one could very easily go further and for instance count all occurrences of such a “datetime” in a given token list regardless of the grouping level it appears in, replace all such occurrences, etc.

% When these are uncommented and compilation is done with pdflatex, ':' is an
% active character in the whole 'document' environment.
% \usepackage[T1]{fontenc}
% \usepackage[french]{babel}
\usepackage{xparse}             % not necessary with LaTeX 2020-10-10 or later


% Compile the regexp (optional; speeds things up if it is used many times).
\regex_const:Nn \c_my_datetime_regex
    \A                          % anchor match at the start of the “string”
    ( (\d{2} | \d{4}) (\-) (\d\d) \- (\d\d) |
%   1 2               3    4         5       <--- captured group numbers
      (\d\d)           \/  (\d\d) \/ (\d{2} | \d{4})
%     6                    7         8
    % optionally followed by: one or more spaces plus time in HH:MM(:SS) format
    % The ':' separators can have category Other (12) or Active (13).
    (?: \ + ( (\d\d) \c[OA]\: (\d\d) (?: \c[OA]\: (\d\d) )? ) )?
%           9 10              11                  12
    \Z                          % we must be at the end of the “string”

\seq_new:N \l__my_result_seq

% Return match group number #1 (an integer expression) from \l__my_result_seq
\cs_new:Npn \__my_group:n #1 { \seq_item:Nn \l__my_result_seq { 1 + (#1) } }

% Generate conditional variants \tl_if_empty:eF and \tl_if_empty:eTF
\prg_generate_conditional_variant:Nnn \tl_if_empty:n { e } { F, TF }

% Is the date in US or in ISO 8601 style?
\prg_new_conditional:Npnn \my_if_US_style: { T, F, TF }
    \tl_if_empty:eTF { \__my_group:n { 3 } }
      { \prg_return_true: }
      { \prg_return_false: }

% Define \__my_get_year:, \__my_get_month: and \__my_get_day:.
% The year is captured group number 8 in US style, number 2 in ISO, style, etc.
\clist_map_inline:nn { { year, 8, 2 }, { month, 6, 4 }, { day, 7, 5 } }
    \cs_new:cpn { __my_get_ \clist_item:nn {#1} { 1 } : }
          { \__my_group:n { \clist_item:nn {#1} { 2 } } }
          { \__my_group:n { \clist_item:nn {#1} { 3 } } }

% Define \__my_get_{time, hour, minute, second}:.
% Yes, one could simply use what precedes, but what follows will be faster upon
% use, since there is no condition to evaluate.
  { { time, 9 }, { hour, 10 }, { minute, 11 }, { second, 12 } }
    \cs_new:cpn { __my_get_ \clist_item:nn {#1} { 1 } : }
        \__my_group:n { \clist_item:nn {#1} { 2 } }

\cs_new_protected:Npn \__my_print_verbatim_date:n #1
    % \tl_to_str:n neutralizes catcodes (':' could be active in French...)
    \texttt { \tl_to_str:n {#1} }

\cs_generate_variant:Nn \tl_count:n { f } % generate variant \tl_count:f

\cs_new_protected:Npn \my_describe_datetime:n #1
   \regex_extract_once:NnNTF \c_my_datetime_regex {#1} \l__my_result_seq
       Valid~date:~\__my_print_verbatim_date:n {#1} \\
       \int_case:nnF { \tl_count:f { \__my_get_year: } }
           { 2 } { two }
           { 4 } { four }
         { this~place~is~unreachable }
       \c_space_token digits.       \c_space_token
       Year:~  \__my_get_year:  ,   \c_space_token
       month:~ \__my_get_month: ,   \c_space_token
       day:~   \__my_get_day:   ,   \c_space_token

       \tl_if_empty:eTF { \__my_get_time: }
         { time~wasn't~specified. }
           hour:~  \__my_get_hour:, \c_space_token
           \tl_if_empty:eF { \__my_get_second: }
             { ,~ second:~ \__my_get_second: }
           .                        % final period. :-)
     { Invalid~date:~\__my_print_verbatim_date:n {#1} }

% Document-level command
\NewDocumentCommand \myDescribeDateTime { m }
  { \my_describe_datetime:n {#1} }



\myDescribeDateTime{2020-10-15 16:33:12}
\myDescribeDateTime{2020-10-15 16:33}
\myDescribeDateTime{10/15/2020 16:33:12}
\myDescribeDateTime{10/15/2020 16:33}
\myDescribeDateTime{10/15/20 16:33}
\myDescribeDateTime{20-10-15 16:33}      % not ISO 8601

{ % Make ':' active as with \usepackage[french]{babel} under pdfTeX.
  \catcode`\:=13 \def:{yes!} `\texttt{\string:}' is now active, understood? :
  \myDescribeDateTime{2020-10-15 22:30:42}

\myDescribeDateTime{2020/15-10 16:33:12} % incorrect
\myDescribeDateTime{covfefe}             % also incorrect


(*) Unfortunately, Knuth prefers to talk about “mouth” and “stomach” instead of expansion and execution in the TeXbook, but this is exactly the same. This just illustrates the fact that, IMHO, these things were not the main objectives of the book for him.
Answer #2
There is already a post highlighting the strengths of `expl3`, which will eventually become `l3` without `exp`, which originally stood for experimental. I never said that this scheme is useless or bad because I do not think this is the case. However, I am critical of many developments. Here are a few examples:
1. To me the notion "experimental" seemed to suggest that this is a trial. At the end of the trial there should be a decision whether or not this is the way to go. IMHO this decision should be a democratic decision by the user base. However, we will have to live with `l3` without any poll. (Just to prevent statements saying that this is impossible: I am also an arXiv user, and the arXiv does such polls.)
2. It already has been mentioned that there is nothing in `expl3` that cannot be done within (La)TeX "only". This is a true statement because it is just a layer on top. The more relevant question should be whether or not there are things in TeX that cannot be done with `expl3` only. I do not know the answer, but presumably you can always import every TeX primitive you want and make things work, somehow.
3. It is hard to ignore the fact that `expl3` treats spaces in a peculiar way. This means, in particular, that you cannot blend in pgf keys easily, which can contain spaces. (To those who want to make comments: I know that you can use `~` unless they are used otherwise already, and I know what the so-called spurious spaces are. I find it just hard to believe that it is possible to write packages like `unravel` and at the same time it is hard to develop tools that allow one to spot these spaces more easily.)
4. The naming conventions have been mentioned already. One should not forget that these are rules that the users are supposed to follow. Imposed also by some of those who implemented somewhat random patterns regarding the usage `@`. Please note that I, too, want to know, say, if a macro is global or local. However, I'd think that if you make these drastic changes to the kernel then you surely will be able to write a macro or switch that keeps track of that.
5. I condemn, in the strongest terms, this excerpt from `interface3.pdf`
![Screen Shot 2020-10-15 at 12.41.19 PM.png](/image?hash=a88d780dcae1126031ca85c60796c0a9bfe480977225526100a0d72c5690a6a1)
I do not think that we should have two circles of users. This is, in a way, the underlying reason for my criticism: I do not think that establishing a caste system among the LaTeX users is acceptable. (Please do not bombard me with examples in which something goes wrong. You can completely screw up your document regardless of whether you use one of the prohibited items.)
6. The documentation is suboptimal to say it politely. Various members of the LaTeX3 team have actually signalled to me that they agree with this statement, at least to some extent. I also know that writing a good documentation is real and hard work, and is nontrivial. And I hold those who wrote good manuals in my highest regards. If you think of it, `beamer` and `Ti*k*Z/pgf` are arguably among the most widely used packages, and really have excellent manuals, which is probably not just coincidence. However, saying that the manual is a lot of work is IMHO no good excuse for not providing one if you change the kernel that **every user has to load**. I know that I will receive the usual comments from some experts who tell me that they are OK with the manuals. This is not about them, nor me, but about general users who are wondering "What's going on in LaTeX?". I think that we should not exclude them from actively participating by not providing accessible manuals that also serves newcomers.
7. I could very well be that I am just expecting too much. However, I was fortunate enough to have known Peter Breitenlohner personally. I cannot ignore the drastic change of personalities among those who spend time and efforts to keep (La)TeX alive and improve it for beings like me. I just wish more of these very competent and humble people were around, an in charge. Peter did not tell random people that he is a great physicist (but he was a brilliant physicist, with even some important bound being named after him). Nowadays LaTeX3 has a member who ... let's not go there.

This list is, by far, not exhaustive. This is also not a real answer to the question. However, I wrote this post just so that there is an alternative to the IMHO overly rosy picture that gets painted elsewhere. I am writing it merely to say that there are also some who are critical and not convinced that what is currently been done will help LaTeX to keep its large user base. 

Enter question or answer id or url (and optionally further answer ids/urls from the same question) from

Separate each id/url with a space. No need to list your own answers; they will be imported automatically.