Today I wanted to talk about a common question I come across: Does LaTeX count as programming? Many people dismiss this question directly with a no. But I say the answer is not that simple and depending on how you practice LaTeX can definitely be ‘yes’ much more than you might think!
Also, something I really don’t appreciate is people meaning to degrade LaTeX when saying using LaTeX has nothing to do with programming (because it does and most people who think that way have just never seen LaTeX being used more like programming). LaTeX is, strictly speaking, a programming language and Turing-complete. Or rather, LaTeX is a macro package for TeX which is the actual Turing complete programming language. The typesetting-specific tools LaTeX provides probably can’t, however, be considered a full programming language on their own anymore. You could theoretically do anything with it, though it might just not be the easiest possible way to accomplish your ends (unless they are world dominion, of course. Like mine… 😉 ). Also consider looking at this Quora question “Is LaTeX a programming language?”. So now that we have figured that out, we can start discussing whether you can “program” using LaTeX – whatever we mean by programming anyway.
Furthermore, unless you want to start writing packages or become an advanced user, it isn’t might not be more than a markup language to you (to find out more about markup languages, see my intro to markup and annotation [to come]). You will only need to learn how to “program” with LaTeX for package writing and advanced uses, maybe for TikZ and so on.
Simple LaTeX is like markup, Advanced LaTeX is more like programming
LaTeX is basically a set of macros to facilitate using TeX. It provides macros with easy-to-understand names which function kind of like semantic markup. But the whole thing being (presentational) markup is basically an illusion created by Lamport’s macros. Behind the scenes, TeX is a procedural language.
So most users can use LaTeX like a markup language. But once you have more advanced needs, it starts morphing more and more into a programming language. (Which is a bit of a weird way to phrase it but you get what I mean. But like with data types, it’s all a question of interpretation and perspective 😉 )
LaTeX typesetting vs. web development languages
I argue LaTeX is, in fact, most definitely like a programming language (even if you don’t want to call it one) in the way that you have to continue learning when using it over a long period of time. If you want to become a basic LaTeX user, to you it’s going to feel like learning markup. But unlike most kinds of markup languages, LaTeX does get more complicated. For example, when comparing it to XML, for XML all you really need to know is that it consists of a start and end tag, content, a root element and it all needs to be structured hierarchichally like a tree. Mabye it’s a bit more complicated than that. But most certainly, nobody will argue when me when I say there isn’t much new to learn about XML after you have been using it for a year. I’ve been using LaTeX for a long time now and I’m still learning, so that tells me there must be some kind of difference here. Probably it’s the fact that there are standards for XML maybe, but even many of them combined don’t compare to the complexity of all the different LaTeX packages out there you might want to learn or use.
Tools of the Digital Humanist: LaTeX vs. XSLT?
LaTeX is maybe a bit like XSLT in the way that you can use it to “manage” and transform all these three aspects I compared it to above (structure, styling and dynamic stuff). But XSLT as a language (Turing-complete too, by the way) is even way more “narrow” than TeX in it’s scope. It just takes XML input and transforms it. This is a very limited range of possible tasks, even though it can take you quite a while to become really proficient in more advanced uses of XSLT (like some functions, super-crazy XPath stuff you really don’t need very often). However, the main difference between XSLT and TeX, in my opinion, is the fact that there are no packages in XSLT. Even though it might take some work to really master all XSLT’s functions – there aren’t that many in the end. Unlike in LaTeX, there isn’t this ever-growing amount of packages you have to keep on top of. Apart from being aware of all those packages, understanding how they work and how to use them, they actively complicate the language because they can interfere with each other. In a language where there just aren’t any packages, a bug has a way smaller amount of possible sources. Since it is possible to know all the functions and exactly what they do by heart but it is not possible to have perfect knowledge and recall of all of the growing amount of LaTeX packages, I’d say LaTeX is much more like a ‘real programming language’ or maybe more exact, a programming language readily recognized as one. With LaTeX, you really get to develop an intuition of where mistakes could invisibly come from with experience. You need to interact with the community to see if somebody might already have tracked down the mistake at some point. If you are a DH person, you probably do that with XSLT too, but still, my argument that the languages range of functions is considerably less broad, remains valid. So a good criterion and mabye my main argument for differentiating LaTeX from mere markup is the presence of a growing base of packages.
LaTeX is more than just markup
You might have to know certain naming convention used in data standards around XML, but that’s about it. Once you know how to produce valid XML / HTML, the learning process is basically over. You can go on to do more fancy things with the markup, but the markup itself doesn’t get any more complicated than that.
This is completely different in LaTeX. The more you use it, the more you have to interact with the packages. You need to be aware of the most important packages, you need to become aware of how TeX works internally at some point, you need to understand the language enough so you can make (even moderate or simple) customizations, you need to understand how packages work to interact with them and to understand how they interconnect and sometimes conflict with each other.
“Knowing programming” vs. “knowing language XY”
You don’t need to know how to construct a complex program, just a line of code will go a long way when using these languages as scripting languages. This, too, is completely different with LaTeX. You cannot hope to make any meaningful changes without a tiny bit of a bigger picture of how the whole complex functions behind the scenes work.
True, some knowledge like that is helpful with scripting languages as well, especially as you go on to program more complicated stuff but it isn’t absolutely necessary. You can use scripting langauges extensively without ever coming in contact with the internal working and without having to really “know how to program”.
“Knowing how to program” I would therefore define more in the direction of knowing about data structures, knowing programming principles which are language-independent (“algorithmic thinking”, pseudo-code).
“Knowing programming language XY”, however, I would understand as being deeply aware of the specificities of the language and how to use them most elegantly, plus – and this is the most important part of the argument here – being familiar with all of the important packages. Keeping up-to-date with packages and understanding just how the work is a huge undertaking.
This is why professional programmers usually specify their one main language and if you were to ask them why that is so (when they know like 10 other languages), they will explain to you exactly that. The fact is that you can’t keep up to date with the new packages and development of a huge amount of languages. This also implicitly tells us that professional programmers make a difference between “having used the language once or so” and thus knowing the basic syntax, is quite different from “mastering a language”. This is also where “knowing how to program” and “knowing a language” become intertwined: Since the basic principles are so similar, a professional developer would probably “learn how to program” on the example of one language where they will become proficient. Now, they will probably go on to learn or at least get to know more languages. Then follows the point where these two skills separate from each other once again. Their skill of “knowing how to program” includes all the basics which are not language specific and the “basics”, so the syntax and basic usage of pretty much any language overlap strongly. They will already be familiar with the basics of the language without really “knowing the language”. (Hopefully this little excursus added something to the point I was making though I’m not quite sure 😉 )
Advanced LaTeX means “knowing packages”
You might be aware of the post where I try to define what the hell I even mean with “Advanced LaTeX (see for example my “misson statement” post). The gist is that, in my opinion, advanced knowledge and mastery of LaTeX comes down to knowing packages and becoming familiar with the internal workings of TeX. Just like I defined what it means to “know a language”. This is why I would say that at least “Advanced LaTeX” is definitely exactly like a programming language, albeit one which is mostly for the limited/targeted scope of typesetting and therefore focuses strongly on providing ways of making this work. It is not a “universal language” you would write a (non-typesetting) program in, for sure. But is that a necessary requirement for passing as “programming”? I’d say no.
DH “programming” often isn’t more than scripting either
So this is it for now, I will hopefully keep you posted on some “advanced LaTeX” topics in the near future and maybe also talk about
TikZ which I think is a good example of how we can see “LaTeX as programming” in action on a few concrete examples.
To wrap it all up, interesting fact of the day: I think you could say that I first learned programming using LaTeX. It was the first langauge I was actually using like an active user (not just copying around snippets from the internet). I’m still not really good at it or not as good as I would like (sadly, getting better at LaTeX is one of those long-term goals with less immediate payoff so my learning efforts always get delayed, also with running this blog and all there isn’t much time to work on my own LaTeX skills). Teaching myself TikZ is probably what became the clear demarcation line for me betweeen markup and programming even though there was lots of package handeling even before I ever looked into TikZ. For understanding TikZ, I needed to understand the basics of graphics programming (how do I use and create those digital shapes, how are they ‘described’, etc.) Spending time on that – and also lots of spying into other people’s code from templates probably – really kickstarted a lot of tech skill for me (and I intentionally didn’t say TeX because what I learned extends way past just the TeXLaTeX world).
Cheers until next time!
Buy me coffee!
If my content has helped you, donate 3€ to buy me coffee. Thanks a lot, I appreciate it!