Nice! Yeah. I had two avenues of understanding available to me when it came to monads. The first was my knowledge as a mathematically-inclined software engineer. The second was my knowledge as someone fluent in high-level mathematics.
I'll say, here was one key to my understanding once I saw it. In a purely functional language you want everything to be referentially transparent. That is, an expression should be able to be substituted for its value at any given moment in time. At the very least, you'll want the ability to denote which parts of your program are referentially transparent and which aren't.
This can be expressed as utopian vision: in a purely functional language we'd like everything -- everything -- to be a value.
We now need some way of translating code with side effects into code that returns a value. The logical abstraction is to say that the "value" is not the work itself -- once the work is done it's out of the bag, after all -- but rather the "value" is the machine which can perform that work.
To a mathematician this screams "functor." If you want to move between the two spaces repeatedly this screams "adjoint functors." There's some work you want to do in Space A that's more easily expressed in Space B, so you take a thing in A, transform it to a thing in B, do the work in B, and then transform back to A.
Think in, e.g., Ruby:
sentence.split(' ').map(&:reverse).join(' ')
split(' ') and join(' ') aren't quite inverses of each other, but they are adjoint. These pairs take us from the land of space-separated strings to the land of arrays back to the land of space separated strings.
You see that all the time in programming and mathematics. I sometimes call it the "Super Mario Brothers" maneuver when I'm trying to teach it to students. Mario wants to get to the end of the level, so he hits a block, goes up the vine to cloud land, runs through cloud land, and then comes back down.
Ka-bam! This sort of intuition is exactly what actually drove home monads to me after I spent far too long "knowing" them in a "I can code with these" kind of sense. Category theory might be "impractical" for coding, but the intuitions it helps you develop are wonderful.
He's playing fast and loose with the formalisms to try to convey the intuition to people without a strong algebraic background. Ruby isn't very well behaved from a categorical perspective (heck, even Haskell doesn't get all of the way there if you want to be really formal) so it's not perfect, but I think the reasoning is morally correct and insightful.
I wouldn't say they're the tightest functors ever, but you could see them as endofunctors between the subcategories String and [String]. Some small amount of intuition would translate, although by and large this setting isn't polymorphic enough to have good behavior. After all, there are a lot of functions on strings that would not have a functorial relationship over split(' ').
Yes, this is more correct, and I was also imagining the category being something like "space-delimited strings." I realize that'd require redefining things like string concatenation to be "space-delimited concatenation" and other such bits.
Anyhow, I was playing loose and I know it. If I were writing in a more serious context I'd cross all the t's and dot all the i's. To me the more important thing was this slow gnawing in my gut, seeing hints of natural transformations and adjoint functors here and there and thinking, "Oh come on, there has to be a way to connect these dots."
Non-functional languages like Ruby don't think in this way, so there are hole all over the language.
Maybe you mean functors instead of endofunctors (an endofunctor goes from a category to itself)? But that's a minor quibble, the main problem is I don't understand which categories you mean? What are the objects and morphisms? My best guess (and I have to guess because you didn't say) is that you mean to treat String and [String] as monoids and thus as one object categories. That is String is the category with a single object, the morphisms from that object to itself are all the possible strings and composition is concatenation; and similarly for [String] with list concatenation. If that's what you meant several things are wrong:
1. split(" ") is not a functor because (x+y).split(" ") is not equal to x.split(" ") + y.split(" "), for example:
"a BC".split(" ") == ["a", "BC"], but
"a B".split(" ") == ["a B"] and "C".split(" ") == ["C"].
(At least join(" ") is a functor, which here just means monoid homomorphism.) I guess this problem could be fixed by replacing String with StringsThatAreEitherEmptyOrEndInSpace (you need the empty string to be the identity for composition).
2. They are not adjoint, even after fixing the monoids to make them homomorphisms! It's easy to easy that if f and g are adjoint monoid homomorphisms, with unit η and counit ε, then the functions m ⟼ ε f(m) and n ⟼ g(n) η are inverses of each other. This does not happen here since, for example, join(' ') is not injective.
Can you fix the example, maybe by regarding them as categories in some other way? My gut feeling is that this won't work, but I haven't thought about it very much.
If, as I suspect, this adjointness is wrong and not easily fixable, does it still have value as an explanation? I think that's a personality question, I find it more confusing than enlightening, but can imagine some people would find it helpful.
I'm not trying to defend the example in detail—I agree that they don't have an obvious, rigorous categorical connection. I broadly think that with so little polymorphism you're not going to get a terrific categorical reading. I agree with the op that they still "feel" adjoint and may have a better reading there with a little generalization.
But yeah, it's not the greatest example. I don't mean to defend it as something rigorous.
Oh, and also, the moment this became clear to me was when I read the original monad paper. How frustrating -- all this ink spilled on explaining monads and I just needed to read the original paper to see the real motivation.
I'll say, here was one key to my understanding once I saw it. In a purely functional language you want everything to be referentially transparent. That is, an expression should be able to be substituted for its value at any given moment in time. At the very least, you'll want the ability to denote which parts of your program are referentially transparent and which aren't.
This can be expressed as utopian vision: in a purely functional language we'd like everything -- everything -- to be a value.
We now need some way of translating code with side effects into code that returns a value. The logical abstraction is to say that the "value" is not the work itself -- once the work is done it's out of the bag, after all -- but rather the "value" is the machine which can perform that work.
To a mathematician this screams "functor." If you want to move between the two spaces repeatedly this screams "adjoint functors." There's some work you want to do in Space A that's more easily expressed in Space B, so you take a thing in A, transform it to a thing in B, do the work in B, and then transform back to A.
Think in, e.g., Ruby:
split(' ') and join(' ') aren't quite inverses of each other, but they are adjoint. These pairs take us from the land of space-separated strings to the land of arrays back to the land of space separated strings.You see that all the time in programming and mathematics. I sometimes call it the "Super Mario Brothers" maneuver when I'm trying to teach it to students. Mario wants to get to the end of the level, so he hits a block, goes up the vine to cloud land, runs through cloud land, and then comes back down.