
State of the Haskell Ecosystem – February 2016 - stefans
http://www.haskellforall.com/2016/02/state-of-haskell-ecosystem-february.html?m=1
======
rifung
> The rating of the "Educational" section still remains "Immature" until this
> book is out of Early Access and finally released, but once the book is out I
> will finally mark Haskell as having "Mature" educational resources.

I haven't read the book myself, but is the book really so good that we can go
from "Immature" to "Mature" with the release of just one book? I find that to
be a bit strange considering Haskell is a very complicated language; I have a
hard time believing a single book (that is beginner friendly no less) could
really explain everything there is to know about Haskell.

~~~
phamilton
Learn You a Haskell for Great Good has been an excellent resource for the
intermediate programmer. Much of the intermediate to advanced space is already
quite mature. The beginner space was the big gap.

~~~
coolsunglasses
Hi, I'm a coauthor of the book mentioned in the State of the Union post.

The beginner parts were _a_ gap, but they weren't the only gap. In fact, none
of the existing books really went very far beyond Monad, with only RWH
covering monad transformers.

So, part of the appeal of the book isn't just that we cover beginner topics
better, we cover _everything_ from beginner to intermediate/advanced that
you're likely to apply in order to, say, make a web application. And in fact,
we use a micro web framework in Haskell to demonstrate stuff in the later
chapters.

It may not seem like it, because chapters like "data structures" actually
cover - profiling time, profiling memory, containers, benchmarking, constant
applicative forms, avoiding memory leaks, etc.

We'll be updating the site to explain what each chapter covers in more detail
soon.

I've spent a couple years teaching Haskell and haven't found LYAH to set
anyone up for success in Haskell. They usually hit a brick wall because they
don't have either the foundation or intermediate idioms to really get
anywhere. So there's usually a 45-days-in-the-desert period after LYAH where
they have to muck through tens or hundreds of blog posts to plug all the gaps.

I talk about this here: [http://bitemyapp.com/posts/2014-12-31-functional-
education.h...](http://bitemyapp.com/posts/2014-12-31-functional-
education.html)

Suffice to say, I would've happily written a much smaller, shorter book - but
this was needed.

~~~
xiphias
I think the problem with Haskell is that you need to be on the advanced level
to be able to write a web app. Every beginner PHP coder can throw a website
together, it shouldn't be harder than that in a higher level language, but it
still is.

~~~
coolsunglasses
Ah no, the more advanced frameworks have better marketing and more bling to
offer. Scotty is quite usable for someone that knows the basics, much like
Sinatra.

Our coverage is less based on hard necessity and more on "what are they likely
to want to do". Haskell just isn't as flat as other language ecosystems. Tons
of people exploring how to do things better but there's a perfectly pleasant,
conservative core of libraries you can use.

------
dexwiz
Can someone explain to me why Haskell will ever be viable as a fullstack
language? I have done a few toy projects in Haskell, and it has taught me some
great functional programming concepts that I now apply to other languages.
But, purely functional programming seems to work 90% the time, but the other
10% is so negative it invalidates the rest.

 __Edit for clarification: Full Stack would be app server up. So runs a server
(some sort of process /thread/worker management), server scripting is in the
same language (can auth, process requests, interact with a DB, etc), and build
the view (simple JSON/blob response, build html, etc). I exclude client side
form this, since most of the X for client-side projects end up transpiling
into JS.

