22 ms·

Reflecting on Haskell in 2016

263 points by psibi 10y ago

hardwaresofton 10y ago
The Haskell community is incredibly blessed to have Stephen Diehl around. This is an excellent write up on so many of the things that have happened in the Haskell community this year, not to speak of his other written guides and in-depth explanations which are amazing.
- fegu 10y ago
  I came here after reading the article to say something like this. I try to follow the Haskell community, reading articles etc, but I had missed a lot of this stuff.
BellsOnSunday 10y ago
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 something public, learn how to use your language right.
- xwowsersx 10y ago
  > I don't want to be picky but if you're writing something public Neither do I, but there should be a comma before the "but" there.
  - hota_mazi 10y ago
    No: these are dependent clauses, a comma would be incorrect.
    - charlieflowers 10y ago
      Actually a comma is needed because that is a compound sentence. The 2nd independent clause has a subject of "you" (implied) and a verb of "learn."
    - GavinMcG 10y ago
      What you just wrote is a comma splice, by the way. You should read up on semicolons.
- burkaman 10y ago
  "infelecities" isn't a word.
  - deleted 10y ago
    [deleted]
- the_duke 10y ago
  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...
moxious 10y ago
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.
- chowells 10y ago
  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.
  - caconym_ 10y ago
    I agree. The nature of Haskell and its type system means that the basic haddock docs are already pretty darn useful even without hand-written content (examples, etc.) being included.
  - barrkel 10y ago
    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/columns/launchings/launchings_12_08.html http://www.maa.org/external_archive/columns/launchings/launc...
    - mitchty 10y ago
      > 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.
bipvanwinkle 10y ago
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.
- wyager 10y ago
  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.
  - bipvanwinkle 10y ago
    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.
    - dllthomas 10y ago
      I'm not sure how useful an introduction it is, but I really enjoyed this talk: https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation https://skillsmatter.com/skillscasts/4251-lenses-composition...
    - greenrd 10y ago
      The main lens library in Haskell doesn't exactly have no documentation, but it is pretty much impenetrable without a third-party tutorial or blog post. But persevere - it's really powerful!
  - axman6 10y ago
    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
    - dllthomas 10y ago
TheAceOfHearts 10y ago
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 were too long. They'd benefit from being broken up into more pages, instead of pushing so much all at once. With that said, the information presented in the docs is actually quite clear and well written. Looking at the Downloads section [1] on the Haskell website, it looks like they've improved the docs since I last visited, but it's still a bit confusing. What's the point of Haskell Platform? It looks like it includes stack, which already covers all my requirements. Maybe it'd be useful to include a "why" section for each choice, to provide some examples of scenarios in which you might go with one choice over the other. Telling me what I'm getting doesn't give me any meaningful information if I don't know why I'd want that in the first place. I think there's too much information up-front, even though people landing there probably aren't equipped to make use of it. Why would someone pick the Haskell Platform option or the minimal install option? While reading Learn You a Haskell, I used Haskell for Mac [2] for poking around. It's pretty great, although I didn't end up purchasing it, as I'm not doing anything that would benefit from using it. Something I liked about Elixir is that you can just read their getting started docs and pick up Phoenix framework to get a web app up and running. That gives you a nice base on which to gradually build upon as you learn. Does anyone have a similar suggestion for Haskell? [0] https://docs.haskellstack.org/en/stable/README/ https://docs.haskellstack.org/en/stable/README/ [1] https://www.haskell.org/downloads https://www.haskell.org/downloads [2] http://haskellformac.com/ http://haskellformac.com/
- harpocrates 10y ago
  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 https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems
deleted 10y ago
[deleted]
willtim 10y ago
A nice summary. I'd also like to mention Don's talk again, which I feel should be added to the talk list, regarding the production Haskell we have at SCB: https://skillsmatter.com/skillscasts/9098-haskell-in-the-large-the-day-to-day-practice-of-using-haskell-to-write-large-systems https://skillsmatter.com/skillscasts/9098-haskell-in-the-lar...
elliptic 10y ago
< A lot of industrial Haskell sadly still uses string interpolation for SQL synthesis, or fall back on libraries that use TemplateHaskell to unsafely lock a specific build to a snapshot of a database at compile-time. This sounds kinda off-putting, but I'm not totally sure what it means. Are the SQL libraries for haskell comparable to e.g knex, or psycopg, or sqlalchemy? The bit about string interpolation makes me think that prepared statements aren't used?
elliotec 10y ago
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.
- mjhm2539 10y ago
  https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/ https://code.facebook.com/posts/745068642270222/fighting-spa...
- evincarofautumn 10y ago
  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…)
  - armitron 10y ago
    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-To-Compute https://www.infoq.com/presentations/We-Really-Dont-Know-How-...
dllthomas 10y ago
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/ http://projects.haskell.org/diagrams/) or yesod (http://www.yesodweb.com/ 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

263 points by psibi 10y ago

The Haskell community is incredibly blessed to have Stephen Diehl around. This is an excellent write up on so many of the things that have happened in the Haskell community this year, not to speak of his other written guides and in-depth explanations which are amazing.

fegu 10y ago
I came here after reading the article to say something like this. I try to follow the Haskell community, reading articles etc, but I had missed a lot of this stuff.

BellsOnSunday 10y ago

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 something public, learn how to use your language right.

xwowsersx 10y ago
> I don't want to be picky but if you're writing something public Neither do I, but there should be a comma before the "but" there.
- hota_mazi 10y ago
  No: these are dependent clauses, a comma would be incorrect.
  - charlieflowers 10y ago
    Actually a comma is needed because that is a compound sentence. The 2nd independent clause has a subject of "you" (implied) and a verb of "learn."
  - GavinMcG 10y ago
    What you just wrote is a comma splice, by the way. You should read up on semicolons.
burkaman 10y ago
"infelecities" isn't a word.
- deleted 10y ago
  [deleted]
the_duke 10y ago
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...

moxious 10y ago

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.

chowells 10y ago
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.
- caconym_ 10y ago
  I agree. The nature of Haskell and its type system means that the basic haddock docs are already pretty darn useful even without hand-written content (examples, etc.) being included.
- barrkel 10y ago
  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/columns/launchings/launchings_12_08.html http://www.maa.org/external_archive/columns/launchings/launc...
  - mitchty 10y ago
    > 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.

bipvanwinkle 10y ago

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.

wyager 10y ago
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.
- bipvanwinkle 10y ago
  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.
  - dllthomas 10y ago
    I'm not sure how useful an introduction it is, but I really enjoyed this talk: https://skillsmatter.com/skillscasts/4251-lenses-compositional-data-access-and-manipulation https://skillsmatter.com/skillscasts/4251-lenses-composition...
  - greenrd 10y ago
    The main lens library in Haskell doesn't exactly have no documentation, but it is pretty much impenetrable without a third-party tutorial or blog post. But persevere - it's really powerful!
- axman6 10y ago
  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
  - dllthomas 10y ago

TheAceOfHearts 10y ago

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 were too long. They'd benefit from being broken up into more pages, instead of pushing so much all at once. With that said, the information presented in the docs is actually quite clear and well written. Looking at the Downloads section [1] on the Haskell website, it looks like they've improved the docs since I last visited, but it's still a bit confusing. What's the point of Haskell Platform? It looks like it includes stack, which already covers all my requirements. Maybe it'd be useful to include a "why" section for each choice, to provide some examples of scenarios in which you might go with one choice over the other. Telling me what I'm getting doesn't give me any meaningful information if I don't know why I'd want that in the first place. I think there's too much information up-front, even though people landing there probably aren't equipped to make use of it. Why would someone pick the Haskell Platform option or the minimal install option? While reading Learn You a Haskell, I used Haskell for Mac [2] for poking around. It's pretty great, although I didn't end up purchasing it, as I'm not doing anything that would benefit from using it. Something I liked about Elixir is that you can just read their getting started docs and pick up Phoenix framework to get a web app up and running. That gives you a nice base on which to gradually build upon as you learn. Does anyone have a similar suggestion for Haskell? [0] https://docs.haskellstack.org/en/stable/README/ https://docs.haskellstack.org/en/stable/README/ [1] https://www.haskell.org/downloads https://www.haskell.org/downloads [2] http://haskellformac.com/ http://haskellformac.com/

harpocrates 10y ago
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 https://wiki.haskell.org/H-99:_Ninety-Nine_Haskell_Problems

deleted 10y ago

[deleted]

willtim 10y ago

A nice summary. I'd also like to mention Don's talk again, which I feel should be added to the talk list, regarding the production Haskell we have at SCB: https://skillsmatter.com/skillscasts/9098-haskell-in-the-large-the-day-to-day-practice-of-using-haskell-to-write-large-systems https://skillsmatter.com/skillscasts/9098-haskell-in-the-lar...

elliptic 10y ago

< A lot of industrial Haskell sadly still uses string interpolation for SQL synthesis, or fall back on libraries that use TemplateHaskell to unsafely lock a specific build to a snapshot of a database at compile-time. This sounds kinda off-putting, but I'm not totally sure what it means. Are the SQL libraries for haskell comparable to e.g knex, or psycopg, or sqlalchemy? The bit about string interpolation makes me think that prepared statements aren't used?

elliotec 10y ago

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.

mjhm2539 10y ago
https://code.facebook.com/posts/745068642270222/fighting-spam-with-haskell/ https://code.facebook.com/posts/745068642270222/fighting-spa...
evincarofautumn 10y ago
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…)
- armitron 10y ago
  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-To-Compute https://www.infoq.com/presentations/We-Really-Dont-Know-How-...

dllthomas 10y ago

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/ http://projects.haskell.org/diagrams/) or yesod (http://www.yesodweb.com/ 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