For what it's worth, I would suggest just writing code as a means of building your intuition. Don't worry about understanding every last detail; just hack away

For what it's worth, I would suggest just writing code as a means of building your intuition. Don't worry about understanding every last detail; just hack away at it and intuition will come as a natural consequence of your persistence. At least that has been my experience. (Honestly, this is probably true of most things that are challenging to learn, not just unusual programming languages.) I felt much the same way as you when I first decided to dig into Haskell and went through a period of some frustration in which I felt that, although I was more or less understanding the literal text of the books and documentation I was reading, I was lacking a feel for the "big picture" of how it all fit together. I could explain specific details of how the language worked but I couldn't really visualize how to put together a complete, useful program in it. For whatever reason, something about Haskell really intrigued me despite my frustration, and I kept at it. There was never any major epiphany where everything just clicked, though there were a few minor moments of enlightenment, as when I discovered that the neat pattern I had started using in some of my code actually had a name and a well known type class: "Applicative". I also recall reading a particular article about monads (and manually working through its examples) that made me suddenly realize how utterly simple they were, despite the ridiculous hype. After writing enough Haskell code, it eventually dawned on me that I "got it". I wasn't struggling anymore. Haskell had, without my noticing it, become my default, natural way of thinking and reasoning about code, and it just made sense in a deeply fundamental way. I could no longer even see why I'd been confused in the first place. Professionally, I've used mostly Java and Ruby, and have never written a single line of Haskell for pay. But like the author of this article, I've found that it shapes the way I write code in other languages, even those far removed from pure FP, in significant ways. My mental design process when writing new code at work usually takes place in terms of Haskell's data types and abstractions, and then gets translated into whatever language I'm actually using once I feel like I have a good handle on the direction that I'm heading. This usually results in nice, clean designs, consisting mostly of pure, composable functions and immutable data with as little shared state as I can get away with, arranged, when necessary, around an imperative, IO-driven core. Basically the same way I'd structure actual Haskell code. If you're intrigued enough to keep at it, then patience is all you need, and you'll get there. It's pretty fun when you do.