It'll teach you enough to be dangerous. Obviously your learning has just begun, but with a mental platform that lets you study other resources in time and practically test things out.
Also consider https://leanpub.com/fp-made-easier , which teachers Purescript, very similar to Haskell. I've skimmed some of that book and like the writing style.
I'll add my two cents. Over the past year or so I went from being completely overwhelmed by Haskell to feeling pretty comfortable reading / writing Haskell, even enough to make my first PR to a Haskell package! Here's what worked for me:
* I went through LYAH, but at a certain point I felt like it wasn't doing me any favors by sweeping some of the inherent complexity under the rug. So I started listening to talks by SPJ, Wadler, et al. and reading the papers they wrote in the 1990s-2000s. See for instance the SPJ talk on Typeclasses [1], the Beautiful Concurrency paper [2], and the one about Monadic Parser Combinators [3].
* Don't just read stuff, run it in GHCI, or better, learn how to set up a minimal project with Cabal/Stack.
* I spent a lot of time reading about type theory and category theory. This isn't strictly necessarily, but it gives me context and perspective on the language.
* Haskell Language Server integration with VS Code was a lifesaver. Being able to hover over an expression and see the inferred type makes it so much easier to reason about Haskell code as a beginner.
* To understand monads, it was most helpful to see how do-notation and the >>= and >> operations desugar into a sequence of lambda abstractions. In general, I tried to find as many different examples of monads as possible. Seeing monad comprehension syntax really helped as well.
* After a while, I could read Haskell, but felt absolutely lost when trying to write it myself. So, I started working on a small cli that forced me to learn stuff like: how to manage a monad transformer stack, how to make http requests, how to parse and serialize json, how to write to a database, etc.. It took months and months, and I would often get stuck and have to go and spend a few weeks learning something else. But I always had a project to come back to and apply what I learned.
The main reason to learn category theory for Haskell is to learn how much of the Haskell meme complex is wrong. Otherwise, it won't help the typical newcomer. I think it's important to explain that Hask isn't a category, that Haskell's type system is unsound, that Haskell doesn't have sum types, etc.
There are powerful applications of category theory to other parts of computer science. If one keeps in mind that Haskell is Just Another Programming Language, then one can apply category theory more generally and fully.
Agreed. Let me drop some references about the relationship between Haskell and Category Theory that really helped me untangle these concepts, in case it might help others.
>forced me to learn stuff like: how to manage a monad transformer stack, how to make http requests, how to parse and serialize json, how to write to a database, etc..
I am currently just before this stage. I can use Haskell for stuff like projecteuler.net problems but I haven't written a single useful, real-world program without copy-pasting some code.
I tried doing something with http requests to an API for stock trading but I failed to understand how to make a request. There are a few packages but they all have their flaws (e.g. no https) and aren't really developed that much.
My question is: did you write all these things with mostly only the Prelude of Haskell or did you use packages for all those things you listed (http requests, json data, databases etc.)?
I'd love some pointers in the right direction for http requests as well as maybe ideas for initial real-world project ideas that are exciting (I don't care for the standard ones you find online).
Yeah, the goal was (rather, is---I'm still working on it!) to learn more about real-world Haskell by actually learning how to use packages and forcing myself to read the Hackage docs, so for this project I pretty liberally import a new library whenever I need something.
The "req" package is very intuitive to use for requests, and plays nicely with "aeson" for parsing JSON. I'm also using "persistent" to manage a sqlite database.
For project ideas, try to scratch a personal itch. If you're solving a problem (or a daily frustration) that's important to you, you'll be more motivated to follow through! For me, I had been using the beets (https://beets.io/) command line tool to manage tags for my music library, but it isn't really optimized for my use case, and I thought I could do better. So I decided to write a cli [1] with Haskell to tag all my local music files with metadata from Discogs/MusicBrainz, modeled after the beets tagging loop. I'm also working on a more advanced tagging system that uses Datalog inference rules, inspired by a blog post [2].
Try using wreq[0] instead. Here's also a post[1] which describes someone else facing the same pains earlier that you're currently having. For anything to do with JSON, you need Aeson[2]. For working with databases, Persistent[3] and Esqueleto[4] (they're designed to work together) work great.
I would recommend starting with Elm. The language is much smaller, and the error messages are best in class. The error messages from the Glasgow Haskell Compiler (GHC) are often intimidating and it takes time to get used to them. Whatever you learn in Elm will translate more or less directly to Haskell.
They have vastly different use cases. Elm is a frontend language while haskell is a backend one.
You may want to learn both for making a full stack app. Or just learn Haskell and use its wasm compiler.
Even if you want to learn Haskell, learn Elm first. Two weekend of Elm will do more to explain Haskell do you than just about anything else.
Elm is beautifully simple. And it gives you such a solid foundation to learn Haskell and how to think in Haskell. Even if it's not Haskell and is a much smaller language.
4 out of 5 people will learn Haskell faster by learning Elm first, than by just focusing on Haskell. And I mean even accounting for the time learning Elm it still will be faster to learn Haskell.
Purescript is almost Haskell anyway. I love writing it, but it probably makes more sense to just learn the mother language first, since so many more educational resources are available.
Yes, Elm ignores many of the more interesting and important aspects of Haskell for the sake of appealing to JS devs. Go Elm if you want a ML based framework for web clients, but for actual language study, go Haskell.
EDIT: Seriously downvotes for that? Go watch some of Evan's talks on Elm, when pressed for why he doesn't implement some of Haskell's more out-there features, he states that his goal is not to appeal to Haskell devs, but to JS devs, and that he wants to keep the language palatable to them.
There's a massive intellectual black hole at the center of the Haskell galaxy, yet many worlds have evolved happy, advanced civilizations without spiraling into that black hole.
A small subset of Haskell makes for a spectacularly effective functional language. Visualize that this subset exists, and have fun learning it. It helps if one has seen other small languages that work, such as Scheme.
Unfortunately, that subset isn't closed or isn't powerful enough to escape primitive recursion; take your pick.
Suppose that I'm wrong and it's both closed and powerful enough. Then, fix an arbitrary Haskell type signature for some function `f`, and consider defining it as `f = undefined` or `f = f` respectively, and work out what still remains in the subset. Indeed, `undefined = undefined` is its typical definition.
I went through most of the Hutton book but I already had an elementary background in the language. Then some of the recommended CIS194 course. (3-6 months spent studying total.) Finally I decided upon a project that was right in one of Haskell's strong points: parsing/compilation [0]. Everything was a Google search: how to start a Haskell project with Nix? How parse command-line arguments? How to write a parser for a calculator? What the hell does this compiler error mean??!! Find the answer and get straight back to it. I would still consider myself intermediate, and not proficient, at the language.
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?
Learning Haskell as a beginner might be, IMO, comparable to learning something like Java or other languages w/ a lot of baggage (= daunting for a beginner), so I believe books or tutorials can only help so much.
I would suggest playing w/ a "smaller" language like ML (https://learnxinyminutes.com/docs/standard-ml/) or even Hope (https://github.com/hcarvalhoalves/hopeless) to understand the sources of inspiration and grasp some concepts of FP, pattern matching and algebraic data types. The more featureful Haskell may be less confusing if you can better discern what are core concepts vs. unique features, and also avoid fixating in monad tutorials.
This got me thinking of something a bit ridiculous: could it be possible, given enough carefully designed examples, to effectively teach the basics of a language without using a single word of a human language?
That's how many puzzle games work, so I'm pretty sure this can be done with programming languages just as well. It would need a good progression of examples/exercises, but I think that could even be better in some aspects. For one it enforces a certain quality for the code examples because they can't rely on any explanation. And it would be less ambiguous when covering more abstract concepts (my biggest difficulties in understanding OOP and interfaces for the first time were caused by misleading explanations).
I would say "No", because there's far more to programming than syntax.
Eg, how do you explain things like scope, object lifetimes, and destruction without words? In C for instance, there are various non-intuitive things such as that the string "Hello" is actually 6 bytes.
IMO, syntax is the least important part of programming. It's far more important to understand what exactly that syntax does. Take for instance #include. It looks straightforward on the surface, but there are lots of un-intuitive parts to it, such as that you're effectively copy/pasting a file into your code, that you need include guards, that order can make and a.h can #define something that breaks b.h, that you need to #define _GNU_SOURCE to get some particular bit of functionality before a particular header...
You can definitely write sample code to illustrate all that but I can't think of any way of explaining "what's going on" and "why we're doing this magical looking bit here" without using words.
"So I read a couple of tutorials online and went through the famous Learn You a Haskell for Great Good ! It was a long and painful journey - which is not over yet. After some retrospection I wanted to share my own introduction to Haskell based on my python experience. What I wished I had learnt first and what I wished I learnt later down the road."
That book was heavy on syntax right off the bat, and light on underlying theory, which is why I ended up bailing. The blog is even more extreme, and gives no explanation as to why a beginner should even bother. Might as well read the official Haskell documentation instead.
LYAH is a great resource but it is a bit dated at this point and there have been more entries into the space.
Haskell needs more content like this to show people how approachable it is, and especially when they're more up to date and more in line with recent best practices in using haskell.
As long as we're not all doing burrito tutorials, the more people that engage with Haskell (and write posts about it), especially simple, straight to the point ones like this the better.
I personally have written a guide on how to build practical APIs in Haskell that is now quite outdated[0], and while I tried to go from zero, it is almost certainly not a good entry guide. Glad to see more people taking stabs at it.
RWH is even more outdated than LYAH, unfortunately. I learned off Haskell Programming from First Principles, but it's since become controversial because of a falling-out between the authors.
Because it's not an effective learning resource. Too many people read LYAH only to be left with a very shallow understanding of how to use Haskell and little to no experience on building even small projects in Haskell.
Or maybe because his journey was not the best with the book, and he wanted to share how he wishes it was explained (it's written in the article, if you can read!)
1) WHY: The Functional Programmer's Toolkit - Scott Wlaschin : https://www.youtube.com/watch?v=Nrp_LZ-XGsY
2) WHAT: Learn Haskell in one video : https://www.youtube.com/watch?v=02_H3LjqMr8
3) HOW: Haskell without the theory : https://www.vacationlabs.com/haskell/
It'll teach you enough to be dangerous. Obviously your learning has just begun, but with a mental platform that lets you study other resources in time and practically test things out.