Live data from Hacker News

Reflecting on Haskell in 2016

stephendiehl.com

21–30 of 107 posts

Re: Reflecting on Haskell in 2016

#21
post #14
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.

There's research that shows people learn abstractions better when they also have examples. See e.g. [1] for references. However, I find your tone particularly unpleasant. The sneer in "seem to be people who need worked examples of things to understand them" is repulsive. If this is a representative example of your community, it's one no-one should be proud to be a member of. [1] http://www.maa.org/external_archive/co…

> However, I find your tone particularly unpleasant. The sneer in "seem to be people who need worked examples of things to understand them" is repulsive. If this is a representative example of your community, it's one no-one should be proud to be a member of.

Its always good to apply the principle of good faith. You have no idea who you're talking to, are likely going in biased away from someones arguments, and this will be the first time you've ever conversed. On top of that you're hobbled by text. You also don't know if the writer is a native english speaker or not and might consider the phrase "seem to be people who need worked examples of things to understand them" entirely neutral in tone.

Communication is a 2 way street, the tone you perceive may not have been intended. And painting an entire group by one sentence, in one post, that you perhaps disagree with, is a bit of an overreaction in almost any circumstance. The tone you perceive is not one I've personally experienced, quite the opossite.

As a beginner in Haskell that is still learning, and learns best by examples, the gp's opinion on documentation drives me nuts. But by and large, most examples aren't all that necessary in haskell with the type system. But when you're learning, I have to say, I hate "the types will document everything" mindset. They tend not to when you're a stranger in a strange land.

I wouldn't say documentation itself is a problem in haskell, there is tons. I would say the problem is in quality documentation that at least recognizes audiences of disparate skill level would be at issue. Examples help, but if the examples use something like the state monad that you're not familiar with, it probably won't do you a lick of good to understand how to use it.

Re: Reflecting on Haskell in 2016

#22
post #14
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.

There's research that shows people learn abstractions better when they also have examples. See e.g. [1] for references. However, I find your tone particularly unpleasant. The sneer in "seem to be people who need worked examples of things to understand them" is repulsive. If this is a representative example of your community, it's one no-one should be proud to be a member of. [1] http://www.maa.org/external_archive/co…

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.

Re: Reflecting on Haskell in 2016

#23
post #19

Out of curiosity what progress has been made in regards to improving the ergonomics of records in Haskell? Stephen references that an answer is in the works, but it looks like it has stalled out.

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.

Re: Reflecting on Haskell in 2016

#24

Out of curiosity what progress has been made in regards to improving the ergonomics of records in Haskell? Stephen references that an answer is in the works, but it looks like it has stalled out.

Actually, a lot has been done and a lot is coming in the near future. GHC 8.0 brought us `DuplicateRecordFields`, so that we can finally use the same field name for two records.

There is active work done by Adam Gundry to extend this even further [1]. The key part of this is that there will be a new type class so that I can express as a constraint that a type must have a field with a certain name and with a certain type.

Further in the future, but still actively discussed is using overloaded labels as lenses [2]. Past that, I can't imagine anything else I would want records to do.

[1] https://github.com/adamgundry/ghc-proposals/blob/overloaded-... [2] http://stackoverflow.com/questions/38136144/replace-record-p...

Re: Reflecting on Haskell in 2016

#25
post #14
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.

There's research that shows people learn abstractions better when they also have examples. See e.g. [1] for references. However, I find your tone particularly unpleasant. The sneer in "seem to be people who need worked examples of things to understand them" is repulsive. If this is a representative example of your community, it's one no-one should be proud to be a member of. [1] http://www.maa.org/external_archive/co…

If that single line is "repulsive" to you maybe you need to re-evaluate your world view a bit.... stop looking for something to be offended about if someone has a differing view

Re: Reflecting on Haskell in 2016

#26

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 easy upgrade path for GHC (no need to install or uninstall) - I just change the global resolver
  * I can have multiple GHC versions installed at once (great for debugging)
  * getting rid of old versions (to clear up space) is just deleting a folder
  * most of my dependency problems get solved by resolvers
The only downside I've encountered so far is that building GHC itself is quite finicky with this setup. Unlike the Haskell Platform, I will have to install manually the libraries I need - that makes development offline quite tough (you find yourself without internet and without the library you need installed).

That aside, one good starting point for building up Haskell is the 99 problems [1]. Haskell is more general purpose than Elixir, so past that, it really depends on what you want to do with it.

[1] https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems

Re: Reflecting on Haskell in 2016

#27

I know I won't be thanked for pointing out non-technical infelecities in the writing, and I'm not a grammar nazi or anything but... "There was a lot of excellent Haskell writing this year. One can’t possible enumerate all of them..." A lot of excellent writing is a singular noun, then it refers to "them", plural. Exactly the same mistake made in the next paragraph. I don't want to be picky but if you're writing somet…

When you spend half of your comment on justifying it's existence, it might be the wisest choice to just not post it at all...

Re: Reflecting on Haskell in 2016

#28
post #6
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.

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.

This opinion is unfortunately common in the Haskell community and one of the biggest things holding back Haskell adoption. I'm a big fan of Haskell (see my recent comment history), but types are not sufficient documentation. Doubly-so with the cryptic symbols / function names that are so prolific.

Python, PHP, etc... are incredible in that every single page of their standard library docs have fully worked examples. When you're trying to get things done, it's great to have a foundation to start from and see how others have done something.

Re: Reflecting on Haskell in 2016

#29

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…

Environment setup has been heavily discussed[1] in the community and is definitely a pain point when getting started with Haskell. Unfortunately there are several sides with differing opinions on how to bootstrap a user and get them using Haskell, although the new Downloads page seems to be a good first step towards achieving a more unified goal.

The opinions kind of break down as:

1. Simply get GHC on their machine - Typically academic instructors trying to get their students started with low overhead. They simply want GHC and GHCi available so an assignment can compile, or code can be tested in the repl.

2. Install Haskell Platform - This has been strongly supported by what I would call the older Haskell community, although admittedly share your confusion as to its point. This seems to target point-and-click users and give them every tool in the ecosystem so that when they reference the random blogs/documentation out there they aren't confused by missing a command.

3. Use Stack - This has been heavily pushed by people trying to help Haskell grow in the programming industry. It's a fantastic tool and I recommend everyone use it if they plan on doing complex projects, especially in a team setting.

My hope is that over the next year or so we'll see more stack adoption, ideally because there are more consistent tutorials/guides/documentation published which target it as the basic tool to start developing Haskell in.

[1] https://www.reddit.com/r/haskell/comments/50prvg/haskellcomm...

Re: Reflecting on Haskell in 2016

#30
post #6
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.

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 up specifics of how things work after I already get the basic idea.

It's not because I "need worked examples of things to understand them", it's because that is the way I like to work, because I have had many instances of my life of trying to make sense out of documentation that seems to have been written from a mindset of "formal writing involves not actually telling the reader what things are really for, straightforwardly". I don't know why that disease is so common, but almost all documentation is like that.

Post reply on HN