agree, I'm fine with Typst throwing out the old ways and doing the new ones... just, do your research; do it right

The problem is what is “right” in the minds of people using the old thing is sometimes very biased.

I was not implying they should make the same design choices, but there should be a deeper understanding of the underlying problems.

Case in point: backslashes and braces in TeX were there for a reason. You can say they make TeX code look ugly, and you would not be wrong. But when you throw them away without addressing the reason they were introduced, well, you end up with blog posts like this one.

The backslashes are not really relevant to the problem discussed in the post. The ambiguity between symbols and argument-taking macros exists just the same in LaTeX. Consider:

    $ f_\abs{x} $
    $ f_\pi{x} $

LaTeX just happens to do what the post calls "runtime parsing" because LaTeX doesn't really distinguish between different compiler stages at all. If you look at a macro, you can't know whether it will eat up the following braced argument.

In fact, not using backslashes for symbols can actually give an _edge_ with this problem because it would allow distinguishing `pi` and `#abs` (option E in the post).

What are some examples of the Julia design issues you mention?

For me one is that one can write `for i = 1:3` is one when `=` means assignment otherwise (at least `for i in 1:3` is available.

This seems like a counter-example. The `=` was for time the only syntax (presumably taken by MATLAB--which in turn adapted it from IDL/Fortran--that initially Julia was heavily influenced from) with `in` (and `∈`) added afterwards (`in` being the only syntax used by the much more popular {Python, R}). Imo `=` alone was fine since as you say `=` means assignment, just within `for` it's an assignment applied iteratively. Opposite to that, `in` is also used as membership operator (`1 in [1, 2, 3]`) that is entirely different from its `for` role.