[Haskell-cafe] [Haskell] GHC is a monopoly compiler

[Wizek]

>
> 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 <mgsloan at gmail.com> 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 <amindfv at gmail.com> 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 <tonyday567 at gmail.com> 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 at 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/haskell-cafe/attachments/20160927/6960802a/attachment.html>