Generally speaking the programmers' approach to all of these concepts seems very weird to me compared to the logician/category-theorist take, but McBride and Paterson's "Applicative programming with effects" is a really awesome paper that synthesizes the two points of view pretty well for the case of applicative functors. The punchline is that what a Haskell hacker calls applicative functors are what a category theorist calls strong lax monoidal functors. Yes, both strong and lax! Terribly, from a terminological point of view, "lax" means that the functor is weaker than "weak", and "strong" isn't the opposite of "weak" (if anything, "strict" is --- but since "lax" exists as a concept, it's hard to say that "strict" is the opposite of "weak", just that it's, ahem, a stronger condition than "weak") and means that the functor has a "strength".
Ok, everybody sufficiently confused now? Good.
The important thing about these
But wait, I hear you saying, weren't we told that monads were the ultimate story on a pure functional treatment of effects and sequencing and stuff? Answer: they're one story, yes. The intuitive distinction between monads and applicatives (which the paper above explains rather nicely) is that monads, unlike applicatives, let you use the result of one computation to influence which other computation takes place as the second step. Just look at the Kleisli star's type, it's right there:
TA → (A → TB) → TB
The second argument gets the value of type A before it spits out the final computation. If T were just an applicative functor, the most we could make out of TA and (A → TB) would be TTB. When T is a monad, we have exactly the categorical μ to turn that into TB (this is of course exactly how the Kleisli star is implemented from the categorical data T, η, μ) but when T is merely applicative, TTB is considered a more complicated thingy than TB --- it has two stages of computational dependency, which we're not allowed to erase.