Hacker News Reader

Comment by riobard | Hacker News Reader

(La)TeX the typesetting engine is great, but (La)TeX the language is clunky. Without proper support for namespace, it's rather difficult to abstract and write macros without worrying about side effects. I have real troubles to guess which package a command is from.

Are there any alternatives that have solved this problem?

View on HN

I think the best alternative out there, honestly, is to just write simpler papers. Having finally started digging into the some of the core works of Knuth, I must say that the source and the results both read fairly well. There are macros, but they are judiciously used.

Probably doesn't hurt to adopt his style of reuse. Which is not necessarily to "link" to a full blown library of macros for purposes, but to pick and choose some that you wish to use. Possibly even just redefining them yourself.

That's easier said than done. To make some of the mathematical equations work and be legible in several of my papers required a lot of subtle positioning; this was not helped by strict conference page limits or requirements for e.g. 2 column layout (which exposes a lot of weird issues with LaTeX's rendering, which then have to be dealt with). Knuth's original papers, lovely though they are, are much simpler. If you want an example, consider Figure 4 from http://sigwinch.org/Graham/papers/Interface%20Grammars%20for... which was really quite tricky to lay out. I don't have the source code with me right at the moment for some reason, but I recall it being very tricky to modify.

Perhaps this means we should be trying to do simpler stuff, but I'm pretty sure that's impossible in the conference driven world I found myself in.

