5 ms·
Thanks for your interest in our project, that hasn't released any version 0.1 in three years, and yet manages to concentrate a lot of (maybe necessary) love and
by pmeunier 12y ago
Thanks for your interest in our project, that hasn't released any version 0.1 in three years, and yet manages to concentrate a lot of (maybe necessary) love and hate.
First, about the technical points:
- Ocaml has been backward compatible for the last 20 years, which is why we rely on it for backward/forward compatibility. After some time, we obviously hope to release a forward compatible version of Patoline. As a side note, I've got several papers written in LaTeX on my hard drive, that don't compile anymore after only eight years.
I imagine that debugging and improving packages written in TeX is hard enough that authors who manage to do it do not bother about compatibility. With the exception, of course of those "who know TeX and LaTeX pretty well" (at least until the day they write their first package, like I did shortly before beginning Patoline).
Moreover, there is something called "a type system" that OCaml uses, that makes your code more likely that any other non-functional language to remain stable through time. I know there are people who do not acknowledge the existence of this, and confuse it with older systems such as type checking in C, or who believe functional programming is a parenthesis writing competition.
I would like not to use the kind of authority arguments I've seen in this page to convince you. Trying ocaml or haskell is a good way, but you need to be willing to be convinced, which is usually not the case in this kind of discussions.
At least it makes sure that the program cannot run into an "undefined behavior" without the author being aware of it, something that my own daily experience with programs such as svg2tex does not do.
- In our first project meeting about Patoline, it was decided to not choose a definitive language. This is probably the only design choice. Of course there is a default one (intended to be forward compatible, if you are still following), but you can change it. Like markdown? Write a compiler to Ocaml, it should not take more than a couple of hours, and you won't have to rewrite 20000 lines of code to handle the crappy font formats that Microsoft, Apple and Adobe have designed for you, nor 3000 to output reasonably portable PDF documents that most printers can print (maybe this is an explanation of the size).
- Knowing quads, struts, \expandafter and \futurelet is cool knowledge. Did you also known that TeX uses its own fixed-point algebra? While these are certainly "inventions of a genius", using 21st century numerical methods to adjust spaces is efficient use of science and technology, and that's what we do.
By the way, have you heard of IEEE-754? It doesn't begin with a slash, I've seen it used at Caltech, probably Stanford knows about it too.
Now about other points:
- What is "feature-completeness"? I know "Turing-completeness", which is the ability to simulate any Turing machine. On the operating systems we have today, "Turing^OS-completeness" (the ability to simulate any Turing machine with the OS as an oracle) is probably a great feature too. This is something Patoline has, that TeX doesn't. Querying online bibliographic databases in Patoline is a matter of writing a few lines of OCaml. In TeX, it means writing pascal code, for a variant of pascal that can talk to the OS (web2c probably can, I'm sure, although it was not written by a genius).
- We also seek to provide a development platform for new typesetting algorithm. While Knuth may be regarded as "the man who invented dynamic programming", he was ten years old when Bellman discovered it.
Today, we have other methods, such as approximation algorithms. We could even imagine learning good typographic choice using methods from machine learning.
There is space for innovation on this planet, and although I use emacs and vim, and even pdflatex on a daily basis, I do not consider them a full stop to software.
- gone35 12y agoTo go along with the Gospel of Matthew references [1], "No one can serve two masters" (Matt 6:29). This is a lesson your arguably most relevant predecessor, the NTS project from the early 2000s [3,4], learned too well --they too found TeX82 hopelessly quaint and monolithic, frozen in time for the sake of backward compatibility [2]: "The stated aims of the project are very simple: to continue the tradition of Donald Knuth's TeX by providing first-class typesetting software which is both portable and available free of charge. But whereas TeX is now frozen (Knuth no longer has either the time or the inclination to extend it), NTS is intended to remain flexible and extensible. Indeed, its very raison d'être is to provide a portable platform on which experiments and extensions can be easily layered." And how could anyone find fault in their reasoning? It felt right after all: in the dawn of the 21st century, with modern programming paradigms and all that computing power, why get stuck with Pascal and outdated space concerns? And so they did [2]: "NTS is written in Java; the group debated for some time which language was the ideal language for a complete re-implementation, and although the original desiderata stressed that it should be a modern, rapid-prototyping language, further introspection suggested that a modern, object-oriented, truly portable language was even more important. On that basis, Sun's Java was chosen, and experience during the first year has suggested that that decision was justified. Even though Java lacks something in terms of type declarations and static polymorphism, its genuinely portable nature ("compile once, run anywhere" is Sun's justifiable claim for this language), combined with its network-awareness and widespread availability, make it an ideal language for the task." Suffice to say their efforts didn't pan out as they hoped. It turns out, efficiency is a thing --even with modern hardware [5,6]-- and, as it happens, high extensibility/modularity and efficiency are very, very hard to achieve in the general case. [1] https://news.ycombinator.com/item?id=8026671 https://news.ycombinator.com/item?id=8026671 [2] http://nts.tug.org/ http://nts.tug.org/ [3] http://en.wikipedia.org/wiki/New_Typesetting_System http://en.wikipedia.org/wiki/New_Typesetting_System [4] Or their immediate successors, the ExTeX project - http://www.extex.org/ http://www.extex.org/ [5] http://en.wikipedia.org/wiki/Wirth%27s_law http://en.wikipedia.org/wiki/Wirth%27s_law [6] http://en.wikipedia.org/wiki/Induced_demand http://en.wikipedia.org/wiki/Induced_demand
- pmeunier 12y agoThank you for this pertinent observation. I must confess that after examining all the failed attempts at "writing modern TeX" when I got upset with the TeX packages I wanted to write, I got despaired that so many people had tried and failed before. NTS is probably the worst example, since "rewriting software X using language Y" is something I do not really understand nor support (especially when language Y is only "felt" superior to the original language, using only non-theoretically-backed dogmas such as "object coolness" to support these assertions). Lout is certainly a more pertinent example, but there are also others, including Microsoft Word. After examining the possibilities of doing something usable, and reading great books (most importantly Bringhurt's Elements of Typograhic Style) we felt that we could do something different, and that the world really needed a different tool. And right now, Patoline is already different, because we are not serving any master. The idea is the following: imagine you have two users, God and Baal. God wants a forward-compatible tool that he can write stable rules for the universe with. Baal wants bleeding-edge experimental features to be added all the time, and compile his documents to web pages for ever-changing standards. When we are ready to release Patoline 1.0, both will be able to combine the modules into their favorite tool: God will be able to write something that will work in saecula, and Baal will have his fancy stuff.