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

91–100 of 107 posts

Re: Reflecting on Haskell in 2016

#91

Post by Buttons840 »

rpglover64 wrote: post #88
Buttons840 wrote: post #83

Earlier quoted context omitted.

I don't know exactly what it does, but I do know it only uses basic mathematical operations, it's just a formula. I also know it doesn't do any logging, or "launch nukes", and that it is thread safe. You're never given only the type signature however, you also will have the source code. It's very likely that foo is no more complicated than something like: foo :: Num a => a -> a foo n = n * 42 + 1 If foo is as complic…

> it's just a formula. I also know it doesn't do any logging, or "launch nukes", and that it is thread safe. So the type claims. Without looking at the implementation or using `-XSafeHaskell`, you don't know if there's an `unsafePerformIO` call lurking. /pedantry

Even if the function had documentation that said "this function does not have side effects" it could still have side effects.

So within the context of this thread, type signatures vs hand written documentation, I would say your point is a +0 for hand written documentation. Both type signatures and hand written documentation can lie.

Re: Reflecting on Haskell in 2016

#92

Post by bojo »

mightybyte wrote: post #68
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 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...

I was considering writing roughly the same thing you did, thanks. There's a lot of terrible documentation in every language, but I think it may be a losing battle to show this as a counter example unfortunately.

I think it's just that the gap to get proficient with Haskell for an imperative programmer is a hurdle they are blind to (I was blind myself!), and they assume a few simple tutorials will bootstrap them into the language like it did the other handful they learned.

This is clearly an education problem, but I guess we still have a ways to go to get acceptance.

Re: Reflecting on Haskell in 2016

#93

Post by armitron »

evincarofautumn wrote: post #86
elliotec wrote: post #82

Not having examples in documentation is a non-starter for me. It seems like there is a superiority complex there, that the Haskell community thrives on. That's ok I guess, I've never heard a practical use for it and I'm sure it will remain in it's insular state for the foreseeable future.

I strongly prefer having examples, too, but I doubt it’s due to any kind of “superiority complex” that docs are lacking. Writing good docs takes work, and some library authors are more willing to put in that work than others. Well-designed types can give you a great deal of what you’d get from docs in other languages, but they aren’t a panacea. Now, I find it very hard to believe that you’ve never heard of a practica…

Can you name a single, widely used (outside the Haskell camp) opensource application written in Haskell?

I can only think of "darcs" which for all intents and purposes was a failure. IIRC, one of the darcs retrospectives I've read, pointed out that GHC runtime behavior and its hard-to-foresee and hard-to-measure complexity properties, was a problem.

Moreover, another high-profile failure that springs to mind, is Joel Reymont (wagerlabs.com) trying to write a high-performance poker server in Haskell and eventually abandoning it in disgust due to non-predictable behavior of the GHC runtime. He delivered it (with assorted paeans) in Erlang instead, which proved quite lucrative for him.

I used Haskell for 2 years during my undergraduate degree, for program analysis. It was a good choice for such a theoretical domain. Some time later, I had another look at applying it to more practical problems. Besides the slight turn-off due to cultish behavior - which is also obvious in this thread, many posts excuse the lack of documentation or posit it as not a problem (!?), if not outright exalt it! - I got from the community itself, the language felt completely sterile and - most importantly - not fun. The syntax is also atrocious.

I concluded that if static typing was needed, I would pick ML every single time over Haskell. I also have no affinity with Haskell's type system (in the sense that it leads to better programs) or its interactive nature (laughable compared to Lisp/Smalltalk). I also remember something Sussman said, "Haskell is the most advanced of the obsolete languages" [1], and can't help but chuckle.

[1] https://www.infoq.com/presentations/We-Really-Dont-Know-How-...

Re: Reflecting on Haskell in 2016

#94

Post by sjakobi »

armitron wrote: post #93
evincarofautumn wrote: post #86

Earlier quoted context omitted.

I strongly prefer having examples, too, but I doubt it’s due to any kind of “superiority complex” that docs are lacking. Writing good docs takes work, and some library authors are more willing to put in that work than others. Well-designed types can give you a great deal of what you’d get from docs in other languages, but they aren’t a panacea. Now, I find it very hard to believe that you’ve never heard of a practica…

Can you name a single, widely used (outside the Haskell camp) opensource application written in Haskell? I can only think of "darcs" which for all intents and purposes was a failure. IIRC, one of the darcs retrospectives I've read, pointed out that GHC runtime behavior and its hard-to-foresee and hard-to-measure complexity properties, was a problem. Moreover, another high-profile failure that springs to mind, is Joel…