Apologies, I did not mean to imply that "simpler papers" would be easier. Indeed, I suspect that depending on where you are wanting your paper submitted, it will not be possible. :(

My main thought is that as you bring in more and more libraries to accomplish things, you start bringing in more and more sets of assumptions about the underlying abstraction and these don't always hold. Somewhat ironically, I think of paper layout now as an optimization problem, akin to how TeX thinks of paragraph layout. That is, it will be somewhat iterative. No getting around that.

So, I sadly don't have any prescriptive advice. Just the observation that the simpler papers out there of Knuth's are quite a bit easier to read in source than many of the ones I have ever authored.

http://patoline.org/ tries to be better and it seems like the authors have a good grasp of typesetting.

I want to belive, but i have seen serveral TeX alternatives (Such as ANT [1][2] and Rhinotype[3]), but they all die very quickly.

Esp. ANT would have been a fantastic improvement.

[1] https://web.archive.org/web/20090310012257/http://ant.berlio... [2] http://sourceforge.net/projects/ant.berlios/ [3] https://news.ycombinator.com/item?id=6668551

Patoline is a great project, that I have mentioned a few times in comments.

To start gaining traction though, it should migrate from darcs to git, and move their own repo to github. It would enable people to contribute more easily, as well as bug reporting and editing the documentation.

The tarball is still there, though.

The commit graph (http://wiki.patoline.org/developers.html) shows commits every month from December 2011 to now.

> Is this project still alive?

pmeunier (https://news.ycombinator.com/user?id=pmeunier), one of the authors, discusses this a bit at https://news.ycombinator.com/item?id=8026930 (though without, I think, committing to any definitive answer).

Namespaces are the least of my worries.

TeX is not a programming language, it's two programming languages. These languages have a self modifying syntax and is parsed with state machines that can be changed. Changing the syntax into something meaningful other is yet quite impossible. It's meant not meant to be able to read markdown or xml.

These Languages are so odd even division of two variables is non-trivial, yet both are truing complete and servly limited, a classic turing tar pit, even division of two variables is nontrivial.

The hole TeX thing is a huge state machine, and uses imperative paradigms, while declaratives would have been much nicer.

All that leads to a horrible, monkey patching coding style.

On the internals there are other horrible things: Unicode was known when it was invented, font formats are a mess (even with XeTeX; I think I can't have another mapping for my the cursive style of a font then for regular. Good thing is the very verbose documentation for fontspec does mention "mapping" twice)

You fall into a simple trap: TeX is not a programming language. At all. It's a typesetting DSL. Whether it's a good one is another thing.

It's typesetting DSL, but if you want to typeset you'd need a typesetting meta-DSL. The one thing that works fine with TeX is math, because math typesetting is build in. Typesetting something more specific other than english text and math is hard and ugly.

If does follow imperative paradigms, as it does, the programming language part is essential if you want to do anything meaningful with it. If exotic task you never need in typesetting, such as multiplication, is hard to implement, something is wrong. And IMO that is why LaTeX is so odd and hackish.

Context is much better, tough.

And, by the way, the unfortunalty dead ANT uses a nice Haskell like language and is still a typesetting DSL.

http://sourceforge.net/projects/ant.berlios/ https://web.archive.org/web/20090310012257/http://ant.berlio...

If it's Turing complete, it's a programming language.

Magic: The Gathering is turing complete. SQL as well. Petri-Nets with certain extensions are. Many logic systems are.

They are hardly programming languages.

According to Knuth (quoted at http://tex.stackexchange.com/a/167443/1169):

    Knuth: So TeX is a programming language but I had to put in those features kicking and screaming.

But the quote equally shows how much it is not intended to be.

> But the quote equally shows how much it is not intended to be.

Yes, certainly, but you said (https://news.ycombinator.com/item?id=8615643):

> TeX is not a programming language.

rather than "TeX is not intended to be a programming language." It is nit-picking to be sure, but I think that, if the creator of a language (especially one who knows his stuff as Knuth does) says that it is a programming language, then it is.

Another appeal to (a lesser) authority—the TeX Users Group (https://www.tug.org/whatis.html):

    In summary, TeX is a special-purpose programming language that is the centerpiece of a typesetting system that produces publication quality mathematics (and surrounding text), available to and usable by individuals.

… and an appeal to the fact that people have written programs in it: http://stackoverflow.com/a/1931289.

(P.S. To "so, is XSLT a programming language because of, say, http://www.unidex.com/turing/utm.htm ?" I say "sure, why not?" What is the point of excluding something from being a programming language?)

Actually LaTeX was invented to be a typesetting DSL. As someone who has taught TeX and LaTeX and written my own software on top of TeX, I have come across this question very often. Basic TeX is not meant to be high level at all. LaTeX hides the complexity of 95% of the typesetting needs.

> Unicode was known when it was invented

Certainly not, not even latin-1 was existing when TeX was created.

Indeed, TeX: 1978. Unicode: 1987.

Perhaps some dyslexia lead someone to believe they were invented in the same year? :-)

I agree - clearly a lot of work has gone into typesetting algorithms, but the language and package ecosystem is a mess, and there's not a good enough separation of presentation and content. A lot of macros and commands should really go in the template rather than the document, a lot of others could be made redundant.

Personally I'm a fan of markdown->latex->pdf using pandoc, although figure/table/equation numbering is still a bit of a hack (though there's wip plugins for them, or you can cheat with some embedded latex)

Not really an alternative to classic LaTeX (scientific articles, homework and college / university work) but for database publishing (XML -> PDF):

https://github.com/speedata/publisher

manual:

http://speedata.github.io/publisher/manual/index.html

built on top of (Lua)TeX.

Some effort is going towards this in LaTeX3 (see the experimental package: http://www.ctan.org/pkg/expl3).

Really? What evidence do you have for that? This thing has been promised for decades now, since the early 1990s.

Evidence that it's trying to improve LaTeX macro programming? It's in the documentation. Evidence that it will be released any time this century? I have none of that. It looks like the last commit to the SVN was in January.

I know some of the latex3 people, and I know they are working on it. It is not a frontend code (for example such thing as \tableofcontents), but currently purely backend stuff.

A lot of latex2e packages are using latex3 in the background (for example fontspec).

There is ASCIIDOC and ASCIIDOCTOR http://asciidoctor.org/ I wrote my thesis with it. If you want to publish HTML, it's great. For PDF the current way to go it is to compile to DocBook and from DocBook to PDF. But there a ASCIIDOC to PDF renderer in the works.

Couldn't that be solved by a new language that compiles to Latex?

Well, you would probably compile to TeX, not LaTeX.

I don't want a new language, myself, because new languages are much more difficult to migrate to. Personally, I just want an implementation that knows how to produce good error messages despite LaTeX's macro implementation. By the time TeX sees the results of the LaTeX macros, it loses the context for producing meaningful diagnostics.

Reply on news.ycombinator.com