That's a fair question, to be sure.

However, your comments regarding monads see a bit off. I've seen the same sentiments expressed elsewhere (i.e. by others), so I think they represent something of a common misunderstanding.

First of all, monads are simply programming patterns which relate a set of values to a set of of functions. For any monad X, we can say that a function is monadic if it returns a value in the X Monad. The set of values are precisely those such that the following three Monad Laws[1] hold:

[ Using JavaScript syntax, they can be approximated as... ]

Left Identity

mBind( mReturn(x), f ) == f(x);
// => true

Right Identity

mBind( mReturn(x), mReturn ) == mReturn(x);
// => true

Associativity

mBind( mBind( mReturn(x), f ), g ) == mBind( mReturn(x), function(x) { return mBind( f(x), g ); } );
// => true

Above, x is any value in the Monad X; f and g are monadic functions for the same monad. The definitions of mBind and mReturn will vary depending on the monad, but the same laws (and sometimes additional properties) hold for each group of things taken as a whole – the monadic values, monadic functions, and the mBind and mReturn pair for those values and functions.

As you can see, there is nothing special that requires a statically typed language. That being said, if your language is statically typed, and even more so if its type system has advanced capabilities (e.g. Haskell's type system), then the relationships between the monadic values and functions can be leveraged to do a number of useful things, including catching a host of errors at compile time (though that's true regardless of monads).

If your language is dynamically typed, then you won't get those extra benefits, but you can still take advantage of the fact that monads can abstract away a great deal of plumbing between various pieces of your program.

Sometimes the "monad patterns" will appear in a language under another name, or will be used "under the hood" to implement a particular API. Clojure/Script's `let` for example is essentially the Identity Monad; and its `for` is very much akin to the List Monad (the same is true for list comprehensions in other languages). The core.async library involves an inspiring application of the State Monad pattern[2].

In my case, I'm working on an SCXML-like[3] framework which builds on Google Polymer, core.async and protocol-monads (and core.logic at some point?). By using the State Monad pattern (together with trampolines and core.async channels), the algorithms of SCXML can be implemented in a manner that's not dependent on side effects, instead flowing the "global state" between the computational steps in a manner that is consisent and relatively easy to reason about. To boot, by using channels to link together steps in the "mainEventLoop", time is deliberately yielded back to the CPU, making the framework even more concurrency friendly. The project will be open source soon, and I can follow up with some links to source code once it goes public on GitHub.

[1] http://en.wikipedia.org/wiki/Monad_(functional_programming)#...

[2] https://github.com/clojure/core.async/blob/master/src/main/c...

[&] https://github.com/clojure/core.async/blob/master/src/main/c...

[3] http://www.w3.org/TR/scxml/