[harry8]

There seem to be not so many haskell applications that succeed to the point where they are of general use, as in not simply useful to programmers doing programming (probably in Haskell) At least this is a frequent observation about Haskell and one I've made myself. https://news.ycombinator.com/item?id=11907839 Obviously around here the ideal is we keep language wars/boosterism/accusations of being a virus etc out if it (Hey I /like/ Haskell, I've just found it useful for my brain rather than being especially useful for performing data transformations that come my way).

/If/ you accept that premise, why do you think Pandoc has been so very successful where perhaps other applications written in haskell have not? The Problem domain (something about writing parsers)? The contributors? The culture? Something else entirely?

Of course if you reject that premise I'd also be interested to hear your thoughts on it in as much detail as you care to provide.

Cheers.

[tarleb]

First, let me challenge the premise: the list of popular Haskell projects on GitHub is far longer than you might expect. Pandoc isn't even the most popular one: https://github.com/search?q=language%3Ahaskell+stars%3A%3E10...

But there still may be some truth to the claim. A simple fact is that smaller mind share -> fewer programs -> less chance for extremely successful projects. From personal experience: it took me three tries and multiple months to get comfortable enough with Haskell to the point that I was able to write my first contribution to pandoc (the org-mode parser), despite having dabbled in functional-style Lisp for years before that. But Haskell, as used by pandoc, isn't difficult. In fact, I often find it easier to use Haskell, thanks to its excellent type system. It's just very different and requires a bit more investment up front, with huge benefits lurking down the road.

Data to support my claim that Haskell is actually easy to use: over 300 people have contributed to pandoc, with over 100 contributing Haskell code. Many of those contributors have never written any Haskell before, but the type system helped them to find their way.

I talked a bit about the whole topic here: https://youtu.be/JpNEIpLtCHs

[harry8]

Just to address the premise with the data in the link you provide. Click your link, remove anything that is a compiler, a linter, some other parser of programming languages, a library for use when programming haskell or a programming framework and that list gets very, very dramatically shorter.

I don't think that's entirely fair fwiw, it's github ordered by stars, that will turn up things used by programmers for programming in any language. But either way I don't find the refutation convincing.

I'd love it if the premise was no longer fair. That the data really does not support it. I want monad tutorials, there are thousands. That is no exaggeration. I want Haskell applications useful for something that isn't programming a computer - really not much.

I was kind of hoping you'd say something about the parsing problem domain and why that /seems/ to work particularly well with haskell but other domains not quite so much, at least yet, and whether that can be changed or is simply the nature of statically typed, pure functional programming languages (I really hope not).

It's not "successful" let alone "extremely successful" programs so much as "existant" that is the bar that needs clearing first.

Pandoc is great. Haskell works well for those of you hacking on it. I've used it, liked it and thank you for it! It isn't necessary to have an opinion on the topic at all, of course.

[tikej]

Thank You for the ever improving org-mode parser. Org-mode is in general difficult since it's a bit of a moving target, so I'm surprised that it's so well supported!

[tarleb]

Thanks, comments like yours make my day :)

Not sure if I'll ever find the time, but I'd like to make the org-parser less useful for Emacs users. The idea is to write an org exporter which produces pandoc's AST JSON format; all Emacs Org settings would be respected that way, the detour through pandoc's parser would no longer be necessary, and remaining parser incompatibilities wouldn't matter for users exporting from Emacs through pandoc. Well, some day...

[tikej]

That will be great. Org’s greatest power it’s also a weakness – coupling with Emacs. I mean it’s great in all aspects except getting other people to use it.

Pandocs makes it possible/bearable to interact with rest of the world (I’m in the process of moving more things to org).

Being able to export directly to pandoc’s AST Json will probably allow to avoid using other programs to edit content at all! I’ll wait for this day to come; perhaps I’ll even learn enough Elisp to contribute untill then. ;)

[tome]

> There seem to be not so many haskell applications that succeed to the point where they are of general use, as in not simply useful to programmers doing programming (probably in Haskell) At least this is a frequent observation about Haskell and one I've made myself.

Yes, repeatedly, and I'd love to know why you think it matters and what it is indicative of!

[amelius]

Perhaps performance plays a role; transforming documents is usually not a bottleneck (unless you are running some server farm).

Also transforming documents seems like a task well suited to functional languages.

[mb2100]

I heard somebody say "Haskell people tend to write libraries, Rust people commandline tools". Pandoc is the excpetion that proves the rule ;-)