Hashcards: A plain-text spaced repetition system

Original Article ↗ Hacker News Discussion ↗

Plain Text, Markdown, and Recutils

  • Many commenters like the core idea: cards as plain text, editable with any editor and managed with git and Unix tools.
  • Markdown is praised as a “final form” for text systems: readable, extensible, easy to render on GitHub, and supports images, math, and cross-links.
  • Some wish the project had used GNU recutils/recfiles (plain-text structured data) instead of inventing a new format; others note that tooling and editor support for recutils is still weak.

Relationship to Anki and Other SRS Tools

  • Hashcards is seen as a simpler, more transparent alternative to Anki, especially for terminal-focused users.
  • Several people defend Anki strongly: flexible note/model system, templates, CSS/JS customization, plugin ecosystem, and deck hierarchies.
  • Others find Anki powerful but UX-heavy, confusing for beginners, and “good enough but painful.”
  • A recurring wish: robust “import from Anki” in new tools; developers note that Anki’s data model is complex and often underestimated.

Design Choices: Hash IDs, SQLite, Media

  • Content-addressed cards (ID = hash of text) raise concerns: any edit—even a typo fix—creates a new card and discards history. Opinions split between “major drawback” and “actually good; corrected facts should be relearned.”
  • Some disappointment that the article touts “no database” but still uses SQLite for review history; defenders argue only card content must be plain text.
  • Images and audio are already supported via standard Markdown syntax.

Card Creation and AI Assistance

  • Many agree that card entry is the main bottleneck.
  • LLMs are being used to mass-generate cards from PDFs, websites, or news, with the learner later pruning or editing; especially useful for language learning.

How People Use SRS and Pitfalls

  • Use cases mentioned: languages, music intervals, chess openings, mathematics, bar exam prep, technical knowledge, and integrating cards into markdown/org notes.
  • Several commenters emphasize selectivity: don’t flood the system with trivial facts or you end up in “review hell.”
  • Suggested practice: multiple cards per important concept, move quickly from basic facts to higher-order or “second-order” cards that compare and apply concepts.

Beyond Facts: Behavior and Life Decisions

  • One long subthread explores using SRS to reshape behavior and relationships (e.g., prompts about past interpersonal mistakes, spouse interactions, or key life judgments).
  • Cards can encode situations and desired reactions; scheduling reviews on simple patterns (e.g., Fibonacci) is suggested instead of fine-grained grading.

Algorithms, Discipline, and Ecosystem

  • FSRS is mentioned positively; people ask about its real-world benefits versus SM‑2.
  • Several note that any SRS works only with near-daily use; long breaks lead to heavy forgetting even for “solid” cards.
  • Numerous alternative tools are cited: org-drill/org-srs (Emacs), Obsidian’s spaced repetition plugin, CLI tools, GoCard, Rails and web apps, and phone-based workflows (e.g., Termux).
  • Ideas extend to “spaced repetition social networks” and even scheduling calls with friends on a spaced repetition schedule.