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

Thu Sep 29 14:52:36 UTC 2016

When parametricity isn't an option, utf-8 is taken for granted, the
language is ambiently strict, it's quite a bit more straight-forward
what you want to do, even if the actual implementation is not trivial.

I'm not saying the decision should be trivial for us, I'm saying that
any attempt to unify the disparate things Haskell programmers want is
going to be much harder than it would be with other languages and
ecosystems.

Also, I use this library for my work regularly:

https://github.com/snoyberg/mono-traversable/blob/17eebcfa2e96e923270e1284675456a76e680119/mono-traversable/src/Data/Sequences.hs#L1236-L1237

With Text (Strict | Lazy) and ByteString (Strict | Lazy)

This suits me fine, but I know people for whom mono-traversable is a hard-no.

On Thu, Sep 29, 2016 at 9:43 AM, Heinrich Apfelmus
<apfelmus at quantentunnel.de> wrote:
>> 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.
>>
>>
>>
>>
>
> _______________________________________________
> 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