A Unix-y spaced repetition system

On Pranab’s site

DRAFT (needs work or removal)

A flashcards app idea inspired by hashcards.

“Hashcards: A Plain Text Spaced Repetition System” is an introductory post for hashcards, an app by Fernando Borretti that uses Markdown files for flashcard “decks”. The idea sparked my imagination, which is what I present to you here.

While hashcards obviously fits their needs, I think it could certainly use a smidge more work, and there’s a few cool ideas that can be built on top, though that’s basically a different app entirely. You’ll see what I mean.

Markdown extension🔗

My only critique of hashcards is that Markdown is an odd choice. The proposed syntax isn’t really Markdown, which makes me think they chose it because the cards will be rendered nicely when uploaded to Github, as they did for their cards. However, the question and answer syntax doesn’t account for how Markdown is rendered.

The syntax used in hashcards:

Q: What is hashcards?
A: A plain text spaced repetition system.

The rendered output:

In Markdown, lines following each other are paragraphs. Line breaks are turned into spaces.

This is the only flaw, which is why I said “a smidge more work”, though that’s a surface-level evaluation.

I’d say unordered lists would work well here.

- What is hashcards
- A plain text spaced repetition system

- What is spaced repetition?
- Repeated tests for knowledge recall with
  spaces of time in between.

Questions and answers are easier to read, - is a bit easier to type than Q or A, Markdown parsers can understand some of the structure, and editors can make it easier to write cards.

- What is hashcards, really?
  Give me a nice long paragraph about it.
- hashcards is a local-first spaced repetition app,
  along the lines of Anki or Mochi.
  Like Anki, it uses FSRS,
  the most advanced scheduling algorithm yet,
  to schedule reviews.

- Hmm, could you list the features?
- - Plain Text
  - Content Addressable
  - Low Friction
  - Simple
  - Efficient

- hashcards is efficient because it uses [FSRS]

That’s my only reasonable suggestion. From this point onwards, I’m describing a completely different app.

A Unix-y system🔗

The hashcards format isn’t really Markdown, though it could be taken as an extension.

Why not a more concise syntax? What if you prefer other formats? Especially given the problems with markdown, as described by John MacFarlane in his essay “Beyond Markdown”.

Beyond Markdown

What if you’d like to extract cards from existing note files?

Additionally, the app will always have its own internal representation of the cards.

So what if we only had a certain internal representation, and the input format could be anything you want, assuming there’s a converter or that you’ll create it.

The app could be extended in several ways:

• A scripting interface, maybe using Lua.

• Provide the API as a library to use in your programming language of choice.

• Allow running executables that print cards to stdout, perhaps using a JSON or other line-oriented schema, which the app can take as input.

That last one is the “Unix-y” bit I’ve talked about. You can write an executable in whatever language you prefer and configure the app to call it how you like, and then the app will consume its output to produce the internal card representation. You can bundle these executables in the same folder, or use compiled binaries in your PATH, like an AWK script to parse some CSV or a Rust binary to import notes from Notion.

Configuration would be in a file that’s within the same folder as the cards.

// This file was auto-generated by The App
// See the-app.com/configuration to know more
import *.md builtin markdown
import notion-link.txt custom {
	"./notion-card-importer.py" "--card-json" $file
}

The app will need to store a hash of the config file as well because changing it also changes the cards.

The rest can be the same as hashcards, although plain text statistics would be great, perhaps stored in a similar file as the config. It would make it easy to extract information and to backup history along with the cards.

I might start working on it in December, in an upcoming code jam, assuming it’s within the rules.