Pandoc is a wonderful tool and by extension a wonderful library. It takes a simple idea--convert between different document formats--and executes it very well.

Pandoc is a wonderful tool and by extension a wonderful library. It takes a simple idea--convert between different document formats--and executes it very well. It then turns out that this simple idea is extremely handy. This article about the API shows how it uses a great design: the actual tool is written as a frontend to a generic library. This way, the actual logic is not tied to the frontend at all; the dependency flows from the logic to the interface. Since it's designed as a library first, the API is a first-class citizen. Using it never feels like scripting an app, because it isn't. I really like this way of separating concerns. It makes the "meat" of the program so much more useful and reusable. Moreover, there is no reason not to use this approach for GUI apps as well, but I see it all too rarely. It would be particularly nice for IDEs. There's no reason why all the great refactoring and analysis tools need to be tied to a given frontend. I'd rather have the two clearly split to make the backend much easier to reuse and repurpose. This sort of design is implicitly encouraged by Haskell (as in the case of Pandoc). The language naturally pushes you to carefully split the logic and the interface, partly through managing IO explicitly. Even the build tool pushes you in this direction, making it very easy to build both a library and an executable at the same time. Of course, this is also very easy to do in other languages, although I've found it a bit easier to mix concerns in an OOP setting. It's just too easy to add a render method to your Document class instead of maintaining a strict separation; this is especially true if Document contains extensive private state. I really hope future tools will continue with this sort of split design so that building new things on top of them continues to be easy. I've already benefited from this with Pandoc: the static site generator I use is built on top of Pandoc, giving it some very nice capabilities. Since it uses Pandoc as a library, it's more powerful than just passing files through the tool--the configuration can also use and depend on variables in the Pandoc templates, for example, which is very useful and requires programmatic access to Pandoc's internals.