Pandoc at 20: From a Haskell experiment to the world's most popular document converter
Twenty Years of Pandoc
John MacFarlane reflects on two decades of Pandoc, the universal document converter he started in 2006 as a way to learn Haskell. What began as a 3,000-line tool for converting Markdown, reStructuredText, HTML, and LaTeX has grown into a project with over 200 releases, support for more than 50 formats, and integration into tools like Quarto and Jupyter Notebook. MacFarlane shares the project's evolution, from early days on his website to becoming the most popular Haskell program on GitHub, and discusses key milestones like the creation of CommonMark and the shift to a more flexible architecture.
A project that started out as nothing more than the product of procrastination was nurtured by the joy of writing in Haskell and by its increasing usefulness for my own academic work.
- PeterStuer
"The choice of Haskell has also led to a high quality and low volume of contributors"
I feel this influence of choosing a tech stack and its impact on self selected and auto-reenforced culture is most often underestimated.
From my own experience, at a time I was (involuntarily) working in Java, and when .Net was released, from a pure technical point of view it was like a breath of fresh air. Java was suffering from overengineering, archtecture astronauts galore and no sensible UX framework. .Net, the new kid, came in lean and clean with a UX library that 'just worked'.
Problem later was that for all its flaws and being overly 'academic', in teams (the real thing, not the awfull app), you could have indepth discussions about non trivial aspects of SWE topics in the Java world, whereas for all its technical prowess, in .Net land you were mostly dwelling amongst the 2 week CRUD app bootcamp folks. This ofc is a gross oversimplication.
You had brilliant engineers and challanged codemonkeys on both sides. But the skew was more than a little biased.
- adamddev1
> by writing N parsers (“readers”) and M renderers (“writers”), one could support N × M conversions.
Beautiful writeup for a wonderful project. In an age of vibe-coding hype it's also so nice to see how things can be extended and snowball in usefulness when things are built correctly, by hand, from basic principles.
> Perhaps, then, in the future, people will no longer have a need for tools like pandoc.
I think we will need wonderful things like pandoc more and more. As mentioned there is a huge ecological and practical difference. Even if LLMs could get infintisamally close to deterministic-level reliability, it's still so many more orders of magnitude better in efficiency, especially with big batch jobs etc.
- aanet
That a professor of philosophy [1] made tools [2] that are used by millions around the world... that's just mind boggling. In a good (great!) way.
Pandoc is my go-to tool. Thank you, Sir!
- rahimnathwani
Pandoc is great. I use it multiple times per day to move content between Outlook emails and a coding harness:
https://gist.github.com/rahimnathwani/210b1f9cb6ce731a304322...
cat email-to-xyz.md | md2clip
clip2md > email-from-xyz.md
- jillesvangurp
A few years ago, I gobbled together some bash scripts around pandoc to build a site generator for my personal website. Works great. I use html templates, markdown for the content, etc. Mostly the bash scripts just serve to list files and process them one by one. I actually process them concurrently by forking processes so it's reasonably fast. A bit wonky but it works fine for my use case.
As for Haskell, I guess tree transformations and parsing are the perfect use case for functional programming. I studied in Utrecht in the nineties when Erik Meijer was still teaching there (later went to work at Microsoft Research where he contributed to things like F# and Linq). In short, my compiler course was taught using functional programming. We were toying around with writing our own parser generators to implement a subset of Modula 3 or our own toy languages. Lots of monads and other esoteric abstractions.
I haven't really done much professionally with any of that since except having a really easy time when languages like Kotlin, Javascript, etc. started borrowing liberally from functional programming. These days, if you have a list, calling map or forEach on it with another function is perfectly normal in many languages. Very nice alternative to a for or while loop.