Live data from Hacker News

Reflecting on Haskell in 2016

stephendiehl.com

31–40 of 107 posts

Re: Reflecting on Haskell in 2016

#31
post #30
post #6

Earlier quoted context omitted.

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 am a programmer with a lot of experience who has written a lot of things from scratch (not in Haskell). I think most documentation sucks and I dislike trying to read it, because it's very hard to get a picture of what's going on, and what these procedures / data structures / etc are really for. I am much happier when I can just look at a straightforward and clear example, and then just use the documentation to look…

[deleted]

Re: Reflecting on Haskell in 2016

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

I'm not, especially for the many more-abstract-concepts. 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.. A lot of explanations in the Haskell ecosystem are super-abstract and forever-self-referencing and as someone arriving with a sense of urgency of pumping out Brave New Apps to the world, I'm always itching and saying "OK transformables turn foldables that contain applicatives into functors that fold applicatives into transformables so in other words I CAN SKIP THIS RITE?" Leave it in the shadows as it was clearly a priority to neatly have the abstractions that allowed making MayBe/IO/Lists etc as usable language features in there.

On the other hand I don't want to end up writing 10k lines that could have been expressed in 500 had I grasped the more obtuse abstractions.

Experience tells me that once you happen across a simple real-world use, the shocking simplicity of what was encrypted in mathematical-logical-calculi lingo is instantly revealed. The absence of such "code examples" (with a real-world touch, not just x,y,z,f,g,h identifiers in a senseless vacuum) is truly annoying and goes all the way from the Wiki to Diehl's articles to various books.. it's hyperprevalent throughout the community.

Re: Reflecting on Haskell in 2016

#34
post #22
post #14

Earlier quoted context omitted.

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/co…

That attitude is not representative of the community. Some people would like more documentation and some are content, but either way it's still Haskell and the types get you very close to full understanding.

This is only true after you've fully grokked the implications of the types. And, IME, that takes a long time. To give you an example, I spent ages trying to figure out how to create an X. X was a Monad of A. Solution's obvious now...

Re: Reflecting on Haskell in 2016

#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

Re: Reflecting on Haskell in 2016

#36
post #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.

On the contrary, lenses are far more powerful than what's available in JavaScript and all other OO languages. Traversals and Prisms give so much power that's lacking in OO

Re: Reflecting on Haskell in 2016

#37
post #21
post #14

Earlier quoted context omitted.

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/co…

> 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. Its always good to apply the principle of good faith. You have no idea who you're talking to, are likely going in biased away from someones arguments, and this…

I taught myself Haskell to an intermediate level a few years ago, and I think you're touching on the truth here.

Haskell is hard to learn, or at least it was for me. There is a whole laundry list of concepts I had never even heard of that I had to understand before I could do anything real with the language. Some were apparently dead simple yet frustratingly abstract (e.g. Monoids). Some were intuitive but still took time to grok (e.g. list manipulation stuff). Some twisted my brain into knots and only yielded to persistent study and practice (e.g. monads with threaded state).

As I was working through all these "basics", I was constantly frustrated trying to write simple programs. I don't recall whether I blamed it on a lack of beginner-friendly documentation or not, but slowly it all started to resolve into a coherent picture and once I could consistently read and understand real-world types I found that the available documentation was almost always enough for me to quickly understand an interface and how to proceed in using it.

I think both sides of this debate are partly right. Haskell's learning curve seems to keep going up as far as you want to climb, and some of the stuff at the intermediate level IMO could really use more examples and documentation, or at least that was my opinion when I was looking at it a year or so ago. One good example might be Template Haskell, which pissed me off to no end every time I tried to use it even in very simple applications. It involves a lot of new syntax and concepts and IIRC had literally no documentation besides what Haddock gives you for free.

On the other hand, I think a lot of people criticize Haskell's documentation without knowing the language well enough to make use of said docs or even understand how they might be useful. IMO it's unrealistic to expect every module and library to provide documentation specifically for beginners who don't understand challenging yet ubiquitous concepts (like state monads, to use your example), and I don't think other languages necessarily do a better job at this, but Haskell is just so darn tricky to get your head around that the "total beginner" phase lasts way longer than it might in e.g. Python.

For beginners who do want to learn about the core concepts of the language, I found that there was plenty of material to help me on my journey: Real World Haskell, LYAH, the IRC channel, and the internet full of blog posts, to name just a few. I don't mean for this comment to cause offense, or to belittle anyone. I'm certainly not an expert Haskell programmer, and there is much that I still don't understand about it. I just wanted to share some insights I've had learning it and using it in some practical applications.

Re: Reflecting on Haskell in 2016

#38
post #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 wer…

I think types are a bit mediocre as documentation. But as you say, mediocre correct documentation beats the pants off of any sort of incorrect documentation.

Moreover, it's documentation that's immediately available for the expression I just assembled at the repl!

None of which is to say most of us wouldn't love some good, correct documentation. But that takes a lot of effort, and I can see why priorities wind up being elsewhere given that it's a smaller improvement over what's available free than in other languages.

Worked examples are actually low-hanging fruit that we really should be making available, given that we can mechanically ensure correctness. Come to think of it, I wonder if this could just be a matter of surfacing existing end-to-end tests somewhere visible.

Re: Reflecting on Haskell in 2016

#39
post #19

Earlier quoted context omitted.

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.

I'll need to check out lenses. I've run in to a few annoying this working with records so far so I was hoping some progress was in the works.

I'm not sure how useful an introduction it is, but I really enjoyed this talk:

https://skillsmatter.com/skillscasts/4251-lenses-composition...

Re: Reflecting on Haskell in 2016

#40
post #9
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.

I'm also in the "I think there is plenty of documentation" camp, so this topic tends to confuse me when it comes up. I suppose what people who are curious about Haskell find lacking are definitive language guides like the Rust Book, Effective Go, and the like?

I am one of the people who are interested in Haskell and find its documentation lacking. I don’t miss comprehensive language books, I miss module documentation. It almost looks as the Haskell community has something against examples in documentation. I stress that the types are not enough. Contrast that with Elm, where I was able to write a working app in a day or so. But Elm is written off quite harshly in the post, so I am again left with the feeling that Haskell may not be the language meant for people like me.
Post reply on HN