Reflecting on Haskell in 2016 • Hacker News Board

Re: Reflecting on Haskell in 2016

#101

Post by GenWintergreen » Tue, Dec 27, 2016, 2:19 PM UTC

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…

Finding the setup to be more than a small bump. Running this on Mac Sierra, and running into resolver issues everywhere. Latest was using stack setup with a specific resolver, and having the version it installed be the wrong one (at least, according to the stack documents).

Just a bit frustrating.

Re: Reflecting on Haskell in 2016

#102

Post by PopsiclePete » Tue, Dec 27, 2016, 4:28 PM UTC

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…

The only piece of Haskell I rely on is Pandoc. Which is awesome. But I think hardly a shining example of "Look what you can do in Haskell that you can't do in X!"

Re: Reflecting on Haskell in 2016

#103

Post by dllthomas » Tue, Dec 27, 2016, 10:10 PM UTC

One thing missed in the various discussions of documentation here is that the Haskell ecosystem is actually highly variable in both the amount of and need for various types of documentation.

There's a pile of packages like diagrams (http://projects.haskell.org/diagrams/) or yesod (http://www.yesodweb.com/) which have tutorials, examples, books. People who have been working mainly with these should be completely expected not to feel much of a problem with the state of documentation.

There are also packages which have mostly/only API information. Sometimes, this tells you everything you need to use a package effectively. Sometimes it doesn't. And this is impacted substantially by people's level of skill -- at Haskell and at inferring usage from names and type information in particular.

There's room for people to have very different experiences

Re: Reflecting on Haskell in 2016

#104

Post by 14113 » Tue, Dec 27, 2016, 10:58 PM UTC

Buttons840 wrote: post #83

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

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…

I guess the counterexample would be library functions that look like:

     foo :: (BarMonad m, BazApplicative b) => ConfigurationStructure t -> (b -> m t) -> [b] -> t

You can figure out a little of what it does, but how that fits into the application it supports, and what exactly it should be used for is non trivial.

Haskell programmers (whose numbers I count myself amongst) saying that "the types are the documentation" is like expecting someone to build a lego model from the picture on the box, and saying "well the studs are the documentation of how the pieces fit together". It's correct, but it misses all the nuance of how the functions should be composed, not just how they can be composed.

Re: Reflecting on Haskell in 2016

#105

Post by axman6 » Wed, Dec 28, 2016, 10:50 AM UTC

dllthomas wrote: post #41

axman6 wrote: post #36

Earlier quoted context omitted.

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

I don't see how that's contrary to what the parent said.

I guess that my point was that for the situations where the built in syntax in OO languages is used, the lens alternative is usually at most about 2 characters longer, which is hardly more inconvenient.

Re: Reflecting on Haskell in 2016

#106

Post by dllthomas » Wed, Dec 28, 2016, 3:18 PM UTC

axman6 wrote: post #105

dllthomas wrote: post #41

Earlier quoted context omitted.

I don't see how that's contrary to what the parent said.

I guess that my point was that for the situations where the built in syntax in OO languages is used, the lens alternative is usually at most about 2 characters longer, which is hardly more inconvenient.

That's a point, just one that was entirely missing from your previous comment.

That said, it's not just use. You've also gotta deal with some additional imports, and with defining your lenses. For the simplest case, that's a bit of overhead compared to having it all baked in.

Re: Reflecting on Haskell in 2016

#107

Post by vanessa98 » Fri, Dec 30, 2016, 5:08 PM UTC

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…

Oh man, please don't ever use Joel Reymont as a language reference - his noisy, uninformed, continuous churn through various programming languages was exhausting back in the day. Just be thankful the hack has gone quiet.