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

[Joachim Durchholz]

Am 27.09.2016 um 23:25 schrieb Olaf Klinke:
> Can someone please define what exactly a "batteries included"
> standard library is?

Anything you'll typically need is already available.
For some value of "typically need", so it's slightly squishy - here's a 
list of batteries I'd like included:
- Reading/writing files
- Reading over HTTP (reliably - HTTP is surprisingly complex)
- Search&replace in test streams
- Easy-to-use string->string maps
- JSON parsing and printing (bonus points for YAML)
- GUI stuff
- Website stuff
- Sending mails
- Solid ecosystem:
   - build system,
   - library directory,
   - no-brainer automated testing support.
     (Complicated testing means more bugs in test code than in
     production code - this diverges.)

 > 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 do not think that Python actually comes with all batteries included.
And in some areas support is pretty bad.

>  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.

That, and the idea that class and function declarations are executable 
statements.
Circular dependencies are "handled" by passing partially-initialized 
objects around; the Python interpreter handles this with no problems, 
but programmers have fun because nobody assumes incomplete initialization.

I.e. Python's language semantics is broken by design in pretty 
fundamental areas.

That said, it's good for banging something together quickly. Been there, 
done that, got the t-shirt.
Just don't do anything that you need a team for with it, the lack of 
guarantees will really start to hurt.

> 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.

I think Python shares that problem with Lisp: it's so easy to add 
another meta-idiom that too many people actually do this, and most don't 
even think about composability or guarantees.

 > 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.

I sense a conflict of objectives here.
Having many batteries pushes you towards wide APIs.
However, the wider an API, the harder it is to make it combinable. More 
surface that must be made to match.

Making an API that's feature-complete *and* narrow is really hard and 
takes a huge amount of designer and programmer time, plus the 
willingness to lose most of your existing user base for an unproven idea 
of improvement. This road is a really hard one, and you need corporate 
backing or personal obsession to follow it.