While it is one person's opinion (albeit well explained) I strongly appreciated Chris Allen's efforts to evaluate existing learning material (prior to co-writing his book) as well as recommending a learning path [2]. Ultimately there is multitudinous material to study. For the textbook-like route, choose something that seems sensible and commit, leaving only when it appears to no longer be fulfilling the purpose. Juggling too many artifacts is like interrupting programmers.
I don't use VS Code but again, my elementary knowledge of the language, plus sufficiency with GHCi, meant I could stay within my Vim comfort zone. If anyone has a good single resource for configuring Vim for Haskell I'd love to see it?
[0] State of the Haskell ecosystem https://github.com/Gabriel439/post-rfc/blob/master/sotu.md [1] Functional Education https://bitemyapp.com/blog/functional-education/ (December 2014) [2] How to learn Haskell https://github.com/bitemyapp/learnhaskell
tl;dr: 1) If you want to buy a book, http://haskellbook.com/ is supposed to be good
2) If you instead want to learn from free online sources, a) cis194 spring 2013 followed by b) The data61 course (links in the github link above).
The current best resource for beginning with Haskell seems to be haskell-book (listed on the Github link above): http://haskellbook.com/. Chris Allen also authored this book with Julie Moronuki.
If you're looking to diversify your interests to broader CS/FP topics, you may find this link helpful: http://reinh.com/notes/posts/2014-07-25-recommended-reading-...
Other references from around here: https://news.ycombinator.com/item?id=9807066
http://bitemyapp.com/posts/2014-12-31-functional-education.h...
http://bitemyapp.com/posts/2015-08-23-why-we-dont-chuck-read...
http://bitemyapp.com/posts/2016-02-06-haskell-is-not-trivial...
https://github.com/bitemyapp/learnhaskell
http://haskellbook.com/ by the above author
This is the approach we take in our book, Haskell Programming from First Principles. (http://haskellbook.com/) The book starts with a _brief_ introduction to lambda calculus and builds on what the reader knows incrementally. You can see in our chapter listing: http://haskellbook.com/progress.html what order we do things in. Importantly, it's not just show & tell. The book has _a lot_ of exercises and detailed explanation for the concepts covered.
I'd worked with and taught quite a few people before starting the book, in addition to maintaining a fairly popular guide (https://github.com/bitemyapp/learnhaskell) for learning Haskell and helping people working through the recommended materials. Further, my coauthor on the book was completely new to programming when she began working with me. What we cover and in how much detail is influenced by working with her, our ~10 deep-dive reviewers, and the over 1,300 emails of feedback/questions we've gotten from readers.
What I did in the book is based on that experience and data. If I could've written less and still solved the same problems, I would've. Maybe a future edition will be shorter after we refactor some things.
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
>"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.
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
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
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...
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
He's currently writing a book, that will cost money ($59 I think), which has beta-access and is IMHO already the best resource out there for most learners of this wonderful language. More info on this here:
https://github.com/commercialhaskell/stack
After installing stack and putting ~/.local/bin on your path here is how I start a project:
cabal init
< answer questions >
stack init
Learning:
https://github.com/bitemyapp/learnhaskell
After those, just start writing crappy Haskell code to solve real tasks you need/want solved. The most important thing is to focus on creating working software with the language, since that's the fastest way to learn.
After you've done this a couple times start reading source code of libraries which solve the same problems you've implemented and see how they are different. This may include lots of learning before you understand the libraries.
Once you understand this library, start going down the most popular libraries and understanding how they work (You might want to skip lens though! I hear it's very difficult to understand the source code and sheer generality):
http://hackage.haskell.org/packages/top
Some papers I feel I'd do a disservice of not mentioning:
http://homepages.inf.ed.ac.uk/wadler/papers/marktoberdorf/ba...
http://www.cs.virginia.edu/~wh5a/personal/Transformers.pdf
Also, I use these as references while writing crappy (and sometimes not as I get more experienced) Haskell code:
https://en.wikibooks.org/wiki/Haskell
http://book.realworldhaskell.org/read/
http://book.realworldhaskell.org/read/
http://adit.io/posts/2013-04-17-functors,_applicatives,_and_...
"We were pleased to get a total of 42 applications, of which 19 merited serious consideration, and we eventually settled on a shortlist of 7 to interview. " [0]
Then there's the entire ecosystem surrounding Haskell, which is still old and antiquated (looking at you Cabal) and moving very slowly (interfacing to NoSQL or AWS, etc...).
> looking at you cabal
See this link for a solution: https://news.ycombinator.com/item?id=9766943
> interfacing to NoSQL
I recently used the Haskell riak[3] binding in my day job for an application. The mongoDB[4] package was uploaded "Tue Jan 19 06:04:06 UTC 2010"[5]
> AWS
There has been an AWS binding since 2011[1][2].
> etc
cassandra[6][7][8]
couchdb[9]
> Finally, the very high bar to just learn how to correctly program in Haskell puts it out of reach of 99% of the developer community.
A 10 year old can do it[9], so I'm sure more than 5% of the developer community can as well!
I wouldn't say I'm a spectacular programmer and I have both learned Haskell and used it in the real world easily enough. I will admit in the past there was a learning issue, but actions to make Haskell easier to learn have (and continue) to happen.[11][12][13][14]
I'm looking forward to any rebuttals you may have to these! :)
0: http://www.well-typed.com/blog/2010/08/on-hiring-haskell-peo...
1: http://hackage.haskell.org/package/aws-0.0.1
2: http://hackage.haskell.org/package/aws
3: http://hackage.haskell.org/package/riak
4: http://hackage.haskell.org/package/mongoDB
5: http://hackage.haskell.org/package/mongoDB-0.1
6: http://hackage.haskell.org/package/cassandra-thrift
7: http://hackage.haskell.org/package/hscassandra
8: http://hackage.haskell.org/package/cassy
9: http://hackage.haskell.org/packages/search?terms=couchdb
10: https://superginbaby.wordpress.com/2015/04/08/teaching-haske...
11: https://github.com/bitemyapp/learnhaskell
13: http://www.amazon.com/Beginning-Haskell-A-Project-Based-Appr...
OO has 'Inheritance', 'Subclassing', 'SOLID', 'Liskov', every design pattern name, 'Object', 'Class', 'Overloading', 'Factory', etc, etc.
Haskell has similar words, covering both core concepts, and common patterns of implementation. 'Monoid', 'Monad', 'State', 'Reader', 'Function', 'Lambda', 'Typeclass' are all examples of terminology in Haskell
None of those words are inherently more difficult than the OO ones, you're just not familiar with them.
The best way to learn Haskell is to follow along with a course that has you do exercises, and actually do the exercises. See the https://github.com/bitemyapp/learnhaskell course for some class recommendations.
The alien-ness is what makes it difficult, not the actual design. Less design surface area makes it considerably easier to learn in that respect. That doesn't mean Haskell is easy to learn in general, for now. There's a huge difference in jumping from Ruby->Python->JS vs. learning how to program in terms of a foundation built on lambda calculus.
"singular composite of expressions" - this doesn't mean a lot, and doesn't really fit, I think. You can hand-wave do syntax and pretend you're writing imperative code in IO. A lot of people do that when first starting out so they can get the hang of things. SPJ (OG Haskell honcho & compiler hacker) likes to say that Haskell is the nicest imperative programming language to use. I'd tend to agree :)
Takes practice. You need exercises.
If you haven't already seen it, I'd recommend taking a look at the guide I've maintained on how to learn Haskell: https://github.com/bitemyapp/learnhaskell
Pretty thrilled about this book.
There are rather few recent Haskell texts with beginners in mind, and Chris of the https://github.com/bitemyapp/learnhaskell fame is probably one of the most qualified people out there to teach the subject. At Front Row we actually use learnhaskell pretty heavily with our new developers. For us it's the central hub for devs to start learning the language.
Anything that helps people get started and advance through the skillset is a huge boon to the community.
The learnhaskell guide (https://github.com/bitemyapp/learnhaskell) is the product of 41 individual contributors. I got the ball rolling on the guide a year ago.
There are rather few recent Haskell texts with beginners in mind, and Chris of the https://github.com/bitemyapp/learnhaskell fame is probably one of the most qualified people out there to teach the subject.
Anything that helps people get started and advance through the skillset is a huge boon to the community.
https://github.com/bitemyapp/learnhaskell
I have a general question about Haskell though: I've read in more than one place that writing high-performance Haskell code is not easy for a non-expert to do, and to at times you have to sacrifice conciseness.
While I love the aesthetics of Haskell syntax and higher order functions, I have this paranoia that beautiful code may be slow code.
My guide for learning Haskell is here: https://github.com/bitemyapp/learnhaskell
You can get help in the IRC channel if you'd like as well. I don't recommend using LearnYouAHaskell.
I feel a bit bad as Hudak's books were the only ones I hadn't checked out before starting on my book. Rectifying that soon.
it's comforting -for me- to see that almost everybody is going through the same phases while learning haskell. i believe that should say something to haskell community.
i've recently started learning haskell. it's been 25 days. (so says cabal) i was reading a book and struggling to build a web app. (why web app?) i was so close to quitting. later i decided this is not the way to learn haskell. one simply does not read the book and try stuff. that was not enough. at least for me. so i changed my method.
my new method of learning haskell is:
- read the book.
- find one or more mentors (i have two) that are really good at haskell and can answer all kinds of impatient questions you have.
- watch people doing and explaining haskell stuff.
- join #haskell-beginners on freenode and ask your questions.
- create something small first that you can turn into something big later.
online haskell resources are surprisingly deficient however #haskell-beginners community is awesome when it comes to helping n00bs like me and "learn you a haskell" book is an excellent book.
one more resource that i use as reference material is the "haskell from scratch" [0] screencast series by chris forno (@jekor).
before you begin, make sure you checkout chris allen's (@bitemyapp) "learn haskell" [1] guide.
we'll get there people, we'll get there. :)
[0] https://www.youtube.com/playlist?list=PLxj9UAX4Em-Ij4TKwKvo-...
https://github.com/bitemyapp/learnhaskell
OP's article is still a great way of wetting appetite, and sharing insights; but moving on from there is better facilitated by Chris Allen's recommendations.
There is also the IDE issue; FPComplete has a web-based IDE that is good for beginners, and it is possible to setup Emacs to be a very helpful IDE (though this is by no means simple). With Haskell an IDE is really helpful: see the errors as you type, and resolving them before running into a wall of compile errors.
Anyway: go Haskell. I'm looking forward to a less buggy future :)
There's also Chris Allen's guide: https://github.com/bitemyapp/learnhaskell . You can also go through the (good, but very dated) book, Real World Haskell.
Sometimes you have to find the tutorials and blog posts first. The lens type signatures aren't the easiest to understand, and sometimes its easier to just use things "empirically" without fully understanding them, and then get a sense of the type signatures when you really want to know what the compiler's actually doing. Being able to use lenses is not as hard as understanding why its intimidating rank-2 type signature is the right one.
Finally, sometimes it helps to de-generalize. To replace (Monad m) with IO, for example, and think about what that special case might mean.
For example, the type signature for Control.Arrow.first is:
first :: Arrow a => a b c -> a (b, d) (c, d)
first :: (b -> c) -> (b, d) -> (c, d)
As for nomenclature, I don't disagree. I had this discussion with Brian Hurt (and owe him for the insights): we'd be more marketable if we called Monoid "Appendable" and Functor "Mappable". Monad is one where it's hard to come up with a more accessible name for it: it abstracts over computational context (i.e. what do we actually mean when we talk about computational effects) but that would be a mouthful of words and not any more clear.
[1] http://book.realworldhaskell.org/
[2] https://www.edx.org/course/introduction-functional-programmi...
After a few months of starting from nothing (zero programming experience), my main non-programmer student is now coauthoring a book on learning Haskell [1] with me.
Learning Haskell doesn't have to be hard. It helps to follow a guide designed by people that have plenty of experience teaching Haskell [2].
There is an IRC channel at #haskell-beginners on Freenode.
The author of the post refused to avail himself of other peoples' help, particularly via the mailing list. If you seek help you can learn Haskell and apply it to practical problems in less time than you'd think.
[1]: http://haskellbook.com [2]: https://github.com/bitemyapp/learnhaskell
1. Forget everything you know and follow the types.
It wasn’t a sudden switch and while the iron tools owned the future, they were inferior at first. Took a long time before iron tools and weapons became the most popular thing, even after iron tools could be made that were superior to bronze.
Popularity doesn't say anything about tool quality.
A lot changed from 2010-2012 for Haskell. There was an explosion of libraries and tool fix-up. This continues, no doubt, but it has shifted the equation in favor of tools that don't have to make compromises that harm productivity.
I teach Haskell in a decided un-academic manner. This is partly because I have no academic background nor degree. It is also because I teach people Haskell in a manner designed to enable its use for practical projects.
This is the guide I use to teach people Haskell: https://github.com/bitemyapp/learnhaskell
I've taught Haskell successfully for the last year to programmers and non-programmers.
The usual sequence is [1] followed by [2].
Augment with [3] and [4] as needed.
One negative thing about Coq/Agda/Idris is they don't have a satisfactory encoding of typeclasses [5]. This is a problem in general with all dependently typed languages. Proof obligations get "churned" by changing code and the only tool to address that is extremely general proof terms combined with proof search. The best proof search is Coq, but the code extraction is heartburn-inducing for Haskell users.
Whereas in Haskell, we get extremely lightweight and type-safe code refactoring because of the way in which we leverage typeclasses and parametricity. This turns out to be very valuable as your projects get more serious.
That said, still entirely worthwhile to learn Coq or Agda.
By the way, this [6] is how I teach Haskell. Working on a book as well.
[1]: http://www.cis.upenn.edu/~bcpierce/sf/current/index.html
[2]: http://adam.chlipala.net/cpdt/
[3]: http://cheng.staff.shef.ac.uk/proofguide/proofguide.pdf
[4]: http://www.amazon.com/How-Prove-It-Structured-Approach/dp/05...
[5]: http://wiki.portal.chalmers.se/agda/pmwiki.php?n=ReferenceMa...
- ex-Python and Clojure user, teach Haskell now.
Que no!
Bloodhound, which is expressly about talking to an outside database, has >500 type signatures. Fewer than 40 have IO in them. You most certainly do not need to add IO to pure code just because something in IO invokes it.
This is why we have things like Functor, monad transformers, etc.
Want to know more?
I can't even remember the last time it was cold-suggested to somebody.
The last person I knew to do so, did so knowing they were going about it the "hard way". They also did it with the intent of actively upgrading/updating the code WYASI48H as they went into a more modern style. They gave a talk on it after.
It's a good way to firm up your knowledge if it's the sort of project that interests you, but needs love and isn't a good introduction for most.
Additionally, you're working with the knowledge that once you install Haskell Platform, you need to update cabal-install (This is not something a newcomer would expect given that they just downloaded cabal via Haskell Platform).
Just getting the Platform installed is misleading as well; there's still the issue of dealing with package conflicts which happens frequently in Haskell and is non-trivial to deal with for a newcomer.
Finally, using Haskell Platform at all might cause troubles; it's explicitly recommended against by the popular Getting Started guide by bitemyapp https://github.com/bitemyapp/learnhaskell because it uses the global package database.
Cabal does OK for the most part nowadays, but it's definitely still a challenge with the monster projects like Yesod. Supposedly that's a work in progress for now.
It also has an irc channel that is fairly active (#haskell-beginners).
I think CIS 194 would be nice to be added in the book listing section? It's a great course with exercises and at the same time refer to chapters of both LYAH and RWH.
If none of that helps, come to freenode #haskell, those packages really should work.
I teach Haskell to experienced programmers and people that have never written code before. I know nothing about math, I dropped out of uni after one quarter, I have not studied math since that time. Most of my students didn't know any math and weren't any worse for it.
https://github.com/bitemyapp/learnhaskell
If you start going through the guide and get stuck, I will help you.
Only fear can stop you, be brave!
I offer to teach people online and I have an IRC channel called #haskell-beginners on Freenode.
People go through my course: https://github.com/bitemyapp/learnhaskell
And when they get stuck, they ask questions.
I'll begin giving local classes soon. I'm giving a talk the 19th in Austin.
Cf. "Visitor pattern"
I wasn't ignorant enough at the time I wrote the code to fuck up in the way you describe. I can only show an example of stuff I've made.
Here we go, three more uses of Monoidic functions (mempty, mappend)
https://github.com/bitemyapp/bloodhound/blob/master/Database...
It's not just about code, it's about conceptual memoization.
If you know what a Monoid is and you're learning how a data type like ByteString works, you can intuit how to "stitch" bytestrings together as well as how to get an "empty" ByteString.
It's about killing off unnecessarily ad-hoc APIs as much as anything.
Being able to realize when you're implementing a Functor/Monoid/Applicative/Monad is powerful because it lends you intuition on what the rules for a well-behaved API are and allow powerful, polymorphic code-reuse.
Consider the reusability of the functions here across the vast set of Monadic types out there: http://hackage.haskell.org/package/base-4.7.0.0/docs/Control...
This is worth pondering as well: https://github.com/jwiegley/simple-conduit
The code savings described are usually associated with not having to rewrite the polymorphic generic functions used in the Haskell ecosystem for the one-off a person made. The conceptual power from having a community that understands these patterns is more important.
You'll learn more and faster by learning Haskell.