The price of a LaTeX rewrite would be even higher: incompatibility. If one tries to rewrite TeX, the problem gets much much worse, since TeX is, for all intents and purposes, bug-free. A new implementation will certainly not be. Joel Spolsky said it very well
http://www.joelonsoftware.com/articles/fog0000000069.html
I disagree that the current situation is LaTeX developers' fault. TeX and LaTeX are complex pieces of software, that are developed over time. They were extended as the capabilities of their platforms increased, to take advantage of those capabilities. This requires full access to the OS utilities, and naturally LaTeX environment does that. If anything, this is Apple's fault. For whatever reason, they cannot allow applications to use the existing capabilities of the underlying OS. This goes against the Unix mindset; of course there will be unpleasant consequences, but one cannot hold Unix mindset responsible for these.
Unless I'm forgetting something from the article, the author never said it was the LaTeX developer's fault -- he simply said Apple was right for not allowing it in its current state. Not all situations are someone's "fault", and thus just because Apple is not at fault doesn't mean the developers are. It's just as you declared it, an unfortunate result of many decisions which were right at the time.
That being said, I also think you have a low bar for definitions of "bugs". Terrible performance is very much a "bug" in my book. Even the things that aren't "bugs" in the strictest sense can still make for bad software. The executable described here is 4GB, that's 1/4 thte total space on a low end iPad! Also, if tomorrow someone does discover a bug, it sounds like this would be a mess to fix. The jumble of source simply won't be attracting many new developers (whether it be to fix existing bugs, add new features, or port to new platforms).
The LaTeX executable isn't 4GB, it's 3MB or so (pdflatex/pdftex) or 16MB in the case of XeLaTeX. The 4GB consists of billions of extension/modules/packages for typesetting documents.
Yes I noticed that in the comments before I posted which is why I was careful to specifically say "The executable described here is 4GB" so as to refer to whatever it is he was trying to work with. I suppose whether all of the 4GB is needed for what he wanted, whether it could easily be taken apart, or could now be remade in a much smaller package, are all valid questions.
4G is a bit over the top. My install (TeXLive 2010 on OpenBSD) is ~2G, and that includes gobs of rarely-used packages and documentation.
Really, borrowing MikTeX's install-on-first-use for packages and making documentation optional should result in a much more reasonable size. If you want to get fancy, teach LaTeX how to decompress packages on demand.
Here comes the problem: Apple requires it to be a single binary, distributed once. You can't install packages the LaTeX ways should you want to, so you have to bundle most (if not all) packages into the single binary.
You could use a virtual machine library (if anything suitable exists) and run everything inside one executable - it would probably have horrid performance but you get rid of the single binary restriction. You can put on a nice front-end and tell the user how much longer he has to wait until the operation is complete.
Virtual machines are generally prohibited by the guidelines as well. (Exceptions exist for things like script interpreters, which need to be present for some games to run, e.g. Lua.)
I think the difference here is between interpreting scripts that come with the binary, and downloading new scripts from the internet (or other untrusted locations). The latter is prohibited.
To get around it, you'd have to make it In App Purchases, because these also come from a the App Store.
Apple wants to restrict the platform options available to preserve their user lock-in. They were sort of forced to make an exception for games because they had no alternative to offer.
It seems the cult of Apple is touchy today and can't detect a joke. I'm sorry if I have inadvertently hurt your feelings - I will be sure to clearly state my humorous intentions next time. </humour>
For the record, I do not own devices based on iOS or Android and I don't care for your little Apple-Google feud with which you seem to be so concerned with. So please, carry on with those market statistics about Android, I am dying to know more.
Well you obviously weren't careful enough. Nowhere in the article does he talk about a 4 GB binary or binaries. To quote him:"A 4GB Tex distribution dependant on over a 100 binaries" He is talking about the _whole_ distribution not a single or several binaries. So even though you were careful, you still misquoted the article.
"The App Store guidelines insist that any iPad app be a single executable. Jailbreaking would ease this restriction, but in this case Apple’s gatekeepers are right. A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad."
From that quote ("A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad."), it is clear that he is musing about a scenario where he ships all 4GB. As stated many times (and also in that same quote), on the iPhone you are forced to ship something as one executable. Thus, the theoretical distribution he is referring to would in fact be a single executable of about 4GB. In fact I think that's the whole point of those two sentences. So it appears that I was indeed quite careful.
> As stated many times (and also in that same quote), on the iPhone you are forced to ship something as one executable.
On the other hand, yes the executable must be "one". On the other hand you can download stuff (either directly or via DLC). The issue is that while Apple has relaxed their restrictions on bundling interpreters in applications (you can do that), they have not relaxed their restrictions on downloading interpretable code: it's not allowed. So downloading even styles would be verboten, since styles are TeX, and TeX is executable code.
I think you are missing the point. The apple guidelines do not state that a program can only consist of an executable. That would not make any sense. Rather they state that any application can only consist of a single executable in addition to whatever resource files are included. In the case of the Latex distribution in question one would have to convert all 100 executables into one executable, my guess would be perhaps 100 megabytes. In addition one would have to include lots of resource files, mainly sty-files bringing the whole bundle of an executable + resource files up to 4GB.
AFAIK Apple doesn't restrict you from bundling files in your application. That simply wouldn't make any sense.
The point here is that he is talking about an application consisting of a single runnable binary of size X with tons of bundled .sty-files that brings the whole application up to 4GB.
Previously, this would not be allowed, since .sty-files are interpreted (which in turn would make it impossible to implement LaTeX on the iPhone), but that really wasn't the point here. The point is simply that this wouldn't be a single 4GB executable, but a an executable of perhaps 100MB bundled with a whole bunch of .sty (and other) files to a total size of 4 GB.
Edit: Fixed typos. Sorry. HN doesn't work very well on my phone.
> For whatever reason, they cannot allow applications to use the existing capabilities of the underlying OS. This goes against the Unix mindset; of course there will be unpleasant consequences, but one cannot hold Unix mindset responsible for these.
Using the native capabilities of the OS in the sense you mean - allowing TeX to use its ancient, hideous bitmap font system, goes against:
- Unix philisophy - do one thing well, link against or pipe to other apps/libraries that do their thing well
- Simplicity. The user should not be forced to make an unnecessary choice where one option is almost always superor to the other.
Knuth's concept of 'bug free' is one of an academic computer scientist. TeX has many, many issues: unnecessary dependencies, a horrible build process, and many UX issues that stopped TeX from reaching TeX's original goal of 'allowing anyone to create typeset documents'. This is fine: Knuth is a mathematically focused computer scientist from a period where everyone who had access to a computer was a programmer. It was valid in this era.
TeX's original goal of 'allowing anyone to create typeset documents'
Actually, according to this interview[1], speaking of the very first version of TeX, "I should mention that I had no idea that I was designing a typesetting system that anybody else in the world would ever use, besides me and my secretary. My idea was that I would teach Phyllis, who was my secretary for almost 20 years… So Phyllis and I were going to be the users of this TeX system. … I tried to design it just good enough to do my books and no other books."
Even with the released version, I don't think TeX was ever intended to be the last word on typesetting; it was simply his best attempt at a decent markup. He then froze the features so that previously typeset books could be corrected and reprinted using the same source. He left it up to future programs to innovate.
The big problem on tablet devices is constraints in memory. Yes the unix way is to have various small utilities work together through pipes and interprocess communications. The big challenge at that point is how to do you manage memory? What if a single process in that huge chain uses up all of the memory and another process gets killed by the OS which was part of that chain (do note, no swap on mobile devices)... How is the calling program supposed to handle one of its subprocesses suddenly dying?
Do note that the same is true on Google's Android OS. You can run as many threads as you want, but no calling other executables to do work in the background ...
A current tablet device, even a cheap one, has about 256Mb of main memory. Android (at least the cyanogen mod kernel) has also the ability to use a part of the main memory to store compressed swap partition data. That leaves about 80 Megabytes to userspace programs (on Android). About the amount a normal desktop computer had in 1998.
LaTex dates back to the beginning of the 80s. Given that it has the ability to create large documents, I doubt that the required amount of main memory scales linearly with the size of the document.
Also, when you use subprocesses, besides checking their return value, you have some sort of interprocess communication which should detect when one process failed to finish his job.
It looks more like the smartphone runtimes and their sandboxes just don't support it at all, because modern GUI applications rarely build upon multiple executables in the background.
Android does have IPC mechanisms (Intents and remote methods) that can be used to have another process do work in the background. The difference is that even if you use them, you're still not likely to wind up with something that looks like a set of cooperating command-line utilities.
In any case, I absolutely agree that resource constraints aren't keeping LaTeX off of our mobile devices.
I have TeX Live available in the Ubuntu chroot on my HP TouchPad, so you're right that it's not a resource thing. Admittedly in this case webOS provides a pretty standard Linux environment under the hood, so it falls pretty firmly outside the Android model (much less iOS).
I'm curious where you get the idea that LaTeX is bug free. In my experience it is rare to find two packages that work together bug free, yet alone the collections of them needed to form even a respectable document.
I assume he meant that core TeX (the part written ages ago by Knuth) is in effect bug-free. However you do have a good point that one effect of core TeX being ancient and not really updated is that, in practice, what people actually use is TeX plus giant macro packages whose size is bigger than TeX itself, and those are certainly not bug-free. It's at least plausible that a rewrite wouldn't lead to more bugs total, if the rewrite made it easier to write less-buggy macro packages that interacted more nicely (the TeX macro/module situation is not great for that).
Nobody uses (Knuth's) TeX anymore. They use PDFTeX, XeTeX and LuaTeX. None of these are as stable as TeX, but in practice a whole lot better than most other software I use.
All of these versions of TeX are just extensions of the original TeX. The core Knuth's code is still used in each one of them. The stability comes from the core, not just from the work of pdftex, xetex and luatex developers.
The stability comes from the core, but the problems arise from the extensions. I have pushed LuaTeX to some limits and seen lots of segfaults and other errors.
It's 'bug-free' in the same sense that qmail is bug free: you take a piece of software, design it very carefully to do only the minimum amount required to make it fulfill its purpose, spend a lot of time on making sure there are no 'bugs' under a very strict technocratic definition of 'bugs' (i.e., few features, slow running speed, idiosyncratic workings aren't 'bugs') and then make a career out of marketing yourself as being able to write 'bug free' code.
Of course to make the software useful in the real world, a lot of things have to be added to it - make sure to not include any of it in the 'core' otherwise the 'bug free' claim will go out the window really quickly.
So yeah, in that sense I guess it's technically (which I use as a euphemism for 'autistically') correct to call TeX bug free (the bounty program for bugs found in it is quite famous, and part of fore-mentioned marketing).
You think Donald Knuth has made a career for himself out of being able to right 'bug free code'?
Really?
He's made a career for himself out of being an extremely creative computer scientist and writing outstandingly scholarly books about programming. Far from marketing himself as producing bug-free code, he has published articles entirely devoted to the history of bugs found in his software.
(As for the bits that turn TeX into LaTeX, no one is making a career out of claiming that they are bug free -- for the simple reason that no one thinks they are.)
Of course not, it's hyperbole to illustrate the point. In the specific cases of Qmail and TeX, the 'bug free' aspect of it however is overblown and a marketing gimmick. It's not that hard (given enough time) to make something bug free, it's a whole different thing when the software needs to evolve at the same time to meet the (changing and expanding) requirements of actual users.
Actually, the reason for not evolving/rewriting TeX is so that old documents can be typeset and produce the same results. I find that an appealing goal.
TeX wasn't born in a night and suddenly appear in binary form. Knuth worked a hell lot to make it clean, make it work and make it fast. At least, for when he wrote it. Go and read The TeXbook
It is also worth pointing out Joel says "don't rewrite" specifically in the context of a software company, where I strongly believe it is largely correct. In the context of a decades-old open source project the decision may be quite different for legitimate reasons.
I find it likely that you'd be better off performing an algorithm extraction and doing a true from-scratch rewrite than trying to incrementally translate TeX and LaTeX.
The only think i 'd keep from old tex is part of the mathematical notation. Otherwise, it's bloated, quirky and doesn't handle international text well.
"""The price of a LaTeX rewrite would be even higher: incompatibility."""
Yeah. The only benefit is a codebase that reflects current needs and can grow in new directions and follow current practices, that programmers of today are familiar with. And also be faster, and more flexible. But what are those compared to compatibility right?
(Of course people interested in pure compatibility could just continue to use the old version, until the new is compatible enough, or they don't need compatibility anymore).
"""If one tries to rewrite TeX, the problem gets much much worse, since TeX is, for all intents and purposes, bug-free."""
And your wrong assumption is a) that a problem has to be bug free to be useful or b) that a new effort can't produce a relatively bug free codebase?
And your wrong assumption is a) that a problem has to be bug free to be useful or b) that a new effort can't produce a relatively bug free codebase?
How are either of those requirements wrong? I certainly expect my programs to be bug free. LaTeX is a tool that's older than many GNU utilities. It's been reviewed and tested numerous times over by the harshest test suite of all: the real world.
Yes, in theory, you could rewrite TeX to be cleaner, while maintaining backwards compatibility and lack of bugs and regressions. In practice, this is very very hard. It's so hard that no one, no individual or company has managed to pull it off.
But hey, who knows? You could be the first. The LaTeX codebase is open-source. If you think you can pull off what the most talented software engineers in the world haven't been able to do, go right ahead.
"""How are either of those requirements wrong? I certainly expect my programs to be bug free."""
Good luck with that. What I said, though, was that "a problem has to be bug free to be useful" is a wrong assumption. We all use programs that have bugs, and still found them immensely useful.
"""Yes, in theory, you could rewrite TeX to be cleaner, while maintaining backwards compatibility and lack of bugs and regressions. In practice, this is very very hard. It's so hard that no one, no individual or company has managed to pull it off."""
What are you talking about? Tons of people have written TeX versions of their own, even in Lua, and most of those are widely used.
"""But hey, who knows? You could be the first."""
Hardly. There is LuaTex, XeTeX (even more widely used) and others. Are you just talking out of your ass? (Not to mention several other modern typesetting engines that are not TeX based. You make it sound like TeX is an impossible achievement).
Now, what I said I'd like to see was not a rewriting of TeX itself, but a modern version of a TeX like engine, with or without compatibility. Programs like XeTeX and Omega for example provide Unicode support and TTF/OT support to TeX, but I'd like to see something more modular, and with a more streamlined markup than TeX+LaTeX. While we're at it, even scriptable.
There are also some improvements found since in typesetting, like those employed in the InDesign layout engine concerning edge text and hyphenation.
Both LuaTeX and XeTeX have the original TeX code at their core, so they are not bottom-up rewrites.
The purpose and benefit of backward compatibility for TeX is that a 30 year old manuscript written in TeX can be fed to the latest version and produce identical output to what was produced 30 years ago. (Of course, you'd also have to archive the macro packages and font files you were using, but those were never machine dependent).
Thanks. A have given lout a look in the past, but I though it wasn't actively developed anymore. I also liked Prince, but it is proprietary unfortunately.
Don't you think intelligent people have better things to do than to rewrite old code, just because Apple's platform lacks important features that have been well-known for several decades?
The notion that every time we have a new language/platform, we must REWRITE THE WORLD!! is absurd and a huge waste of resources. We should stop making excuses for it.
"""Don't you think intelligent people have better things to do than to rewrite old code, just because Apple's platform lacks important features that have been well-known for several decades?"""
Yeah, you probably missed the whole point of the comment, TFA, and several other stuff besides.
It's not Apple's platform that's the problem, is TeX/LaTeX that is lacking important features. In EVERY platform.
People have been hacking them on to it, but having a better codebase to start off, without the assumptions TeX/LaTeX make would really make it so much easier.
"""The notion that every time we have a new language/platform, we must REWRITE THE WORLD!! is absurd and a huge waste of resources."""
Yeah, good thing that nobody suggested anything like that in the thread.
Btw, the notion that you can add your worthless reply without first understanding what the parent poster says is absurd. You should stop making excuses for it.
* First of all, the OP mixes up LaTeX and TeX. TeX is written in a very portable language and has been ported to more platforms than most other software, including PDP-10 and others.
* You only need one binary to work with TeX. Either PDFTeX or LuaTeX. All other binaries are just glue code (for example to generate missing Metafont fonts, but who wants them these days anyway?
"One binary" is a bit optimistic; even if you never do anything fancy with fonts, you'll want bibtex. And makeindex, if you're writing a large work. PSTricks does not work with PDFLaTeX (Tikz is arguably better than PSTricks, but PSTricks won't be dead anytime soon). XeLaTeX is required to use system fonts easily.
And that's before getting into anything truly gross.
I am running a TeX distribution with only one binary. And with bibliography and index: these could be done with the Lua part of LuaTeX. True about the others.
Indeed, Norman Ramsey essentially reimplemented Bibtex in Lua: look at bibtex.lua.in in his Nbibtex; tarball avilable from http://www.cs.tufts.edu/~nr/nbibtex/
> * You only need one binary to work with TeX. Either PDFTeX or LuaTeX. All other binaries are just glue code (for example to generate missing Metafont fonts, but who wants them these days anyway?
A lot of TeX uses Computer Modern to typeset the body (a metafont font) and I don't think I have ever see a TeX document that doesn't use Computer Modern or Euler (another metafont font) for equation typesetting.
I also wonder whether it's possible to achieve the excellent equation typesetting capabilities of TeX without metafont.
Metafont is hardly used these days. All TeX distributions use either a Type1 font of Computer Modern or Latin Modern. And the equation typesetting has nothing(!) to do with Metafont. Everything is set into the TeX binary (and its formats). You just need a good math font (and that is not trivial, but not related to Metafont)
Yep, it always surprises me how few people change off the default Computer Modern -- which I find really spindly and ugly -- given that a single \usepackage{...} will give you a beautiful Palatino, for example. I sometimes suspect they're just wanting to hit me in the face with the fact that they're LaTeX users...
Computer modern is a nice font for documents that contain equations. I suspect that it is because of the subtle changes in density. But for normal prose it really doesn't work very well.
Palatino for text is fine, but what math fonts go well with it? I think them main reason I use Computer Modern is that the math and text fonts look so good together.
One real issue is that most users' LaTeX environments are highly customized and tweaked to our own liking. Even if it weren't absolutely nuts to put every-package-and-extension-known-to-man inside a iOS binary, it still wouldn't be right. Like, what if I want LaTeX2HTML (I've never not had to highly tweak this)? What about my snazzy custom fonts? That bibliography style that only one journal accepts and requires these crufty old stys from 2.09?
If I needed LaTeX on a daily, here's what I would do:
1. Install DropBox on my mobile device and a designated "build" box--maybe just your home computer or an EC2 micro.
2. Set up Jenkins on a box that's got your favorite LaTeX environment and create a job that takes your LaTeX source files, builds and outputs your desired formats and pops them into an output folder you created on DropBox.
3. Set a build trigger that runs a build every time you touch a specific "ready to build" file.
4. Edit and write LaTeX source files on your mobile device using an app that syncs with DropBox like PlainText.
5. Increment something in your "build trigger" file.
6. Et voila, check the DropBox app on your mobile device for output and log files. :)
Sounds to me like a LaTeX App for iPad that offloaded page rendering to a server which also handled configuration would be a nice product. I'm guessing the market might not be large enough.
The integration is where the value is. Even LaTeX users value some kind of ease of use or they wouldn't sully themselves with LaTeX, they'd use TeX or just write PostScript directly like a true neckbeard.
Which is very similar to what I did. A simple cron job with a bash script is quite sufficient (assume a *nix environment), and you can use the make utility to add your build trigger support quite simply.
I don't think this is a problem with LaTeX & "messy codebase", I think this is a problem with restrictions on iOS from Apple.
The crux of the problems with porting it seem to be that everything has to be in 1 executable, that there can be no scripts, and it must be in an approved language. That's merely a problem from Apple.
A correct title would be "The price of restriction on apps: No LaTeX on iPad"
The author also thinks it's be easy to just switch licence to GPL. Unless LaTex & TeX required copyright assignment, you cannot switch to GPL without getting every contributor to agree. The author is also under the believe that you cannot have commerical software that's GPL. It's DRM software you cannot have with GPL, and that's why Apple doesn't allow it.
"I don't think this is a problem with LaTeX & "messy codebase", I think this is a problem with restrictions on iOS from Apple."
No. It's a problem with LaTeX & messy codebase.
Take Apple out of the picture, for a minute: the messy codebase remains a problem with TeX/LaTeX.
It doesn't lead itself to easy extension, it doesn't lead itself to easy incorporation of features such as full Unicode support, Open Type font special capabilities, and much much more. There have been several attempts to fix this, namely LaTeX3e, Omega et al, but none has been that successful. We're stuck with a codebase that works, but is messy, too complicated (ever tried to set up a LaTex/Tex distro from scratch), and obsolete in many parts.
How can you say this when every item in your list is currently supported? Unicode, open type, pdf, etc. are all currently supported by new distributions.
Maybe you misunderstood me? I wrote "it doesn't lead itself to easy incorporation of features" (such as the above). I also acknowledge several attempts to fix this. What I lament is that "We're stuck with a codebase that works, but is messy, too complicated and obsolete in many parts".
I know a lot of the above are supported (I use LaTeX myself, and follow the developments quite closely) in newer TeX implementations, but not in clean way and not with first class support, to the legacy limitation.
I was asking for a clean implementation, no something like XeTex --that while supports several modern features it inherits tons of design problems from the original TeX.
So the next hot article will be "OMG a GNU/Linux distribution has a messy code base"?
Once you are talking about a multiple GB system, of course it's messy. Except it is actually a very poor choosing to describe the situation. E.g. mixing multiples programming langages in a big system has nothing messy, it would even be a HUGE warning not to encounter multiple programming langages in such a huge system.
In this paper[1], they say that much of the latex running time is eaten up in the startup and shutdown of the program
and the actual typesetting time is in the microseconds.
A long-running process (daemon) is therefore a much more efficient way to run (La)TeX.
[1] www.tug.org/TUGboat/tb27-0/fine.pdf
"""
On my current 800 MHz PC, the command
$ tex story \\end
takes about 0.137 seconds, while
$ tex \\end
takes 0.133 seconds. The first command typesets a small page of material; the second does nothing but start TEX and then exit. Thus, typesetting the small page takes about 0.004 seconds.
"""
It strikes me that TeX ought to take a page from Lisp interpreters and dump core after loading all the standard configuration files, so that future runs won't need to waste so much time on initialization.
It does, that's how LaTeX starts up and why you have to run it as latex instead of tex. Ditto texinfo, and probably ConTeXt. For a variety of reasons the TeX engine still has to reload a lot of stuff because it might possibly have changed, which is a suboptimal situation; but there is a concept of a "dump" state that has most of the kernel initialized. I suspect people don't care enough to work around it, and the people most likely to do the work (TeX kernel hackers) are also the people who are most likely to be inconvenienced by it not noticing the tweaking they're doing.
Having ported a TeX distribution to MacOS classic some 15 years ago, I feel that the author overstates some of the difficulties. In particular, it's not all that hard to get kpathsea to work without callouts to bash scripts (it's not like Mac OS classic supported system() or anything like it). Basically, kpathsea is an API, and the implementation can be switched out (e.g. I implemented a dbm based file name cache).
Admittedly, getting everything linked into a single binary might be fairly hard.
Sorry, but I fail to understand, why any serious TeX-Head would say that. The platform is crippled and your problem shows it. You are ranting in the wrong direction.
"Beautiful" has nothing to do with whether it's crippled or not. In any case, how is a 4GB executable + several-second runtime for trivial documents Apple's fault? Is the iPad crippled because it can't run a crappy cross-compiled version of OpenOffice with a PS/2 mouse?
I guess the argument is that it's apple's "fault" because the restrictions of the platform require the whole package to be bundled as a single binary, instead of allowing a more modular distribution mechanism. Most of the contents in the 4G are extension packages.
But I am not sure if "fault" is an appropriate term here anyway, we're simply observing two different approaches to software bundling that happen to be incompatible.
The restrictions are what they are, but TeX doesn't help at all by being large with an internal (circular!) dependency tree that would (should) get you fired in a flash from a commercial software house.
Apart from the fact that trees cannot be circular ;-) LaTeX installations work like a charm for other forms of distributions. I think it's really just a clash of philosophies here.
The author is not a TeX-head, or he wouldn't be surprised about WEB, Pascal and wouldn't confuse Plain TeX with LaTeX (the documentation of TeX is the former not the latter).
Fully agree; computer is something on which you can write, compile and run a native program without using external machines. And TeX is a computer typesetting system.
I don't see any reason why LaTeX should be shelling out to bash. And having a mish-mash of loads of different languages creates unmaintainable bloatware.
I don't see any reason why it should _not_ shell out to bash. TeX/LaTeX was developed in a UNIX environment, which has the explicit philosophy of "the tool box with lots of little tools which do whatever little they do extremely good".
The iOS Philosophy of "It has to be one binary app" resembles the philosophy of Windows Programs. Big single programs with lots of functionality unter one big GUI.
How can anyone really be suprised that one of the oldest and mightiest gods of one religion can not be coerced into the shrine of a completely different religion?
Personally, I'm in the camp of "rely on as little as you can". This includes not shelling out to bash unless you really really really can't achieve the same thing with a bit of more code. Apart from making the app less portable, more bug prone, less maintainable etc, it's just ugly.
I don't know, maybe the author is trying to do something with the iPad which is simply not supposed to do. The iPad is beautiful, pleasant to use etc. but writing a book on the iPad is maybe not the things one does.
I use my tablet to write — quite a lot — way slower than on my regular keyboard, but with time to think. Everything is in text files, synced to my desktop where the typesetting is really performed.
Writing publications or books is a long process where basically the final rendering is taken care at the end because the quality of the wording is more important.
So, just a text editor with hard work on the words, sentences, ideas are where 99% of the time is spent.
Maybe the author can provide an extremely pleasant way to write on the iPad and on the Mac with syncing of the work to have the feeling that the work is never lost, that one can always update a bit of the manuscript and just run "make" on the Mac some times to times. Everything in a smooth workflow.
What if you just wanted to implement a TeX based ebook reader? I think the fact that you can't think of a use-case doesn't negate the problems he's facing.
I understand that tablets are a wonderfully portable device but you can't expect to get 100% desktop functionality. Sometimes you have to find the limit of your software/hardware.
I don't own an iPad, but is there git or the like? If so syncing and keeping track of changes would be simple.
> Sometimes you have to find the limit of your software/hardware.
The point is that there does seem to be a software limit, but there shouldn't need to be a particular limit there. There's certainly not a hardware limit, since an iPad can run circles around almost all of the computers of the era when LaTeX was written. Unless you believe that the TeX system represents an almost magical, once-in-a-lifetime, impossible to replicate achievement in software engineering, there's shouldn't be a software limit either, but the code base is so complicated that there does seem to be one.
From what I can tell, the software limit is that everybody has a different set of custom macros and styles that they use, and that distributing extra code is a violation of Apple policy, one that can't be fixed unless you get rid of not only the reality of LaTeX but the idea of LaTeX as a macro system.
"""I don't know, maybe the author is trying to do something with the iPad which is simply not supposed to do. The iPad is beautiful, pleasant to use etc. but writing a book on the iPad is maybe not the things one does. I use my tablet to write — quite a lot — way slower than on my regular keyboard, but with time to think."""
You can pair the iPad with a bluetooth keyboard and write away at full speed.
And with something like LaTeX you won't even have formatting to slow you down.
Wouldn't it be possible to just write a front end for the iPad, and run a LaTeX service in the cloud? I think this would be by far the easiest way to do it, and I don't think it's really optimal to do all the LaTeX stuff client-side on limited hardware and battery anyway.
A cloud service would be nice for a pretty frontend, but isn't at all necessary. iSSH + Dropbox + home server with full LaTeX installation = typography-fu.
Many people seem to think that tablets functioning as "laptop replacements" means duplicating all laptop functionality on tablet hardware. I take "replacement" to it's full meaning, in that a tablet allows you to develop on a server while making no compromise on portability.
If you wants to carry around the full LaTeX installation, you need a laptop. If you want a laptop replacement, you can't expect to not replace your way of working.
I am sure many papers have been written in LaTeX on machines slower than the iPad, and on laptops with less capable batteries. I don't see a reason why this would be unreasonable to do on the client (except for reasons mentioned in the article, of course).
I was agog when I downloaded the LaTeX binary install for my new Mac a few years ago and discovered how massive it was. LaTeX is almost as big as the entire operating system disk!
The full TexLive distribution contains all officially accepted packages ever written (this includes fonts, iconography, compiled documentation and other heavy stuff), most of the compilers, the LaTeX and Context (MK II and IV) packages and a huge toolchain. For compatibility reasons, packages are (almost) never removed. Also for compatibility reasons, the LPPL (Latex Project Public License) discourages[1] the release of a modified package under the same name, so there are copies within the distribution.
So, the TexLive distribution is the "fire-and-forget"-package in the LaTeX world, thats why it is so big. I use it for around 10 years now and I never had to install an additional package.
[1] It even prohibited that for a while, see Wikipedia.
Vast numbers of packages to do just about anything you could possibly want.....
Things like inserting graphics with text flowing around them (picins), or document classes for resumes,or textpos (for absolute text positioning), or......
Basically you have nearly two thousand such packages in TexLive......
I remember installing it a few weeks ago on ubuntu to update my cv.
The base system was 280+ mb along with 190+ mb of documentation. I found it mildly amusing that I had to download ~500 mb of stuff just to update my cv.
I was also surprised. I installed miktex which is around 200Mb and then it still automatically downloads and installs even the most basic packages i use from the internet.
Isn't latex from the 80's? I think my first disk that had more than 200Mb is from the early 90's? How did people use it back then? Also it is still horribly slow even on a core2 with 4gb ram and superfetch.
This article seems to advocate a huge amount of work to an existing, open, and highly stable software product - all to allow it to work on a proprietary device with heavy restrictions on software availability and installation.
Should we do all this work - mandated by business-driven 'app store guidelines' - simply to allow known good software to continue to work?
This article is a proof of the stupidity, ignorance, and general jerkiness of an Apple user. It's like, the world must resolve around some standards set by Apple because it fails to deliver a system that actually works. Oh, and never mind that the stupid guy never understands the reason why the code base is set up as it is.
All in all, here is my opinion: who ever upvote this should feel ashame of yourself for wasting everyone's real-estate on this stupid rant.
Have you actually spent a little moment to at least really RTA?
The author states that even with the restriction lifted, it wouldn't make much sense, as with all the extension that it requires to meet the author's need it would take 4GB.
The situation would be pretty much the same in Android, despite it being rooted in Linux. The article is not so much about Apple as it is about LaTeX.
If you would like to make a point, at least read the article.
Thanks for contributing nothing but personal insults to a very serious argument. LaTeX is extremely useful, while the computing is going more and more mobile. How do we reconcile the situation and enable people to use LaTeX going forward on devices they like is I believe I an important issue.
Wait a sec. "No LaTeX on the iPad" conflates "editing a LaTeX document" and "rendering and compiling LaTex to a final document.". Editing LaTeX on the iPad is already perfectly easy and really quite pleasant, especially with a bluetooth keyboard -- I do it most days (currently, Textastic is my preferred platform, supports syntax higlighting, DropBox and MobileMe).
Rendering to DVI or PDF is something else entirely. While other comments here indicate its doable, I have to ask why? I render my documents on another machine (I actually have a script that monitors dropbox and periodically re-pdflatex's if the timestamp changes -- redirecting error messages to a file is trivial if you need to troubleshoot remotely). If you're attempting to do LaTeX with a WYSIAYG interface or (worse) doing the edit-a-line-rerender-repeat cycle, I'd have to say that you're doing it wrong. The assertion that "doing LaTeX" (or, frankly, any platform that supports simple text editing) requires the native presence of the entire LaTex codebase is just misinformed.
Finally, the author of the post apparently started his project without knowing that the original TeX distribution was written using literate programming, what kpathsea was, or that there were other implementations of LaTeX. Perhaps they weren't quite prepared/qualified for the undertaking? This smells like a classic case of "this isn't how I would do it/use the tool, so it must be broken".
Ah - forgot to mention. If you (like me) occaisionally need to see AMSLaTeX (math) rendered to make sure you got it right, Mathbot on the iPad is your friend.
This is a total 'Bed of Procrustes' argument. In order to deal with the problem of this ONE device and in particular the App Store guidelines, you want to cut off the legs of the source code.
Don't use an entertainment toy for TeX. iPad is a very nice piece of hardware but it is only a consumer (gamer) device - not a full featured Computer. Its good for games and ebooks but I would never use it as a developer engine.
Why do you want to hurt yourself typing TeX on a virtual keyboard? If you consider to add a real keyboard to your ipad then you should better get serious and use a Macbook, Linux or Windows.
This is an interesting solution, because the problem is that the original codebase is messy and therefore not portable. It seems to happen to most software as it ages.
Putting it on a server makes the architecture more robust against messy code (and changes in programming languages and environments), because pieces can be changed independently.
The problem isn't that the original codebase is messy (it's aged, but there are still comparatively new projects working on it e.g. LuaTeX) or that it's non-portable, as demonstrated by the multitude of platforms it's available for.
The problem is roughly equivalent to producing a non-upgradable perl. It's not very useful on its own, but it's completely impractical to include a copy of the entire CPAN with it. And Apple's policies prevent you from downloading additional packages. It's just not worth the effort.
why not? As I understand it, it would, as there would be no need to port (La)Tex to anything: just deploy it in a jailed environment on the server, and the thing you need to have on the ipad is a text editor and a pdf viewer.
It does not solve the problem of writing TeX on an iPad offline, obviously.
Hear, hear! This post provides a perfect example of the utter failure of software engineering in the real world. I am reminded of it every time I try to install software, with all the ridiculous dependencies and multiple versions. Instead of addressing the serious foundational issues facing software development and architecture, the geniuses are busy inventing the latest, greatest programming language, creating even more problems.
Computer science and engineering departments should use these situations to train their students.
> the geniuses are busy inventing the latest, greatest programming language, creating even more problems.
There is some truth in your microrant here. I would restate it like this: Instead of getting excited with how expressive is a new sexy multi-injection functional language when you write the nth Fibonacci sequence, I would think it more realist and constructive to get excited with how a new language or a new extension of an existing language allow to handle module and package dependencies in a clean, safe and explicit way.
It resonates also with my work today: I spend a few hours removing those evil "import *" from our codebase... (Python's "we are grownups" mantra is nice, but I think a piece of the quote is missing: "we are grownups, thus we run pylint and comply to all the rules, except a few carefully chosen ones")
> This dream lasted a few days until we discovered that TeX, the typesetting engine underlying LaTeX, isn’t written in C. TeX is written in WEB, Donald Knuth’s “literate” programming language.
Seriously, they discovered that after starting the project???
There certainly must exist some reasonable snapshot that is less than 4GB as I ran Tex on a computer with less than a 1GB HD in the distant past -- and it didn't consume most of the HD at the time.
Um, for about any other reason that you would want to use document editing software on a tablet? For instance, I use LibreOffice and its ilk only for the most throwaway documents (and open others' files). Having an iPad means I don't need to lug my laptop around to work on my thesis (I run Emacs on a VPS via SSH to do it, and while personally I don't particularly care about the aesthetics, I'd say the use case is certainly there).
I use a ZaggMate which doubles as protection, weighs about the same as any other case and is not bulky at all. It works quite well.
> Maybe you just need a smaller laptop ..
No, I don't want to have a small laptop as my main computer. I had an Eee before the iPad, but the difference in the writing experience is not too different in the end and the other advantages of the iPad are greater. In any case, you can hardly call me a person who unreasonably hangs on to Apple stuff: I'm writing this under Linux which I installed on the MBP my university gave me. I hardly ever boot into OS X here.
> Also, terminals are great, but writing anything serious without X is a pain.
Why? Emacs doesn't really need X, and I don't need to re-typeset my work every five minutes.
Guess this depends on how you work. I often find myself starting many instances of the editor[1] which is a pain if you have to create a new ssh connection for each (or use ctrl-z etc).
"the writing experience is not too different [..] the other advantages of the iPad are greater."
Guess the real difference between us is that you see something great in the iPad, so you are willing to live with its obvious shortcomings[2] compared to a laptop.
I have yet to discover why it's so amazing, and only see a small, but pretty much useless gadget. It could be used for reading I guess..
[1] yes, it has tabs.. still
[2] low resolution, can't run what I want to run, can't type on it without a keyboard, and at that point you could just as easily carry a small laptop (not an Eee ffs, a real laptop).
Oh, absolutely. If I were a actual road warrior, the iPad wouldn't work at all for me. However, between my laptops at home and at work I don't really need a third one, and since I already have the iPad I'd rather make as much I can with it for short trips where I am not going have too much time and/or wifi to pull sustained work sessions.
> It could be used for reading I guess..
That too. For an academic, GoodReader is a blessing. I have finally stopped printing out loads of articles and/or finding that I printed out this same article a couple of years ago. Not to mention Kindle etc. Again, if I were spending significant amounts of time away from either home or the office, I'd consider investing in a proper portable laptop; but I'm not, and for my use case the iPad is ideal.
> can't run what I want to run
Yep, I agree that it's frustrating.
> (not an Eee ffs, a real laptop).
No everybody can afford another proper laptop that's as easy to carry around as an iPad, y'know.
Anyway, YMMV, of course. I was just pointing out that solutions are available.
I've got a dell mini running Ubuntu. I wouldn't recommend it due to a bug in the graphics drivers that causes a crash on resume from hibernate, but, it is a great machine and works perfectly for LaTeX.
This has nothing to do with a 'messy codebase'; a minimalist LaTeX installation would run perfectly well on iOS if it wasn't for the arbitrary rules that Apple imposes upon iOS.
If you want to use a 'walled garden' device like an iPad, you can't really complain when you run into artificial limitations.
the idea that LaTeX has a messy codebase is almost mindboggling to me--I had assumed that TeX--practically the only code that's published as a book (see: The TeX Book) would be clean. I guess the complaint is mostly about the Pascal + C that's code-generated by TANGLE.
It's not so much core TeX that's a mess as the ecosystem; the set of font-generation, path-management, shell scripts, PS/PDF/DVI code, and special-purpose glue binaries gets pretty hairy.
Has Apple started allowing non-trivial Turing complete languages into the App store now? Unless I'm mistaken LaTeX would be rejected out of hand no matter how much you clean it up because it is an interpreter.
I think we're going to see this as a more common problem as we move into the future of non-desktop computing systems and the want for older tools on them. Unfortunately, what LaTex has done is use much of the core unix philosophy which I generally agree with (using small programs that you can pipe text in and out of to make a larger program). When you find that you can't port 20 sub-apps due to each of them being written in various language, etc you'll hit problems.
That's right - that's why Apple released stuff like GarageBand, Pages, Keynote, Numbers and iMovie for the iPad - so that people would not use all this content-creation software to create content.
Yeah I have all those app on my iPhone 4. iMove is useful if I'm out and about and want to trim and upload a video to facebook etc (these apps should really be shipped with the OS), but that's far cry from actual work or real video editing.
The other applications pages, numbers, keynote are severely limited, and really slow and difficult to use. They are OK for viewing documents created elsewhere, but not so much for creating new one.
The Isaacson biography states explicitly that Apple released those apps to counter the perception (which they disagreed with) that the iPad was for "consuming content only"...
I digress. I write in my iPad, mostly for my blog or free-form, with a bluetooth keyboard. Not perfect for TeX, but using iSSH against the cloud works quite well.
has anyone thought of just having a bunch of cloud servers with LaTeX built there, and then writing a front-end which uploads your docs, compiles them and downloads the resulting PDF? with fast enough servers and good enough data speeds, this might even rival the estimated 10 seconds for a fully ported LaTeX app.
I'm assuming it's been ruled out for other reasons though.
EDIT: this would also make it trivial to use it on android/blackberry, without any extra effort. apparently, also, http://www.scribtex.com/
At ScribTeX we regularly get comments from users about how fast our compiling is. Even with the round trip to the server, the PDF appears in the user's browser quicker than if they compile it locally. This isn't due to anything especially clever that we've done but instead stands as a testament to data speeds, and the performance of the Linodes that we compile on. Particularly with Linode, I think the high disk IO performance makes for a very quick LaTeX compile.
I wouldn't sasume it has been ruled out - people (myself included) sometimes get mentally stuck on one solution and fail to spot another obvious avenue.
I'd rather go with a rewrite that also redesigns the typesetting language. It feels like C++ of typesetting to me, although of course maybe I'm just not familiar enough with the language to see its key concepts clearly.
Maybe the Lout system will pick enough traction one day.
It's a quirky mess, but none of the others, to my knowledge (and I've used most of them, which certainly includes Lout) do nearly as good a job typesetting. Lout does a bunch of things subtly wrong that I can't remember right now but that are very visually distinct, and troff is so far down that road I can recognize troff typeset documents at six feet from a glance.
Lout's equation formatting is especially primitive as I recall, and that is a huge amount of work to get TeX-like quality for. I am unaware of any system that typesets mathematics as nicely as TeX does.
Yeah, I'd like to see someone do a modern rewrite of the whole TeX/LaTeX/XeTeX/XeLaTeX/etc. mess. Something that has modern syntax and support for modern features (such as output to PDF, HTML, even OOXML).
It would be good to see UTF-8 natively supported, and for all the common packages to be absorbed into the core libraries. Right now, you can sometimes find 2 or 3 different packages that do the same thing, often with varying benefits. Take the best package, add the missing features from the other packages, and bundle it all into one distribution. For example, the absolutely horrible table support, where merging cells is a nightmare.
Indeed, once you get set up with LaTeX it's okay, but if I were to go and make a new essay I'd have a hard time remembering wtf packages I used for the last one and what they actually did.
2 cent take: While it may have been an epic build story to get LaTeX running on an iPad, I guess I gotta ask why not just install an iPad ssh client (iSSH, Prompt, etc.) and run LaTeX remotely? Or if you really insist on building a native client, why not one that talks to daemon on a system with LaTeX installed?
Viewing the output would be trivial: convert the output to PDF. For the ssh client case, push the PDF to a cloud file service like Dropbox. In the native client case, have the daemon push back the PDF for native client to render.
If anyone is interested in a simple, no-nonsense version of TeX, check out Thierry Laronde's KerTeX (http://www.kergis.com/en/kertex.html). The whole thing comes in at a bit under 10 MB, and it can run on Linux, *BSD, and even Plan 9! I compiled it on Plan 9, built LaTeX as per his instructions in the README, and have been happily generating LaTeX documents since then :)
If you're mobile, carrying around a keyboard negates the value of the iPad. If you're stationary, a real computer gives you far more flexibility. Then you have the issue of unbearably long compiles, as the article stated. The iPad is not the right tool for the job of TeX editing.
Perhaps LaTeX creation system should move to the cloud, think of a google-docs like service which will offer a rich, reliable and simple set of tools to create, publish and collaboratively work on documents.
How about a service to render the LaTeX files? i.e. an app where users just write in LaTeX, there's a render button which sends the file to some server which renders it and sends it back.
The size of the distribution has nothing to do with TeX itself, but with the huge amount of fonts, style files, and other configuration files used to typeset modern documents on desktop systems. TeX itself is very self contained and already runs on most architectures you can think of. The author's problem is that he is trying to port to a mobile device a distribution that was created for UNIX systems.
Maybe we should let LaTex be the way it is now and focus instead on generating better HTML authoring tools. With eBooks becoming more popular, there is certainly a need for such tools. While I understand HTML is no match for the power of LaTex currently, we need to think ahead and maybe help to create a platform for the future rather than getting bogged down by technologies of the past.
I don't think literate programming is obsolete, nor has it been superseded by "modern source code documentation".
LP means treating a program as a piece of literature. A literate program is free from the structure of conventional source code layout; this is different to simply documenting source code.
I don't claim LP is a hot topic, but I think to say it's obsolete is to misunderstand the concept.
I wonder how hard it would be to modify TeX (or kpathsea, whatever) to load its libraries out of a single compressed tarball or fast database of some kind. Seeing as TeX libraries are text files, I do find it surprising that they don't compress better. Is it mostly the fonts and documentation taking up all that space?
On the go doesn't always mean on the go with a reasonable internet connection. The underground trains are a good example where in a big city like London, a journey may last an hour. A flight is another.
For the record, I have no interest in running a TeX rendering process on an iPad.
What I would like to run on the iPad, on the other hand, is a TeX-syntax-aware, document-validating editor that knows how to consume a rendering web service that runs on a Real Computer.
Since I have just spent several hours unsuccessfully debugging a problem with a Journal template, a missing font, and my TeX distribution, I understand why the author thinks Latex is messy.
"... A 4GB TeX distribution dependant on over 100 binaries is not acceptable on the iPad. It is incapable of delivering the slick user experience that the iOS platform’s adherents expect and love ..."
ironically, it could work super easily on a $99 touchpad. since you have all the UNIX stack to play with, and no corporate control-freak limiting what you can do with your device.
In fact, you could run a remote Emacs and edit LaTeX with it, using the excellent AUCTeX package. Of course, that means you need to have a network connection plus a server you can ssh into.
I've never tried using auctex remotely, but in general if you have a file open in Tramp, you can also run arbitrary shell commands with M-! and M-& remotely, as well as opening shell buffers that let you run commands remotely as normal.
Yeah, that's right... You could scp the .pdf back to the iPad, but that's a bit cumbersome. Oh, well, unless you give Emacs advice to do that for you after each latex command...
I had to write a paper with it. I found it so horrible that I ended up not writing the paper (on a very interesting topic) and failed class. I just assumed the professor was nutty and kept onto some weird niche software.
Nope, the professor was requesting that you use the standard typesetting software. Some of your classmates might have to write many papers, and hence it's good that they start learning.
Apparently. It's a shame that researchers hae to use such software. Probably part of why research is so conservative and slow. Why not a funky html "paper"? With interactive formulae, clickable links (hey, wasn't PageRank based on references? Maybe time to turn that around) to references. Most important, a clickable link to an academic profile.
Please explain to me how to type the fraction (a^2+b^2-c^2)/(2ab), which is the simple $\frac{a^2+b^2-c^2}{2ab}$ in TeX, so that the numerator appears above the denominator in HTML. Or any non-TeX layout.
I didn't downvote but, pretty much every academic in the CS/physics/stats/math I've met uses LaTeX. Even a bunch of linguists I know use LaTeX.
It's definitely not perfect--I really wish there were something better--but for writing technical academic papers, it seems like far and away the best.
Only someone not related to typesetting can say that LaTeX is dead. Exactly the opposite is true. Even though there are good alternatives these days such as InDesign and (I hate to say that:) MS Word (which now has a much better formula editor and OpenType Math fonts), great developments are taking place, for example LuaTeX. Not directly LaTeX but TeX: I have built a high quality database publishing system based on LuaTeX: http://speedata.github.com/publisher/
I think that page could benefit from some examples created by speedataPublisher; now I only see a list of features and requirements, not what I'm able to create with it.
Go and find some download stats for some LaTeX distributions. LaTeX is still used in academia everyday, and I conject that it is used to generate docs in business too.
LaTeX is about as far from dead as the desktop computer.
I disagree that the current situation is LaTeX developers' fault. TeX and LaTeX are complex pieces of software, that are developed over time. They were extended as the capabilities of their platforms increased, to take advantage of those capabilities. This requires full access to the OS utilities, and naturally LaTeX environment does that. If anything, this is Apple's fault. For whatever reason, they cannot allow applications to use the existing capabilities of the underlying OS. This goes against the Unix mindset; of course there will be unpleasant consequences, but one cannot hold Unix mindset responsible for these.