Commenters debate whether Haskell's primary bottleneck is technical performance, such as compile time and incremental builds, or its lack of a coherent, polished ecosystem for building diverse applications like web and desktop software. While some argue that foundational libraries and better developer experience are the missing pieces, others contend that the language's utility is constrained by fragmented tooling and unclear positioning compared to more universal alternatives.
17 readable replies · Supporting reply 1 · Supporting reply 2 · Supporting reply 3 · Supporting reply 4jgm
pandoc
Haskell2012–2026
jgm / pandoc
pandoc
Universal markup converter
56Distinct people
63Mentions
1Explicit recommenders
46.9KGitHub stars
What to know before exploring
What it is
Universal markup converter
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I really hope that they borrow a lot if not everything from pandoc[1]. My only real complaint with pandoc is the table formatting, but I think fiddlosopher is adding org-mode…
dfc used a recommendation phrase. One indexed comment matches. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 8:03:49 PM UTC.
Mentions over time
HN mentions by year63 dated mentions
Observed mentions: 2012-02-25 18:15:18 UTC to 2026-10-01 15:56:48 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2012 | 2012-01-01 00:00:00 UTC | 2013-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2013 | 2013-01-01 00:00:00 UTC | 2014-01-01 00:00:00 UTC | 0 | 0 | 0 |
| 2014 | 2014-01-01 00:00:00 UTC | 2015-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 2 | 0 | 2 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 3 | 0 | 3 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 3 | 1 | 2 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 8 | 1 | 7 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 2 | 1 | 1 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 7 | 1 | 6 |
What Hacker News says
5 sourcesFOfoob·Oct 30, 2017Submission
5 points · Open discussionI don't understand the question.
I am not familiar with Haskell but from what I understand
Pandoc is a group of hand crafted parsers (readers) for markup formats.
How does this relate to a discussion on the relevance of parser generators / libraries?
https://github.com/jgm/pandoc/tree/master/src/Text/Pandoc
In Ohm: Parsing Made EasyIt's a modification of the default Pandoc template. I add css to it directly, but it can load css files if you wish. Think of it like this - there's a $body$ statement in the middle of the template. The html generated by Pandoc goes there. Everything else in the template file stays there.
You can view the Pandoc html5 default here: https://github.com/jgm/pandoc/blob/master/data/templates/def...
In Why I do not like HugoThis is very similar to Pandoc, which also processes things into its own AST/Internal representation. It then knows how to translate its representation into a many different outputs. Pandoc is really nice and you can script it with a variety of languages, though if you really want to dig in you have to use Haskell.
Kramdown using Ruby makes it more accessible and has some cool options like table of contents generation that is more flexible than Pandoc. You can see some discussion of supporting Kramdown in pandoc. https://github.com/jgm/pandoc/issues/2711
Generally I think pandoc is the more mature tool, but I can see places where it might be a better call (especially if your app needs it as a library and you aren't willing to call a command (Pandoc).
In Kramdown – A Ruby library for parsing and converting a superset of MarkdownThe article describes Markdown[1], basically. In my opinion, content should be written once and transformed to any format[2], including ConTeXt[3], docx, HTML, EPUB, or plain text. But here's a puzzler.
Every software developer defines and uses variables. If variables are so powerful, why do WYSIWYG word processors lack the ability to quickly and easily insert variable definitions?[4] In the screenshot, the left-hand side provides an editable variable definition hierarchy, the middle pane provides a Markdown editor, and the right-hand side provides a real-time HTML preview of the content with variables interpolated and substituted.
After variables, programming language integration--such as R[5]--comes naturally. Consider the following syntax (that could be hidden through a UI):
`r#csv2md('data.csv',totals=TRUE)`
The function imports
Read the rest
data from an external data source and converts it to Markdown. The HTML version can be styled, or piped through pandoc to create beautiful PDF output[6]. In the screenshot, the left-hand side shows the csv2md command (totals are calculated automatically for numeric columns), the middle pane shows an HTML preview (real-time), and the right-hand side shows a PDF produced from the same source document using pandoc and ConTeXt.
The CSV file could also be a JSON request over HTTP, or database query, meaning that the document is always up-to-date with the most recent data: a living document. This could be accomplished without having to change the source document, as well:
`r#import(v$data$source,totals=TRUE)`
Here, v$data$source is a variable that defines a data source. In this case, the value might be 'data.csv', but could be 'protocol://host/app/api/json'. The variables themselves could be sourced from a YAML file, JSON data stream, or remote database.
This is what I've been working towards for the last several months.[7] There's more that this editor can do, but it's still in early beta stages, should anyone care to try it.
[1]: https://github.com/jgm/pandoc/issues/168
[2]: http://pandoc.org/
[3]: http://wiki.contextgarden.net/
[4]: https://raw.githubusercontent.com/DaveJarvis/scrivenvar/mast...
[5]: https://github.com/bedatadriven/renjin/
[6]: http://i.imgur.com/Qe6mTpx.png
[7]: https://github.com/DaveJarvis/scrivenvar