Andrew, I understand why you're concerned, but I would encourage you to press onward. In my experience - building commercial web applications in Haskell for the last 4 years - Haskell's library ecosystem works very well in practice. In a recent project, I was able to run an interesting experiment: half my team (and half my code) was using JavaScript, and half was using Haskell. In both cases, we made an effort to avoid "not invented here" syndrome, and I think we largely succeeded in maintaining the right mentality about outside libraries. However, the *results* of that mentality were very different in these two cases. In the case of JavaScript, for any problem we had, there were many libraries that tried to solve it. That was awesome. However, before integrating a library, we had to spend a lot of time testing it, making sure it wouldn't interfere with our existing code, and integrating it. After 2 years, we had about 10 JS library dependencies, and we had gone through 10 or 20 more - integrated them, found they had serious issues, and then been forced to replace them. In Haskell, there were usually only one or two choices for a particular problem. However, with a cursory glance of the code, we were usually able to determine that the code didn't do anything nasty. With QuickCheck and ghci, we were able to test things out very rapidly, to make sure they basically worked. Although cabal hell did occasionally rear its head, we were very strict about dependency versioning (eventually adopting Nix, which has very good Haskell support, to lock everything down) which meant that only the person working on the library integration had to deal with any sort of hell, and the rest of the team could simply pull and build. By the end of the project, we were using over 80 libraries from Hackage (more than 200, if you count dependencies-of-dependencies), there was only one time we had to replace a library that had made it past our initial vetting process. I don't know much about how Hackage works or what the download counts represent, but I have found the download counts to be a useful, very rough approximation of relative popularity. If one library has wildly more downloads than another, I'll often look at it first - although, I'll usually look at the other ones as well, eventually. Although the version numbers can look strange, you should know that the Package Version Policy (PVP) counts both the first and second digit groups as "Major version" numbers, with the first group usually used incremented only when the project is seriously overhauled. So, many projects stay at 0.1 indefinitely. For example, the containers library https://hackage.haskell.org/package/containers is currently at version 0.5.6.3, despite being very mature, completely stable, and in use by thousands of projects. About 10% of the 200 transitive dependencies in my earlier project were version 0.1.something. So, to make a long story short, my experience with Hackage libraries has been overwhelmingly positive. The success rate with integrations has been over 98%, and the vetting and integration process has generally been quick and painless. Compared to the other ecosystems I've had experience with, I've been able to integrate - and *keep* integrated, for the long haul - far more code from Hackage than from anywhere else. I hope you'll give it a shot, and I think you'll be pleasantly surprised by how things turn out. Regards, Ryan On Wed, Sep 30, 2015 at 6:22 AM, emacstheviking wrote:

Andrew,

The sheer number of packages is overwhelming and you can spend a very long time indeed trying to find something "suitable"... which... eventually may lead one to the conclusion, "It'll be quicker to roll my own" and then "Hey, I will upload it to Hackage, someone else might like it"... and so the list grows and grows and what began as an altruistic thought serves only to make it harder for the next guy to "find a suitable package".

Personally, I've walked away from Haskell purely because I got fed up being continually bitten by "cabal hell". It's a shame because apart from LISP no other language has had such an impact on my thinking.

I did find that whatever package I used though, they tend to work, so maybe take the first one and get on with it, that's what I used to do.

Hope that helped, it probably didn't. All the best, Sean Charles.

On 28 September 2015 at 16:15, Andrew Bernard wrote:

...

Since starting to look on Hackage for packages for such vital things as queues and algorithms, I am surprised to see very low numbers of downloads for packages that seem to me to be vitally important. For example, queuelike has only been downloaded 1617 times since being uploaded in 2009. Similar very low numbers seem to apply for many packages. Another example is cubicspline with only 485 downloads.

My question is, are the numbers on Hackage correct, and if so, do they indicate hardly anybody uses them, or indeed Haskell? I am starting to wonder.

I also notice version numbers are very low, often less than one and most often around 0.1 or so. This is either a display of extreme modesty on the part of Haskell library code developers (in fact, often found in open source communities), or an indication of lack of maturity of the code. Overall I am puzzled about this. I am trying to establish what packages to use in my coding and there seems to be little indication of what to choose, and how to assess code maturity. What am I missing?

Andrew

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

_______________________________________________ Beginners mailing list Beginners@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/beginners

I remember Louis as being quite active on the Libraries mailing list as the queue package was developed and possibly was even keen to have a priority queue include in the Base library "Containers". So I expect the code is of pretty high quality and a quick scan indicates Louis went as far as adding SPECIALIZE and INLINE pragmas for performance. However, queues seem to be relatively unused but functional programmers (Chris Okasaki's famous Edison data structures have a similar "small" download count on Hackage). Maybe even the author didn't need them often after they were written. On 30 September 2015 at 14:29, David McBride wrote:

Ultimately when browsing hackage, there are a few things on a package that stop people from using them. Louis Wasserman, no idea who that is. Last updated in Aptirl 2009, boy that's a long time ago. No link to his repository, no link to documentation or a website.

This could be a great library, a real diamond in the rough, but there is no shortage of alternative data structure libraries on hackage that have been tried and tested.

Hello, As for the queuelike package, I think its non-priority queue part loses users to container's Sequence, monadic queues seem to at least partially overlap in functionality with streaming libraries (pipes, conduit), and priority queues are also implemented by a couple of packages (priority-queue, pqueue). (also, I imagine not everyone likes the type class + implementations style of programming.) Unfortunately, Hackage is a bit of a mess. I've started programming in Haskell years after the last version of queuelike was uploaded, and today is the first time I've heard of it. The last time I needed a queue I've used Sequence, and when I was googling for priority queues I didn't see any mention of this package. I figure it being filed under "Algorithms" and not "Containers" also doesn't help things. As for the 0.* versions, as it was said, people in general seem not to pay attention to the numbers, and only bump the major version when they make some really significant change, or they run out of comfortable minor version numbers. Hackage's package versioning policy insists only on bumping the minor version number for breaking changes. Best regards, Marcin Mrotek