4 ms·

> the single most cost effective way to speed up math and physics research by a philanthropist would be taking a few million dollars and hiring a team of develo

> the single most cost effective way to speed up math and physics research by a philanthropist would be taking a few million dollars and hiring a team of developers to bring LaTeX into the 21st century This might be a niche opinion, but I think Rmarkdown & Jupyter get us a non-negligible portion of the way there. You can use LaTeX chunks when you need equations, markdown syntax when you need formatting (IIRC this is a pain with LaTeX), and executed code chunks to (e.g.) create and insert a graph. (One advantage of Rmarkdown is that you can have as many languages in a single document as knitr can handle, each its own chunk [0]). Neither is all the way there yet, but, as Yihui Xie puts it [1]: > I have a dream that one day all students and researchers will forget what "formatting a paper" even means. I have a dream that one day journals and grad schools no longer have style guides. I have a dream that one day no missing $ is inserted, and \hbox is never overfull. [0]: https://bookdown.org/yihui/rmarkdown/language-engines.html https://bookdown.org/yihui/rmarkdown/language-engines.html [1] https://twitter.com/xieyihui/status/1022873179532996609 https://twitter.com/xieyihui/status/1022873179532996609

j-pb 6y ago
bUt MuH TypESeTtInG! I think you're absolutely right. But people seem to value a specific flavour of aesthetics over easy to understand and reproducible research. I guess that's maybe partly caused by the publication pressure, once you start to pump out papers for pumping out papers sake, there is little incentive to go beyond the superficial.
- derefr 6y ago
  I have a dream that one day we'll get a language for typesetting that isn't a markup language. Rather, this language would be designed to come after writing, in the same way that flagship Desktop Publishing software (InDesign, Publisher) make the assumption that layout happens after writing. (Sure, you can write inside the layout software, but you're not supposed to. They're assuming e.g. a journalist–editor–layout–typesetter pipeline.) You'd have a "layout file" (written in the typesetting DSL) that has separate "non-typeset rich-text" files linked to it via file/URI references (just like Desktop Publishing apps do.) The person doing layout would never modify the linked source files; if they wanted to e.g. change certain character sequences into filligrees, that'd be something stored entirely as an annotation in the layout file, not as markup in the source file. In that world, scientists just write the "non-typeset rich text" (for which Rmarkdown / Jupyter would be a great fit); and then it's the job of science journals to produce the "layout + typesetting annotations." And hey, then journals would actually have a reason to exist! They would be to science as physical magazines are to journalism at this point: a place to find the articles you can already read online, but typeset much better.
  - abdullahkhalids 6y ago
    Its not as straightforward. Converting a document from one column to two, often means that some equations have to be intelligently broken up across lines. There have been times when I have defined new variables, so I would not constantly have to break the two column layout for long equations. Figure sizes are also a function of document fonts and size.
    - derefr 6y ago
      I'm not saying you shouldn't be able to modify the way the source appears, even going so far as saying "there should be a new variable here." I'm just saying that those modifications should live in the layout document, rather than in the source itself. Think of it like an archivist restoring a painting. First, they add a (removable) clear-resin barrier layer; and then they do restoration work on top of that barrier. In essence, rather than the paint they're adding becoming part of the painting, it instead becomes part of a "wrapper" for the painting, which can always be "unwrapped" back to the source. Except this analogy isn't perfect, because you can only override a painting point-by-point; whereas a layout document can "losslessly" cut a linked source up into chunks and put each chunk in a different place, repeat chunks, insert things between chunks, etc. A better analogy, actually, might be a DAW project. The input audio samples are immutable; the DAW project takes samples from the inputs, applies changes to those samples, and then sequences the results. And note that a large part of the point of this workflow (in desktop publishing, at least) is that the upstream can continue iterating on the linked document as the downstream lays it out. Those changes may break the downstream layout, but they usually don't, because the downstream layout has usually been defined by constraints. For example, in a newspaper article, if the source-text of the article gets more wordy, then up to a point, the layout engine just packs those same paragraphs tighter on the page it already decided they appear on, while keeping the paragraphs that appear on the next page spaced as before, and not allowing any lines from the paragraphs on page A to migrate to the flow-box on page B. But at a certain point, it switches strategies, moves an entire paragraph from A to B, and then relaxes the spacing of A back down. At that point, the layout may have been broken (because now B might be either too long to fit its flow-box, or unreadably tightly-spaced.) But that happens surprisingly rarely, compared to constraint-based reflow "just working" to absorb linked-document changes. (And note that either the writer or the layout designer can aid this process by inserting explicit page/section breaks that add weights to these constraints, to keep reflow from flapping lengths around.) ----- Note that everything I'm talking about is already how a very domain-specific kind of Desktop Publishing already works: "engraving", a.k.a. sheet-music publishing. The score itself (the thing that contains information that could be converted to MIDI) and the engraving details (the way to present the score to a human) are kept separate in most engraving-tool formats.
