[pdw]

I never got deep into TeX, but I browsed the code at one time and some of what I found seemed utterly insane to me. For example, it includes an IEEE floating point implementation, based entirely on TeX string expansion [1]. I don't know if it is widely used, but I'm not surprised by slow LaTeX compiles anymore.

You say "TeX is already heavily optimized", but that's only true for the layout engine. The input language is entirely based on macros and string expansion. That's fine if you're only going to use it for a bit of text substitution. But as a programming language it's inherently slow. (To be fair, I believe Knuth expected that large extensions, such as LaTeX, would be implemented in WEB.)

[1] https://github.com/latex3/latex3/blob/main/l3kernel/l3fp-bas...

[svat]

That's precisely my point: the slowness comes not from TeX but from the LaTeX macro packages that the user has included on top. And if you want to make things faster for the user, you don't have to replace TeX (which is already plenty fast); you have to replace the macro packages or provide faster alternatives.

If you're going to create a new system with a new way of doing things (i.e. not using the existing popular LaTeX macro packages), then you can already do that on top of TeX, by just not using those packages! (Use LuaTeX and program in Lua instead of via TeX macros, or do the programming outside and generate the TeX input, or whatever.)

What I'm proposing is that the hard/worthwhile problem is to take real users' real LaTeX documents and give them ways of profiling (what inefficiently written macro packages are making this so slow, because surely it's not the typesetting) and replacing the slow parts.