Commercially (aka using Haskell to put food on the table), haskell puts you on the economic fringes - I've met a lot of smart haskellers but never a rich one. So, trust me that I'm not a bug-eyed, profit-maximizing entrepreneurial flag-waver. In my experience, as an open-source contributor within mostly a haskell context, it's not all holding hands and singing Kumbaya. The currency of transaction is different to other economic systems; things like respect, reputation, the ability to say no to PRs, and the power to bike-shed an idea to death. A haskeller who makes a living improving GHC, or teaching haskell, or writing papers survives quite well even if the tooling and documentation isn't up to scratch. But for the commercial haskell hacker, (if and when they find work), livelihood and future prospects depend on the very best tooling, the most productive documentation, and rates of adoption. In other words, commercial users need GHC to survive, but GHC looks pretty much the same without them. On Tue, Sep 27, 2016 at 10:03 AM, Jeffrey Brown wrote:

...

GHC is a great compiler, but should actively be discouraged from monopolizing the associated tooling and documentation chains.

Are you saying you wish those chains could be used with other languages? I would certianly agree to that, if it didn't harm Haskell.

Are you saying you wish Haskell documentation was available in more than one way?

It's funny to distinguish monopoly from competition in this environment, because the "haskell monopoly" is exactly the result of a competition, one between languages in the minds of programmers. Monopolies (use force of law to) align against; (open-source) programmers align together.

