[Haskell-cafe] Batteries included (Was: GHC is a monopoly compiler)

Michael Sloan mgsloan at gmail.com
Tue Sep 27 22:25:21 UTC 2016

Hi Olaf!

I believe I was the one to recently bring up the subject of "batteries
included".  I think wikipedia has a good treatment of it -

> Python has a large standard library, commonly cited as one of Python's greatest strengths,[77] providing tools suited to many tasks. This is deliberate and has been described as a "batteries included"[29] Python philosophy. For Internet-facing applications, many standard formats and protocols (such as MIME and HTTP) are supported. Modules for creating graphical user interfaces, connecting to relational databases, pseudorandom number generators, arithmetic with arbitrary precision decimals,[78] manipulating regular expressions, and doing unit testing are also included.

Happily, there are efforts underway to fix this problem for Haskell.
In particular, I think the team of people working on the new
foundation library has a very good chance on delivering on the promise
of having batteries included for Haskell.  I implore the community to
give foundation a try and pitch in to make it happen.  Want to make
sure we don't screw up new-base?  Help guide foundation's development.
Here is the link:


Why is the Python <-> Haskell comparison unfair?  We need to be
realistic in our self analysis, and comparing to a very successful
language can indicate what we need to do to make Haskell even more

Fairness does not matter.  The world is not fair, it is made up of
people who have a wide range of opinions and attitude.  Many in the
community would love to share Haskell with more people.  Why?  Because
it is such a valuable thing to learn, and one of the best general
purpose programming languages out there.

Why identify Haskell as a research language, when it has so clearly
grown far beyond that vision?  Even if it is considered a research
language, isn't it good for your research to reach the widest audience
possible?  This means that the fantastic ideas that make up Haskell /
GHC can reach a wider audience.  Some members of that audience are
going to be designing future languages.  Do we really want these
future language designers to do that without learning Haskell?  I
would prefer that they learn it.

I have recently had a discussion, which I find quite disturbing, where
prominent community members are essentially saying that they are
content with (avoiding success (at all costs)), rather than (avoiding
(success at all costs)).  Take a look:

Frankly, these statements frighten and confuse me.  It seems blatantly
unreasonable to me, to make the statement that we should be apathetic
towards marketing and lowering the barrier to entry for Haskell.


On Tue, Sep 27, 2016 at 2:25 PM, Olaf Klinke <olf at aatal-apotheke.de> wrote:
> Can someone please define what exactly a "batteries included" standard library is? IMHO that Python-Haskell comparison is unfair. Although both claim to be general-purpose languages, the focus in Haskell certainly has been on language research for most of its life.
> I recently hacked together a web client in python, my first project in that language. Documentation is excellent. Yet I am still horrified I had to use a language that provides so few static guarantees to control megawatt machines.
> What puts me off Haskell nowadays is the direct result of Haskell's roots in language research: Often when I come across a package that does what I need, it uses the conduit, lens or another idiom, which are like a language in a language to learn. In milder ways Python seems to suffer the same problem. So please, developers: Write more batteries, but make them expose a neat lambda calculus interface if possible that can be combined freely with other batteries.
> Regards,
> Olaf
> _______________________________________________
> 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.

More information about the Haskell-Cafe mailing list