I've felt the power of Haskell before, through tidbits I've learned and books like Learn You A Haskell. However, Haskell still presents itself as a giant rock in my mind, somewhat impenetrable and obtuse. It's so different from my normal thinking processes that my brain has an incredibly difficult time adjusting. It's like my thinking process turns to goo after the first few layout steps.
Basically, I wish I could understand Haskell so I could harness its power.
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.
> It's like my thinking process turns to goo after the first few layout steps.
If you've gone beyond a few layout steps, consider factoring out more small functions from your code. I've found that even very large Haskell codebases tend to end up with mostly two or three types of functions: short single-purpose functions of a few highly expressive lines, long but conceptually simple pattern matches covering a data type with many constructors, and long but conceptually simple monadic functions sequencing a flat series of steps gluing together other functions.
You'll spend most of your time reading and writing the short functions, writing types and names that make them self-explanatory, finding ways to factor out more of them, and occasionally staring at them and thinking "it feels like I've missed some simpler way to write that"; the long functions will fly off your keyboard almost as fast as you can think and type them.
The best way to do that would be to sit down and just write something fun in Haskell. I think the Write Yourself a Scheme in 48 Hours tutorial is a good place to start. While I'm not sure it has the best code style, it's probably the easiest way to get yourself into the Haskell mindset.
It's funny, because I used to feel that way about Lisp before I learned Haskell, and I still feel that way about Smalltalk even though I do know Haskell.
At some point I decided that there are things I like and am passionate about that I'm simply not going to be able to master for one reason or another and I'll have to live with admiration from afar. The last time I used Lisp I came away feeling like I had successfully tricked it into doing what I wanted, and I looked back at what I had written and thought, this is no way for me to live. I suspect what you're describing is the same thing.
> It's so different from my normal thinking processes that my brain has an incredibly difficult time adjusting.
This is precisely why learning Haskell is important...at least for those interested in self improvement. When I started Haskell, I picked it because it seemed like the hardest language I knew of at the time. It was one of the best things I've done for my career.
Don't give up. I kept myself at it for many days, thinking while walking/eating and even before I slept. Eventually it clicks. Probably the most memorable experience I have had as a programmer, so far (still young).