=================
 Dependency hell
=================

One of the things I dislike about Haskell is libraries: loads of
indirect dependencies, usually static linking (hence no automated
system updates with common setups), subpar reimplementation of C
libraries (well, that applies to most languages), sometimes cruel and
unusual abstractions, and/or poor documentation. To be fair, there's
plenty of nice ones, and I'm generally happy with those, just not with
everything about them.

Working on a project based on pgxhtml (mentioned in a post a month
ago), I found that HXT ("The Haskell XML Toolbox") lacks something I
needed, while it's not trivial to add, but libxml supports it. I also
noticed that the dependency graph was huge.

Omitting the details, I spent the next few days switching from HXT to
libxml/libxslt/libexslt, from high-level to low-level PostgreSQL
(libpq) bindings, and eliminating web-related packages (even though I
didn't use any fancy web framework in the first place), switching to
plain CGI with custom application/x-www-form-urlencoded parsing. Went
from about 200 LOC to about 300, but the dependency graph was trimmed
considerably. The functionality is not exactly the same, but got what
I needed, and removed what I didn't need.

I have been thinking of rewriting it in C, but perhaps it would be
taking that too far: the code size would increase further, memory- and
type-safety would further decrease. This seems to be mostly about
balancing between different types of bloat and complexity.

This week I started doing something similar with work projects:
removed one heavy dependency between two of those, and probably will
try to cut out a bit more. There it also comes with minor drawbacks,
but I guess I'm assigning a bit more weight to dependencies when
judging overall complexity now. Or not exactly "now", but rather
sometimes, depending on a project, yet got focused on it now a bit
more than usual.


----

:Date: 2019-02-07