Live data from Hacker News

Sile: A Modern Rewrite of TeX

sile-typesetter.org

101–110 of 181 posts

Re: Sile: A Modern Rewrite of TeX

#101

TeX is one of those bits of software that's so complex to replace, it'll take another few decades (and likely a few false starts) before we can get there. The fundamentals of TeX's typesetting are amazing, but everything else is just bolted on. You'd probably want to rebuild it with its own, custom language, perhaps inspired more by modern XML/markdown rather than the old TeX language. The biggest problem that we're…

I never figured the purpose of MathML. It's ugly/impractical to type as a text-based format. Verbose and inefficient compared to a binary format. A middle ground some people might like, but I can't stand.

I'd prefer one of these:

  - A human-writable text format that's displayed in a formatted way, eg TeX or MathJax
  - A binary format that represents structs and enums in code with a clear documentation of how it's packed and unpacked. That can be formatted for reading, and perhaps has a TeX-like API (or is just constructed programmatically using an API)
MathML, in contrast, provides neither the speed and small size of a binary format, while being unreadable and unwriteable.

Re: Sile: A Modern Rewrite of TeX

#102
post #100

Earlier quoted context omitted.

Arcane, but I wouldn't say hideous. What's wrong with \alpha for α or \sum for Σ? Do you have a better idea than this?

I feel that the answer to your question is right there in your question.

I don't understand

Re: Sile: A Modern Rewrite of TeX

#103

Something I've wondered, and the Tex users here can probably answer - why not just use Acrobat or Word for math? Does it not support something?

Not even close, these are not plaintext based so you can't track changes with git, let alone automatic generation of formulas.

.docx files are a zip folder of plaintext XML files. Theoretically they could be tracked with git if you unzip/zip every commit/checkout.

Re: Sile: A Modern Rewrite of TeX

#105

I didn't touch latex in years and I don't regret it one minute. Yes the result looks very clean, and yes it's the best system for writing math, but controlling the layout was an everyday fight.

I found even typesetting math was a struggle for the layout, I still have nightmares of getting equations for my wife's PhD thesis split nicely across 2 lines.

Re: Sile: A Modern Rewrite of TeX

#106

I didn't touch latex in years and I don't regret it one minute. Yes the result looks very clean, and yes it's the best system for writing math, but controlling the layout was an everyday fight.

I have yet to see an environment that controlling the layout is not a nightmare pretty quickly.

The entirety of the web world with their rube goldberg interactions between way too many divs isn't exactly giving me inspiration that modern approaches are going to be an answer here.

Re: Sile: A Modern Rewrite of TeX

#107
post #3

Does it come with a context-free syntax? If not, that would be a grave mistake. Being unparseable is one of the biggest problems of TeX, IMO. Not the least because you cannot automatically work with TeX "documents".

This is a red herring, I assert. There is no "boiling the problem down to a simple grammar" that has promise for a total solution. There are plenty of ways to combine the different parts that work well, and even more ways to combine them into nonsense. Disallowing the nonsense is probably not going to make the ways that work well any better.

Re: Sile: A Modern Rewrite of TeX

#108
TeX and Literate Programming (and Lisp) are my fundamental, day-to-day tools.

Code it, explain it, generate a Literate PDF containing the code.

The programming cycle is simple. Write the code in a latex block. Run make. The makefile extracts the code from the latex, compiles it, runs the test cases (also in the latex), and regenerates the PDF. Code and explanations are always up to date and in sync.

I have found no better toolset.

Re: Sile: A Modern Rewrite of TeX

#109
I've been using TeX for decades. No, not LaTeX, just TeX as in D. Knuth's The TeXbook.

I've been thrilled with TeX from my first usage to the present. Of course, when I want to write some math, I use TeX. I also have a collection of TeX macros I wrote for verbatim, cross-references, annotation of figures, foils, ordered lists, simple lists, etc. TeX is my standard for any good or better quality writing, e.g., serious letters. For my last published paper in applied math, right, I did that in TeX (I don't like to publish -- seems financially irresponsible). The journal was very happy to get my TeX source. I also included the source of the few macros of mine that I used in the paper, and the journal was also happy to receive those. For the core, original applied math for my startup, I wrote that in TeX.

Net, I really like TeX.

For "parsing" TeX as in this Hacker News thread, I have no idea what that might mean or why I would want to do that. TeX, just the way Knuth designed and documented it are just fine with me. For me, TeX solves a big problem; I'm just thrilled to have that problem SOLVED; and I have no desire to invest time or energy in another solution to the problem.

