Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflecting on Haskell in 2016

stephendiehl.com

Post reply on HN
Print view View original

51–60 of 107 posts

Re: Reflecting on Haskell in 2016

#51

Post by greenrd »

moomin wrote: post #34
efnx wrote: post #22

Earlier quoted context omitted.

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

Yes, it's a mistake to believe that the type class instances of a type are always going to be advanced details that can be skipped until later. They might be, or they might not.

Re: Reflecting on Haskell in 2016

#52

Post by greenrd »

jblow wrote: post #30
chowells wrote: 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…

I think it's because people commonly forget what it's like to be a beginner and which things that are obvious to them are not obvious to a beginner. This is probably more true in Haskell where there is just so much that it's possible to learn that the most advanced Haskell programmers are very, very far ahead of the beginners.

Re: Reflecting on Haskell in 2016

#53

Post by greenrd »

dllthomas wrote: post #42
dualogy wrote: post #32

Earlier quoted context omitted.

> 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 an…

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

Re: Reflecting on Haskell in 2016

#54

Post by greenrd »

unhammer wrote: post #43
chowells wrote: 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'm one of those who need examples. Fortunately, haddock has this "source" link on each function, so I typically find something usable by browsing through the source of the library I'm using. This takes a lot more time than it would to just have an example in the docs themselves, of course (and isn't always even fruitful). I do notice that after a while, I can get more and more from types alone, but I would never get…

Type-checked examples are becoming more popular in the Scala community, e.g. using the tut tool. This is one of the few ways in which the Scala community appears to be ahead of the Haskell community, in terms of technology.

Re: Reflecting on Haskell in 2016

#55

Post by s_kilk »

zoul wrote: post #40
bojo wrote: post #9

Earlier quoted context omitted.

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…

> I stress that the types are not enough

Exactly.

Quick, tell me what this function does:

    foo :: Num a => a -> a

Re: Reflecting on Haskell in 2016

#56

Post by greenrd »

bipvanwinkle wrote: post #23
wyager wrote: 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.

The main lens library in Haskell doesn't exactly have no documentation, but it is pretty much impenetrable without a third-party tutorial or blog post. But persevere - it's really powerful!

Re: Reflecting on Haskell in 2016

#57

Post by Bahamut »

caconym_ wrote: post #48
ChubbyGlasses wrote: post #45

Earlier quoted context omitted.

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…

Your example can be written more clearly (IMO) in Haskell like this: sum $ map (^2) $ filter odd [1..10] Or, defined as a function: > let foo = sum . map (^2) . filter odd > foo [1..10] 165 You can write it without using the composition operator at all, if you prefer: > let bar xs = sum (map (^2) (filter odd xs)) > bar [1..10] 165 In general, you can write out your programs as crazy sequences of operators (whose prec…

To add to that from someone who went into programming after math grad school, composition is actually much more natural in the way to think about functions. When putting together functions, and where they map to, it is more natural to think about functions the way Haskell thinks about them, but more natural when writing them to go the other way at first. This is because when one is working at the lower level of just writing code it becomes easier to move from one data state to another, but at the high level, you lose some flexibility in seeing the high level structure and it becomes more difficult to figure out how to move things around if it turns out you have to modify the code.

In math, the preferred way of writing functions is via composition, as then it enables tools of visualization such as commutative diagrams. One thing to note is that in general mathematicians have a history of picking the right choice in notations for thinking about abstractions at an intuitive level in the world of mathematics (when there is a choice and it matters), and IMO they were correct about how they chose to represent function composition, although it is not immediately obvious unless you start talking about function domains and ranges - the composition notation matches the flow of reading how functions map values from one set to another.

That Clojure version reads like a complete mess to me personally.

Re: Reflecting on Haskell in 2016

#58

Post by sordina »

unhammer wrote: post #43
chowells wrote: 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'm one of those who need examples. Fortunately, haddock has this "source" link on each function, so I typically find something usable by browsing through the source of the library I'm using. This takes a lot more time than it would to just have an example in the docs themselves, of course (and isn't always even fruitful). I do notice that after a while, I can get more and more from types alone, but I would never get…

https://github.com/sol/doctest#readme - Very popular.

Re: Reflecting on Haskell in 2016

#59

Post by chriswarbo »

ChubbyGlasses wrote: post #45
TheAceOfHearts wrote: post #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 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 former is much more readable from and LTR English language PoV. In Haskell I need to start from the right and work my way left;

For short chains, pronouncing `.` as "of" works well in English, e.g. `sum . tail $ foo` is "the sum of the tail of foo`, and it follows the same order as nested function application: `sum (tail foo)`.

I agree the the other way around, e.g. a "then" operator `>>>`, is easier to understand with long chains: with `f . g . h . ...` we have to remember `f`, `g`, `h`, etc. in a "mental stack", until we get the the end. With the other way round, `... >>> h >>> g >>> f` we can "mentally apply" each function to a "mental accumulator" as we encounter it.

Re: Reflecting on Haskell in 2016

#60

Post by pronik »

bojo wrote: post #49
zoul wrote: post #40

Earlier quoted context omitted.

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…

To be fair this thread is an example of the Haskell community agreeing with you: https://www.reddit.com/r/haskell/comments/2ory86/there_is_a_... (2014) After using the language for two years I find that the types are actually enough to understand a new library, however, am taking for granted that it's an acquired skill. Looking back I do recall being in the same position as you, someone who just wanted to wrap their…

As a recent beginner, I've found it incredibly hard to write something practical by putting a library into good use. If you want more that printing out Fibonnacci sequences, like printing out your own Twitter stream, like I have done, you better be ready for a lot of pain. The twitter module makes extensive usage of lens, wraps everything with conduit (at least within the examples). Conduit itself is exhaustively documented, as are lens, but you can't get started without a couple of external tutorials, since there is no practical description of the basic underlying concepts in the main documentation on hackage. And even then you don't know exactly how everything fits in, since all you get is for the most part what, but not how and especially why you should be using this what.

So my basic impression is: as soon as you know where the library fits in and how it works and even more importantly why it is doing things the way it does, you can get by just by using type signatures. But that knowledge is usually hidden behind a myriad of half-done blog posts and well-meant tutorials, which introduce you to the what but still assume a good deal of knowledge about why. And the rabbit hole gets larger with every dependency boiled onto your actual study target.

It's not by any means impossible to get in, but I think it could get a lot better. Just making a habit of merging tutorials and introductions into the module's documentation would be a great step forward. A mandatory ELI5 section might do wonders :)

Post reply on HN