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.