Hacker News new | ask | show | jobs
by wcrichton 976 days ago
Hi, Nota creator here. A high-level comment:

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 :-)

15 comments

Just my two cents -

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.

Surprised more legal docs aren’t tracked like git, with pull requests
A moment of imagining how that would influence the market value of certain skillsets should easily cure you from that surprise ;)

On the other hand, legal systems have effectively been doing the equivalent of git since basically forever. There have been very few law books written from the ground up. All other law authoring, be it by kings, priests, dictators or parliaments, was I the form of diffs to an existing codebase.

The Common Paper app[1], though not quite a git workflow, has always struck me as being pretty close to how an software engineer might approach contracts:

1. An immutable set of standard terms, with variable references.

2. A collection of cover page variables, that modify the standard terms by reference.

3. A structured negotiation workflow, where users "propose changes" to the cover page variables with automatic "diff-ing" (redlining).

It's not a product targeted to software engineers, but has always appealed to me as a way to sneak in some engineering best-practices into the world of lawyering :)

Full disclosure: I'm an employee

[1]: https://commonpaper.com/product/

Nisus Writer Pro [0] has been around for 40 years this year IIRC (IANANWP) and has a user base who can vouch for many of the features that HN readers want something to offer.

[0] https://nisus.com/pro

One of the interesting things that I discovered while working on some legal papers with a lawyer were that legal documents don't have copyright protection. Lawyers regularly copy and paste from other lawyers work. I suppose, that since legislators most often have backgrounds as lawyers, they legislated rules for themselves that are not the same as the rule the rest of us have to follow.

I am not a lawyer so I don't know that anything in the previous paragraph is true; it's just based on a recollection of something I was told once a long time ago.

> legal documents don't have copyright protection

1. That's an overstatement: For "original works of authorship," copyright happens automatically upon "fixation" in a "tangible medium of expression" (e.g., saving to a file, maybe even just typing). [0] And it doesn't take much "original ... authorship" to qualify for copyright protection.

2. Here's A hypothetical example: Alice drafts a contract from scratch as Version 1 and saves it to a file. It's copyrighted; on these facts, Alice owns the copyright. [0] Then Bob takes Alice's Version 1 and modifies it to create Version 1.1: Bob's "original" contributions to Version 1.1 are themselves protected by copyright, which Bob owns, bu with two caveats:

(a) Bob has no claim to copyright in Alice's Version 1; and

(b) Bob's own contributions to Version 1.1 won't be protected unless one or both of the following is true: (1) Bob had Alice's permission to base his "derivative work" on Alice's Version 1; [1] and/or (2) Bob's use of Version 1 qualified as "fair use" (a complicated question in itself). [2]

NOTES:

[0] https://www.law.cornell.edu/uscode/text/17/101; see also, e.g., https://www.adamsdrafting.com/the-contract-drafter-as-copyri...

[1] https://www.law.cornell.edu/uscode/text/17/103

[2] https://www.law.cornell.edu/uscode/text/17/107

Cause git ain’t user friendly enough for lawyers and they use word not a plain text editor which doesnt make it easy to see the diffs. But yes ;)
Style and substance separation is easy and should be a requirement. Legal is pure text "programming" and what I mean is that the style of the text has zero bearing on the judicial process.

The benefits of working at the proper level of abstraction compound. It enables tech like diffs and git, which then nicely solves a bunch of other problems as well. Using Word completely side-steps all those benefits. Sure, you get a few nice buttons, but that's literally it. You are trapped forever with no way forward.

This feels like actually programming in Word and manually highlighting comments to be green or something. It's a travesty IMO.

Of course this isn't and hasn't been true for quite some time. I'm the first to blast MS Word for being a total disaster (esp. templates, ie. style/substance separation, are bad) but it is no longer a locked-in platform. Even the docx format is only a zipped XML file. If you want, you can unpack the document file and put it into git. Thank you Open Document Foundation!

