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

[Heinrich Apfelmus]

> Relative no-brainer topics in other communities like how text should
> be represented are highly contentious.

Actually, choosing a good representation for text / strings is not a 
no-brainer, and the difficulty can be traced to several features of the 
Haskell language that are simply not present in other languages. Some of 
these features are:

1) Pattern matching.

We can extract the first character and subsequent characters of a 
`String` and distinguish cases while doing so:

     isPrefixOf []     _      = True
     isPrefixOf (x:xs) []     = False
     isPrefixOf (x:xs) (y:ys) = isPrefixOf xs ys

This is not possible in, say, Python.

2) Parametric polymorphism.

The `isPrefixOf` function above is actually polymorphic. It works not 
only for `String`, but for any kind of list.

3) Lazy data structures.

We can represent text of *infinite* length!

     cycle "Haskell" :: String

And we can use them in a streaming fashion

   interact (take 10 . lines) :: IO ()

See also

   https://wiki.haskell.org/Simple_Unix_tools

You cannot do this with a standard Python string.


Also, it's not like other languages all agree on their preferred method 
of representing strings: NULL-terminated (C) vs "length-byte-first" 
(Pascal) comes to mind.


Best regard
Heinrich Apfelmus

--
http://apfelmus.nfshost.com


Christopher Allen wrote:
> 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.
> 
> 
>