After developing the initial prototype you see in the webpage, I've since gone back to the drawing board. I'm working on developing a firmer foundation for issues like:
I still very much believe in the high-level philosophy, but Nota will look very different within ~6 months. In the meantime, the single coolest development in the document language space is Typst, which I encourage you to check out: https://typst.app/
Also: the next version of Nota will be written 99% in Rust :-)
Not sure the language you choose matters as much as making the API usable by a wide audience. Sure if performance is a real issue then rust makes more sense than JS but I’m not sure that’s going to be hugely meaningful in most use cases.
I’ve never been a fan of Latex despite writing some mammoth documents over the years. Latex always felt like a beast for academics not for business. Yet there’s often things I wanted to do consistently in Word etc. that have never been easy.
Styles can easily become a muddle. Having consistent numbering and bulleting is a pain and errors can easily creep in.
Tracking changes becomes a real problem when you get into many revisions and that often always ends up relying on a level of trust between parties to not override the tracking. I think there’s a killer app in just fixing this issue with a product that guarantees that guarantees all changes are properly shown from the start of a process to it being fully approved by all parties.
Businesses, lawyers etc would love that stuff. Heck if you sprinkle blockchain in you might even get easy funding but I think it’s more of a basic cryptography thing than a blockchain thing - at least it doesn’t need that level of complexity.
> Not sure the language you choose matters as much as making the API usable by a wide audience.
Fully agree with this, and having typeset my masters thesis and later my resume using LaTeX, I think that the “authoring experience” is definitely the place to focus on improving, LaTeX just takes too damn long to get something good.
If you’re interested in the “markup to document publishing” space, you might also be interested in the open-source report publishing tool I’m now working on, Evidence.dev (https://github.com/evidence-dev/evidence).
It’s similarly based on markdown, though uses code fences to execute code, HTML style tags for charts and components, and {…} for JavaScript, i.e.
---
title: Lorem Ipsum
description: dolor sit amet, consectetur adipiscing elit
---
```sql petal_vs_sepal
SELECT
petal_length,
sepal_length
FROM iris_dataset_table
ORDER BY 1 DESC
```
<ScatterPlot
title="Petal vs Sepal Length"
data={petal_vs_sepal}
x=petal_length
y=sepal_length
/>
The longest petal in the dataset is {petal_vs_sepal[0].petal_length}.
Our design philosophy here is that the rendered documents should be beautiful by default, but highly configurable so you can get pixel perfect results.
We’re also aiming for first class output options for desktop, mobile, PDF and image export.
I always disliked that it was so difficult to interact with Word if you wanted to create automated documents. Instead I'd love it if there was a developer-first experience to create standardised documents from nice looking participation certificates, invoices, memos, documentation up to multi-tome histories.
As an academic, 99% of my time is spent doing two things:
1. Writing statistical computations using a language like R or python.
2. Writing English text.
The most important thing about a document language is that it should prioritize those things. For example, here's why Rmarkdown/Quarto is better than TeX. A TeX document starts:
---
title: "Natural selection in the Health and Retirement Study"
author: "XXX"
abstract: |
I investigate natural selection on polygenic scores
in the contemporary US, using the Health and Retirement
Study. Results
partially support the economic theory of fertility as
an explanation for natural selection: among both white
and black respondents,
scores which correlate negatively (positively) with education are
selected for (against). Selection coefficients are
larger among low-income
and unmarried parents, but not among younger parents or those with less
education. I also estimate effect sizes corrected for noise in the
polygenic scores.
date: "September 2023"
You are comparing apples and oranges, at least a bit. The latex equivalent is
\documentclass{article}
\title{Natural selection in the Health and Retirement Study}
\author{XXX}
\date{\today}
\begin{document}
\begin{abstract}
I investigate natural selection on polygenic scores
in the contemporary US, using the Health and Retirement
Study. Results
partially support the economic theory of fertility as
an explanation for natural selection: among both white
and black respondents,
scores which correlate negatively (positively) with education are
selected for (against). Selection coefficients are
larger among low-income
and unmarried parents, but not among younger parents or those with less
education. I also estimate effect sizes corrected for noise in the
polygenic scores.
\end{abstract}
...
\end{document}
Everything else you have there in your preamble is about either adding capabilities or changing formatting, you don't show how that is achieved in the other markdown.
I think I get your point, but in practice that part doesn't really get in the way, and if you are doing the same thing over and over (e.g. for the same publication) it's just a template anyway.
I don't love Tex/Latex, but most of the other markdown comparisons that emphasize "it's simpler" are because they can't do as much. Which is fine until you need some of that capability.
I don't get the problem. If 99% of your documents need the same packages and formatting, then all you need to do in LaTeX is create a template (eg via Yasnippet in Emacs) or dump it all in a LaTeX class file and then import it in your frontmatter, and Bob's your uncle. There are many frustrating things about LaTeX but I don't see how this is one of them.
\documentclass{article}
\title{Natural selection in the Health and Retirement Study}
\author{XXX}
\date{September 2023}
\begin{document}
\maketitle
\begin{abstract}
I investigate natural selection on polygenic scores in the contemporary US, using the Health and Retirement Study.
Results partially support the economic theory of fertility as an explanation for natural selection: among both white and black respondents, scores which correlate negatively (positively) with education are selected for (against).
Selection coefficients are larger among low-income and unmarried parents, but not among younger parents or those with less education.
I also estimate effect sizes corrected for noise in the polygenic scores.
\end{abstract}
\end{document}
Makes me wonder if Nota did work with Rust, then we could move the dependencies into a cargo.toml file and compile our documents. That would enable declarative macros for document generation at compile time as well as interactive rust code inside your document at reading time. Plus you could refer to the dependencies by their package name like amsmath::line or something
It would be interesting to see if Nota could solve one problem that TeX and LaTeX, while theoretically capable, don't really solve in practice. Namely, the ease of styling according to dumb external requirements. Just to give you several examples:
* Very tight, but very loaded layouts like A0 conference posters
* Apply a national standard, such as, for example, post-Soviet GOST documentation styling standards
* All combinatorial explosion of bibliography styling requirements in different international traditions
* Make the documents look like a default style in so and so MS Word version
* Precise positioning of one picture upon another, or text upon a picture for quickfixes in the papers
* Be able to consciously tweak any of the above
The problem with tex universe solutions here is while technically all of the above is possible, in practice it requires some black magic far deeper than a lay person (even with a scientific degree) wishes to dive into.
Wow, Nota looks good. I created something similar I call "Literate Markdown"[1], a play on Knuth's "Literate programming" concept. My focus from the beginning was interleaving computation with explaination. It's been a lot of fun to work with for the last few months, for example to explore ideas around SVG animation[2] or flesh out a novel datastructure/algorithm[3]. Also, its about 500 lines of legible node code that is the entire server and markdown processor with very few dependencies, no transitive dependencies and it does not require a compilation step. By default the server allows no 3rd party resources, or cookies, of any kind because why not. It's MIT licensed on github. I want to move it to an organization repo instead of my personal repo and clean up the repo in the process, which is happening today.
Curiously, all these problems, and more, have been reasonably solved in Org Mode. Sadly, too few people know about it because too few people use Emacs.
Can you add a subheading in an Org mode document, then pop out of that subsection to get back to the previous heading? E.g.:
* Foobar
Foobars are great.
** Warning
Foobars are not to be used with Booms.
Foobars are great for reading, writing, and flying. This text is outside the Warning subsection.
If you want another data point, I made my own markup language a while back that aims for markdown-like simplicity while making it easy to define simple macros and operators: http://breuleux.github.io/quaint/
It's pretty extensive. I still use it for my own writing, although I'm probably the only one.
Do you have an example of a document where it’s special features are more heavily used? Most of the posts I saw were basically just paragraphs and italicized sections.
You should definitely look more into restructured text btw. It lets you build documents for many different formats, it has a nice way to reference sections of documents, add code support, and seems to have all the basic features you need. It is very similar to markdown but writing something in restructured text means you can output in just about any document format you need (its much better than markdown or html, imo.)
Your question about content and computation is difficult. When I was writing docs for my side project I would have liked to have done something similar to having an interpreter run in the page itself and have interactive code you can play with. But such an approach wasn't quite practical (ive seen some top-tier docs do this though!.) Though I ended up writing all my code examples in such a way that they're tested in the unittests. So I at least know if anything breaks.
I really don't like Nota, but you get my upvote because:
1. Typst is amazing and
2. you are open to criticism and are looking to redesign it, and I am hopeful you'll create something good
While LaTeX is cool, and I use it extensively, I personally feel that it has not adapted quickly to various use cases. It is not _easy_ to compile into different formats for consumption, and sometimes the layout issues are quite hard to debug. Efforts such as these, even if they do not take off, might give the LaTeX community enough to think about what to focus on for improvement...
> - How do different syntaxes make different document tasks easy, hard, or impossible?
That's a good idea, would be nice to optimize that instead of sticking to the poor decision of markdown to double asterisks for the more common bold formatting while also wasting another _ symbol in the process
I'm also curious. As always for the arXiv there is latex source code for the paper available at the "Other formats" link, and I'm having a hard time telling if its been auto-generated from Nota, but I presume it has given the visual similarity.
Rust makes tremendous sense for this and I really like your borrowing syntax in Nota. Keep it up. This reminds me of MDX, another project I find inspiring and use a lot
> There are two main mediums for digital documents: PDFs and web pages. PDFs were designed to mirror physical documents, so they impose the real-world constraints of paper: page breaks, fixed width, and immutable styling. Web pages, by contrast, provides an essential dynamism. Web pages are undeniably the future of digital documents.
I actually don't agree with this. I think _not_ having "essential dynamism" where it's not needed is actually a feature, not a bug.
OK but then what is the thing in the middle, between documents and applications?
There are fantastic, beautiful interactive experiences (for lack of a better word) that are obviously not documents (they can't be represented on paper, there is code running) but they're not really applications, either (they are fully offline, self-contained, state that's only evident on the page).
This is what I think the future of textbooks and presentations should be. But I think part of the problem is that not only do we not have tools geared toward creating them, we don't even have a name for these things. If we say "document", they flunk the pdf test. If we say "web application", they are lumped into the same lumbering category as office docs and enterprise software.
Maybe Nota is a step in the right direction. But it'd be an even better step if it didn't call itself "21st century documents", if for no other reason than to defend against the valid criticism you levied against it.
Reputable scientific journals now post videos online alongside their articles. Interactivity is even better for understanding. But permanence is an issue I suppose.
There are some genuine benefits that come along with. I mean, if I could have auto expand inline footnotes/references in a document, I'd be a happy camper.
I think some basic dynamism is still necessary to make reading pdf on small screens comfortable (e.g. mobile). When on mobile, I vastly prefer reading webpages over pdf because most reasonable webpage should be able to fit mobile screen.
Sadly, if you have an iPhone I don't think you can easily read Nota docs currently. The article that introduces Nota [1] has only been tested on Chrome. I tried multiple browsers on iOS to no avail (likely since they all use the same underlying rendering engine).
PDFs constrain information by limiting the way it can be reproduced digitally. There is no such thing as "just" copy/pasting from a PDF - weird errors abound. The text has to be extensively reformatted or run through special software.
A format is needed that encodes information visually and digitally. The digital layer doesn't have to be visible by default, just accessible when needed.
>I actually don't agree with this. I think _not_ having "essential dynamism" where it's not needed is actually a feature, not a bug.
Yeah.
To author's surprise, Adobe's PDF spec supports JavaScript execution[1]. And interactive 3D graphics [2][3]. Not to mention, audio and video [4].
And "Liquid Mode" for responsive-layout PDF documents [5].
Of course, these "features" were considered bugs by the ISO PDF/A spec (archival, i.e. future-proof), so they were all stripped out [6].
The point being: sometimes a document should be a document.
As for science papers: LaTeX is written by humans, for humans. Custom latex commands and packages allow one to write a plaintext document that is as easily read as the paper it generates.
Which is great for accessibility, among other things.
The static issue also permeates to webpages and other formats though. Although this is now just yet another competing method for documentation or creation, the restrictions caused by using TeX or LaTeX over more dynamic approaches are not insignificant.
One unfortunate problem is that nobody bothered setting the measure for legibility. On my display the text block is far far too wide. Cf. https://en.wikipedia.org/wiki/Line_length (while we're talking about typography, the fonts for body copy and code are mismatched in size in a distracting way)
As far as formulas/notation is concerned, the notation used in this paper is targeted only at experts in theoretical computer science, approximately the level of advanced grad students or above, who also happen to be pretty familiar with Rust and C++. The gimmicky popups are probably not meaningfully helpful for such an audience, and in my opinion don't really make the notation any more accessible to people without the extremely steep prerequisite expertise (e.g. I don't think this paper is going to be at all accessible to the vast majority of working programmers or computer science undergraduate students).
If you really want to make the paper more accessible, it would be better to focus on reducing the reliance on formulas, reducing the amount of jargon involved, and explaining the concepts and techniques using plain English targeted at a broader audience, rather than trying to add extra colors, click targets, or popups. (A research paper may alternately want to just target experts; that can also be fine. Even for experts this paper is pretty dense though.)
It is needed. I hate reading pdfs on my 24" or 32" monitor. I hate reading them on my Phone. The main thing that my father complained about when switching from Blackberry to iPhone, was missing PDF reflow feature. Basically the only screen where I find pdfs comfortable to read, is on the 12.9" iPad, and only if the author has the same font-size preferences as me.
* More in the space of LaTeX than Markdown (but with elements of each).
* Written in JavaScript (so lots of of people can contribute in a language they already know).
* MIT license.
Nice! I don't know that I have an immediate use for it today, but this looks super nifty. If I did want to write something that needed some LaTeX-y features, and wasn't aiming for publication in a place that required it, I'd give Nota a shot. While I think Knuth is basically a demigod, it's not like he descended from on high, gave us TeX, and said "thou shalt never try anything new ever again".
TeX was definitely groundbreaking, but I consider it a product of its time. Far too much cleverness in macro expansions and weaving tricks to keep memory usage in check for what are now laughable limits.
Missing far too many niceties in comparison to modern languages with more guardrails to protect yourself from silly mistakes. The only way I can write Latex is to heavily rely upon \input{} segments to keep isolated blocks in case I break something through a missed escape.
I keep yearning for a modern take, but it feels like we are stuck in a local optimum from which there is no escape. New platform has to fight with the decades of accumulated inertia and packages which exist in Tex.
There are plenty of these markup languages. The reason none of them really challenge tex/latex in its own space, is that they don't aim to do what tex/latex does.
Latex is "typographically-complete". Markdown and friends are explicitly not. HTML+CSS is. But what latex has is a reasonable enough syntax that a human can write it by hand, unlike HTML+CSS. Moreover, the syntax, though clunky [1] is designed, as much as possible, to not interfere with the content that the human is writing.
For instance, Latex uses curly brackets {} for macro arguments, because they are least used brackets for content. So when you are reading a latex source, you know that () and [] are content, and only {} are ambiguous [2]. Nota, uses a mix of all three brackets for its syntax, causing additional pain for the person reading/writing the source.
The replacement for TeX/latex is never going to a simpler language. It is going to a language just as complex as latex. But it can definitely be cleaned up and sped up compared to latex. IMHO, somebody should write tex from scratch, improve it's syntax but otherwise keep it largely unchanged. Basically, any plain latex source using some of the popular packages should continue to compile and give the same output. That is the only reasonable way out.
[1] A typographically-complete language will never have a non-clunky syntax.
[2] Escaped brackets \{1,2,3 \} are literal curly brackets. Personally, I only use them for mathematical sets and have defined a macro \set, so in my documents {} are 99% not ambiguous.
> I keep yearning for a modern take, but it feels like we are stuck in a local optimum from which there is no escape. New platform has to fight with the decades of accumulated inertia and packages which exist in Tex.
I believe the issue is that the better-than-LaTeX language needs to be not just better, but so much better that all the tooling and extensions for LaTeX are ported to it. Before this, it won’t be better than LaTeX. So it’s a kind of a chicken-and-egg issue.
The problem with any new initiative in this space is that it enters a field that is more than well populated. It doesn't matter if existing solutions are less than perfect.
Its like walking into a historic European city that has architecture going back millennia and arguing for a great new building design. Greenfield space is scarce and people will not just demolish old structures to try something new. They need to sense overwhelming advantage.
The analogy gives some hints as to what needs to happen for a new approach to take hold. In building construction, massively better use of space was one example: For better or worse, use of steel and reinforced concrete opened the vertical dimension and the rest is history.
Is there such an unexplored dimension that could entice people into yet another document format to "improve" on ascii, restructuredText, wikitext, markdown, tex/latex, asciidoc, html etc. etc.?
The stock answer is some sort of semantic hypertext infrastructure. The original vision is still unfulfilled. If we assume that the walled gardens of today are just a bad nightmare that will pass away, in a re-decentralized web one would need modern, user-friendly and empowering document writing infrastructure.
But there might be other dimensions that would elevate document writing and sharing to new heights. The beauty of innovation is that it is not bound by conventional rules and pre-existing wisdom.
If you want a decentralized web, a "Userweb" (maybe to parallel a bit Usenet), in my view you need a BitTorrent-like protocol.
You need efficient documents formats, which means formats that don't try to do everything, which means that you have to segregate different document types in different files - e.g. tables in some standard spreadsheet format - in contrast to HTML that tries to do tables, graphic (SVG), etc. on its own.
Separating each thing in their own file lets the user choose which programs they want to view/manipulate documents (rather that the one-size-fits-all browser), help with distribution across the network, and help with low storage/low bandwidth situations (or do more with the hardware we have right now).
So from my perspective, the answer is negative: there's nothing new to invent. Specialize and refine what was already invented.
If you follow the links, I think https://willcrichton.net/nota/ makes a compelling argument for the benefits of Nota at least in the niche of its intended use-case: making programming language academic papers more understandable.
As mentioned in another comment, rendering to high-quality PDF is an obvious need/question: can it do that?
(Perhaps) better would be rendering to LaTeX for compatibility with existing system.
Basically this is markup + code (Javascript), which is a combination targeted by MDX. The last time someone mentioned this, the author said Nota is geared towards documentation, while MDX is geared towards web sites: https://news.ycombinator.com/item?id=31349579
If that is so, I think someone needs to wrap Nota into a product for it to take off. Because while the results look great, fiddling with node.js to build a document is too much work -- it's like Latex all over again. Most people will prefer to use Notion or a word processor.
LaTeX, or more generally, the TeX family, never went away. It's still the go-to toolkit for writing journal papers in most of the STEM disciplines.
Moreover, Nota is not a direct competitor to the TeX family because Nota generates something for web browsers to read, whereas xxxTeX generates something for PDF readers to read. (And yes, I know xxxTeX can generate other output formats but most people use it to generate PDF.)
The fact that Nota comes with a default style (some kind of article style) already puts it in a completely different league than MDX. MDX is ready, willing, and able to use whatever React/Vue/etc framework you use, but that means it doesn't come with any opinions out of the box.
Nota feels to me like it could be plugged in to a static site generator. Except then you have to get the two to cooperate. Still, I think that's an achievable hope for someone a little more dedicated than I am.
Yeah this looks like a sensible extension to Markdown in a way I quite like the look of. Might be worth spending some time plugging it into Nikola (which does one thing I like really well - let's me blog as iPython notebooks, but that's not always appropriate).
Why do we need a language that creates a text page by compiling to JS? the same set of goals are handled by AsciiDoc. Real publishers (eg Oreilly) use AsciiDoc as their input format to create books and websites.
I can second AsciiDoc. It hits the sweet spot between Markdown (arguably more suited for short-ish content) and LaTeX (full-blown academic papers with citations, formulas, etc.).
Have been using AsciiDoc for the past few years and loving it, only falling back to Markdown on places where AsciiDoc is not (yet?) available. GitHub and GitLab, for example, supports rendering AsciiDoc. PyPI unfortunately has not supported it, but more seem to be looking into it [1], which is great.
asciidoc is my favourite too, thanks to Asciidoctor. I agree, asciidoc hits the sweet spots as a format. Been frustrated by the tooling lately though. I can see the huge effort put into Asciidoctor, and am thankful for it, but there are still big downsides i.e. no semantic html 5 output, difficult (or at least more difficult than necessary) integration with image generators, heavyweight (only ruby dependency on my entire machine). I imagine this just needs more time and resources put to it, as all these issues (except the ruby one) are open on GitHub.
Readit News
After developing the initial prototype you see in the webpage, I've since gone back to the drawing board. I'm working on developing a firmer foundation for issues like:
- How do you interleave content and computation? See: https://arxiv.org/abs/2310.04368
- How do different syntaxes make different document tasks easy, hard, or impossible? See: https://github.com/cognitive-engineering-lab/doclang-benchma...
I still very much believe in the high-level philosophy, but Nota will look very different within ~6 months. In the meantime, the single coolest development in the document language space is Typst, which I encourage you to check out: https://typst.app/
Also: the next version of Nota will be written 99% in Rust :-)
Not sure the language you choose matters as much as making the API usable by a wide audience. Sure if performance is a real issue then rust makes more sense than JS but I’m not sure that’s going to be hugely meaningful in most use cases.
I’ve never been a fan of Latex despite writing some mammoth documents over the years. Latex always felt like a beast for academics not for business. Yet there’s often things I wanted to do consistently in Word etc. that have never been easy.
Styles can easily become a muddle. Having consistent numbering and bulleting is a pain and errors can easily creep in.
Tracking changes becomes a real problem when you get into many revisions and that often always ends up relying on a level of trust between parties to not override the tracking. I think there’s a killer app in just fixing this issue with a product that guarantees that guarantees all changes are properly shown from the start of a process to it being fully approved by all parties. Businesses, lawyers etc would love that stuff. Heck if you sprinkle blockchain in you might even get easy funding but I think it’s more of a basic cryptography thing than a blockchain thing - at least it doesn’t need that level of complexity.
Fully agree with this, and having typeset my masters thesis and later my resume using LaTeX, I think that the “authoring experience” is definitely the place to focus on improving, LaTeX just takes too damn long to get something good.
If you’re interested in the “markup to document publishing” space, you might also be interested in the open-source report publishing tool I’m now working on, Evidence.dev (https://github.com/evidence-dev/evidence).
It’s similarly based on markdown, though uses code fences to execute code, HTML style tags for charts and components, and {…} for JavaScript, i.e.
Our design philosophy here is that the rendered documents should be beautiful by default, but highly configurable so you can get pixel perfect results.We’re also aiming for first class output options for desktop, mobile, PDF and image export.
Previous HN discussion:
https://news.ycombinator.com/item?id=28304781 - 91 comments
https://news.ycombinator.com/item?id=35645464 - 97 comments
As an academic, 99% of my time is spent doing two things:
1. Writing statistical computations using a language like R or python.
2. Writing English text.
The most important thing about a document language is that it should prioritize those things. For example, here's why Rmarkdown/Quarto is better than TeX. A TeX document starts:
A quarto document starts: You see the difference in emphasis.I think I get your point, but in practice that part doesn't really get in the way, and if you are doing the same thing over and over (e.g. for the same publication) it's just a template anyway.
I don't love Tex/Latex, but most of the other markdown comparisons that emphasize "it's simpler" are because they can't do as much. Which is fine until you need some of that capability.
My latex docs look nothing like that because I put all the boiler plate in a .sty file.
1 - https://simpatico.io/lit Literate markdown reference.
2 - https://simpatico.io/svg svg animation using object to elt scattering and a RAF pump
3 - https://simpatico.io/stree3 A navigable n-arry representation of diverging, deterministic state
It's pretty extensive. I still use it for my own writing, although I'm probably the only one.
Your question about content and computation is difficult. When I was writing docs for my side project I would have liked to have done something similar to having an interpreter run in the page itself and have interactive code you can play with. But such an approach wasn't quite practical (ive seen some top-tier docs do this though!.) Though I ended up writing all my code examples in such a way that they're tested in the unittests. So I at least know if anything breaks.
Good luck with the project
While LaTeX is cool, and I use it extensively, I personally feel that it has not adapted quickly to various use cases. It is not _easy_ to compile into different formats for consumption, and sometimes the layout issues are quite hard to debug. Efforts such as these, even if they do not take off, might give the LaTeX community enough to think about what to focus on for improvement...
That's a good idea, would be nice to optimize that instead of sticking to the poor decision of markdown to double asterisks for the more common bold formatting while also wasting another _ symbol in the process
Did you use Nota to write this paper?
Cringed. ty
I actually don't agree with this. I think _not_ having "essential dynamism" where it's not needed is actually a feature, not a bug.
I couldn't agree more. Dynamism is great for web _apps_, but it's the last thing I want in a document
There are fantastic, beautiful interactive experiences (for lack of a better word) that are obviously not documents (they can't be represented on paper, there is code running) but they're not really applications, either (they are fully offline, self-contained, state that's only evident on the page).
But they are, universally: dynamic.
Examples: - https://ciechanow.ski/mechanical-watch/ - http://worrydream.com/TenBrighterIdeas/ - even : https://neal.fun/space-elevator/
This is what I think the future of textbooks and presentations should be. But I think part of the problem is that not only do we not have tools geared toward creating them, we don't even have a name for these things. If we say "document", they flunk the pdf test. If we say "web application", they are lumped into the same lumbering category as office docs and enterprise software.
Maybe Nota is a step in the right direction. But it'd be an even better step if it didn't call itself "21st century documents", if for no other reason than to defend against the valid criticism you levied against it.
Reputable scientific journals now post videos online alongside their articles. Interactivity is even better for understanding. But permanence is an issue I suppose.
[1] https://willcrichton.net/nota/
A format is needed that encodes information visually and digitally. The digital layer doesn't have to be visible by default, just accessible when needed.
Yeah.
To author's surprise, Adobe's PDF spec supports JavaScript execution[1]. And interactive 3D graphics [2][3]. Not to mention, audio and video [4].
And "Liquid Mode" for responsive-layout PDF documents [5].
Of course, these "features" were considered bugs by the ISO PDF/A spec (archival, i.e. future-proof), so they were all stripped out [6].
The point being: sometimes a document should be a document.
As for science papers: LaTeX is written by humans, for humans. Custom latex commands and packages allow one to write a plaintext document that is as easily read as the paper it generates.
Which is great for accessibility, among other things.
[1] https://helpx.adobe.com/acrobat/using/applying-actions-scrip...
[2] https://www.youtube.com/watch?v=PKfyFt3zT5A
[3] https://www.youtube.com/watch?v=vW5-1LVtd9U
[4] https://helpx.adobe.com/acrobat/using/rich-media.html
[5] https://www.adobe.com/acrobat/hub/what-is-adobe-liquid-mode....
[6] https://en.wikipedia.org/wiki/PDF/A
I think that there's interesting open space for dynamic documents, but you need some good examples of people using it with taste.
One unfortunate problem is that nobody bothered setting the measure for legibility. On my display the text block is far far too wide. Cf. https://en.wikipedia.org/wiki/Line_length (while we're talking about typography, the fonts for body copy and code are mismatched in size in a distracting way)
As far as formulas/notation is concerned, the notation used in this paper is targeted only at experts in theoretical computer science, approximately the level of advanced grad students or above, who also happen to be pretty familiar with Rust and C++. The gimmicky popups are probably not meaningfully helpful for such an audience, and in my opinion don't really make the notation any more accessible to people without the extremely steep prerequisite expertise (e.g. I don't think this paper is going to be at all accessible to the vast majority of working programmers or computer science undergraduate students).
If you really want to make the paper more accessible, it would be better to focus on reducing the reliance on formulas, reducing the amount of jargon involved, and explaining the concepts and techniques using plain English targeted at a broader audience, rather than trying to add extra colors, click targets, or popups. (A research paper may alternately want to just target experts; that can also be fine. Even for experts this paper is pretty dense though.)
That can also really mess with screen readers and other accessibility features.
There's a reason PDF/A spec forbids scripts in any PDF documents that are expected to be available in the future.
[1] https://en.wikipedia.org/wiki/PDF/A
If we want documents that work well on all screens, then we use EPUB.
Deleted Comment
It used to be. But not anymore. Web browser + js are too bloat for any serious documentation usage.
In theory a PDF is a static document that should display the same in any PDF reader.
Every time I can choose between PDF and EPUB, I choose EPUB.
* More in the space of LaTeX than Markdown (but with elements of each).
* Written in JavaScript (so lots of of people can contribute in a language they already know).
* MIT license.
Nice! I don't know that I have an immediate use for it today, but this looks super nifty. If I did want to write something that needed some LaTeX-y features, and wasn't aiming for publication in a place that required it, I'd give Nota a shot. While I think Knuth is basically a demigod, it's not like he descended from on high, gave us TeX, and said "thou shalt never try anything new ever again".
Missing far too many niceties in comparison to modern languages with more guardrails to protect yourself from silly mistakes. The only way I can write Latex is to heavily rely upon \input{} segments to keep isolated blocks in case I break something through a missed escape.
I keep yearning for a modern take, but it feels like we are stuck in a local optimum from which there is no escape. New platform has to fight with the decades of accumulated inertia and packages which exist in Tex.
Latex is "typographically-complete". Markdown and friends are explicitly not. HTML+CSS is. But what latex has is a reasonable enough syntax that a human can write it by hand, unlike HTML+CSS. Moreover, the syntax, though clunky [1] is designed, as much as possible, to not interfere with the content that the human is writing.
For instance, Latex uses curly brackets {} for macro arguments, because they are least used brackets for content. So when you are reading a latex source, you know that () and [] are content, and only {} are ambiguous [2]. Nota, uses a mix of all three brackets for its syntax, causing additional pain for the person reading/writing the source.
The replacement for TeX/latex is never going to a simpler language. It is going to a language just as complex as latex. But it can definitely be cleaned up and sped up compared to latex. IMHO, somebody should write tex from scratch, improve it's syntax but otherwise keep it largely unchanged. Basically, any plain latex source using some of the popular packages should continue to compile and give the same output. That is the only reasonable way out.
[1] A typographically-complete language will never have a non-clunky syntax.
[2] Escaped brackets \{1,2,3 \} are literal curly brackets. Personally, I only use them for mathematical sets and have defined a macro \set, so in my documents {} are 99% not ambiguous.
I believe the issue is that the better-than-LaTeX language needs to be not just better, but so much better that all the tooling and extensions for LaTeX are ported to it. Before this, it won’t be better than LaTeX. So it’s a kind of a chicken-and-egg issue.
The correct way to do it is:
Your favorite markup -> pandoc script and includes -> Latex
- https://pandoc.org/
- https://quarto.org/
- https://markdoc.dev/
- https://mdxjs.com/
- https://typst.app/
Its like walking into a historic European city that has architecture going back millennia and arguing for a great new building design. Greenfield space is scarce and people will not just demolish old structures to try something new. They need to sense overwhelming advantage.
The analogy gives some hints as to what needs to happen for a new approach to take hold. In building construction, massively better use of space was one example: For better or worse, use of steel and reinforced concrete opened the vertical dimension and the rest is history.
Is there such an unexplored dimension that could entice people into yet another document format to "improve" on ascii, restructuredText, wikitext, markdown, tex/latex, asciidoc, html etc. etc.?
The stock answer is some sort of semantic hypertext infrastructure. The original vision is still unfulfilled. If we assume that the walled gardens of today are just a bad nightmare that will pass away, in a re-decentralized web one would need modern, user-friendly and empowering document writing infrastructure.
But there might be other dimensions that would elevate document writing and sharing to new heights. The beauty of innovation is that it is not bound by conventional rules and pre-existing wisdom.
You need efficient documents formats, which means formats that don't try to do everything, which means that you have to segregate different document types in different files - e.g. tables in some standard spreadsheet format - in contrast to HTML that tries to do tables, graphic (SVG), etc. on its own.
Separating each thing in their own file lets the user choose which programs they want to view/manipulate documents (rather that the one-size-fits-all browser), help with distribution across the network, and help with low storage/low bandwidth situations (or do more with the hardware we have right now).
So from my perspective, the answer is negative: there's nothing new to invent. Specialize and refine what was already invented.
As mentioned in another comment, rendering to high-quality PDF is an obvious need/question: can it do that?
(Perhaps) better would be rendering to LaTeX for compatibility with existing system.
If that is so, I think someone needs to wrap Nota into a product for it to take off. Because while the results look great, fiddling with node.js to build a document is too much work -- it's like Latex all over again. Most people will prefer to use Notion or a word processor.
LaTeX, or more generally, the TeX family, never went away. It's still the go-to toolkit for writing journal papers in most of the STEM disciplines.
Moreover, Nota is not a direct competitor to the TeX family because Nota generates something for web browsers to read, whereas xxxTeX generates something for PDF readers to read. (And yes, I know xxxTeX can generate other output formats but most people use it to generate PDF.)
Nota feels to me like it could be plugged in to a static site generator. Except then you have to get the two to cooperate. Still, I think that's an achievable hope for someone a little more dedicated than I am.
Have been using AsciiDoc for the past few years and loving it, only falling back to Markdown on places where AsciiDoc is not (yet?) available. GitHub and GitLab, for example, supports rendering AsciiDoc. PyPI unfortunately has not supported it, but more seem to be looking into it [1], which is great.
--- [1] https://github.com/pypa/readme_renderer/issues/205