Live data from Hacker News

Reflecting on Haskell in 2016

stephendiehl.com

71–80 of 107 posts

Re: Reflecting on Haskell in 2016

#71
post #6
post #5

The Haskell community identifies "no documentation" as a key flaw of their own community? I was going to ask why there hasn't been more uptake of Haskell for all of the apparently cool ideas that are there, but nevermind, I don't think I need to ask now.

Note that it's a contentious issue. Lots of people think there's plenty of documentation. I'm one of them. The people who think documentation is lacking seem to be people who need worked examples of things to understand them. I'm of the opinion that worked examples are often worse than no documentation.

> I'm of the opinion that worked examples are often worse than no documentation.

That's completely baffling to me so I'd be really curious to hear your reasons (or those of someone who shares that opinion, as there are others in the thread apparently).

When learning about an abstract notion, it has been my experience that having good examples in mind (in the sense that they are not too complex, but non-trivial enough to illustrate the relevant aspect of the notion at hand) is very helpful, if not essential, for comprehension. All the more so for very abstract subjects (e.g. back in grad school I was studying algebraic geometry, and you can't go very far in that subject trying to prove things about functors on the category of rings without examples in mind that connect the abstract nonsense to some actual geometric meaning).

Speaking of abstract nonsense, by the way, under the Curry-Howard isomorphism, publishing a library with type signatures but no worked out example is equivalent to publishing a mathematical paper consisting entirely of lemmas with no example of how to combine them to prove something interesting (in fact, it's worse, because the expressiveness of the Haskell type system obviously pales in comparison to the language of mathematical papers). I would almost certainly reject a paper like that if I received one for review, and I expect most referees would too.

Re: Reflecting on Haskell in 2016

#72

Out of curiosity what progress has been made in regards to improving the ergonomics of records in Haskell? Stephen references that an answer is in the works, but it looks like it has stalled out.

I use Vinyl[0], though be warned it uses advanced Haskell many seem disgruntled with in this thread.

You may be alright with vanilla Haskell records now that duplicate record fields are allowed in GHC 8.

I think something like rawr[1] might be what most are looking for when talking about better Haskell records, though.

0: https://hackage.haskell.org/package/vinyl-0.5.3/docs/Data-Vi...

1: http://hackage.haskell.org/package/rawr-0.0.0.1/docs/Data-Ra...

Re: Reflecting on Haskell in 2016

#73
post #53

Earlier quoted context omitted.

> I have yet to see a followable code case demonstrating the use of custom monads (not IO or Maybe or lists etc) that show why (when) I should ever write my own, to understand even just using them better generally. For an interpreter I'm working on I have an "Eval" type, implemented as a newtype wrapper around a transformer stack. This gives me a context to work in where I can access variables in scope (carried in a…

That looks like more of a combination of existing monads than a truly new monad. I must admit that I can't remember ever creating my own monad from scratch.

> That looks like more of a combination of existing monads than a truly new monad.

Well sure, but if we're going to exclude those then the grandparent's ask is a bit high: either we present something useless and pedagogic, or we present something useful that exists in a library somewhere, or we present something new and useful... that we should then also put in a library somewhere!

Re: Reflecting on Haskell in 2016

#74

I started learning Haskell this year. One of the small bumps I had was getting my environment setup. Based on my experiences with Ruby and Node, I knew I'd want to have a tool for managing the language's version and dependencies per-project, so I ended up going with stack [0]. Arriving at that decision required a bit more reading than with other languages. Additionally, while setting up stack, I thought their docs we…

I'm in the same boat as you. I learning Haskell earlier this year, and while I really really want to like it (if nothing else, I'm a sucker for type systems) and even start using it for projects I can't when, IMO, there are languages out there that feel so much more productive to me. A few key concerns I have with the language and community: 1. I feel like there is a really strong push towards writing concise code, w…

> The millions of syntax extensions in ghci, some of which are incompatible with each other. This means ProjectA and ProjectB can be written in completely different, possible incompatible, 'dialects' of Haskell.

To my knowledge, there are no GHC extensions that are incompatible on a project level (that is, you could have one enabled in one file, another enabled in another, and it would break things). I'm much less confident that there are no extensions that are incompatible if you try to use them within the same file, but I am not able to think of any off the top of my head.

Re: Reflecting on Haskell in 2016

#76

Out of curiosity what progress has been made in regards to improving the ergonomics of records in Haskell? Stephen references that an answer is in the works, but it looks like it has stalled out.

I find the ergonomics of records with RecordWildCards great for most of my uses. Nested records in Haskell are still a pain if you're trying to do things to internal bits directly - that's what lenses address.

Re: Reflecting on Haskell in 2016

#77
post #35

I started learning Haskell this year. One of the small bumps I had was getting my environment setup. Based on my experiences with Ruby and Node, I knew I'd want to have a tool for managing the language's version and dependencies per-project, so I ended up going with stack [0]. Arriving at that decision required a bit more reading than with other languages. Additionally, while setting up stack, I thought their docs we…

I think the haskell-lang.org [0] people did a good job trying to get a better "getting started" [1] experience for new haskellers. [0] https://haskell-lang.org [1] https://haskell-lang.org/get-started

Although I recommend stack heartily, note that haskell-lang is hosted by FP complete, and IIRC they either fully developed or had a big part of developing stack. Just FYI.

Re: Reflecting on Haskell in 2016

#78
post #61
post #47

Earlier quoted context omitted.

My point is: I tried several times to write something in Haskell, I really want to like the language. But each time I felt too stupid for it, it just feels like too much work. In Elm I got a working app in a day and enjoyed the experience. Isn’t there a lesson for the Haskell community other than “Elm does polymorphism wrong, meh”?

Maybe both are catering to different programmers?

Is Haskell catering to programmers who don't want to be able to get a simple app up in a day? Who are these programmers who fight through the first steps of picking up a language and are thrilled by that.

Re: Reflecting on Haskell in 2016

#79
post #62
post #55

Earlier quoted context omitted.

> I stress that the types are not enough Exactly. Quick, tell me what this function does: foo :: Num a => a -> a

It foos a number into another number, what else? If it does something else or if it's unclear what fooing is, it should be renamed and the parameter types should be at least aliased to something more adjusted to the task. It's basically Haskell code smell. Other languages we are used to do not allow exact precision when talking about input and output types, that's why we don't think about overly-generic function decl…

[deleted]

Re: Reflecting on Haskell in 2016

#80
post #62
post #55

Earlier quoted context omitted.

> I stress that the types are not enough Exactly. Quick, tell me what this function does: foo :: Num a => a -> a

It foos a number into another number, what else? If it does something else or if it's unclear what fooing is, it should be renamed and the parameter types should be at least aliased to something more adjusted to the task. It's basically Haskell code smell. Other languages we are used to do not allow exact precision when talking about input and output types, that's why we don't think about overly-generic function decl…

Just out of curiosity, how would you change the following definition to make sure it's clear without reading anything else?

    words :: String -> [String]
If you say it's already obvious, I disagree, since this code prints "1":

    main = print $ length $ words "jack am I"
(The spaces in the string are six-per-em unicode characters)
Post reply on HN