Live data from Hacker News

Reflecting on Haskell in 2016

stephendiehl.com

11–20 of 107 posts

Re: Reflecting on Haskell in 2016

#11
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 agree. The nature of Haskell and its type system means that the basic haddock docs are already pretty darn useful even without hand-written content (examples, etc.) being included.

Re: Reflecting on Haskell in 2016

#12
post #8

I know I won't be thanked for pointing out non-technical infelecities in the writing, and I'm not a grammar nazi or anything but... "There was a lot of excellent Haskell writing this year. One can’t possible enumerate all of them..." A lot of excellent writing is a singular noun, then it refers to "them", plural. Exactly the same mistake made in the next paragraph. I don't want to be picky but if you're writing somet…

"infelecities" isn't a word.

[deleted]

Re: Reflecting on Haskell in 2016

#13

Earlier quoted context omitted.

> I don't want to be picky but if you're writing something public Neither do I, but there should be a comma before the "but" there.

No: these are dependent clauses, a comma would be incorrect.

What you just wrote is a comma splice, by the way. You should read up on semicolons.

Re: Reflecting on Haskell in 2016

#14
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.

There's research that shows people learn abstractions better when they also have examples. See e.g. [1] for references.

However, I find your tone particularly unpleasant. The sneer in "seem to be people who need worked examples of things to understand them" is repulsive. If this is a representative example of your community, it's one no-one should be proud to be a member of.

[1] http://www.maa.org/external_archive/columns/launchings/launc...

Re: Reflecting on Haskell in 2016

#15
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.

Counterpoint: this is what keeps me away from Haskell.

I really want to learn, and I really do appreciate the formal approach, but being able to do a few simple things quickly (driven mostly by intuition) helps fight frustration.

Haskell really does look great, but it's a bit... prickly.

Re: Reflecting on Haskell in 2016

#17
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've been coming back to Haskell sporadically over the past couple of months. Every time I do I find the documentation for things like Prelude to be excellent since that's stuff that I already understand but when trying to dive head-first into a new library I end up with 50 tabs open at various points in the doc to try to keep track of all the different parts. For libraries like megaparsec that have not only great documentation but tutorials and examples available it's often much easier to go in and read the "raw" documentation. Haskell isn't like C++ or other imperative languages in that you don't have "these are the method you can use on this class. Good chance you can figure it out from there". That's why I think that Haskell benefits from good example more than "conventional" languages.

Disclaimer: I'm very much a Haskell noobie

Re: Reflecting on Haskell in 2016

#18
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.

The thing is that the types are so good that they usually act as ultra-descriptive irrefutable documentation. I've found tons of straight up incorrect documentation in semi-popular Python libraries, but you're never going to find an incorrect type in a Haskell library doc.

As an example, I was doing some password hashing stuff a while back. The most popular Python library had horrible docs where all the arguments were strings and it was ambiguous what exactly went where. The Haskell library had almost no prose docs, but the type signature was something like

    Password -> Salt -> Difficulty -> HashedPassword
Literally impossible to mess up.

Personally, I'll take Haskell type-based docs over any other extant documentation that I've come across. Learning to read types effectively and quickly is a bit of a learned skill, but it comes naturally with a bit of use of Hackage or Stackage.

Also, Haskell has services like Hayoo or Hoogle where you can come up with a type signature and it will tell you anything that had that signature. Like let's say I want a function that goes through a list of maybes and returns them all if none of them are Nothing. I just search for

    [Maybe a] -> Maybe [a]
I get "sequence", which is the correct answer. Good luck doing something like that with the Python or Java docs.

> why there hasn't been more uptake of Haskell for all of the apparently cool ideas that are there,

People already know how to get the job done one way or another and learning new stuff is hard. It's an unfortunate but pragmatic viewpoint for many people.

Re: Reflecting on Haskell in 2016

#19

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.

Most people use Lenses for heavily record-oriented programming. They work quite well. They are less convenient than built-in structural syntax like in Javascript, but once you get past the initial inconvenience they are vastly more powerful.

Re: Reflecting on Haskell in 2016

#20
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 were too long. They'd benefit from being broken up into more pages, instead of pushing so much all at once. With that said, the information presented in the docs is actually quite clear and well written.

Looking at the Downloads section [1] on the Haskell website, it looks like they've improved the docs since I last visited, but it's still a bit confusing. What's the point of Haskell Platform? It looks like it includes stack, which already covers all my requirements. Maybe it'd be useful to include a "why" section for each choice, to provide some examples of scenarios in which you might go with one choice over the other. Telling me what I'm getting doesn't give me any meaningful information if I don't know why I'd want that in the first place. I think there's too much information up-front, even though people landing there probably aren't equipped to make use of it. Why would someone pick the Haskell Platform option or the minimal install option?

While reading Learn You a Haskell, I used Haskell for Mac [2] for poking around. It's pretty great, although I didn't end up purchasing it, as I'm not doing anything that would benefit from using it.

Something I liked about Elixir is that you can just read their getting started docs and pick up Phoenix framework to get a web app up and running. That gives you a nice base on which to gradually build upon as you learn. Does anyone have a similar suggestion for Haskell?

[0] https://docs.haskellstack.org/en/stable/README/

[1] https://www.haskell.org/downloads

[2] http://haskellformac.com/

Post reply on HN