Does TeX/LaTeX give a headstart with other programming languages?

Question

I've seen many programmers here at tex.se, and I'd like to know how they view TeX/LaTeX as a programming language in relation to other languages, and whether it would boost my progress as a beginner using other (non-typesetting related) languages, that is of course in an abstract or semantic sense.

Answer 1

My not-oft-enough-expressed opinion is that TeX is a terrible programming language and that anyone learning to program is well advised to avoid learning anything from it. In fact, it is much more helpful to have experience programming in order to write TeX than the opposite. Various points major and minor come to mind:

• When writing TeX, one has to pay entirely too much attention to the exact characters in the code, up to and including newlines (!) and individual spaces (!!), which both affect its behavior subtly. This means that lots of effort goes into doing something which isn't even algorithmic.

• Speaking of the input format, because of catcodes, it is entirely fluid. The example in this answer is extremely interesting, in sort of the same way that an okapi is interesting. So even if you think you know TeX's syntax, you (probably) only know the syntax of the plain TeX format. Or of LaTeX. Or of ConTeXt.

• TeX is a macro language. That means that by design, its code is self-modifying, which is up there with the goto statement in terms of damage to program structure for the reasons given by Dijkstra in that article.

• However! TeX is not a macro language, because its directives ultimately expand to typesetting primitives. This fact is prominently advertised in the TeXbook in describing TeX's modes of operation as the "eyes", the "mouth", and the "stomach"; it's the mouth that's the macro language. The aforementioned issues with input format are the "eyes"; the typesetting part is the "stomach". Except, of course, when it is not just the typesetting, for example the execution of \def directives.

• If you read this site, you'll occasionally hear people talking about "fully expandable"; by this they mean code that is processed only in the mouth (as macros). It is not really known why this distinction exists, but as with many aspects of TeX, it may just be an artifact of its age. This is not a good advertisement for learning a programming language, all other things being equal.

