4 ms·

The packages are secondary; TeX stripped of all its accouterments already solves a really really hard problem, and is extremely fast and free to boot. The rate

The packages are secondary; TeX stripped of all its accouterments already solves a really really hard problem, and is extremely fast and free to boot. The rate of bug discovery has slowed to about one a decade so there is really no need to mess with the internals at this point. It "just works". I think TeX will be with us for a very long time yet.

Retra 12y ago
Hopefully someone will get so fed up with it that they just make a powerful replacement from scratch. (Maybe with a TeX export utility.)
- JadeNB 12y ago
  I think that, as with standards, the problem isn't no replacement but too many: see Pandoc (http://johnmacfarlane.net/pandoc http://johnmacfarlane.net/pandoc), Lout (http://savannah.nongnu.org/projects/lout http://savannah.nongnu.org/projects/lout), its (not yet existing) successor Nonpareil (http://sydney.edu.au/engineering/it/~jeff/nonpareil http://sydney.edu.au/engineering/it/~jeff/nonpareil), Skribilo (http://www.nongnu.org/skribilo http://www.nongnu.org/skribilo), and Pantoline (which I can't find with a quick Google search), for example. The problem is that TeX has so much inertia, and such an eco-system behind it, that getting significant investment in any one of them is likely to be difficult to impossible. I think compilation to TeX is probably always going to be less successful than compilation from TeX—that is, taking the same code and (slightly) improving the processing. See the pdfTeX (http://www.tug.org/applications/pdftex http://www.tug.org/applications/pdftex) and LuaTeX (http://www.luatex.org http://www.luatex.org) projects. As a remedy to too much ambition even when trying to build directly on TeX, see the fate of LaTeX3 (http://tex.stackexchange.com/questions/953/why-is-latex3-taking-so-long-to-come-out http://tex.stackexchange.com/questions/953/why-is-latex3-tak...).
- TTPrograms 12y ago
  Alternately, you could rely exclusively on a TeX export utility and make a clean, less verbose language that compiles to TeX. Then existing packages could be either wrapped similarly or inserted as TeX blocks.
  - ivan_ah 12y ago
    on that note, check out the combo https://github.com/softcover/softcover/ https://github.com/softcover/softcover/ + https://github.com/softcover/polytexnic/ https://github.com/softcover/polytexnic/ which is a very good first start on that approach: markdown --> .tex ____ pdflatex --> .pdf \ \___ tralics --> ruby_scripts --> .epub
  - _delirium 12y ago
    I think one reason most people wanting a next-gen-TeX project don't aim to compile to TeX is that some of the biggest pain points of TeX are baked into the core. So if you want to improve them, you need to change or replace at least some of the core layout algorithms, not just the front-end input language. For example a big wishlist item for many years has been some kind of improvement on TeX's quite frustrating figure placement, possibly with a more pluggable layout algorithm.

Retra 12y ago

Hopefully someone will get so fed up with it that they just make a powerful replacement from scratch. (Maybe with a TeX export utility.)

JadeNB 12y ago
I think that, as with standards, the problem isn't no replacement but too many: see Pandoc (http://johnmacfarlane.net/pandoc http://johnmacfarlane.net/pandoc), Lout (http://savannah.nongnu.org/projects/lout http://savannah.nongnu.org/projects/lout), its (not yet existing) successor Nonpareil (http://sydney.edu.au/engineering/it/~jeff/nonpareil http://sydney.edu.au/engineering/it/~jeff/nonpareil), Skribilo (http://www.nongnu.org/skribilo http://www.nongnu.org/skribilo), and Pantoline (which I can't find with a quick Google search), for example. The problem is that TeX has so much inertia, and such an eco-system behind it, that getting significant investment in any one of them is likely to be difficult to impossible. I think compilation to TeX is probably always going to be less successful than compilation from TeX—that is, taking the same code and (slightly) improving the processing. See the pdfTeX (http://www.tug.org/applications/pdftex http://www.tug.org/applications/pdftex) and LuaTeX (http://www.luatex.org http://www.luatex.org) projects. As a remedy to too much ambition even when trying to build directly on TeX, see the fate of LaTeX3 (http://tex.stackexchange.com/questions/953/why-is-latex3-taking-so-long-to-come-out http://tex.stackexchange.com/questions/953/why-is-latex3-tak...).
TTPrograms 12y ago
Alternately, you could rely exclusively on a TeX export utility and make a clean, less verbose language that compiles to TeX. Then existing packages could be either wrapped similarly or inserted as TeX blocks.
- ivan_ah 12y ago
  on that note, check out the combo https://github.com/softcover/softcover/ https://github.com/softcover/softcover/ + https://github.com/softcover/polytexnic/ https://github.com/softcover/polytexnic/ which is a very good first start on that approach: markdown --> .tex ____ pdflatex --> .pdf \ \___ tralics --> ruby_scripts --> .epub
- _delirium 12y ago
  I think one reason most people wanting a next-gen-TeX project don't aim to compile to TeX is that some of the biggest pain points of TeX are baked into the core. So if you want to improve them, you need to change or replace at least some of the core layout algorithms, not just the front-end input language. For example a big wishlist item for many years has been some kind of improvement on TeX's quite frustrating figure placement, possibly with a more pluggable layout algorithm.