~~~
tathougies
I use Haskell exclusively on my SaaS app
([http://sostenoto.com](http://sostenoto.com)). The backend not only provides
a simple REST API, but it also provides WebRTC signaling and a real-time
graphical communications and presence protocol.

Haskell makes it so easy to write correct concurrent code it's not even funny.
GHC's magnificent IO manager means I can handle 1000s of connections on one
amazon instance. Can't understand why you wouldn't be using Haskell for
server-side web development.

No other popular server-side language supports concurrency (see STM, MVar's,
and Chans), transparent futures/promises for I/O (the entire IO monad in GHC
is non-blocking), support for multiple processors (Just add +RTS -N<n> to make
your program scale to n processors), and a blazing fast HTTP server (warp).

~~~
johan_larson
> Can't understand why you wouldn't be using Haskell for server-side web
> development.

I can't tell whether that's just a rhetorical flourish, so I'll answer
straight.

To begin with, there are a couple of concerns that might kill an attempt to
use Haskell.

1\. I might not be able to get management approval. Haskell is an obscure
language with a reputation for difficulty. The bosses might well say no. 2\. I
might need to work with an existing codebase in something like Java or Python.
Not possible from Haskell.

If those don't kill the project, there's the cost-benefit tradeoff. On the
benefits side: 1\. Haskell code is very concise. (definitely) And greater
concision means faster development. (possibly) 2\. Haskell code is less likely
to contain errors, because of very strict typing. (probably) 3\. Haskell
coders are disproportionately capable, because the language is obscure and
difficult. (probably)

On the costs side: 1\. I have much more experience in other languages. It
would take at least a year, maybe two before I'd be up to pro standards in
Haskell. 2\. The community of Haskell programmers is small. It might be
difficult to hire anyone if the project grew; I might be faced with training
someone from scratch, not just in a new language, but in a new programming
paradigm.

So, this isn't anything like a slam dunk. Quite the opposite, actually. There
are a couple of issues that might nix the project right up front, and then a
daunting cost-benefit calculation.

~~~
fizbin
My experience with writing real production Haskell code is this: your first
large Haskell project will be a failure, largely from missed deadlines and
being unable to properly judge what is going to be easy and what hard. (Unless
you deliberately aim low and spend much more time than is really justifiable
on something you could have done in some language you know better in a few
days)

Your second one will take longer than it would have in PHP or J2EE or whatever
else you're used to building web stuff in. It will, like the first, also be
ugly but unlike the first project will eventually work. It'll also fall over
catastrophically early on, but will be salvageable. Once past its initial
deployment/perf issues, it'll sit and hum away quietly in a corner with much
less care and feeding than traditional web technologies. (Though you'll keep
wanting to go back to it, because it's more fun to work in that than whatever
else you're working on)

The third production Haskell project will come together much more quickly.
Unfortunately, by this time you'll probably be bringing other people on and
this will be their first big Haskell project. (See above about what happens to
first big Haskell projects) So the parts delegated to other programmers will
fail to work, and there will need to be lots of hand-holding and discussion of
type design at first.

Selling management on this is indeed difficult. I'll admit that I'm still not
clear on how we sold the first (failed) project to management or how I
convinced my boss to let me use Haskell a second time. I mean, I was there,
but I don't know how I did it.

------
bootload
A great comparison to the above article is this post by Stephen Diehl, _"
Reflecting on Haskell in 2015"_. [0] A great read and an interesting pointer
on the state of Haskell / Javascript (Elm, Purescript). Also, work your way
through _" Write you a Haskell"_, [1] well worth the effort.

Going through the post, this looks like a comprehensive book. Read the
rationale behind, 'how to learn Haskell' from author. [2]

[0] _" Reflecting on Haskell in 2015"_
[http://www.stephendiehl.com/posts/haskell_2016.html](http://www.stephendiehl.com/posts/haskell_2016.html)

[1] _" Building a modern functional compiler from first principles."_
[http://dev.stephendiehl.com/fun/index.html](http://dev.stephendiehl.com/fun/index.html)

[2] _" Why we don't chuck our readers into web apps_"
[http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-
read...](http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-readers-into-
web-apps.html)

------
steveklabnik
I really, really enjoy these posts. Figuring out what an ecosystem even has
and it's quality can be daunting for those considering a language, and gives
experienced community members and idea of what to improve.

------
melling
It sounds like tooling has improved but it's still the biggest hurdle for
beginners:

"Improving IDE support is the single easiest way to lower the entry barrier to
newcomers."

~~~
etcinit
I think stack has helped in that area. As a beginner, I found stack's ability
to create a new project from a template very useful when getting started with
projects.

The plugins for vim and Atom do a really good job for auto-completion and
showing linter/compiler warnings, but they are a bit hard to setup initially.

~~~
bloaf
And they graduate from "a bit hard" to "downright painful" if you want to do
it in windows. The consequences of doing it wrong can be severe[1].

[1] [https://github.com/atom-haskell/ide-
haskell/issues/83](https://github.com/atom-haskell/ide-haskell/issues/83)

------
noobermin
This might be a good place to ask this: if one decides to go deep into
Haskell, is it a good gamble? What does the job market look like for Haskell
developers?

~~~
coolsunglasses
Speaking as the co-author of the Haskell book mentioned in the post and
somebody that has used Haskell 9-5 for a couple years - you'll have more luck
getting permission to trial Haskell internally than you will competing with
other Haskellers for the jobs that are out there.

I recommend getting comfortable with the sorts of libraries you'd use at work
before trialing to avoid what fizbin mentioned elsewhere in the thread.

tl;dr create, don't take, a Haskell job

------
mark_l_watson
I think that I own 7 Haskell books, and there are good parts in all of them. A
few of them are great. Why all the love and strong recommendation for a new
unpublished book?

I use Emacs, IntelliJ, and TextMate for Haskell. I love all three.

I thought the best part of this article was the coverage of libraries because
I find myself to be uncertain of selecting the most appropriate ones. I use a
small subset of Haskell but that works for me.

~~~
coolsunglasses
Hi, I'm a co-author of the book mentioned. Unpublished might be a bit
uncharitable, the current version of the book is 26 chapters and over one
thousand pages.

As for why? We make certain you actually learn everything you need to know and
we _aggressively_ test and review the material with actual learners. My co-
author Julie's first programming language is Haskell, which she has learned
from me and while writing the book.

Here's a screenshot from our Zendesk for processing reader feedback and
reviews: [http://imgur.com/EdpL4ql](http://imgur.com/EdpL4ql)

We are writing the book because I've been helping people in IRC (#haskell-
beginners mostly which floats around 300 users), on Twitter, etc. I saw too
many people burn out and give up with the existing resources (free & paid),
despite maintaining a guide for learning Haskell with free resources:
[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

It's just harder than it needs to be, so we're fixing that. Even the better
existing books/resources don't cover nearly enough for somebody to move on to,
say, writing a web application.

I wrote about the pedagogical issues with some of the existing resources here:
[http://bitemyapp.com/posts/2014-12-31-functional-
education.h...](http://bitemyapp.com/posts/2014-12-31-functional-
education.html)

If you didn't find it difficult to learn Haskell, that's great! But most
people find it intensely difficult and I think that's completely unnecessary.
I've given a talk on this titled, "Learn Haskell in less than five years"
located here:
[https://www.youtube.com/watch?v=Bg9ccYzMbxc](https://www.youtube.com/watch?v=Bg9ccYzMbxc)

~~~
mark_l_watson
OK, I read "early access" and thought "unpublished".

I stand by my minor complaint that the article was deep in praise for your
book and I thought minimized the impact of the many fine existing books on
Haskell.

Good luck with your book. I like your enthusiasm.

------
hyperpape
The author of the book mentioned has a post called: "Why we don't chuck
readers into web apps"[0] that is...not encouraging.

"....Understanding algebraic datatypes requires understanding products and
sums. Understanding products and sums requires understanding addition,
multiplication, types, cardinality, type constructors, and data
constructors...."

By the time I reach cardinality I wonder if maybe the author is more
interested in making things sound intimidating than helping? Or will readers
be quizzed on the Continuum hypothesis?

"Why can’t I learn Haskell the way I learned $BOZOLANG?"

...I hope the book itself won't take this tone. The community doesn't need it.

[0] [http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-
read...](http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-readers-into-
web-apps.html)

~~~
coolsunglasses
>By the time I reach cardinality I wonder if maybe the author is more
interested in making things sound intimidating than helping?

I'm overstating my case in that post, but underestimating how hard this
currently is doesn't change that there are things you'd want to understand
before diving into a Haskell web application. Part of this is on the framework
designers, it's mostly/only Scotty that has made any attempt not to
incorporate concepts that would be difficult for beginners and it's more
"hiding" than "not using".

You don't need 100% grokhood all along the way, but the current status quo is
that people frequently flounder and burn out because the resources they _did_
use didn't explain things usefully or cover enough. This is not conjecture,
this from a _lot_ of time spent working with people hands on via IRC and Skype
and curating a popular guide:
[https://github.com/bitemyapp/learnhaskell](https://github.com/bitemyapp/learnhaskell)

>"Why can’t I learn Haskell the way I learned $BOZOLANG?" >...I hope the book
itself won't encourage the stereotypes about Haskell the way this post does.

The stereotype that I grew up reading c2 wiki and hacker lore? I've spent most
of my career so far writing C#, VB.NET, and Python. I don't even really mind a
bit of Python here and there, but I don't have much cause to resort to it any
more except for Ansible.

As it stands, our readers have been taking breaks from the book to
successfully work on side projects starting at about chapter 9 through chapter
26. Different people find there are different spots in the book where they can
step away and get things done. The point is that the rest of it is always
there if they need it. Education-by-blog-diaspora has not been terribly
successful for many Haskell beginners up to this point. Partly because there
aren't enough people for there to be enough angles on something that beginners
can reliably find something that "clicks" for them. Another problem is that
you want exercises to thoroughly understand a different way of thinking about
and putting together programs.

In the end, it feels little different in my head than when I'm writing in
something imperative, but the experience is more difficult than it needed to
be for beginners for a long time. The book is me "scaling up" my ability to
help people. Like it or don't, whatever, but please don't try to make a blog
post I wrote into something it isn't so you can try to take me down ad
hominem.

>...I hope the book itself won't take this tone. The community doesn't need
it.

You can find out what the tone of the book is by checking out the sample
provided on the book's website. No need to speculate. As it is, the tone is
light but to the point. Readers have enjoyed the dry humor which is not at all
like how I write on my blog. Which people have liked too. You should spend
less time on HN commenting on things you don't like.

I have writing to do. Goodnight.

~~~
hyperpape
_You can find out what the tone of the book is by checking out the sample
provided on the book 's website. No need to speculate._

You're right. I shouldn't have implied anything about the book based on this
blog post. That's unreasonable. I have things I dislike about this post, but
that doesn't imply anything about your book.

I should've been clearer when I first wrote my post that there's no major
content in your post that I disagree with. There are a lot of things to learn
before you can write actual applications in Haskell (I've been at it for
awhile, and am just really getting to understand Monad Transformers). But I do
think that paragraph is a bad way to put the point. It reminds me of when a
student two years older than me tried to intimidate me by asking if I knew
what a _RECIPROCAL_ was.

I also think that the $BOZOLANG comment is a bad idea. Haskell has a
stereotype that it's users look down on everyone else. You may think it's a
nice little joke, but I'm not sure if it will translate to people who already
worry about whether they're smart enough for Haskell.

~~~
coolsunglasses
[http://imgur.com/K4yXrgs](http://imgur.com/K4yXrgs)

~~~
hyperpape
Cool. I think the line below the headline still has "$BOZOLANG", btw.

~~~
coolsunglasses
Fixed, thank you.

------
fiatjaf
I've tried many times to learn Haskell. The problem is always with setting up
a compiler, getting packages, setting environment, not getting a ton of
gigabytes of duplicated packages, getting useful vim support etc.

~~~
tome
Have you tried stack? It was released about six months ago and has
revolutionised Haskell's offering in this area.

~~~
Volt
>not getting a ton of gigabytes of duplicated packages

How does stack help here?

~~~
tobik
Dependencies are downloaded and compiled once for all your projects using the
same Stackage release and are shared between projects.

In the end you still might have duplicated dependencies if you use different
stackage.org releases but it's a much better situation than using Cabal
sandboxes where every project has its own copy of dependencies.

------
misja111
I like this sentence:

> For a long time vim and emacs were the Haskell editors of choice. Now _more
> traditional_ IDEs like Atom and IntelliJ are starting to get Haskell support

~~~
white-flame
While vim and emacs are certainly more "traditional", they're not IDEs, and
hence not "traditional IDEs".

As a Lisper, I'm still stuck with emacs as the best-supported tool, and that's
kind of a sorry state of things.

------
p4wnc6
I am a beginner Haskeller maybe just crossing the border into "intermediate."

What has been most frustrating for me is not really the quality or
availability of books or learning materials. Instead, it has been hard to deal
with the variability in the opinions of veteran Haskellers as to what it even
means to be a beginner.

For example, in one job interview I had, the people interviewing me (several
of whom had used Haskell for 10+ years) were very impressed by simple things
-- using ADTs to model a take-home programming problem; knowing about tail-
call elimination and how it impacts folds and when to write something with a
helper function; basics of type classes; and fluency with Monads perhaps just
slightly beyond what is discussed in LYAH.

In another interview, someone right off the bat asked me to explain Arrows in
great detail. I admitted I didn't know anything about Arrows except that they
were in some sense a generalization of the "context" view of Monads.

Another interviewer once asked me frightening questions about Template Haskell
and using it for SQL queries (e.g. HASQL).

Yet another asked me "design" questions about multi-parameter type classes and
multi-parameter ADTs. I could point out examples of the latter, like Either,
and I could name-drop the idea of Phantom Types because I heard it once in a
Haskell lecture, but I tried to communicate to them that I didn't have any
real command over these things in a real-life situation.

It's frustrating on one hand because it makes it seem like there is no path,
of any kind, from beginner to intermediate. It's like a Heaviside functions or
something. You are just a beginner until one day you're suddenly not.

It's kind of like playing Marco Polo in a swimming pool too. One person's
yelling from that corner about Arrows. Someone else is yelling about multi-
parameter type class design patterns. Someone else thinks you should know
Template Haskell.

There's seriously no way to prioritize studying those things. If you want to
go an learn Arrows, especially if you're in a geographically isolated area
like I am (hence no ability to attend meetups) and you don't already have a
job providing the crucible of real work to drive learning, then you'll just
flounder for weeks or months with Wikibooks entries on Arrows, etc. Then
somebody stops you and says you're not good enough because you don't know
multi-parameter type class patterns and so now you stop and pivot to that.
Maybe whack-a-mole is a better analogy than Marco Polo.

Of course there will always be some corners of an ecosystem that are obscure.
But the problem with Haskell is that it seems like _everything_ is obscure and
everything pulls you in an entirely different direction, and you don't
understand how they are related until long after you've mastered them at an
intermediate proficiency.

What I'd really like to see is more of a community consensus about what it
means to be "beginner" or "intermediate" or "advanced".

Maybe then people who are putting up job ads for relatively junior positions
or positions where they pay clearly means it's junior will at least have some
community guidance for the sort of out-of-the-box recitational knowledge to
expect?

~~~
striking
Just like Haskell, people learn CS by lazy evaluation. Racking up bullet
points is not how people should be hiring.

They should be able to train you to do what they expect you to do.

~~~
p4wnc6
Hey, I agree. I even wrote up a lengthy diatribe once about this issue [0].

But the reality is that people hire by bullet points and no engineer involved
in the hiring process is going to miss a chance to assert superiority by
asking about something obscure, or some riddle, or some on-the-spot whiteboard
hazing.

In well-known languages, you can at least study what the hazing will consist
of and memorize parts of it. But with an obscure language like Haskell, you're
at the complete mercy of your interviewer. They largely can pick their own
idea of "beginner" and hold you to it. I feel like it's much harder to do that
for Python, Java, C++, etc.

[0] [http://suitdummy.blogspot.com/2015/07/the-unicorn-
inequality...](http://suitdummy.blogspot.com/2015/07/the-unicorn-
inequality.html)

