wither the Platform

[Jeremy O'Donoghue]

On 24 March 2015 at 03:07, Mike Meyer <mwm at mired.org> wrote:

> On Mon, Mar 23, 2015 at 10:19 AM, Richard Eisenberg <eir at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150324/108d328f/attachment.html>