5 ms·
I see this claim a lot, but it's simply not true. TeX is a relic of another age, frozen in time. a) TeX isn't stable, it's dead. It can't generate PDF, or Post
by jahewson 12y ago
I see this claim a lot, but it's simply not true. TeX is a relic of another age, frozen in time.
a) TeX isn't stable, it's dead. It can't generate PDF, or PostScript, or HTML. It can't handle Unicode, it can't use OpenType, TrueType, or even Type 1 fonts. Without the need to conform to external standards, it's easy to declare a defect to be a feature. Everything which makes TeX usable in the modern world is a third party program, there's an entire "life support" ecosystem written by others, with stability issues, and bugs, and worts in abundance. TeX is by definition "stable" because it's maintainer does not wish to develop it further - and that's not good for TeX, which has now fragmented in to various competing successors.
b) Much of the TeX ecosystem is buggy, CTAN packages frequently conflict with each other, in ways which are very challenging to resolve. The minimal and low-level nature of TeX's macro language is the root cause of such bugs, because it's hard to write macros correctly, and even harder to debug them. By keeping the core of TeX unchanged and minimal, the responsibility for dealing with complexity is forced onto macro package authors.
c) As for the claim that it is fast, that is questionable. TeX is needlessly slow at resolving cross-references, requiring documents to be re-typeset up to three times in a row. It also spends a lot of time doing I/O on its many macro files - the end result is waiting 10sec or more to typeset a file which should have taken under half a second.
d) TeX is written in Knuth's own private language, WEB, which makes it very hard to read. WEB uses a complex system of macros which is highly unconventional by modern standards. The code is highly non-linear, with macros jumping all over the place. Everything is a global variable. No amount of explaining or literate programming can make this mess "readable". It requires the utmost effort and study to extract meaning from - as the OP explains so well.
If you want to praise any open source project of the past 30 years, I'd suggest looking at the Linux kernel. It's alive and well, for a start.
- taeric 12y agoIf we are just allowed to say things are true by adding the adjective simply, then I will counter with it is simply true. :) To the points, though. a) I actually mostly agree with this concern, with the caveat that I have fewer problems producing pdfs of documents from TeX than I do any other tool I have ever had the joy of using for the same purpose. I will also note that even just treating TeX as a "core" for LaTeX, it is still a good example of stability. Specifically in the, "I can still typeset any LaTeX document I have." This is far from true for opening pretty much any other file I have. Period. Hell, even just compiling old c programs is less guaranteed. b) Applications have bugs. Pretty much period. While the overall ecosystem has unforeseen bugs, especially when you mix and match different contributions, I still know of pretty much no examples of a core as large as TeX that is essentially bug free. Care to provide any examples? And, to my point, I would wager there are more bugs in this clojure rewrite than there are in the original. c) This is pretty much only claimed because of the failure of the clojure version to achieve similar speeds. I mean, if we are fine with setting contrived expectations ("should have taken under half a second"), then I don't understand why I have to wait at all for a fully typeset product to emerge. In the meantime, I have yet to see a product that competes in speed. Tons of claims for those that should be able to, but few actual examples. d) Is it a language you are familiar with? Obviously not. Does it require effort and study to extract meaning? I'd actually agree that it does. I fail to see how that is a detriment, though. I have yet to see any solution to any non-trivial problem that does not require the same. Specifically to the complaint of non-linearity of the code. Code is pretty heavily understood in a non-linear fashion. Same for many other topics, actually. One of the things I actually admire about WEB is that it is non-linear and allows the author to introduce a narrative into the process. Seriously, this is hugely beneficial once it is understood.
- jahewson 12y agoa) I don't see how a piece of software which has essentially not changed for twenty years is a "good example of stability". Stability in the face of what? Real software occupies a constantly changing world and TeX is sheltered from that by the surrounding third-party tools. TeX's stability would only be impressive of it were changing or growing while still retaining it's original functionality. Anybody can refuse to update a program and declare it to be stable - there's no lesson for me as an engineer, beyond just refusing to write code. b) I don't understand this claim that TeX is bug free - there have been 947 documented bugs in TeX, with 427 of them occurring after TeX82. There was at least at least one bug in TeX found every year until 1995 and over a dozen have been found since then - in a code base which hasn't changed. The number of bugs in TeX as a percentage of the number of lines doesn't seem to be unusually low, and given that very little development has been done in the past 26 years, there has been very little chance of introducing new bugs. Once again, I'm not sure what I'm supposed to be learning from TeX as an engineer other than refusing to write code. c) I'm not talking about clojure, I'm talking about TeX. I agree that there are few examples of fast, high quality typesetting software. But TeX is still slow - it does so much file I/O because it assumes a tiny amount of RAM. A modern rewrite could be 10 times faster, I reckon. d) By definition it's a language that almost nobody is familiar with - and that's a problem. After some careful study, I am now familiar with it, but it's still very hard to read a program which is structured to be read as a book. Once cannot skim read the code or get a good understanding of its fundamental structure as a program. Instead one is always trapped in Knuth's narrative. I don't want to read a book - I want to read a program, and web makes that practically impossible. The end result is neither a program nor a book, and is unwieldy to programmer and reader alike - indeed, literate programming never caught on. The software I really admire is software which has reacted to change, modernised, improved. Even Microsoft Windows is a great example of stability in the long run. TeX isn't, because it hasn't done any of those things. It still compiles - and its very good a typesetting - but as an exercise in writing code, it offers few relevant lessons to the modern programmer.
- taeric 12y agoStability in the sense that, if you wrote something against TeX and find bugs, the bugs are yours, not TeX's. There are plenty of programs which "have not changed" but retain bugs. I did not say that the life of TeX was bug free. Just that its current status is essentially bug free. Now, I do grant that a large class of bugs, namely regressions, are renderred impossible by the development style. But, I personally think there may be lessons in that. For your speed claim, you need more than "it doesn't work how I think it should." Numbers, or you are just pipe dreaming. Clojure is relevant here, because it is a recent attempt to modernize TeX. It is slower, by the author's admission. Any examples that aren't slow? I mean, yes, I understand your point about I/O being somewhat of a red flag for speedups. I'm curious why it has never panned out that this low hanging fruit has dropped. For d), I just have to disagree. As someone that doesn't even know Pascal, I found it approachable. Are there parts that are tough? Sure, it is a full product. Try reading parts of git's source. (Granted, the parts that get heavy math in reasoning about are particularly tough, but I consider that my failing.)