(Most of us, I think, rely on possession. I'm not saying it's a trait humanity quickly sheds -- but there is clearly more power in sharing, making one's work public for others to build on.)

Haskell's not really a monopoly! Possession is not the biggest player in the programming world. Some tiny information is private, yes, but the giant awesome things are given away for free. There's some abstract sense in which the technical landscape rather than the people exhibits a monopoly -- there is an energy valley, some awesome states are much easiest gotten to by a certain path, like how there is only one Jerusalem. Indeed maybe a pilgrimage ethos is helpful.

...

collaboration trumping competition

It does! Popular, widespread collaboration has more potential, because scale matters.

On Mon, Sep 26, 2016 at 3:53 PM, Tom Murphy wrote:

...

This is not the right mailing list for this ( https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@

Tom

On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote:

...

I would argue that the adventure that is GHC is a natural monopoly - an example of collaboration trumping competition. Certainly the results speak for themselves, and I personally find it the most satisfying, the only sane way to practice the craft of coding. So, as an enthusiastic user of a monopolistic service (the best power to weight ratio I could find to misquote Kmett), I would like to suggest to the community that we have a respectful discussion on the implications of natural monopolies.

Monopolies have their problems. They create power imbalances that need active management to control. A community should be particularly wary of monopolies attempting to vertically integrate up the production chain into areas where a monopoly makes less sense. I would call the whole cabal versus stack drama a text-book case of over-reach. Everyone agrees stack operates at a higher level of abstraction then cabal, on top of it is accurate. Cabal shouldn't even be allowed to compete above it's current abstraction point.

Haddock is another example of being blessed by ghc. It hits a corner-case of perfection for the "I'm a hackage library" monopoly. But the outside world of documentation, editing, rendering and conversion is invisible to this monopolistic use case. We are forced to learn and use haddock, and, for those of us with documentation needs outside hackage, the resultant workflow is cruel and unusual.

GHC is a great compiler, but should actively be discouraged from monopolizing the associated tooling and documentation chains. There is evidence of healthy open-source competition and significant gains to be had, and Haskell runs the risk of missing out.

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

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Jeff Brown | Jeffrey Benjamin Brown Website https://msu.edu/~brown202/ Facebook https://www.facebook.com/mejeff.younotjeff LinkedIn https://www.linkedin.com/in/jeffreybenjaminbrown (InMail is unreliable) Github https://github.com/jeffreybenjaminbrown

A bit of a tangent to a tangential conversation, but I wish that Haskell could move towards the "batteries included" attitude of Python's standard library.

Although I am not sure a dictatorship would be required -- benevolent or otherwise -- but batteries would certainly be welcome in the standard libraries. On 27 September 2016 at 02:25, Michael Sloan wrote:

Monopolies directed by benevolent dictators are highly efficient, and often yield results that are highly valuable. If we are running with this metaphor, I'd agree that GHC and stack could fall into such a category. For both of these, though, we do not have dictatorship, we just have spiritual leaders (SPJ!! To name one, Simon is certainly a leader, in spirit, for the community).

A bit of a tangent to a tangential conversation, but I wish that Haskell could move towards the "batteries included" attitude of Python's standard library. That is an example of benevolent dictatorship / vertical monopoly going very very well.

-Michael

On Mon, Sep 26, 2016 at 3:53 PM, Tom Murphy wrote:

...

This is not the right mailing list for this (https://wiki.haskell.org/Mailing_lists) ; forwarding to haskell-cafe@

Tom

On Tue, Sep 27, 2016 at 7:48 AM, Tony Day wrote:

...

I would argue that the adventure that is GHC is a natural monopoly - an example of collaboration trumping competition. Certainly the results

speak

...

for themselves, and I personally find it the most satisfying, the only sane way to practice the craft of coding. So, as an enthusiastic user of a monopolistic service (the best power to weight ratio I could find to misquote Kmett), I would like to suggest to the community that we have a respectful discussion on the implications of natural monopolies.

Monopolies have their problems. They create power imbalances that need active management to control. A community should be particularly wary of monopolies attempting to vertically integrate up the production chain into areas where a monopoly makes less sense. I would call the whole cabal versus stack drama a text-book case of over-reach. Everyone agrees stack operates at a higher level of abstraction then cabal, on top of it is accurate. Cabal shouldn't even be allowed to compete above it's current abstraction point.

Haddock is another example of being blessed by ghc. It hits a corner-case of perfection for the "I'm a hackage library" monopoly. But the outside world of documentation, editing, rendering and conversion is invisible to this monopolistic use case. We are forced to learn and use haddock, and, for those of us with documentation needs outside hackage, the resultant workflow is cruel and unusual.

GHC is a great compiler, but should actively be discouraged from monopolizing the associated tooling and documentation chains. There is evidence of healthy open-source competition and significant gains to be had, and Haskell runs the risk of missing out.

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

_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

---

Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

Do you have a link? I am not psychic. On Mon, Sep 26, 2016 at 6:52 PM, Brandon Allbery wrote:

On Mon, Sep 26, 2016 at 9:33 PM, Wizek <123.wizek@gmail.com> wrote:

...

...

Although I am not sure a dictatorship would be required -- benevolent or otherwise -- but batteries would certainly be welcome in the standard libraries.

On 27 September 2016 at 02:25, Michael Sloan wrote:

...

A bit of a tangent to a tangential conversation, but I wish that Haskell could move towards the "batteries included" attitude of Python's standard library. That is an example of benevolent dictatorship / vertical monopoly going very very well.

That was attempted. Everyone hated it and newcomers are loudly warned to never ever use it.

-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

What is it to include batteries? What is a PRI? (I googled both for like ten minutes.) On Mon, Sep 26, 2016 at 7:55 PM, Francesco Ariis wrote:

On Mon, Sep 26, 2016 at 07:49:57PM -0700, Michael Sloan wrote:

...

Do you have a link? I am not psychic.

https://en.wikipedia.org/wiki/Haskell_Platform _______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.

-- Jeff Brown | Jeffrey Benjamin Brown Website https://msu.edu/~brown202/ Facebook https://www.facebook.com/mejeff.younotjeff LinkedIn https://www.linkedin.com/in/jeffreybenjaminbrown (InMail is unreliable) Github https://github.com/jeffreybenjaminbrown

On Tue, Sep 27, 2016 at 12:11 PM, Michael Sloan wrote:

LOL! Oh man, this guy must be pulling my leg... Haskell platform was never a batteries included plan. It was a plan for package bureaucracy, mixed in with a broken installation approach. Sorry, but that was not a good enough attempt at emulating python's "batteries included" . From https://www.python.org/dev/peps/pep-0206/

The substance of your positions on packaging/HP aside, it has been 15 hours since SPJ's email about having more respectful discussion in our community. Please speak with civility. Tom

Thanks for the graceful reply! So as not to think I'm singling anyone out, I should say the "hatchet job" comment above is also the kind of thing very few of us want to be part of our day-to-day conversation. Everyone makes mistakes, not a big thing! It's just important that, on average, when people come visit our corner of the internet the thing they see isn't people saying hurtful things to each other. When I started here I felt like I could ask a question and not be ridiculed for it. Others should have the same feeling when they come by. Thanks! Tom On Tue, Sep 27, 2016 at 12:24 PM, Michael Sloan wrote:

Fair point, my mistake, sorry. I will try to tone it down and be a more civil communicator. To me equating the Haskell Platform with python's batteries included approach is laughable, so I laughed.

I find Brandon's opinions on things to often be diametrically opposed to my own, and this seems to be a cause of a great deal of contention.

-Michael

On Mon, Sep 26, 2016 at 8:20 PM, Tom Murphy wrote:

...

On Tue, Sep 27, 2016 at 12:11 PM, Michael Sloan wrote:

...

LOL! Oh man, this guy must be pulling my leg... Haskell platform was never a batteries included plan. It was a plan for package bureaucracy, mixed in with a broken installation approach. Sorry, but that was not a good enough attempt at emulating python's "batteries included" . From https://www.python.org/dev/peps/pep-0206/

The substance of your positions on packaging/HP aside, it has been 15 hours since SPJ's email about having more respectful discussion in our community. Please speak with civility.

Tom

On Mon, Sep 26, 2016 at 11:11 PM, Michael Sloan wrote:

LOL! Oh man, this guy must be pulling my leg... Haskell platform was never a batteries included plan. It was a plan for package bureaucracy, mixed in with a broken installation approach. Sorry, but that was not a good enough attempt at emulating python's "batteries included" . From https://www.python.org/dev/peps/pep-0206/

Wrong. Its enemies did a very thorough hatchet job. But they did let on their real intent: "batteries included" meant they can't force people to install their new incompatible batteries whenever they decide. "Batteries included" was exactly what they did NOT want, and do not want, because it limits them; unless, of course, they are the only source of the batteries. So now we have a battery store run by a company, which also ships its own build tool that works primarily with that store, and requires you to specify which generation of batteries to use --- and still runs into conflicts when someone wants to mix different versions of things because they're building the tool with the parts they need instead of the ones authorized by the store. Granted, a largeish chunk of the problem is that putting anything into the "batteries included" package space (ghc global packages) makes using any other versions of those packages scary at best. This is still a problem for the packages that ghc itself uses, and are therefore difficult to upgrade without replacing ghc. -- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

On Tue, Sep 27, 2016 at 10:37 AM, Tony Day wrote:

...

Its enemies did a very thorough hatchet job.

Not thorough enough I say, as a sworn enemy. I actually have haskell platform installed with batteries included at work on windows (because that's how we set up python - I pleaded but got nowhere). I even have a current bug falling somewhere between the platform and stack - something crashed looking for the standard linux command line tools - was it the msys2 or mingw in platform, or was it stack? Where do I even turn for help?

I'm not part of the 'they' straw-man you sketch out, and I'm asserting that the reality in the community is the opposite - commercial Haskell is the runt of the litter and shame on the community for not acknowledging this.

At the very least, bashing commercial Haskell interests for being commercial is a weak argument, given the reality of how little commercial scope exists right now. Accusations of engagement in monopolistic intent is, quite frankly, pure projection.

On Tue, Sep 27, 2016 at 1:21 PM, Brandon Allbery wrote:

...

On Mon, Sep 26, 2016 at 11:11 PM, Michael Sloan wrote:

...

LOL! Oh man, this guy must be pulling my leg... Haskell platform was never a batteries included plan. It was a plan for package bureaucracy, mixed in with a broken installation approach. Sorry, but that was not a good enough attempt at emulating python's "batteries included" . From https://www.python.org/dev/peps/pep-0206/

Wrong.

Its enemies did a very thorough hatchet job. But they did let on their real intent: "batteries included" meant they can't force people to install their new incompatible batteries whenever they decide. "Batteries included" was exactly what they did NOT want, and do not want, because it limits them; unless, of course, they are the only source of the batteries.

So now we have a battery store run by a company, which also ships its own build tool that works primarily with that store, and requires you to specify which generation of batteries to use --- and still runs into conflicts when someone wants to mix different versions of things because they're building the tool with the parts they need instead of the ones authorized by the store.

Granted, a largeish chunk of the problem is that putting anything into the "batteries included" package space (ghc global packages) makes using any other versions of those packages scary at best. This is still a problem for the packages that ghc itself uses, and are therefore difficult to upgrade without replacing ghc.

The bug you're referring to is this:

https://github.com/haskell/haskell-platform/issues/251 You can work around it by adding `system-ghc: false` to your config files. And yes, that basically means that everything shipped with the HP besides the Stack executable itself is being ignored. Michael

Thanks to you both.

mailinglists (such as cafe — look, it worked!)

I'm totally sold on this new-fangled mailing list thing. It's like slack for adults who like to shuffle at their own pace.

Not thorough enough I say, as a sworn enemy.

I'm not really - I was kind of glad when they installed Haskell Platform with batteries so I could prove a point, if only to myself, that stack was the better choice, but it's been smooth sailing except for this one bug. I've been able to install everything I need, creating an isolated and sane oasis in this weird windows world. I think I unfairly identify HP with cabal hell, and then the flashbacks trigger. On Tue, Sep 27, 2016 at 5:50 PM, Gershom B wrote:

On September 27, 2016 at 3:37:40 AM, Tony Day (tonyday567@gmail.com) wrote:

...

I even have a current bug falling somewhere between the platform and stack - something crashed looking for the standard linux command line tools - was it the msys2 or mingw in platform, or was it stack? Where do I even turn for help?

This patch should fix the issue if it is what I think it is. But the patch is not in a release yet :-/

https://github.com/commercialhaskell/stack/pull/2552

One workaround is suggested on an associated ticket: https://github.com/commercialhaskell/stack/issues/1714

Another workaround as I understand it is to just invoke stack always with --no-system-ghc for now.

As to where to turn for help, I think the usual sources all would work — irc, slack, mailinglists (such as cafe — look, it worked!), stackoverflow, etc.

Hope this helps, Gershom

* Michael Sloan:

So in other words, the Python guys knew that an approach like Haskell Platform would never work well, and so they didn't do it. Instead they built one big excellent standard library.

But this approach causes problems. There are quite a few example where Python got things wrong and did not fix them for a long time due to backwards compatibility concerns. Examples are HTTPS with host name validation, and email parsing. The trouble is that if you get it wrong, you still have to support it for a long time (perhaps eternally) because your users want to upgrade the platform without rewriting their software. In the Haskell context, an early batteries-included version of the standard library would likely have relied extensively on strings-as-lists and lazy I/O, and the latter is somewhat controversial these days (the former is rather inefficient).

On Mon, Sep 26, 2016 at 08:56:55PM -0500, Christopher Allen wrote:

Streaming is a good example here. It's not "obvious" how to do many things in Haskell that are "obvious" in other languages. Partly because industry hasn't used languages like Haskell much, partly because the canvas we work with permits more structure.

Is it obvious how to do streaming in other languages?

On Mon, Sep 26, 2016 at 05:25:34PM -0700, Michael Sloan wrote:

A bit of a tangent to a tangential conversation, but I wish that Haskell could move towards the "batteries included" attitude of Python's standard library. That is an example of benevolent dictatorship / vertical monopoly going very very well.

The problem with batteries included is, that the batteries might never be the best. I think that's already the case for some parts of the Python standard library, that other external libraries are preferred. Now you still have to educate Newbies which libraries they should use.