> Can you name a single, widely used (outside the Haskell camp) opensource application written in Haskell?

How about pandoc, PostgREST, git-annex, the Elm compiler?

You can find more examples here: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

Re: Reflecting on Haskell in 2016

#95

Post by codygman »

armitron wrote: post #93
evincarofautumn wrote: post #86

Earlier quoted context omitted.

I strongly prefer having examples, too, but I doubt it’s due to any kind of “superiority complex” that docs are lacking. Writing good docs takes work, and some library authors are more willing to put in that work than others. Well-designed types can give you a great deal of what you’d get from docs in other languages, but they aren’t a panacea. Now, I find it very hard to believe that you’ve never heard of a practica…

Can you name a single, widely used (outside the Haskell camp) opensource application written in Haskell? I can only think of "darcs" which for all intents and purposes was a failure. IIRC, one of the darcs retrospectives I've read, pointed out that GHC runtime behavior and its hard-to-foresee and hard-to-measure complexity properties, was a problem. Moreover, another high-profile failure that springs to mind, is Joel…

https://github.com/Microsoft/bond

Re: Reflecting on Haskell in 2016

#96

Post by mightybyte »

bojo wrote: post #92
mightybyte wrote: post #68

Earlier quoted context omitted.

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

I was considering writing roughly the same thing you did, thanks. There's a lot of terrible documentation in every language, but I think it may be a losing battle to show this as a counter example unfortunately. I think it's just that the gap to get proficient with Haskell for an imperative programmer is a hurdle they are blind to (I was blind myself!), and they assume a few simple tutorials will bootstrap them into…

> I think it may be a losing battle to show this as a counter example unfortunately.

Yeah, my intent wasn't to suggest that all non-haskell docs suck. But to show how other languages are much more howto/tutorial oriented, which I didn't appreciate as much before I had to look at ACE recently.

Re: Reflecting on Haskell in 2016

#97

Post by sjakobi »

sjakobi wrote: post #94
armitron wrote: post #93

Earlier quoted context omitted.

Can you name a single, widely used (outside the Haskell camp) opensource application written in Haskell? I can only think of "darcs" which for all intents and purposes was a failure. IIRC, one of the darcs retrospectives I've read, pointed out that GHC runtime behavior and its hard-to-foresee and hard-to-measure complexity properties, was a problem. Moreover, another high-profile failure that springs to mind, is Joel…

> Can you name a single, widely used (outside the Haskell camp) opensource application written in Haskell? How about pandoc, PostgREST, git-annex, the Elm compiler? You can find more examples here: https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

What's the reason for the downvotes?

Re: Reflecting on Haskell in 2016

#98

Post by gilmi »

harpocrates wrote: post #77
gilmi wrote: post #35

Earlier quoted context omitted.

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.

Some of them are from FPCo and some are not. But why does this matter? Why did you mention it?

Re: Reflecting on Haskell in 2016

#99

Post by greenrd »

armitron wrote: post #93
evincarofautumn wrote: post #86

Earlier quoted context omitted.

I strongly prefer having examples, too, but I doubt it’s due to any kind of “superiority complex” that docs are lacking. Writing good docs takes work, and some library authors are more willing to put in that work than others. Well-designed types can give you a great deal of what you’d get from docs in other languages, but they aren’t a panacea. Now, I find it very hard to believe that you’ve never heard of a practica…

Can you name a single, widely used (outside the Haskell camp) opensource application written in Haskell? I can only think of "darcs" which for all intents and purposes was a failure. IIRC, one of the darcs retrospectives I've read, pointed out that GHC runtime behavior and its hard-to-foresee and hard-to-measure complexity properties, was a problem. Moreover, another high-profile failure that springs to mind, is Joel…

Darcs was mostly a failure because no-one, not even the original author, could satisfactorily explain its patch model - whereas git's patch model is simple and easy to understand. That has nothing to do with Haskell.

Re: Reflecting on Haskell in 2016

#100

Post by eklavya »

8fGTBjZxBcHq wrote: post #78
eklavya wrote: post #61

Earlier quoted context omitted.

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.

Maybe yes, You can not learn Haskell in one day, if that was your point. My point is learning Haskell takes time and it's hard and it is totally understandable if for some people that is not a good investment.
Post reply on HN