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).
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.
To get around it, you'd have to make it In App Purchases, because these also come from a the App Store.
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.
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.
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.
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.
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.
All kidding aside, I use (La)TeX almost every day and it's bulletproof. It's not going anywhere, so you might as well learn to love it, worts and all.
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 ...
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.
In any case, I absolutely agree that resource constraints aren't keeping LaTeX off of our mobile devices.
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).
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.)
The point those packages make is that some problems can have a solution that lasts years or decades instead of mere months.
But I don't think Joel is against a slow, one line at a time, working on the old code base rewrite.
It is not clear what kind of re-write the OP is advocating. But I would be surprised if he is pro the start from scratch kind.
But it might be just my biased perception.
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.
For the reader's convenience and reference: http://www.joelonsoftware.com/articles/fog0000000069.html
I'm interested to see how this could be justified, instead of "hit'n'run" style.
Noting here that other than the source problems, performance was a considerable issue.
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?
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.
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.
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).
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.
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.
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.