<div dir="ltr"><div class="gmail_extra"><div>On Mon, Mar 23, 2015 at 10:19 AM, Richard Eisenberg <<a href="mailto:eir@cis.upenn.edu">eir@cis.upenn.edu</a>> wrote:</div><div>> Forgive me, all, for asking what many may think a silly question, but I must ask:</div><div>> What's wrong with the platform?</div><div><br></div><div>You know, I don't think we ever really saw an answer to this. Well,</div><div>given that we're looking at ways to make it easier to work with</div><div>packages that aren't in HP when you have HP installed, indicating that</div><div>some people think what's wrong is that it's hard to use non-HP</div><div>libraries with HP.</div><div><br></div><div>I don't think this is what's wrong with HP, I think it's a symptom of</div><div>what's wrong. That's just making it easy to work around having</div><div>installed the platform.</div><div><br></div><div>> One non-answer to this question:</div><div>> - "It's always out-of-date." This statement, while true, isn't a direct indication that something is wrong.</div><div><br></div><div>I think this is another symptom. Yes, there are some people who always</div><div>want the newest, shiniest thing. A system where you bundle up some</div><div>best-of set of libraries won't make them happy, unless maintenance of</div><div>the libraries moves into HP, or at least has releases coordinated with</div><div>it.</div><div><br></div><div>I don't have to have newest and shiniest. I just want to get my</div><div>problem solved. But I still found that, as soon as I moved beyond</div><div>doing textbook exercises to trying to solve my problems - not</div><div>industrial grade solutions, just thing that would work for me - the</div><div>packages I wanted to use weren't part of HP. Which led to wanting to</div><div>install those packages on top of HP, which led to all the problems the</div><div>current discussions are trying to solve, which led to just installing</div><div>GHC and cabal.</div><div><br></div><div>I didn't have that problem with Python or Clojure. I didn't run into</div><div>it with Python until I was building enterprise-class systems. I ran</div><div>into other issues that made me drop Clojure before I ran into this</div><div>one.</div><div><br></div><div>So, why weren't the packages I wanted to install in the platform? If</div><div>it's really "batteries included" as the</div><div><a href="http://haskell.org/platform/contents.html">haskell.org/platform/contents.html</a> says, shouldn't they be there well</div><div>beyond just doing textbook exercises?</div><div><br></div><div>Well, how do you find packages to solve a problem in Haskell? I bet</div><div>most of you thought "Hackage" or "Hoogle". Maybe a few of you though</div><div>"Google", and even fewer thought "Stackage". Which means you're</div><div>probably checking a disorganized, random collection, may well be</div><div>checking anything on the web, and at best are searching a curated</div><div>library that's trying to do part of what HP should be doing.</div><div><br></div><div>For Python, the answer is "search the Standard library docs". For</div><div>Clojure, it's "search <a href="http://clojure.org">clojure.org</a>". And for the people who habitually</div><div>go to google for every search who are looking for things in the python</div><div>standard library or the clojure library, the first links that come</div><div>back will point back to those docs, not into an archive whose barrier</div><div>to inclusion is compilation.</div><div><br></div><div>And this creates secondary and tertiary problems. With Python and</div><div>Clojure, in the cases where I do need something that's not in the</div><div>libraries, chances are it's built on top of things that are, because</div><div>those are the things people will tend to use. With Haskell, that's not</div><div>the case. And should I need multiple such things - they'll probably</div><div>depend on the same set of libraries. Net result: nearly two decades of</div><div>writing Python code, from version 1.4 back in the last century to</div><div>version 3.4 this year, I never ran into library dependency issues.</div><div><br></div><div>So, why isn't the answer for Haskell "search the platform docs"?</div><div>Maybe because there's no way to do that? If there is, I couldn't find</div><div>it. There is documentation for the libraries, but it's just the</div><div>haddock docs that are available in the other archives.</div><div><br></div><div>Adding a search to the platform docs would be a nice step, but it</div><div>won't solve the problem. I don't think something as integrated as</div><div>python's standard library is possible, as being in the python standard</div><div>library means doing maintenance and releases on CPython's</div><div>schedule. Something like Clojure might be possible, with a small</div><div>standard set of libraries, and a curated set that builds on that, and</div><div>then the wide open archive. And of course, the platform shipping with</div><div>Cabal configured to search only the curated archive by default.</div><div><br></div><div>But that won't solve the problem unless there's broad agreement in the</div><div>community that these are the places to search for Haskell</div><div>packages. Otherwise, people trying to get started will wind up seeing</div><div>a set of choices they really shouldn't be making yet.</div><div><br></div><div>       <mike</div><div><br></div></div></div>