• TeX doesn't actually have programming constructs like variables or loops or conditionals. It does have registers and the \loop...\repeat construct (which works by a clever manipulation of self-modifying code) and it does have a fixed number of builtin \if's, but in general you will find yourself writing an ad-hoc, informally specified, and bug-ridden implementation of half of Common Lisp (or, since I don't actually know Lisp, perhaps I should say "of half of C"). Don't think you'll learn anything this way, other than bad habits. Unless you already know the structures you're trying to invent you will end up with spaghetti code.

• The constructs that do exist are mostly not expandable, despite the fact that the part of TeX that constitutes a programming language is by definition the purely expandable part. The fact that some of them are expandable leads to very obscure tactics, such as the one described in this question and its answers. It is probably not reasonable to ask programmers to worry about the code branches of an if statement actually interfering with the branching code itself.

• TeX has no concept of functions, which is one of the few things that imperative and functional languages agree on. Its macros do absorb "arguments", but because of the tricky expansion issues inherent in the macro language, those arguments are not always what is written in the code. And even if they are what's written, because of the tricky argument-grabbing issues they are still not always what (you think) is written.

• Strangely, despite the crucial importance of things such as braces to the functioning of TeX, and despite the fact that it is a Turing-complete language, and further despite the fact that the exact format of its input is crucial to its functioning, there is no native way to easily do something like determine (expandably, of course) if the next character is a brace! See Bruno Le Floch's comment to this answer. This is actually a good lesson on the difference between "Turing-complete" and "can do anything", so in that sense, is a valuable part of one's programming education.

• It has no debugging facilities to speak of. It does provide the ability to trace code, but this can't be controlled finely and doesn't always reveal crucial facts like "What values do all those variables have right now?". Assuming you can tell what the variables are, that is, since they are probably macros just like the "functions".

Essentially, programming in TeX is an endless parade of frustration over minutiae concerning code format, multiple rounds of parsing and subsequent (possibly partial) execution, and poorly defined program state. Although it's true that "only perl can parse Perl", at least this is true of Perl because of the overwhelming plethora of programming styles and facilities it makes available (including, yes, the ability to modify its own syntax). In TeX you can have a hard time getting it to do addition.

Answer 2

This is more of a long comment rather than an answer.

TeX is an excellent source of learning programming. It tells you how not to write code! One of the basic tenets of programming is that you should write code that is easy to read by others. I find that a lot of TeX code, especially TeX macro code written during the early days of TeX, is impossible to read. Part of the reason is the idiosyncrasies of TeX, the macro language. But a bigger reason is the horrible macro naming convention used by macro authors, especially using @ in the middle of variable names.

As an example, consider the macro \overset and \underset that are part of the amsmath package. They are defined as

 \newcommand{\overset}[2]{\binrel@{#2}%
  \binrel@@{\mathop{\kern\z@#2}\limits^{#1}}}
\newcommand{\underset}[2]{\binrel@{#2}%
  \binrel@@{\mathop{\kern\z@#2}\limits_{#1}}}

where the helper macros \binrel@ and \binreal@@ are defined in amsbsy.sty:

\def\binrel@#1{\begingroup
  \setboxz@h{\thinmuskip0mu
    \medmuskip\m@ne mu\thickmuskip\@ne mu
    \setbox\tw@\hbox{$#1\m@th$}\kern-\wd\tw@
    ${}#1{}\m@th$}%
  \edef\@tempa{\endgroup\let\noexpand\binrel@@
    \ifdim\wdz@<\z@ \mathbin
    \else\ifdim\wdz@>\z@ \mathrel
    \else \relax\fi\fi}%
  \@tempa
}
\let\binrel@@\relax

The above code would have been much easier to read, if the two macros were named \checkmathbinrel and \usemathbinrel (or something similar). Then, one could read the code to understand the intent of the macros.

Note: I do not mean to criticize the authors who wrote the code. I understand that the code was written at a time when computational efficiency was more important than readability.

Modern TeX code, whether written in LaTeX3 style or in ConTeXt style is much easier to read. For example, this is how the same macros are defined in ConTeXt:

\def\math_binrel_apply#1%
  {\begingroup
   \setbox\scratchbox\hbox
     {\thinmuskip   0mu
      \medmuskip   -1mu
      \thickmuskip -1mu
      \setbox\scratchbox\hbox{$#1\mathsurround\zeropoint$}%
      \kern-\wd\scratchbox
      ${}#1{}\mathsurround\zeropoint$}%
   \ifdim\wd\scratchbox<\zeropoint
     \endgroup
     \expandafter\mathbin
   \else\ifdim\wd\scratchbox>\zeropoint
     \endgroup
     \expandafter\expandafter\expandafter\mathrel
   \else
     \endgroup
     \expandafter\expandafter\expandafter\firstofoneargument
   \fi\fi}

\unexpanded\def\overset#1#2%
  {\math_binrel_apply{#2}{\mathop{\kern\zeropoint#2}\limits\normalsuperscript{#1}}}

\unexpanded\def\underset#1#2%
  {\math_binrel_apply{#2}{\mathop{\kern\zeropoint#2}\limits\normalsubscript  {#1}}}

Notice that proper indenting and expressive variable names make the code much easier¹ to understand (perhaps at the cost of efficiency).

So, if you read a lot of TeX code, you will come across the same macro written in different styles. You can compare the two implementations to understand how to write readable code.

---

¹: The \edef\@tempa{\endgroup ...} \@tempa trick, or the {\begingroup ... \engroup \expandafter ... \fi} trick are standard part of TeX programming.)

Answer 3

(This is another long comment along the lines of Aditya's answer.)

Yes, it can help you understand other languages (in a theoretical sense).

And for all the reasons that Ryan gives.

In mathematics, we're always on the look-out for the counterexample, the outlier, the slightly-odd-thing-that-still-satisfies-the-definition. Indeed, we have whole books whose titles are "Counterexamples in X" which are among the "must have" books on people's shelves. We believe that to truly understand a concept, you have to take it to its extreme and examine what happens there - it's not enough to understand the safe, cosy examples that motivated the concept. So we learn about the empty set, discrete metric spaces, non-Hausdorff manifolds, non-separable Banach spaces, the field-with-one-element (aka F_un), and many, many similar things. We do so not because we seriously want to study them, but because if we really want to understand what the statement "S^3 is a smooth manifold" means, we also need to know about the weird examples.

If all you ever want to do is learn one programming language and never be curious as to why it works the way it does, then don't bother looking at TeX. Regard it as Magic and forget about it. But if you truly want to understand what programming is about, and learn what it can really do, then you really should look at TeX because there is nothing quite like it.

Where I'd start is by looking at TeX from the point of view of its purpose (I'm extrapolating back here, I've no real knowledge about its beginnings). It is a programming language embedded into a document typesetting language, and the latter is the dominant part. So the programming language has to hide itself most of the time, which is one reason why spaces and new lines are more significant than in other languages: they are significant in the document typesetting part.

The other main unique feature of TeX is that most of its users are not programmers, and would never wish to be. So, again, its design takes that into account. A writer would expect \emph{hello} to "do what it says on the tin", and \alpha to mean "I want an alpha character right here", so expansion - rather than function calls - is closer to what the average user expects.

(But I'm no expert, and definitely not a programmer. So maybe my view is tainted by my programmatic development.)

Answer 4

In 2004 Victor Eijkhout taught a course of Computer Science based on TeX as a programming language. This year he published the course notes (see http://www.lulu.com/product/paperback/the-computer-science-of-tex-and-latex/18798879). I recently bought this book and I am going to write a review for TUGboat. My initial impression from this book is that TeX as a language indeed gives you a valuable insight in many aspects of CompSci and programming.

Answer 5

This is an interesting question.

I agree with Peter's comment - LaTeX is not a good medium for learning about programming in general, but proficiency in other languages will help you understand LaTeX better. A good language for self-study and experimentation is Python.

The bad news is that working with a concise, flexible, powerful language such as Python will make you realize how incredibly verbose, arcane and crippling programming in TeX and LaTeX actually is. It has been said about Perl that it 'makes simple things simple and hard things possible'. About TeX, it would be fair to say that it makes simple things hard, and hard things virtually impossible.

The good news is that there now is LuaTeX, which allows you to implement all the heavy-lifting inside your own macros in Lua, which is similar to Python in spirit and also in syntax. LuaTeX means that, if you decide to study Lua, you will be rewarded with very real and immediate benefits for your work in TeX and LaTeX.

Answer 6

The answers so far have been fairly negative, but let me try to offer a little bit of positive spin on this. I have, in the past, tried to teach a variety of people a little bit of HTML. If they already used LaTeX, then they were already familiar with the idea of a markup language. This made things much easier. Then you can just say "Look, <i>…</i> just works like \textit{…} does. (I say LaTeX specifically, because that's what people I've talked to use. I don't know if plain TeX or ConTeXt users are any different…)

And then you can use the idea of using titlesec or a similar package to modify the title font as a way of introducing the separation of form and content that the divide between HTML and CSS is supposed to effect. (Obviously, in both cases the separation is far from complete, but still…)

So while HTML is also a fairly specific language (arguably not a programming language at all) but a familiarity with LaTeX does help in learning it.

What doing this has taught me is that most people who use LaTeX use it very badly: \section*{\it 4. Conclusion} for example. It seems like LaTeX offers so many different ways of intervening, at different levels, to produce the same or similar output. So you don't get the corrective of seeing your "program" fail often enough that you are forced into the right kind of practices. For example, python forces you to indent properly. (I actually hate semantic whitespace, but it does at least instill a good practice when beginning).