This example does not fit my experience of "exploratory" programming. Here the author implements DPLL from a textbook, and while there is a gap to fill between

This example does not fit my experience of "exploratory" programming. Here the author implements DPLL from a textbook, and while there is a gap to fill between pseudo-code and Haskell, the problem is already well-defined. Think-upfront-then-code works quite well in those cases. Having compiler feedbacks surely helps to get it right. But exploratory to me means that the problem is not really well defined or understood in the first place. Just as you draft things on paper to get a clear idea of what you want to do, you can use your programming language to express parts of the problem more or less clearly. That also means not being afraid of getting things wrong in the process and being able to code generically. Now, with some languages, you can't explore. I tried in Ada, which I actually happen to like, but every choice was a commitment that would take much time to adapt later, so I actually sticked to pen and paper. I think it can be easier with ML type systems, where it might be easier to have loosely coupled definitions, but I am not sure.