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

81–90 of 107 posts

Re: Reflecting on Haskell in 2016

#81

Post by sjakobi »

marcosdumay wrote: post #63
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…

> On Linux it's easier to compile (yes, it's that bad) your own GHC and cabal, and get stack from cabal.

I had no issues setting up my dev environment with stack on Ubuntu 16.04 as documented on haskellstack.org. What Linux distro do you use?

Re: Reflecting on Haskell in 2016

#82

Post by elliotec »

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.

Re: Reflecting on Haskell in 2016

#83

Post by Buttons840 »

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

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 complicated as that, then a sentence or two explaining what it's purpose is would be helpful; explaining the "why" of such an odd function would be good. The documentation probably can't say "what" foo does any more clearly than the source code however.

If the function is reasonably named, like:

    double :: Num a => a -> a
    double n = n + n
then having some documentation that says "Doubles the given number" isn't going to add much value, and might become out of sync with the actual code. I appreciate that all the Haskell documentation I have ever encountered has a links to the source code throughout.

Aside: When I look at the definition of an unknown function in Haskell, I feel like I'm at the top of an hierarchy. The unknown function may be comprised of other unknown functions, but the entire structure of what is happening is present. I know what all the variables are, etc. When I look at the definition of an unknown object-oriented function I often find myself in the middle of an inheritance stack with implicit behaviors and variables being inherited from above, and unknown functions being called below, and it's more confusing in my opinion.

Re: Reflecting on Haskell in 2016

#84

Post by mjhm2539 »

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.

https://code.facebook.com/posts/745068642270222/fighting-spa...

Re: Reflecting on Haskell in 2016

#85

Post by marcosdumay »

sjakobi wrote: post #81
marcosdumay wrote: post #63

Earlier quoted context omitted.

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…

> On Linux it's easier to compile (yes, it's that bad) your own GHC and cabal, and get stack from cabal. I had no issues setting up my dev environment with stack on Ubuntu 16.04 as documented on haskellstack.org. What Linux distro do you use?

Tried it on Debian 8.

I've installed GHC from binaries more than once without a problem, same for cabal. But I've concluded it's not reliable.

Re: Reflecting on Haskell in 2016

#86

Post by evincarofautumn »

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 practical use for Haskell. Do you just not care about the things that companies are using it for? (Compilers, web apps, backend services, finance, educational apps…)

Re: Reflecting on Haskell in 2016

#87

Post by appleflaxen »

harpocrates wrote: post #26
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…

You bring up good points! As a beginner, you are uniquely poised to observe these things, so thanks for sharing! I think a big part of the install problem is that some of the options (stack, platform) are fairly recent. I recently got a new machine and decided to try _only_ using stack. All I had to run to get started was $ curl -sSL https://get.haskellstack.org/ | sh The advantages of stack are that: * I have an eas…

> Haskell is more general purpose than Elixir

why do you say so? elixir seems pretty general-purpose...

Re: Reflecting on Haskell in 2016

#88

Post by rpglover64 »

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…

> 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

Re: Reflecting on Haskell in 2016

#89

Post by rpglover64 »

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…

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

I think this overstating it, unfortunately. I'm an intermediate Haskeller, and when I tried to use `hasql`, I found the lack of documentation to slow me down.

It's a testament to the power of types as documentation that I was able to use it at all, but examples and simple cookbook-style "Here's how you do this thing" or "Here's how you use this component" or "You can't do this because the interface doesn't allow it; here's why" would have sped up my acquisition of the library immensely.

Re: Reflecting on Haskell in 2016

#90

Post by pronik »

icebraining wrote: post #80
pronik wrote: post #62

Earlier quoted context omitted.

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…

Just out of curiosity, how would you change the following definition to make sure it's clear without reading anything else? words :: String -> [String] If you say it's already obvious, I disagree, since this code prints "1": main = print $ length $ words "jack am I" (The spaces in the string are six-per-em unicode characters)

(like I said elsewhere, I'm a beginner, so I might be over-euphorical about controversial ideas. Also I don't in any way propose working only with type definitions instead of prosa documentation, however I think type definitions can go a long way to introduce the basic operations to the user)

In this case, I'd try something like this:

  words :: Sentence -> [Word]
(Sentence and Word being aliases for String)

A function named `words` with `Sentence` as a parameter implies a common-sense do-what-I-mean function, like breaking on all sensible whitespace. With common sense in play, it's your task to make the function behave like people expect it to (which differs per person of course). If you choose not to, don't write `words`, write a `split` with a parameter for character classes (or indeed a boolean function working on a character) the split should be performed on.

(PS. I assume you are implicitely critisizing Prelude's `words`, which breaks on anything that's `isSpace`, which is explicitely defined. Its definition is way out of my competence, there are probably good reasons for not including thin spaces. If not, they could probably get included with a due process -- with common sense, it's always an iterative process till it's done)

Post reply on HN