- michaelcampbell 6y ago
  > bUt MuH TypESeTtInG! I didn't read the rest of your post after this, because the only purpose of this is to inflame and troll.

j-pb 6y ago

bUt MuH TypESeTtInG! I think you're absolutely right. But people seem to value a specific flavour of aesthetics over easy to understand and reproducible research. I guess that's maybe partly caused by the publication pressure, once you start to pump out papers for pumping out papers sake, there is little incentive to go beyond the superficial.

derefr 6y ago
I have a dream that one day we'll get a language for typesetting that isn't a markup language. Rather, this language would be designed to come after writing, in the same way that flagship Desktop Publishing software (InDesign, Publisher) make the assumption that layout happens after writing. (Sure, you can write inside the layout software, but you're not supposed to. They're assuming e.g. a journalist–editor–layout–typesetter pipeline.) You'd have a "layout file" (written in the typesetting DSL) that has separate "non-typeset rich-text" files linked to it via file/URI references (just like Desktop Publishing apps do.) The person doing layout would never modify the linked source files; if they wanted to e.g. change certain character sequences into filligrees, that'd be something stored entirely as an annotation in the layout file, not as markup in the source file. In that world, scientists just write the "non-typeset rich text" (for which Rmarkdown / Jupyter would be a great fit); and then it's the job of science journals to produce the "layout + typesetting annotations." And hey, then journals would actually have a reason to exist! They would be to science as physical magazines are to journalism at this point: a place to find the articles you can already read online, but typeset much better.
- abdullahkhalids 6y ago
  Its not as straightforward. Converting a document from one column to two, often means that some equations have to be intelligently broken up across lines. There have been times when I have defined new variables, so I would not constantly have to break the two column layout for long equations. Figure sizes are also a function of document fonts and size.
  - derefr 6y ago
    I'm not saying you shouldn't be able to modify the way the source appears, even going so far as saying "there should be a new variable here." I'm just saying that those modifications should live in the layout document, rather than in the source itself. Think of it like an archivist restoring a painting. First, they add a (removable) clear-resin barrier layer; and then they do restoration work on top of that barrier. In essence, rather than the paint they're adding becoming part of the painting, it instead becomes part of a "wrapper" for the painting, which can always be "unwrapped" back to the source. Except this analogy isn't perfect, because you can only override a painting point-by-point; whereas a layout document can "losslessly" cut a linked source up into chunks and put each chunk in a different place, repeat chunks, insert things between chunks, etc. A better analogy, actually, might be a DAW project. The input audio samples are immutable; the DAW project takes samples from the inputs, applies changes to those samples, and then sequences the results. And note that a large part of the point of this workflow (in desktop publishing, at least) is that the upstream can continue iterating on the linked document as the downstream lays it out. Those changes may break the downstream layout, but they usually don't, because the downstream layout has usually been defined by constraints. For example, in a newspaper article, if the source-text of the article gets more wordy, then up to a point, the layout engine just packs those same paragraphs tighter on the page it already decided they appear on, while keeping the paragraphs that appear on the next page spaced as before, and not allowing any lines from the paragraphs on page A to migrate to the flow-box on page B. But at a certain point, it switches strategies, moves an entire paragraph from A to B, and then relaxes the spacing of A back down. At that point, the layout may have been broken (because now B might be either too long to fit its flow-box, or unreadably tightly-spaced.) But that happens surprisingly rarely, compared to constraint-based reflow "just working" to absorb linked-document changes. (And note that either the writer or the layout designer can aid this process by inserting explicit page/section breaks that add weights to these constraints, to keep reflow from flapping lengths around.) ----- Note that everything I'm talking about is already how a very domain-specific kind of Desktop Publishing already works: "engraving", a.k.a. sheet-music publishing. The score itself (the thing that contains information that could be converted to MIDI) and the engraving details (the way to present the score to a human) are kept separate in most engraving-tool formats.
michaelcampbell 6y ago
> bUt MuH TypESeTtInG! I didn't read the rest of your post after this, because the only purpose of this is to inflame and troll.