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

61–70 of 107 posts

Re: Reflecting on Haskell in 2016

#61

Post by eklavya »

zoul wrote: post #47
59nadir wrote: post #46

Earlier quoted context omitted.

Elm was written off because it still does an incredibly bad job at implementing polymorphism. It has a hardcoded "Show" class for turning things into strings and only certain privileged entities can be turned into strings using it. It's all in all a very bad way to do polymorphism and that's what the article points out. It's especially odd in a language like Elm, that obviously is supposed to be like other ML-like la…

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?

Re: Reflecting on Haskell in 2016

#62

Post by pronik »

s_kilk wrote: post #55
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…

> 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 declarations as smelly, but they are.

Re: Reflecting on Haskell in 2016

#63

Post by marcosdumay »

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…

On what building tool to choose:

Stack creates reproducible builds (AKA frozen dependencies), but instead of you freezing everything, the community creates some frozen sets for you, and you choose one. That avoids the dependency hell that happen on other environments when your dependencies list gets big.

Cabal is much more like a run of the mill dependency management system. You'll declare everything in the usual way, it will resolve the dependencies (in a much better than usual way, but still looks like everything else), and make them available for you.

Both systems can manage dependencies globally or in a project by project basis.

I've found that for creating libraries and publishing them on hackage one is almost certainly better off with bare cabal. For creating binaries for distribution, one is almost certainly better off with stack.

About installation, every road will take you to a system with at least ghc, and cabal. Getting stack too is very desirable. I've found that on windows it's easier to run the stack installer, and install everything from it. On Linux it's easier to compile (yes, it's that bad) your own GHC and cabal, and get stack from cabal. The Haskell Platforms looks to be meant to distro package maintainers - I have never had good results from trying to install it from the site.

Re: Reflecting on Haskell in 2016

#64

Post by marcosdumay »

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…

Operation precedence in Haskell is hard to get used to, but it leads to very clean code after you get used. Try:

  sum . map (\x -> x * x) . filter odd $ [1..10]
Function composition leads to a very stable right-to-left syntax. It also takes some practice, but in Haskell you almost never have to go hunting for operators or remember if something is infix or prefix (except for the shameful single argument '-', as in '-1').

Re: Reflecting on Haskell in 2016

#65

Post by marcosdumay »

bojo wrote: post #9
moxious wrote: 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?

Yes, Haskell is missing tutorials, how-tos, stuff that make those more complex concepts easier to understand.

As an example, the single kind off complex library I created (called "interruptible") is still lacking a good explanation of what it is good for, because despite having created it to solve a specific problem of mine, I still could not find a good way to explain it.

Re: Reflecting on Haskell in 2016

#66

Post by auggierose »

pronik wrote: post #62
s_kilk wrote: 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…

That's typical Haskell brain wash talk.

Types can be a useful part of the documentation, but if your program is the least bit interesting, you will have parts that you should properly document. This is so much more true for libraries, especially those that adhere to a more mathematical style. If you write such a library, you should also write a paper explaining the library.

Re: Reflecting on Haskell in 2016

#67

Post by marcosdumay »

silluk wrote: post #17
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'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 do…

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

No, but for this case, type holes are much more powerful. You always have an I have X, I want Y, what functions are there that are X -> Y?

Hoogle is more powerful than anything I've seen on any other language. (If I could only make it use all the local packages, instead of the pre-built index. I'm sure there's a way.)

Haskell has also more need for documentation than most other languages, so hoogle is still not enough. That's the problem, not lack of docs.

Re: Reflecting on Haskell in 2016

#68

Post by mightybyte »

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 was writing a reply to this, but it got long enough that I decided to make it a standalone blog post.

http://softwaresimply.blogspot.com/2016/12/on-haskell-docume...

Re: Reflecting on Haskell in 2016

#69

Post by e12e »

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…

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

I don't really write much haskell - but last I checked, the "howistart.org"-article seemed reasonable:

http://howistart.org/posts/haskell/1

I think it's actually harder to figure out how one (should) start with python an venvs than it is to "find" a reasonable approach for haskell.

Re: Reflecting on Haskell in 2016

#70

Post by efnx »

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

Examples would help in that case, but there would still be much confusion simply from not understanding Monads (enough to write a computation in that one).
Post reply on HN