On top of that, all contemporary word processors I'm aware of have, of course, versioning with diffs. It is just different than git (or other programmer tools.) Just as you are using your tools of your trade and don't know much about MS Word, lawyers use their tools of their trade and don't know much about git. It's like saying that editing POs is superior to Trados, because for a programmer it is but a professional translator is going to tell you a different story.

(Of course, everybody everywhere should be using LaTeX for fine-looking documents in all circumstances. No argument here ;))

My point is not that. Sure, you can go from Word to OpenOffice. Great, now you manually highlight your code in that..

It’s a deeper thing. You can hack Word and related tools for coding and eventually it is acceptable I guess, but it’s starting from the wrong foundation.

This ladder will never reach the moon.

Word’s diffs are not “just different”. they are objectively inferior in many ways. I personally witness daily the travesty of government staff’s handling of information.

Word is a fancy digital typewriter and IMO it’s the wrong abstraction for this day and age and cultural issues are the only thing keeping us back. As always.

Edit: academic papers looking like they were written on a 19th century typewriter.. I don’t get this fascination with style, from scientists of all people. Lay down the info, provide the data. Kerning your fonts properly.. oh my god, I need to cool down. I am a hot headed type of guy, sorry about that.

This 100%. It does get interesting when you get into non-plaintext things that have to somehow integrate into plaintext systems (git managed codebases). We've kind of left it up to CMS systems to handle the non-plaintext bits but this leads to many more orthogonal process problems.

IMO, I think it really comes down to finding a universal mechanism for diffing and 3-way merging things that aren't plain text (document diffing). I think distributed version control can be universal (at least on a data level), how an application renders a meaningful diff for a specific task is incredibly subjective to the document type and task at hand. My point being that I completely agree that plaintext makes a whole lot of sense for programmers and pretty much nobody else. However, distributed version control does not have to be confined to plaintext, it's just tricky to see when all the version control systems we're familiar with are plaintext ones.

You are correct. But this is a culture issue. Culturally legal folk don’t see what they do as programming so they use different tools and work their processes their way. This is advantageous to outsiders who see through this! ;)
I think the main benefit would be to be able to represent yourself in court... otherwise there currently exist certain pratical and ethical hurdles to capitalizing into this, such as passing a bar exam (non-trivial), providing credentials, operating in the best interest of your client/society...etc.
I think markdown might be the solution here.
We used to have word processors that exposed mark up. I wrote immense amounts of documentation in Wordstar on 8 bit machines and it was definitely more efficient than the WYSIWYG word processors that came later and faster even when the newer ones were running on much faster hardware.

Something like Wordstar would be better than MarkDown.

Markdown isn’t detailed enough for legal stuff. Internal references, tables, complex section numbering require extensive post processing or simply don’t work. You quickly wind up with a lot of hidden magic that frustrates people used to word.

Last time I lost patience with doing Legal stuff in word and evaluated alternatives, I was most optimistic about Asciidoc. Unfortunately the ecosystem was relatively anemic… the strong syntax was limited by the tooling.

Looks like there’s been some improvement, maybe I’ll try again. There’s a nice new homepage at least: https://asciidoc.org/

Lawyers have gotten rid of secretaries and so spend time (and billing) futzing around with document formatting, fonts, margins, bullets, numbering, autonumbering and the like.
Many PEs (professional engineers) too.
To me, that just calls for a sensible UI with attractive styling and interaction over a git backend for the heavy lifting of tracking changes through time.

A lot of successful products have been built in this way. I've seen developers get upset with Apple for making successful products out of just giving a nice UI to a piece of open source tech that does the heavy lifting. Like it's cheating.

You should research what happened with distros and UI systems...open source was building lots of nice UIs and you could even have them on Windows/Mac, but the was constant drama over the "right" way to code a UI framework...which led to a ton of fracturing and leaning back towards minimalism (because the nice stuff was always very heavy).

This even happened with Microsoft, they had so many false starts and changes in messaging that they killed their own portfolios. I suspect at least that is why they "embraced linux" because it was excellent at web, and web wasn't busy changing every month (it has been, but that's a different story).

