Hacker News new | past | comments | ask | show | jobs | submit login

To 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

[2] http://nts.tug.org/

[3] http://en.wikipedia.org/wiki/New_Typesetting_System

[4] Or their immediate successors, the ExTeX project - http://www.extex.org/

[5] http://en.wikipedia.org/wiki/Wirth%27s_law

[6] http://en.wikipedia.org/wiki/Induced_demand




Thank 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.


And that would be the holy grail indeed, if you can pull it off! Best of luck.




Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: