
Reflecting on Haskell in 2016 - psibi
http://www.stephendiehl.com/posts/haskell_2017.html
======
hardwaresofton
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
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.

------
TheAceOfHearts
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/)

~~~
ChubbyGlasses
I'm in the same boat as you. I learning Haskell earlier this year, and while I
really really want to like it (if nothing else, I'm a sucker for type systems)
and even start using it for projects I can't when, IMO, there are languages
out there that feel so much more productive to me. A few key concerns I have
with the language and community:

1\. I feel like there is a really strong push towards writing concise code,
which make it really hard to approach for me. I've seen a lot of code which
substitues words as function names for 2 or 3 character symbols. I'm okay with
learning `>>=` and the like, but when every library want to invent its own
symbol-functions, I feel like the barrier to entry for me becomes much higher.
This occours in just about every high profile library I've seen, from parsers
to web frameworks; everyone wants to invent their own DSL.

2\. For as much as Haskell seems to pride it self on function composition I
don't think `.` is the best way to do so; Clojure's threading macros are much
more readable to me. Comparing the thread-last macro ``` (->> (range 10)
(filter odd?) (map #(* % %)) (reduce) ``` to Haskell's composition operator
`(sum . (map (\x -> x * x)) . (filter odd)) [1..10]`. (Please correct me if
there is a clearer way to write this.) The former is much more readable from
and LTR English language PoV. In Haskell I need to start from the right and
work my way left; and this become even more harder for me to decipher when
function operator precedence starts coming into play. It's small quality of
life things life this which makes all the difference IMO.

3\. The millions of syntax extensions in ghci, some of which are incompatible
with each other. This means ProjectA and ProjectB can be written in completely
different, possible incompatible, 'dialects' of Haskell. Now I have to learn
the base Haskell languge and whatever language extensions that project has
dedcided to use just so I can start reading and understanding the code.

4\. AFAIK, there is now easy way to get function documentation in the repl.
Sometimes types aren't enough for me and I would like to have some human
written documentation guide me when I'm trying to use a library.

~~~
caconym_
Your example can be written more clearly (IMO) in Haskell like this:

    
    
      sum $ map (^2) $ filter odd [1..10]
    

Or, defined as a function:

    
    
      > let foo = sum . map (^2) . filter odd
      > foo [1..10]
      165
    

You can write it without using the composition operator at all, if you prefer:

    
    
      > let bar xs = sum (map (^2) (filter odd xs))
      > bar [1..10]
      165
    

In general, you _can_ write out your programs as crazy sequences of operators
(whose precedence may not be obvious to the reader):

    
    
      > take 5 . unfoldr (Just . next) <$> getStdGen >>= putStrLn . show
      [1336079013,234736121,108049288,410228860,1573295749]
    

But you don't _have_ to:

    
    
      > let infiniteRandoms = unfoldr (Just . next) :: StdGen -> [Int]
      > gen <- getStdGen
      > let fiveRandoms = take 5 (infiniteRandoms gen)
      > putStrLn (show fiveRandoms)
      [1336079013,234736121,108049288,410228860,1573295749]
    

People seem to think Haskell is all about writing your whole program in a
single hideous line of code with incomprehensible sequences of arcane
operators glued together by a glut of anonymous functions, but that's just bad
code.

As for left-to-right vs right-to-left, I have never had a problem with the way
Haskell does it. I think if you're coming from a language that does it
differently, it makes sense that Haskell would trip you up in that regard.
Haskell's composition operator matches the way it's usually written in
mathematics, but there's nothing special about it and you could change it to
go the other way if you really wanted to (but please don't):

    
    
      > let g . f = \x -> f (g x)
      > let foo = filter odd . map (^2) . sum
      > foo [1..10]
      165
    

`(>>>)` from `Control.Arrow` is a more reasonable way to get that sweet left-
to-right action but using it might still throw people off:

    
    
      > let foo = filter odd >>> map (^2) >>> sum
      > foo [1..10]
      165

~~~
Bahamut
To add to that from someone who went into programming after math grad school,
composition is actually much more natural in the way to think about functions.
When putting together functions, and where they map to, it is more natural to
think about functions the way Haskell thinks about them, but more natural when
writing them to go the other way at first. This is because when one is working
at the lower level of just writing code it becomes easier to move from one
data state to another, but at the high level, you lose some flexibility in
seeing the high level structure and it becomes more difficult to figure out
how to move things around if it turns out you have to modify the code.

In math, the preferred way of writing functions is via composition, as then it
enables tools of visualization such as commutative diagrams. One thing to note
is that in general mathematicians have a history of picking the right choice
in notations for thinking about abstractions at an intuitive level in the
world of mathematics (when there is a choice and it matters), and IMO they
were correct about how they chose to represent function composition, although
it is not immediately obvious unless you start talking about function domains
and ranges - the composition notation matches the flow of reading how
functions map values from one set to another.

That Clojure version reads like a complete mess to me personally.

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

~~~
barrkel
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/launc...](http://www.maa.org/external_archive/columns/launchings/launchings_12_08.html)

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

~~~
caconym_
I taught myself Haskell to an intermediate level a few years ago, and I think
you're touching on the truth here.

Haskell is _hard_ to learn, or at least it was for me. There is a whole
laundry list of concepts I had never even heard of that I had to understand
before I could do anything real with the language. Some were apparently dead
simple yet frustratingly abstract (e.g. Monoids). Some were intuitive but
still took time to grok (e.g. list manipulation stuff). Some twisted my brain
into knots and only yielded to persistent study and practice (e.g. monads with
threaded state).

As I was working through all these "basics", I was constantly frustrated
trying to write simple programs. I don't recall whether I blamed it on a lack
of beginner-friendly documentation or not, but slowly it all started to
resolve into a coherent picture and once I could consistently read and
understand real-world types I found that the available documentation was
almost always enough for me to quickly understand an interface and how to
proceed in using it.

I think both sides of this debate are partly right. Haskell's learning curve
seems to keep going up as far as you want to climb, and some of the stuff at
the intermediate level IMO could really use more examples and documentation,
or at least that was my opinion when I was looking at it a year or so ago. One
good example might be Template Haskell, which pissed me off to no end every
time I tried to use it even in very simple applications. It involves a lot of
new syntax and concepts and IIRC had literally _no_ documentation besides what
Haddock gives you for free.

On the other hand, I think a lot of people criticize Haskell's documentation
without knowing the language well enough to make use of said docs or even
understand how they might be useful. IMO it's unrealistic to expect every
module and library to provide documentation specifically for beginners who
don't understand challenging yet ubiquitous concepts (like state monads, to
use your example), and I don't think other languages necessarily do a better
job at this, but Haskell is just so darn tricky to get your head around that
the "total beginner" phase lasts way longer than it might in e.g. Python.

For beginners who do want to learn about the core concepts of the language, I
found that there was plenty of material to help me on my journey: _Real World
Haskell_ , _LYAH_ , the IRC channel, and the internet full of blog posts, to
name just a few. I don't mean for this comment to cause offense, or to
belittle anyone. I'm certainly not an expert Haskell programmer, and there is
much that I still don't understand about it. I just wanted to share some
insights I've had learning it and using it in some practical applications.

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

~~~
evincarofautumn
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
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-...](https://www.infoq.com/presentations/We-Really-Dont-Know-How-To-
Compute)

~~~
sjakobi
> 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](https://github.com/Gabriel439/post-
rfc/blob/master/sotu.md)

~~~
sjakobi
What's the reason for the downvotes?

------
bipvanwinkle
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
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
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
I'm not sure how useful an introduction it is, but I really enjoyed this talk:

[https://skillsmatter.com/skillscasts/4251-lenses-
composition...](https://skillsmatter.com/skillscasts/4251-lenses-
compositional-data-access-and-manipulation)

------
willtim
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-
lar...](https://skillsmatter.com/skillscasts/9098-haskell-in-the-large-the-
day-to-day-practice-of-using-haskell-to-write-large-systems)

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

------
elliptic
< 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?

------
BellsOnSunday
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
> 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
No: these are dependent clauses, a comma would be incorrect.

~~~
GavinMcG
What you just wrote is a comma splice, by the way. You should read up on
semicolons.