Apple introduced Swift but besides new Xcode versions I get the general impression their tooling has been far more stable.

Actually the little known "Review" feature of word allows to visually track approve/reject/comment collaborative changes over a document in a really user friendly way, not need for git here
I have never used it but it seems lawyers wants something like Clio which not only does manage documents but runs their entire business.

https://www.clio.com/lawyaw/ https://en.wikipedia.org/wiki/Clio_(software_company)

The standard for legal docs is to redline changes with an additional tool, because you don't necessarily trust the other contributors. They have decent tools for this, and the system works ok I suppose. Editing tends to be in tic-toc fashion anyways so I guess it works. You could do someting like this with git and a markup language, but I don't know you'd convince many lawyers that the squeeze was worth the juice.
What are the tools you mentioned here? Is there like a dominant software, similar to ArcGIS for GIS?
I don't know the names. They all seem to have the pro Acrobat stuff, but more often use something also bundled with search tools perhaps? Communication between lawyers on opposite "sides" often seems to be by PDF, not source (although sometimes that too) so I imagined they both have working docs kept separate because they don't want to to share some of the markup/comments. I asked one of them about that they claimed that using clean pdf output (no metadata or history) was worth the extra hassle as it avoided costly errors.

Anyway that's my limited experience having dealt with a bunch of them - no expert.

It's never pdf. You can't easily make corrections on a pdf, never mind major revisions (such as moving sections around). If someone sends me a pdf I ask for a Word document, or convert the pdf to Word myself. Sending someone a pdf is a little like saying "fuck you."
> 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.

Previous HN discussion:

https://news.ycombinator.com/item?id=28304781 - 91 comments

https://news.ycombinator.com/item?id=35645464 - 97 comments

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.
Try context over latex. Much more “gimme what I ask for” than being super academic about subsubsubsubheaders.
Can I make a simple point?

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:

    \documentclass[12pt,a4paper]{article}
    \usepackage{amsmath}
    \usepackage{amsthm}
    \usepackage{geometry}
    \usepackage{enumitem}
    \setitemize{noitemsep}
    \usepackage{tabularx}
    \usepackage{setspace}
    \newcolumntype{x}{>{\centering\arraybackslash}X}

    \newtheorem{theo}{Theorem}
    \newtheorem{prop}[theo]{Proposition}
    \newtheorem{lemma}{Lemma}

    \usepackage{fontspec,xunicode}
    \defaultfontfeatures{Mapping=tex-text}
    \setsansfont{TeX Gyre Heros}
A quarto 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 see the difference in emphasis.
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.

It's absolutely true that you may need to customize things. And then you are stuck with the big quarto disadvantage: debugging a toolchain that typically looks like

    quarto -> knitr -> markdown -> pandoc -> [tex -> pdf | html]
and not knowing exactly where the error came from.

At the same time, the markdown defaults produce a nice, readable paper. The TeX defaults get you something that reminds you of Rubik's Cube and Duran Duran.

Is Lyx still around? I remember it had good defaults. Haven't used in ages and it had some installer issues but I got fairly comfortable writing latex papers without learning a ton of latex...

Ofc that was a major downside, something other markdown editors figured out - if you give people buttons that make it easy and you make it easy to learn, they will learn what they need.

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.
Probably that's true. But first, I don't know how to create a class file, or a template (if that is a LaTeX thing). And since I've never seen anyone else do this, I guess that most academics don't either.

Second, my point isn't just about the specific issue, it's that this issue reveals how TeX thinks about the world. It thinks you want to spend your time writing TeX. No, I want to spend my time writing English. Here's another example. This is how you embed an image in quarto - it's just markdown:

    ![Caption](path/to/image.png)
And here is how you do it in TeX:

    \begin{figure}[t]
    \includegraphics{path/to/image}
    \centering
    \end{figure}
Which of these is easier to memorize and to read past? Similar comments apply to tables, links, numbering and so on.
I understand your frustration. Maybe it helps to know where this problem comes from.