Also relevant, in praise of simple text:

Uh, my most heavily used program is my favorite text editor, Kedit. To me, the most important view, at the most important level, computing and/or computer usage is just simple text, i.e., is still like old fashioned typing. So, I have 100+ macros I wrote for Kedit, and some of those help with typing TeX.

"Simple text" for computing? Yup. Early in my startup, I decided to go with Microsoft and Windows instead of Linux or other versions of Unix.

For the 100,000 lines of code (~24,000 programming language statements and the rest comments or blank lines) for my startup (a Web site), I wrote that with just Kedit. Once I tried to use Microsoft's Visual Studio, and for just the start on just a first program in Visual Basic .NET, I got a big directory of a lot of files I didn't understand. I could see I would need to invest a lot of time and energy into getting the software for my startup to run via Visual Studio and could see no important reason why I should make that investment. I've been happy with that decision: For Visual Basic .NET, I type that in via Kedit.

In praise of Visual Basic .NET:

I know; I know; according to a lot of people and industry norms, I'm supposed to use C, C++, C#, or other programming languages in the family of C and certainly nothing called basic. Well, as I recall, the original C documentation admitted that the syntax of C was "idiosyncratic". E.g., it appeared that

i = ++j+++++k++

was legal -- increase each of j and k by 1; add them; assign the result to i; then again increase each of them by 1. Once I tried this statement on two C compilers, and they didn't agree on the results! So, it seemed that the syntax was too "idiosyncratic" even for the compiler writers! That was enough to warn me to stay away from C, and mostly I've been successful at that!

Then much of what I like and want from Microsoft is their .NET software and especially their documentation. As far as I can tell Visual Basic .NET (VB.NET) is a perfectly good way to make full or nearly so use of .NET and the CLR (common language runtime or some such), exploit their documentation, etc. And with basic I get traditional programming language syntax. To me, that was enough evidence -- decision made. Problem solved. TODO list item checked off.

Yup, at one point my VB.NET calls some C code, right, LINPACK -- apparently the way to do that is to use "platform invoke", and I did and it works fine. I'm still happy as a clam. So, right, I type in my VB.NET code with just Kedit -- been thrilled! VB.NET and Kedit -- happy as a clam!

For TeX, I type that in via Kedit. For email, Kedit. For forum posts, usually Kedit. For working with collections of files in the Windows file system NTFS (abbreviates maybe New Technology File System), Kedit. For my log of food, exercise, sleep, ..., Kedit. Recipes, sure, Kedit. Shopping lists, Kedit. A very important file, my most important, of various facts, short notes, references, and links, right, Kedit. Generally I like to use just simple text, and, thus, Kedit for as much as possible.

For this thread and its

"Sile: A Modern Rewrite of TeX"

I looked at it and could make no sense out of what it was or what it was for. There was something about hyphenation in Turkish! Looks like I should stay with TeX!

Re: Sile: A Modern Rewrite of TeX

#110

Earlier quoted context omitted.

I'd like to know what a "better LaTeX" means, and how that would move the needle, given that the only things you can't easily do in modern (Xe)LaTeX are things that you shouldn't be using TeX itself for in the first place, but have other tools do so you can simply embed their output. Especially given the availability of WYSIWYG-esque editors with "one-click" compile buttons that run all the nonsense that we used to h…

I have a difficult time with this comment. everyone I know who uses Latex including myself is painfully aware of its shortcomings and fairly steep learning curve. maybe the graphical environments eliminate some of the pain around embedding images, or using wrapped figures. but there is no way they manage to get around the fundamental lack of composibility. that sinking feeling you get when you just add one more thing…

As someone who's written multilingual books with custom typesetting needs in it, the learning curve can definitely be steep, but as someone who's also written regular old papers in it, the learning curve is "use our template", and that's kind of it. The only real learning curve is how to write maths, as long as you don't fall in the trap of trying to make LaTeX do graphics. For the love of all that is sane, use the tools best suited for that job instead. For everything else tex.stackexchange.com already has at least three posts covering any "how do I..." you might ever have.

And as someone who's even written packages: ...you're going to end up needing low level TeX, and TeX is insane, don't try to write packages. It's a world of hurt. (But then most people will never need to write their own packages)

Can you talk more about what you mean with the lack of composibility? Or of course link to some page(s) that makes that point?

Post reply on HN