Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Typst's Math Mode Problem

laurmaedje.github.io

Post reply on HN
Print view View original

51–57 of 57 posts

Re: Typst's Math Mode Problem

#51

Post by lou1306 »

TimorousBestie wrote: post #44
lou1306 wrote: post #32

Earlier quoted context omitted.

I hate recurse to authority, but after a markup slash programming language has been written by Don Knuth and a macro system for it has been developed by Leslie Lamport, maybe one should take some notes so as to why things were done in a certain way?

I actually think Typst should ignore the design of TeX and LaTeX more—and especially the well-meaning advice of LaTeX veterans who have only ever known one way of typesetting. The situation reminds me of how Julia’s evolution was guided in some aspects by some opinionated and vocal {Python, R, MATLAB} developers who never had any intention of transitioning to Julia, whether or not their advice was implemented.

I was not implying they should make the same design choices, but there should be a deeper understanding of the underlying problems.

Case in point: backslashes and braces in TeX were there for a reason. You can say they make TeX code look ugly, and you would not be wrong. But when you throw them away without addressing the reason they were introduced, well, you end up with blog posts like this one.

Re: Typst's Math Mode Problem

#53

Post by adastra22 »

TimorousBestie wrote: post #44
lou1306 wrote: post #32

Earlier quoted context omitted.

I hate recurse to authority, but after a markup slash programming language has been written by Don Knuth and a macro system for it has been developed by Leslie Lamport, maybe one should take some notes so as to why things were done in a certain way?

I actually think Typst should ignore the design of TeX and LaTeX more—and especially the well-meaning advice of LaTeX veterans who have only ever known one way of typesetting. The situation reminds me of how Julia’s evolution was guided in some aspects by some opinionated and vocal {Python, R, MATLAB} developers who never had any intention of transitioning to Julia, whether or not their advice was implemented.

What are some examples of the Julia design issues you mention?

Re: Typst's Math Mode Problem

#54

Post by adastra22 »

ajkjk wrote: post #49
TimorousBestie wrote: post #44

Earlier quoted context omitted.

I actually think Typst should ignore the design of TeX and LaTeX more—and especially the well-meaning advice of LaTeX veterans who have only ever known one way of typesetting. The situation reminds me of how Julia’s evolution was guided in some aspects by some opinionated and vocal {Python, R, MATLAB} developers who never had any intention of transitioning to Julia, whether or not their advice was implemented.

agree, I'm fine with Typst throwing out the old ways and doing the new ones... just, do your research; do it right

The problem is what is “right” in the minds of people using the old thing is sometimes very biased.

Re: Typst's Math Mode Problem

#55

Post by BlackFingolfin »

adastra22 wrote: post #53
TimorousBestie wrote: post #44

Earlier quoted context omitted.

I actually think Typst should ignore the design of TeX and LaTeX more—and especially the well-meaning advice of LaTeX veterans who have only ever known one way of typesetting. The situation reminds me of how Julia’s evolution was guided in some aspects by some opinionated and vocal {Python, R, MATLAB} developers who never had any intention of transitioning to Julia, whether or not their advice was implemented.

What are some examples of the Julia design issues you mention?

For me one is that one can write `for i = 1:3` is one when `=` means assignment otherwise (at least `for i in 1:3` is available.

Re: Typst's Math Mode Problem

#56

Post by laurmaedje »

lou1306 wrote: post #51
TimorousBestie wrote: post #44

Earlier quoted context omitted.

I actually think Typst should ignore the design of TeX and LaTeX more—and especially the well-meaning advice of LaTeX veterans who have only ever known one way of typesetting. The situation reminds me of how Julia’s evolution was guided in some aspects by some opinionated and vocal {Python, R, MATLAB} developers who never had any intention of transitioning to Julia, whether or not their advice was implemented.

I was not implying they should make the same design choices, but there should be a deeper understanding of the underlying problems. Case in point: backslashes and braces in TeX were there for a reason. You can say they make TeX code look ugly, and you would not be wrong. But when you throw them away without addressing the reason they were introduced, well, you end up with blog posts like this one.

The backslashes are not really relevant to the problem discussed in the post. The ambiguity between symbols and argument-taking macros exists just the same in LaTeX. Consider:

    $ f_\abs{x} $
    $ f_\pi{x} $
LaTeX just happens to do what the post calls "runtime parsing" because LaTeX doesn't really distinguish between different compiler stages at all. If you look at a macro, you can't know whether it will eat up the following braced argument.

In fact, not using backslashes for symbols can actually give an _edge_ with this problem because it would allow distinguishing `pi` and `#abs` (option E in the post).

Re: Typst's Math Mode Problem

#57

Post by forgotpwd16 »

BlackFingolfin wrote: post #55
adastra22 wrote: post #53

Earlier quoted context omitted.

What are some examples of the Julia design issues you mention?

For me one is that one can write `for i = 1:3` is one when `=` means assignment otherwise (at least `for i in 1:3` is available.

This seems like a counter-example. The `=` was for time the only syntax (presumably taken by MATLAB--which in turn adapted it from IDL/Fortran--that initially Julia was heavily influenced from) with `in` (and `∈`) added afterwards (`in` being the only syntax used by the much more popular {Python, R}). Imo `=` alone was fine since as you say `=` means assignment, just within `for` it's an assignment applied iteratively. Opposite to that, `in` is also used as membership operator (`1 in [1, 2, 3]`) that is entirely different from its `for` role.
Post reply on HN