TeX is extremely powerful and lets you create arbitrary documents. This is the first time I heard of quarto, but apparently it makes a lot of choices for you that you understandably don't really care about.

Instead of developing quarto, one could have simply written a LaTeX class that defines a function like so:

    \newcommand{\image}[2]{\begin{figure}[t]\includegraphics{#2}\caption{#1}\label{#2}\centering\end{figure}}
Now you can just write:

    \image{caption}{path/to/image}
Of course, it is now much less flexible, as you cannot define a custom label or different placement instructions. But that is the price you pay for short and memorable syntax.

By the way, developing a LaTeX class is not necessarily hard. It is more or less a file whose name ends in `.cls` with all the commands that you typically put in your preamble. It just needs a header of three lines that define some meta data and also supports options. See here for an example: https://github.com/latex-ninja/colour-theme-changing-class-t...

You put it in the same directory as your main tex file or in the system wide TEXMFHOME or user-specific TEXMHFHOME.

More on creating your own class file:

https://www.overleaf.com/learn/latex/Writing_your_own_packag...

How I do it...

I keep a directory called LaTeX inside my home directory. Inside that I keep a file with all my frontmatter, myfrontmatter.sty (technically a package rather than a class), and also my biblatex file and a scan of my signature for signing letters. When I start a new LaTeX document I add the line \usepackage{/home/nanna/LaTeX/myfrontmatter} to the top (note, no .sty). This keeps my frontmatter minimal and tidy.

Inside myfrontmatter.sty:

  \NeedsTeXFormat{LaTeX2e} 
  \ProvidesPackage{/home/nanna/LaTeX/myfrontmatter}[2015/01/01 by me]

  \RequirePackage{amsmath} % Just replace `usepackage` with `RequirePackage`
  \RequirePackage{amsthm}
  ...

  \addbibresource{/home/nanna/LaTeX/biblatex.bib}
  ...

  %% Macros like for inserting my signature
  \newcommand{\mysignature}{\noindent\includegraphics{/home/nanna/LaTeX/signature.png}}
  ...
  \endinput % Not sure if this line does anything?
And that's it. I never have to worry about a package I've forgotten to add in. Granted a journal might not accept my custom package but I can always just copy and paste it all into my frontmatter, minus the top two lines and replace all the RequirePackages with usepackages.
Yes, and with tools like ChatGPT it's even easier to write TeX documents.

I exposed this very problem and ChatGPT proposed exactly the same solution, and also another one using a custom environment.

That is just an expression of the LaTex problem though.

People (as in, the majority of people) will not be comfortable using a tool that is so unintuitive and hard to use that you need to use an AI to help you in writing.

Writing a document is not supposed to be hard and require assistance to do.

> with tools like ChatGPT it's even easier to write TeX documents.

I am not quite sure whether this is satire?

Thanks for the help and I can feel the enthusiasm. I have to tell you, my hatred for TeX is profound and goes far beyond this one point. But if I start ranting, I'll never stop.
Didn't you say with quarto you had to debug a 5 layer pipeline? I wonder if it's not biasing you here a bit...(stuck fighting "arcane" latex syntax somewhere at 3 in the morning).

I'm not saying you should love TeX, but it's a bit like saying you hate assembly language - if you have the wrong abstractions (writing a 3D game or a web page using assembly language) of course the experience will be beyond frustrating. I don't hate assembly language, but I generally don't need to touch it because higher order abstractions generally suffice. If I am optimizing my compiler output, though, then it's a tool I can use.

Ofc if I have the wrong or missing tools while using assembly language, or any other TBH (python, html, etc), that is also a source of considerable frustration. Not sure where the "hatred" comes from, but perhaps you encountered a poorly done package or editor?

> Instead of developing quarto, one could have simply written a LaTeX class that defines a function like so:

If it's so simple, why isn't there QuarTeX that does all of that and removes the extreme verbosity barrier?

Because doing something like this is opinionated. The LaTeX developers try to do the opposite: they want to provide packages that cover as many usecases as possible.

And users of LaTeX are probably not knowledgeable enough or too busy to publish their opinionated subset of LaTeX as a class. I don't know for sure. There is no central body that has an interest in removing barriers, so you might as well ask me or yourself why I or you haven't published anything.

I developed something similar to this at my company, because we write lots of LaTeX documents and need shortcuts like this not only for brevity but also so that we achieve some consistency across the entire team. It's only for internal use though and thus not public.

> in quarto - it's just markdown:

    >    ![Caption](path/to/image.png)
> And here is how you do it in TeX:

    >    \begin{figure}[t]
    >    \includegraphics{path/to/image}
    >    \centering
    >    \end{figure}
This is not the same thing! The LaTeX equivalent to your markdown would be

     \includegraphics{path/to/image.png}
which is arguably simpler and cleaner than the markdown. The figure environment is unnecessary when you just want to put a figure right there. You only need the figure environment when you want your image to "float" to a random place in your page.
> You only need the figure environment when you want your image to "float" to a random place in your page.

Which is also something the Markdown version can't do at all (give fine control over how the image is positioned). You have to use raw HTML plus probably some CSS if you want that.

God, the amount of pain I've had trying to use that "fine-grained control".
I can tell you as another academic i almost always get links and images wrong in Markdown (which of title URL is in square which in round brackets, forgetting the !, the conventions around file paths (some Markdown processors need file://...). Admittedly if I would write always one Markdown style I would get used to it, on the other hand I never get it wrong in latex and let's not even talk about how to do different alignment, captions and labels.
> I don't know how to create a class file, or a template (if that is a LaTeX thing). And since I've never seen anyone else do this, I guess that most academics don't either.

Exactly, academics usually don't do that - they write the text with appropriate markup, and then put it in the publisher's template and the formatting according to the appropriate standards is done. You can write your own template, but usually you use someone else's, with the big benefit that you can generally move your content to a very different template of a different publisher with minimal or no changes to your actual writing.

Now how would I do that in quarto - what (and how much) would I need to write to ensure that, for example, the captions for all the images and all the references to the images are all formatted in a specific manner? Because for quarto I would need to make my own template specifying the exact formatting and layout, and a quick browse of its documentation didn't lead me to any examples on how I would control that.

In sane environments there is a split between text and formatting, however, the formatting part has to be sufficiently powerful to meet the various requirements, so there is a certain quite high minimum bar to meet there. Latex works because I can rely that I will be able to easily get my markup laid out exactly as required by arbitrary standards, for any markdown-type standards I need some assurance that this will be possible and easy, that I won't need to (for example) go over all my references and do something to them.

Again, apples and oranges. Yes it's more markup than e.g. markdown (which is fundamentally less capable) But how do you do the equivalent ot the [t] and \centering in the former on a per figure bases? what about scaling it differently from other figures in your doc, or embedding a reference in caption with a particular style?

For that matter your equivalent is still one line, it's just \includegraphics{path}. The figure environment is just adding extra capabilities.

I agree not everyone needs to do this, but the trade offs you are illustrating are not "X is better than Y" so much as "X is simpler than Y, and can't do as many things"

For you that trade-off makes sense, great. But I wouldn't generalized it to the value of the tool. I know plenty of academics who are quite proficient at Tex, let alone the simpler Latex, and find it lets them generate the content they want easily enough, given it's power.

This isn't just mathematicians either, though most of the people I know using it came to that out of a need to do math typesetting properly. How would you for example generate a mixed language document with both left-to-right and right-to-left languages formatted correctly?

LaTeX's real problem isn't the syntactic load (easily handled with a decent editor) it's the package system. It can be abused to e.g. generate conference posters well, but it's hairy once you get into the details.

That’s a great of the tradeoff. On the surface the latex version looks harder, but you can specify a caption, how the figure floats with other items, how it’s justified, the zoom level, you can add a reference label that you can hyperlink to from elsewhere in the doc, etc etc etc.

The markdown one you get what you get. Maybe that’s fine. If it isn’t you are out of luck.

The latex one requires more of you but gives you much more functionality in return.

Which is better is going to be entirely situational/personal preference.

   \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}
The difference is you know the easy way to get what you want in rmarkdown/quarto but only know the hard way in latex?

My latex docs look nothing like that because I put all the boiler plate in a .sty file.

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
You might be interested in typst. It offers an incremental live compiler.
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.
Templates are one reason products like Notion took off: they simplify the product, and build community at the same time.
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.

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

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.
You can write doctorate level academic papers in Org Mode?
You can, just like you could do in Markdown. You can use inline TeX and get the right overall format with a template. I haven't actually done this for a paper, but I used Pandoc to typeset a textbook with lots of math and code and it worked well. We could have used org-mode just as easily, but Markdown was already familiar to my non-Emacs-using coauthor. (Hey, we all have our faults!)
Yes, and you can use Pandoc to export to different formats, including Epub, HTML, Docx, etc. You can embed LaTeX and customize in multiple ways using Lua filters for Pandoc. I've found Pandoc to be more powerful than Emacs when it comes to writing documents in Org mode, while Emacs is more powerful when you use Org mode to do literate programming. YMMV
You can, but you might be better off just using AUCTex if you are emacs anyway.

YMMV with use case, obviously.

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.
I don't have a whole lot that are public. This section describes one of advanced features I use most: http://breuleux.github.io/quaint/syntax.html#rules

I've used it to create operators for stuff like:

* Lead caps

* Formatting dialogue in a screenplay

* Marking something that's a prop in a screenplay

* Parametric links (e.g. defining @john so that it creates a link to the john handle on X/Twitter)

* Tooltips

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.

Good luck with the project

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
Looks quite nice!

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

Looks amazing that typst!!
What are the similarities and differences between it and quarto?
Quarto will support output to typst in the upcoming 1.4 release: https://quarto.org/docs/prerelease/1.4/typst.html

I think the big different between quarto and typst is the scope. quarto is a tool for combining prose and computation to generate many different output types (HTML, PDF (via latex), PDF (via typst), PPT, ...) through the power of markdown/pandoc. typst is a typesetting system for turning plain-text markup in to beautiful PDFs.

I think you're much more likely to want to write typst by hand than latex, but out of the box it doesn't provide any tooling for combining writing and computing (if that matters to you).

I used typst for some university project and what I really liked about it is that it is as programmable as latex but with a language that's much more intuitive (no macro weirdness, but actual functions/if/loops etc etc). It feels like a better of TeX rather than a different way of writing documents.

I haven't really used quarto so take this with a grain of salt, but from what I can see it is much more declarative, you just declare the content of your document and pick a template to show it. It feels simplier, but at the same time what if I need to customize something here and there? Looks like there are extensions that can be programmed, but they are more like second class citizens that you are not suppose to use normally.

(disclosure: I'm a quarto dev. But I'm also a big fan of typst)

You're right that typst is _very good_ at extensions, and likely will always be superior to quarto when it comes to that. The fundamental advantage typst has is that it's a "greenfield" project, and a very well-designed one at that, especially when compared to TeX.

> Looks like there are extensions that can be programmed, but they are more like second class citizens that you are not suppose to use normally.

We take quarto extensibility pretty seriously! "Simple" customization is available without need to program extensions, mostly through metadata configuration and classes and attributes in the document. This covers the basics like CSS, layout, document listings, etc.

For slightly more sophisticated extensions, you can create "filters" that operate directly on the document AST, either using the built-in Lua extension API or reading/writing a JSON representation (these are both built on top of Pandoc's capabilities, which quarto leverages extensively).

For reusable, packageable functionality, the extension system as it exists today is simple but certainly meant to be used "normally". It's how custom formats (the common, concrete use case is to provide different styles for particular academic journals) are defined and used.

> https://arxiv.org/abs/2310.04368

Did you use Nota to write this paper?

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
Not superrelated but having a resume layout in Nota will drive adoption with high velocity
>Also: the next version of Nota will be written 99% in Rust :-)

Cringed. ty