Scripting / Command-line applications best in class?

[ad-si]

I feel like scripting / cli apps should maybe be "Best in class".
Especially because scripts are normally not tested (well), type-safety should be mandatory.
Furthermore there are some really good modules available for building CLI apps.

[Gabriella439]

The main reason why I don't give Haskell a "Best in class" is mainly due to scripting (as opposed to more stable command-line applications). Specifically, if users want to be able to edit and run source code directly (i.e. using runghc or something similar) then they need to have the Haskell toolchain installed. However, the Haskell toolchain has a large footprint and is not installed by default on most systems. Compare to Python, which doesn't have these issues.

However, for stable command-line applications (i.e. such as pandoc or bench) then I think you can possibly make an argument for this but I'm still not 100% convinced it is best in class. The strongest argument in favor of Haskell is that it is typed and much easier to author compared to other type-safe languages, but I think the strongest arguments against is that the ergonomics for small programs are still not as good as some dynamically typed languages. For example, the ease of parsing/manipulating JSON is still not as good as languages which have anonymous records or ergonomic dictionaries. As another example, Haskell has no analog of Python's docopt package.

[ad-si]

Ok, having to install the Haskell toolchain first is indeed a problem.

JSON parsing with Aeson feels pretty solid. Even more so if you want to make sure the parsed JSON objects are consistent / valid.

Mh, maybe someone should port https://github.com/felixSchl/neodoc to Haskell.
It's basically docopt written in PureScript.

But yeah, I'm not insisting it should be "Best in class", just wanted to hear your thoughts on it and I guess giving it some more time is the right thing.

[nponeccop]

Ok, having to install the Haskell toolchain first is indeed a problem.

I find binary dynamic GHC libraries pretty unbloated. However, this approach doesn't work well in practice:

• Several (reported) bugs in Stack and Cabal prevent dynamic-only Haskell from working well
• Lack of ABI forces too much unnecessary recompilation (which is slow, but that by itself is not a problem)
• Stack largely ignores the binary packaging issues - it forces users to install everything from source which is painfully slow and was acceptable in 2000s but not now. Compared to that, Perl and Python have many libs prepackaged so I don't generally need to wait for module compilation. Network gets faster every year while compilation speed doesn't. And this issue isn't easy to solve, we need some kind of stack snapshots-compatible packaging using native OS package managers.
• There is some sort of "monolithic executables lobby" in Haskell community which shifts focus/priorities and prevents these issues from solving, so there's little hope for near-term improvements.

Another issue for me is that Haskell dictionaries have pretty low performance compared to PyPy and Perl. While CPU performance can be solved by mutability, the memory footprint remains several times larger than state of the art, so this lack of densely packed dictionaries prevents adhoc analysis of large text datasets. So I use other languages for that.

Another issue is IO - if I need to split and join pipelines it doesn't work well yet. Some packages are not fully symmetric yet (I mean duality between production and consumption, map/contramap), some errors are not catched statically (it's pretty easy to shoot yourself in the foot by creating code which doesn't work, mostly in the domain of non-linear - forking and joining - pipelines). And without pipelines Haskell's code becomes too ugly and/or prone to leaks.