wcrichton

My personal site (https://willcrichton.net/), lab site (https://cel.cs.brown.edu/), and Mastodon page (https://mastodon.social/@tonofcrates) are all good ways to follow me!

(Author here) That's exactly why I built this for Rust, and why it's difficult to replicate in any other language.

My issue is that this article is trying to use cognitive load in its specific, academic meaning. It says:

> The average person can hold roughly four such chunks in working memory. Once the cognitive load reaches this threshold, it becomes much harder to understand things.

This is a paraphrase of the scientific meaning. "Intrinsic" and "extrinsic" cognitive load are also terms of art coined by John Sweller in his studies of working memory in education.

I agree the article isn't designed to be peer-reviewed science. And I agree the article has real insights that resonate with working developers. But I'm also a fan of honesty in scientific communication. When we say "vaccines prevent disease", that's based on both an enormous amount of data as well as a relatively precise theory of how vaccines work biologically. But if we say "composition reduces cognitive load", that's just based on personal experience. I think it's valuable to separate out the strength of the evidence for these claims.

I'm not saying that the conclusions in the article are false. As a programmer, I prefer composition to inheritance, too. I'm saying that the justifications are presented using a scientific term of art (cognitive load), but the scientific evidence regarding cognitive load isn't sufficient to justify these claims.

The article is attempting to use a scientific term of art, "cognitive load", to justify claims about programming. Those claim cannot be justified given the existing evidence about cognitive load. As I explain in my linked response, I nonetheless agree with many of the claims, but they're best understood as folk theories than scientific theories.

And I don't think condescension will make this a productive discussion!

I did my PhD at Stanford about the cognitive aspects of programming, including studies of cognitive load. This article uses pseudoscience to justify folk theories about programming. I would encourage readers to take everything with a grain of salt, and do not wave this article around as a "scientific" justification for anything.

I laid out my objections to the article last year when it first circulated: https://github.com/zakirullin/cognitive-load/issues/22

Do you believe that you could implement the Airbnb interface without any CSS or Javascript?

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

Yes, this was my first and probably last experiment using participants from Mechanical Turk. Just too unpredictable.

For the curious, I have done some experiments on working memory and programming: https://arxiv.org/abs/2101.06305

> Program tracing, or mentally simulating a program on concrete inputs, is an important part of general program comprehension. Programs involve many kinds of virtual state that must be held in memory, such as variable/value pairs and a call stack. In this work, we examine the influence of short-term working memory (WM) on a person's ability to remember program state during tracing. [...]

Thanks for the bug report, I will fix that.

Not yet, but that is a high priority TODO. The simplest toolchain is just "Page Print > Save to PDF", but I need to first improve the printer-oriented CSS.

There's a broader issue of layout, like if you want to print a Nota document and a figure is split across two pages. I'm not sure how to handle that, or if it even makes sense to. The goal of Nota is to move away from the paper document model, although people of course still like to print things and scribble on them.

Quarto is a good example where their design requires users to understand many different DSLs to achieve the end result. Just in their code sample you have:

* YAML for the page metadata (title: ...)

* Markdown (```{python}...```)

* Custom in-text notations (@fig-polar)

* Custom markdown notations (#| label: fig-polar)

Whereas in Nota, this would look like:

    %(export let metadata = {
      title: "matplotlib demo",
      format: {html: {codeFold: true}},
      jupyter: "python3"
    })

    For a demonstration of a line plot on a polar axis, see @Ref{fig-polar}.

    @Code[language=Python][label="fig-polar"][figCap="A line plot on a polar axis"]{
      import numpy as np
      import matplotlib.pyplot as plt

      r = np.arange(0, 2, 0.01)
      theta = 2 * np.pi * r
      fig, ax = plt.subplots(
        subplot_kw = {'projection': 'polar'} 
      )
      ax.plot(theta, r)
      ax.set_rticks([0.5, 1, 1.5, 2])
      ax.grid(True)
      plt.show()
    }

When code or structured data is involved, Nota is "just Javascript" (e.g. exporting metadata, specifying code literals). When text is involved, Nota provides a small core set of sigils like @Component[attr=value]{content}.

Note that Quarto's "#| fig-cap" annotation probably doesn't allow for rich text captions, since it only allows strings. But Nota allows deep composition, so you could do:

    @Code[figCap=@{A @strong{line plot} on a @em{polar axis}}]{
      ...
    }

AFAIK Pandoc doesn't really have a story for interaction. Like, "show a tooltip when someone clicks on this text". That's the main value add for Nota.

Nota doesn't require users to specify the implementations of things like footnotes. The goal is the user just says "@Footnote{content}" and the document renderer takes care of all the layout. And you can swap in different implementations of the Footnote component.

A goal for Nota is to gracefully degrade in the absence of Javascript. This already mostly works, since we do server-side rendering to fully generate the HTML contents of the document before providing it to the client. When you first visit nota-lang.org or willcrichton.net you are seeing the pre-rendered document.

Academic writing is definitely a target application area for Nota (since I am an academic). Philosophically, Nota combines together all the ideas I think are needed to make a better platform for writing documents like academic papers that are web-native.

Very cool! Yeah that's about the closest thing to Nota I've seen so far. Haven't seen Urlang, I'll have to check that out.

Nota's syntax is heavily inspired by Scribble. You can think about Nota as "web-native Scribble", or "what if Scribble was written in Javascript".

I'm targeting people who are writing documents: bloggers, academics, textbook writers, that sort of thing. Certainly Nota requires a level of technical expertise to use right now, but I have a WYSIWYG editor as a distant-future TODO.

If you read my original paper about Nota, you can find a more interesting set of applications: https://willcrichton.net/nota/

Yes, I think course notes or textbooks are a great candidate for Notafication. I sadly don't teach 242 anymore since I just graduated, but I'll certainly use it for my next course.

I would be happy to support y'all in using Nota for the new course. And I hadn't heard about Diderot, I will reach out to Umut for sure.

Nota is really two things:

1. An alternative syntax (vs. JSX) for writing React programs.

2. A set of React components for structuring a web document

As a syntax, Nota is meant to make writing prose-heavy React easier. As a set of components, Nota is meant to help readers use the document's structure for understanding the document's content, e.g. by showing the definition of a term when you click on it. It's not a replacement for HTML or Javascript, but an alternative syntax for them with a rich standard library.

Thanks! Currently, I have no plans to convince users of Nota's longevity. It is a research prototype, and I will pursue it as long as I have the time and still think it's a good idea.

My hope is that in the near-term, I (or other early-adopters) will create a gallery of documents that use Nota's features to convey information in a compelling way. Those examples will convince more people to adopt Nota for their blog or website. Maybe a forward-looking academic workshop convinces its authors to write their papers in Nota. And eventually some Nota will gather some institutional momentum to fund its development. Once there are enough Nota documents worth archiving, then people/orgs will invest resources into archival stability.

So right now, I'm more interested in convincing people that using Nota can enable them to write documents that are significantly better for readers without significantly more effort on behalf of the authors.

There isn't, and I would say Nota is not suitable for e.g. a commenting syntax on a forum. It's intended for blog posts, papers, or other documents coming from more trusted sources.

Nota can express any HTML document. It uses KaTeX for math, so it is as expressive as KaTeX.

The goal isn't really to compete with lightweight markup languages like Markdown. There are plenty of those. The goal is to provide a language for writing complex, interactive documents like academic papers.

It isn't as simple as bringing LaTeX to the web. There are many things that LaTeX cannot do or express (e.g. like a tooltip popping up when you click on a reference to a definition). The goal of Nota is to make things like that possible.

I originally tried using MDX. But in my experience, JSX syntax is better suited for writing websites than writing documents. The <Tag></Tag> syntax is more verbose than @Tag{}. I ended up having to do lots of raw string embedding too, like <Component>{r`content...`}</Component> which is even worse. Basically you either had a really concise syntax for special Markdown-supported operations, or you had a really annoying syntax for non-special operations. Nota instead provides a uniform somewhat-nice syntax for both.

Additionally, I found the composition semantics between Markdown and JSX somewhat confusing. Random whitespace and newlines would sometimes have a very significant effect on the resulting document. It wasn't really clear when you would be in Markdown mode vs. JSX mode.

FWIW the Nota React components (e.g. @Definition and @Ref) could be used with MDX. The Nota syntax and Nota runtime are separate.