Take STM for example: this is a way of sharing information across threads.

Basically a variable--the imperative sense of the word--plus some sequence information about who read what value when. Ie. State.

Not quite; or, yes and no. Haskell already had run-of-the-mill mutable vars (called IORef). But STM gains its power from both monads and the fact that there's a typechecker. It's not just some sort of simulated state. You can have ten different functions updating the same TVar, and STM takes care of synchronizing this state across threads. (With no deadlocks and in composable ways; there are slides and a video that explain this very well.) And it's just TVars that you can update this way; your code won't compile if you try to update an IORef that's not part of the concurrency celebration.

Equally, it is perfectly possible to write 'pure' functions in Perl (debatable given aliasing :).

Of course it is! But the benefit that's missing is a typechecker, of the kind that doesn't let you compose functions that wouldn't make sense. How do you tell a function is pure in Perl? You read its code. But surely, the compiler could have figured this out at least?

Having good reason to believe a function is pure can be quite convenient. Your runtime could, for example, decide by default to memoize all pure functions automatically. If the compiler could prove a function only accepts one arg and that arg is a single byte in width, this can be a very cheap optimization! (Who knows, the compiler might precaluculate all possible output values if there were very few of them.) With an impure function, you simply have no grounds to do this, since you don't know if the function is looking at some other concealed input (of if indeed the caller wants it to produce some side-effectual output).

Regarding idiots, sorry, I was using the wrong word. I wasn't referring to anybody's intelligence, but rather to how some people deal with newcomers superciliously. I believe a better term is "gratuitously unpleasant person", though others may also be applicable.

But surely, the compiler could have figured this out at least?

Hm. One way of reading it is that Haskell defaults to assuming that all functions are pure unless a monad is used, in which case they aren't. And it's the programmer that has to know to when to use the monad. Which goes back to my "monads are a complicated form of flag". Yes, I know it's more complicated than that...

Perl is the other way around. All functions are impure unless the programmer knows otherwise. It would be possible to use (say) attributes to allow the programmer to mark functions pure and the compiler could automemoize them on that basis. Maybe there is even a module idea in there somewhere.

For sure, Perl does no where near the depth of analysis that ghc does--but that is true in almost every area. Objects for instance. And maybe it's not possible without strict typing. But it is also a concious choice on behalf of the the language designers, hence Perl 6 won't have HM-style type checking either.

Is that the right decision? You'd have to argue that with Mr Wall. But without Perl's transparent coersion between strings, integers and reals (and Big::*), Perl would not be Perl.

Haskell and Perl go about achieving what they do--programs--in different ways. We all know that. This is not (for me) about which is better. It's about whether Perl could benefit from the inclusion of a monad type mechanism, to which I say emphatically no. Even if it could be implemented, without an HM-style type system, and a deep analysing compiler, it would be another manual process adding a drain on performance, without the benefits. Adding HM-style type checking to Perl (or any dynamic language) would be fairly impractical, but even if it was practical, I personally wouldn't want it. If I wanted that, I wouldn't be using Perl.

Haskell (often) sells itself on the strength of a few elegant snippets--like the quicksort routine using list comprehensions, but when you look beyond those snippets, much of the gloss is tarnished. It's a little like the Quantum::Superpositions module. When you first encounter it, especially the documentation in the form of what I am sure was a spectacular presentation, it really wows you. But when you look inside, you realise--as someone here commented--it's just a bunch of loops. That doesn't make the module any less powerful in what it does--though it is a little slow for some of it's less esoteric possible uses. What it does mean is that when you understand how it does what it does, the wow factor of the documentation/presentation fades somewhat. If the documentation was less wow, more down to earth, it might engender less ire. I'm pretty certain that Junctions will become a big factor in the success of Perl 6, assuming they are documented in a less hyperbolic fashion and are reasoably fast.

Haskell is a fine, powerful, flexible, fast, elegant language--if you like or need that sort of thing and can make the mental shift to that way of thinking. It doesn't need the hyperbole.

I've tried to keep this subthread on topic, but our interaction is rapidly descending into a which is better debate. Unless you think that Perl would benefit from the addition of a monad-like mechanism, I think we are probably done?

---

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

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

One way of reading it is that Haskell defaults to assuming that all functions are pure unless a monad is used, in which case they aren't.

I have some modest Haskell experience myself, and I admit I learned about monads the "wrong" way (starting "as a way to do IO"), but I've come to look at it a bit differently. To my mind, monads let you compose code in a more procedural-esque style without worrying so much about the stuff going on in the background, or whether that stuff involves side effects or not. The thing is, most Haskell monads actually are purely functional in that when you actually expand them out and evaluate them they boil down to simple computations that don't touch the state of the outside world - arguments in, return value out, nothing more to it.

This does mean, to my mind, that Perl is fairly unlikely to benefit much from monads, because there's no need for that sort of simulation. And I agree with you that absent static type-checking, the fact that a monad's very existence constrains the operations allowed within it becomes less useful.

I've tried to keep this subthread on topic, but our interaction is rapidly descending into a which is better debate. Unless you think that Perl would benefit from the addition of a monad-like mechanism, I think we are probably done?
I didn't get the feeling I was saying Haskell's better; I was merely trying to give meaning as to what's good about (an aspect of) it. I kinda like Perl, myself! And no, I wan't saying Perl needed monads anywhere. So sure, if there was a debate aspect to this conversation, I suppose we could wrap it up.

Except :-)

I have to say I felt mentioning Quantum::Superpositions here was something of a strawman. Or even, two strawmen. "It's just a bunch of loops" smells like the notorious expression "It's just a way to arrange JMPs". There's expressive power offered here, even if the implementation emulates something using loops. And secondly, presumably once the technology arrives whence the module got its name and inspiration, the implementation would cease to be an emulation, and the operations would become primitives. But we can drop this too...

An interesting aside arises from working my way through your links on STM. From section 4.4 of STM.pdf:

Like high-level languages, transactional memory does not banish bugs altogether; for example, two threads can easily deadlock if each awaits some communication from the other.

The oft-quoted problem with lock-based shared state is the deadlock problem. I was under the impression that STM was the cure for this. I'm disappointed to discover that's not the case.

See, you gotta look under the covers :)

---

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

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

"Too many [] have been sedated by an oppressive environment of political correctness and risk aversion."

There is no silver bullet. But sometimes you can pick up a better stick.