There are quite a few resources available online to learn Haskell. Lots of PDFs, tutorials and so on. One thing I have noticed only recently (i.e.) just now is that I don't stick till the end. I don't like watching tutorials like a lot of people do, I prefer to read. But, its sure as hell a lot easier to watch a ten hour video than to read a two hundred page book or a seven part tutorial. I don't know why that is. By the time I start to understand some of the constructs, I skip to some other thing and start reading that. I have often joked in my company (i.e. alone not in my organization shudders) that I have read more prefaces and introductions than any man alive or dead. I tend to peter out around Chapter 3. When the going gets tough, I bid adieu. Its a personality trait I think. Why does it happen? I have diagnosed ADHD, so there is that. I have no discipline, so there is that. And most importantly I read very passively. Its easy to read the first few chapters as they are just laying the ground or whatever, but when I actually have to think I sort of start losing my mind. And of course there is the ooh shiny phenomena of course.
The saying, not all who wander are lost comes to mind. Perhaps there is a method to madness. It was alright in school when everyone had a set syllabus and every question had a right answer, but life and especially programming are not like that. This information came to me, when I first received the orientation material for my college. Engineering problems don't always have correct answers, it said. It was a foreign notion to me at that time. Of course there has to be a solution and I felt the ground beneath me shake a bit, the certainty I had in my abilities subsided a little. There is more than one reason for this. One is the unquantifiability of design choices. You want to put a bridge on a body of water, you have to design to a spec. You have to deisgn asking yourself, how much traffic you envisage crossing that river, what should the bridge look like, how long should it stand, what is the river flow and terrain like, is there probability of earthquakes and along these questions, the quintessential one - what is your budget? These questions don't have easy answers and sometimes no answer is the best answer, but more on that later.
Then of course there are the unsolvable problems that defy closed form solutions. I would imagine a space of arguments, where you start moving from an axiom or a proposition to another building your proof until landing at the proof of the theorem. But you could take other paths, you could make other arguments, they just have to be logical (and true). Similarly, the space of design is so vast, as is the space of natural language, so many ways to say such little things. Is I hate you the least in this whole wide world, the same as saying I love you? Is it okay to say, I hope you remember me when I am no more the same or much different?
An analogous situation arises in programming, there are so many high level constructs, so many pathways, so many algorithms, so many libraries, so many languages, so much choice and it could be crippling. As I have said before. Even if you have every component of your stack together, there are so many ways to write the damn thing. One realization I have lately had is that you don't need to learn every facet of a language to learn programming. Leonard Susskind writes a lot of books called the Theoretical Minimum. I think there should be a series like that. I mean, if you are doing python, you could just use dicts for everything. For, if, dicts and the APIs from the libraries you are using, can technically get you there.
But perhaps we are not looking to do, we are doing to look. Sorry for that weird construct, I mean, the reading and tinkering become the task in themselves and we tell ourselves, the next tutorial will get us there, or the one after that or the one after that. But something happens, keep doing enough tutorials, and you actually learn things. Keep reading enough HN posts then you can at least shittalk C++ and make fun of Java devs like a pro. Being in the environment itself can enrich you. You begin to make sense of things that you have no actual knowledge of. You know why floating point errors happen and you know what curl does, which means that when you are thrust in a software engineering role, completely unprepared, it doesn't faze you and you can do a good job at it and hit the ground running, so to speak.