I'm not quite sure what you mean: monads are very well defined even within Haskell, certainly more than most programming abstractions. Essentially, a monad is any type that has some particular functions defined on it that act consistently with each other (e.g. follow the monad laws). That is all a monad is--understanding what they're useful for or why we care is a different story, but you can get that from examples.
You can have a perfectly good grasp of monads in Haskell without understanding the mathematics behind it at all: the a look at the "you could have invented monads"[1] tutorial.
Moreover, the behavior of monads is more precisely proscribed than the behavior of abstractions used in other languages. While you do not need to understand the mathematical background to use monads, the fact that's it's there helps ensure that implementations act consistently. Having explicit laws implementations must follow makes it much easier to rely on them.
So monads are actually very well defined, even if too many people rush out to write ill-advised blog posts before they actually understand anything (this post is a great example, as is the linked talk by Douglas Crockford).
Ultimately, I think Haskell is the language that works best at scale. It both gives you the tools you need to write extremely maintainable code and also actively encourages you to do that. I've found Haskell code to be significantly simpler, more self-contained, more decoupled and more self-documenting than any other language I've used. I've found it far easier to come back to Haskell code I left months ago than to come back to Python out JavaScript or Java code, by a fair margin.
> Ultimately, I think Haskell is the language that works best at scale.
While i agree on that, i think it depends on what one means with "at scale". I've seen that phrase used to mean something like "having a humongous team of 50+ developers and being able to add 50+ new (preferably cheap) developers (who might not be very well versed in the technology nor the business that we're working on) at any time and make them write code right out of the bat". I think Haskell would not fit very well with that "work at scale" definition :)
Comments
I'm not quite sure what you mean: monads are very well defined even within Haskell, certainly more than most programming abstractions. Essentially, a monad is any type that has some particular functions defined on it that act consistently with each other (e.g. follow the monad laws). That is all a monad is--understanding what they're useful for or why we care is a different story, but you can get that from examples.
You can have a perfectly good grasp of monads in Haskell without understanding the mathematics behind it at all: the a look at the "you could have invented monads"[1] tutorial.
[1]: http://blog.sigfpe.com/2006/08/you-could-have-invented-monad...
Moreover, the behavior of monads is more precisely proscribed than the behavior of abstractions used in other languages. While you do not need to understand the mathematical background to use monads, the fact that's it's there helps ensure that implementations act consistently. Having explicit laws implementations must follow makes it much easier to rely on them.
So monads are actually very well defined, even if too many people rush out to write ill-advised blog posts before they actually understand anything (this post is a great example, as is the linked talk by Douglas Crockford).
Ultimately, I think Haskell is the language that works best at scale. It both gives you the tools you need to write extremely maintainable code and also actively encourages you to do that. I've found Haskell code to be significantly simpler, more self-contained, more decoupled and more self-documenting than any other language I've used. I've found it far easier to come back to Haskell code I left months ago than to come back to Python out JavaScript or Java code, by a fair margin.
> Ultimately, I think Haskell is the language that works best at scale.
While i agree on that, i think it depends on what one means with "at scale". I've seen that phrase used to mean something like "having a humongous team of 50+ developers and being able to add 50+ new (preferably cheap) developers (who might not be very well versed in the technology nor the business that we're working on) at any time and make them write code right out of the bat". I think Haskell would not fit very well with that "work at scale" definition :)