hemanth/functional-programming-jargon: a glossary you read, not a library you install

What the functional-programming-jargon glossary is actually for

Functional programming has a vocabulary problem. You can write working JavaScript for years and still stall on a sentence like "a monad is a pointed functor with a flatMap", because nothing in day to day web work forces you to learn the words. This repository attacks that gap directly: it is a glossary of FP terms, each entry a short definition followed by a JavaScript example and, in many cases, links to further reading. The README states the goal plainly, that by providing a glossary the authors hope to make learning FP easier.

The intended reader is someone who already writes code and is now hitting FP terminology in library documentation, type signatures or code review. The examples are presented in JavaScript (ES2015) and the README links to a wiki page titled Why JavaScript? rather than defending the choice inline. Where applicable, the document uses terms defined in the Fantasy Land spec, which matters if you spend time in the JavaScript FP ecosystem, because the spec is what gives words like Functor and Semigroup a concrete method set.

It is not a tutorial and not a course. There is no progression, no exercises and no project you build. It is a lookup table with commentary, and the table of contents is long: from Arity and Closure through Currying and Function Composition, into the algebra (Monoid, Monad, Comonad, Semigroup), the morphism family, and practical entries like Memoization, Lens, Prism and Option.

How the repository is put together

The architecture is unusually flat, and that is the point. The main artifact is readme.md, a single markdown document that holds the entire glossary. Each term is an H2 section, so anchors like #currying resolve directly, which is how the table of contents links work. The table of contents is generated, not hand-maintained: package.json defines a toc script that runs roadmarks, and roadmarks writes the block between the RM comment markers.

Around that document sit a few supporting pieces. app/ holds a separate Node project, referenced by the dev, build and preview scripts, which npm runs with the --prefix app flag. That is what produces the interactive graph linked from the readme at hemanth.github.io/functional-programming-jargon. The repository also ships an LLM-oriented file at hemanth.github.io/functional-programming-jargon/llms.txt, a machine-readable rendering of the same content.

Two details are worth noting because they shape how you use it. First, the code examples inside readme.md are linted: the test script is eslint readme.md, and the devDependencies include eslint-plugin-markdown, so the JavaScript in the fenced blocks is checked as code, not treated as decoration. Second, a pre-commit hook runs both test and toc, which is how the table of contents stays in sync with the sections. The practical consequence is that examples tend to be syntactically valid, but it also means the repository is a document with a build pipeline attached, not a software project with a document attached.

Reading the glossary locally and running the checks

There is nothing to install in order to read it. Clone the repository and open readme.md, or read it on GitHub. If you want the interactive graph or you intend to edit entries, you work with the app subproject and the lint pipeline.

The root package.json wires the app commands through npm --prefix, so you do not need to cd into app/ yourself:

npm install
yarn dev

The dev script delegates to npm --prefix app run dev, which starts the app project's development server. The README does not state which port that server binds, so check the output in your terminal rather than assuming a number.

To verify that your edits to readme.md still pass, run the same two commands the pre-commit hook runs:

npm test
npm run toc

npm test runs eslint over readme.md, so a broken example in a fenced js block fails the check. npm run toc regenerates the table of contents with roadmarks; if you added a section and did not update the contents, this is what fixes it. Note that the repository has a yarn.lock and the readme's own scripts use npm; the package.json scripts themselves are runner-agnostic, so either works for the commands above.

For a first real use, skip the tooling. Pick a term you keep meeting, open its section, and read the example. The Arity entry is a good test of the format: it defines arity as the number of arguments a function takes, then shows sum with arity 2, inc with arity 1 and zero with arity 0.

Where the format breaks down

The glossary is deliberately shallow, and some entries suffer for it. Arity gets three one-line examples and a Wikipedia link. That is fine. But the algebra entries carry far more weight than a paragraph and a snippet can support, and the document does not pretend otherwise: it points at the Fantasy Land spec for the authoritative definitions. If you arrive expecting Monad to click after reading the entry, you will likely leave unsatisfied, because the entry gives you the shape of the idea rather than the intuition.

There is also a versioning risk that the repository does not address. The examples are ES2015 JavaScript and the lint configuration pins eslint at ^8.20.0 with eslint-config-standard ^17.0.0. The readme does not document a policy for updating examples as the language and the lint plugins move on, and there are no releases in the repository, so there is no changelog to check when an example stops matching current practice.

Finally, the translations are separate repositories maintained by other people, linked from the readme. Nothing in the repository indicates a sync mechanism between them and the English source, so a translated copy may lag. Treat a translation as a starting point and the English readme.md as the reference. The wrong tool case is equally clear: if you want a library to import, this is not it. There is a main field pointing at index.js in package.json, but no such file appears in the repository's top-level entries, and the package is not presented as something you install.

Compared with the libraries the readme points you toward

The readme ends with a section titled Functional Programming Libraries in JavaScript, which is the honest alternative to the glossary itself. The difference in approach is categorical rather than incremental. A library such as Ramda or Sanctuary gives you callable functions, a type system in the Sanctuary case, and documentation generated from the code. The glossary gives you prose and examples, and expects you to bring your own runtime.

That split is useful to understand before you start. If your problem is "I do not know what a profunctor is and the library docs assume I do", the glossary is the right stop and the library is not. If your problem is "I need a pipe function with sensible currying today", the glossary will explain what currying means and then leave you to install something else. The two are complements, and the repository positions itself that way by ending on the library list rather than on its own terms.

The interactive graph is the closest thing here to a tool rather than a text. It is built from the app/ subproject and published at the project's GitHub Pages URL. It is a way to move through the vocabulary visually, not a way to apply it, and the readme presents it as an addition to the document rather than a replacement.

Maintenance, licence and what it costs to keep using it

The licence is MIT, declared in package.json and in the LICENSE file at the repository root. That is permissive and imposes no obligation beyond keeping the notice, but it applies to this repository's content. The translations are forks or separate repositories under their own authors, so their licensing is a question for those repositories, not this one. Nothing here is legal advice; check the LICENSE file and the translation's own repository if you plan to redistribute.

The repository is not archived, and the last push was on 2026-09-14, so it is receiving changes. There are no releases, which means upgrade cost is not measured in versions. It is measured in the two commands that guard the document: eslint readme.md and roadmarks. If you fork it to add terms, those are the checks you inherit, and the pre-commit configuration runs both, so a stale table of contents or an invalid example blocks the commit. For a reader who never edits it, the ongoing cost is zero; you re-read the file when a term confuses you.

The realistic maintenance burden falls on anyone translating or extending it. Adding a section means updating the generated table of contents, keeping the example lint-clean, and, if you care about the translated copies, chasing a separate repository that has no documented sync with this one.

Editorial conclusion

Adopt it as a reference when you are reading Fantasy Land style type signatures and need plain definitions with ES2015 examples. Do not adopt it as a runtime: there is no index.js, no published package and no library to import, so if you need working FP utilities, look at the libraries the readme lists. Before relying on it, open readme.md on the master branch, check whether the term you need is in the table of contents, and confirm the linked translation for your language still matches the English entries.

Frequently asked questions

Official sources

1. hemanth/functional-programming-jargon on GitHub
2. Issues
3. License: MIT
4. Project website
5. README