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

[Christopher Allen]

Batteries included is a bad idea when the community is this divided.
Relative no-brainer topics in other communities like how text should
be represented are highly contentious.

I'd sooner see some basic test cases hammered out and integrated into
base before a real attempt at this is launched. Something that would
help the Cabal devs.

On Tue, Sep 27, 2016 at 6:14 PM, Joachim Durchholz <jo at durchholz.org> wrote:
> 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.
>
> _______________________________________________
> 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.



-- 
Chris Allen
Currently working on http://haskellbook.com