Monads are a part of haskell. Without them the language wouldn't be useful at all. They are an integral feature, and not anything like inline assembler.

The only difference is that monadic functions and pure ones are separated by the type system, and that previously when haskell was not a very practical language, monads didn't exist at all.

Otherwise this is a part of haskell as much as sort is a part of perl.

The distinction is that in a pure FP language, Autrijus' emminently clever code would not be possible.

The inclusion of the monad into the previously pure FP Haskell, is testiment to the practical restrictions that pure FP implies. There are some tasks that FP algorithms are far and away the best alternative. There are some tasks that imperative algorithms (with their inherent utilisation of side effects) are more practical.

Once you remove the "no side-effects" aspect from FP, you end up with the main distinction between FP and imperative code being the syntax used. For some algorithms, a declarative syntax is the most clear and concise. For some algoriths, a recursive definition is the easiest to code, understand and maintain--whether using declarative or imperative syntax. For some algorithms, good ol'imperative loops and blocks and side-effects is just the ticket.

My preference--and there is no implication in this that seeks to restrict anyone else to my choices--is for a language that supports all these styles of syntax, without artificial restristions. For me, currently, the best choice available is Perl, which is why I come back to Perl in preference to all the other languages I've tried over the last few years.

My conclusion from Autrujus' example, is that to address the constraints imposed by my posted problem (memory), the requirement is to utilise side-effects. What Autrujus demonstrated was that this can indeed be done within Haskell.

So, we reach the point where the given task can be tackled in both languages, so the choice of language comes down to personal preference--mine is Perl.

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

Lingua non convalesco, consenesco et abolesco.

Rule 1 has a caveat! -- Who broke the cabal?

The distinction is that in a pure FP language, Autrijus' emminently clever code would not be possible.

That is not correct at all. All programs exist to generate side-effects; otherwise they will be indistinguishable from no-ops that take lots of time to run. This is true for all programming languages of all times, FP or not.

The distinction that a pure FP language makes, is merely that pure functions and side-effectful actions are separated, because the former is always inlinable and memoizable, and the latter always executed sequentially. In contrast, in a language that does not make this distinction, both are executed in some arbitary order.

In other words, functions never have side-effects, but a program does. In Haskell and other pure FP languages, you can write functions that defines composable actions, and group them under the main function. The action defined by main will then be executed as the program itself.

Personally, if I was to implement a fair shuffle in real-world situations, I also would choose Perl instead of Haskell, since it would save me some time, to the order of one minute versus ten minutes. But if memory use (or, sometimes, speed) is of critical importance, as often demanded in my paying work, then GHC is a much more elegant alternative than GCC to me. Which is why I'm working on Inline::GHC after all...

Also, I have no doubt that Perl 6, as compiled by Pugs to Parrot, can be even more efficient than GHC here. :-)

Monads are both pure and side-effectful. This isn't really a Functional Zen Koan (or hey, maybe it is), it's just that purity and side-effects are not really mutually exclusive.

Rather than sharing with you my second-hand understanding, I suggest you check out Simon Peyton-Jones' Awkward Squad paper. It has quotes that directly bear on this conversation such as:

"Call-by-need (or lazy) languages, such as Haskell, wear a hair shirt because their evaluation order is deliberately unspecified."

This paper may answer some of your earlier questions in greater detail.

In any case, I do think we should each use the language(s) we prefer. But I also think it's hard to know whether or not you prefer a language if you haven't tried it.

--Shae Erisson (lambafolk in the process of learning Perl from the inside out)