On 24 March 2015 at 03:07, Mike Meyer <mwm@mired.org> wrote:
On Mon, Mar 23, 2015 at 10:19 AM, Richard Eisenberg <eir@cis.upenn.edu> wrote:
> Forgive me, all, for asking what many may think a silly question, but I must ask:
> What's wrong with the platform?
> One non-answer to this question:
> - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong.

I think this is another symptom. Yes, there are some people who always
want the newest, shiniest thing. A system where you bundle up some
best-of set of libraries won't make them happy, unless maintenance of
the libraries moves into HP, or at least has releases coordinated with
it.

+100

For me, HP is the only Haskell environment I will consider because:

1) Code I write needs to run on Mac (where it is written), Windows and Linux (where it is usually used). None of the 'build it yourself' alternatives gives a way to ensure, with confidence, that I have the same platform on each of my machines.
2) Life is too short to spend time messing around with things that won't build, out of date 'install from source' instructions and the like.
3) Haskell is not my core day job. HP always works, and is stable, predictable and documented.

However, it seems to me that each HP release is essentially a snapshot, and is not really maintained thereafter. What I would love to see is for HP releases to have some level of maintenance. In particular, Michael Snowman's comment earlier that:

"the version of attoparsec used by the platform today forces an old version of aeson to be used (0.6.2.1). The combination of that aeson and attoparsec version is vulnerable to an incredibly severe DoS attack for specially crafted JSON strings"

goes to the heart of the matter for me.
 
I didn't have that problem with Python or Clojure. I didn't run into
it with Python until I was building enterprise-class systems. I ran
into other issues that made me drop Clojure before I ran into this
one.

So, why weren't the packages I wanted to install in the platform? If
it's really "batteries included" as the
haskell.org/platform/contents.html says, shouldn't they be there well
beyond just doing textbook exercises?

I think there are a few issues here, some of which are probably specific to the Haskell community.

- There are not many Haskell users in the enterprise space who are in a position to make significant contributions of reasonably complete and 'battle tested' libraries for common problems. The OCaml community is very well served by the efforts of Jane Street in this respect.

- Related to the above, there are many libraries that are incomplete (as typically the contributor will solve the subset of the problem that relates to his/her needs.

- In some cases, people simply find better ways to do something that was previously messy, and this renders older (and otherwise stable) APIs and libraries unattractive. An example would be the way that Lenses have hugely simplified working on certain types of problem.

- There is a huge gap in understanding between even moderately capable Haskell programmers and those at the cutting edge. I believe that this could in many cases be filled with better documentation, but the fact remains that some packages have APIs which are designed at a level of type abstraction that is unnatural to me, which makes them very hard to use. As an example, when I look at the package documentation for Data.Lens.Partial.Common, I have no clue as to where to even start. Perhaps this is a reason why there are now almost as many Lens tutorials as Monad tutorials (and with a regrettably similarly poor signal to noise ratio). OTOH, maybe my IQ is just too low to be a Haskeller :-(

- I think, perhaps, that Haskell shares with Lisp communities the tendency that "we have a tool of great power available to us, so it is easier to roll our own solutions than use someone else's". I understand this, but the overall community is much better served where it can get behind a single library in each area that covers all major use cases, and which is well documented, maintained, builds cleanly and runs on all major platforms and generally remains backward compatible on upgrade.

I'm not sure if I am really offering any solutions here, but FWIW, I would advocate:

- HP probably does need to become smaller,of only because we do not all agree on what 'Batteries Included' means for Haskell.

- HP should be maintained, at least for critical bug fixes, until at least release of next HP + a short period (maybe 3 months).

- I would love to see a community effort to develop (or select from existing libraries) 'one library to rule them all' in some of the critical areas. This effort would include comprehensive documentation for every function, a meaningful set of examples and a commitment to bug fixes. The Python Standard library would be a good place to start in terms of which libraries are most needed - obviously not for API design!

Finally, to Mark and the HP team: the work you have done over the years is outstanding. The work of patiently pulling together inputs from many moving targets, testing on multiple platforms and releasing is patient, challenging and unglamorous. My sincere thanks to you all.

Best regards
Jeremy