{
  "$type": "site.standard.document",
  "description": "Okay, it kind of is but that's like calling an airplane a car.",
  "path": "/posts/burritos/",
  "publishedAt": "2024-12-21T14:34:47.000Z",
  "site": "at://did:plc:6n2ngs7zpcpwxz3jaoxj56tu/site.standard.publication/3mo6y7ludvn2h",
  "tags": [
    "math",
    "category-theory"
  ],
  "textContent": "Repeat after me:\n A monad is NOT a burrito.\n\nA monad is NOT a taco.\n\nA monad is NOT a wrapper.\n\nAchtung!\nThis post will talk about Category Theory.\nAs complex and confusing as Category Theory is, I don't think most of the things\nmentioned here about Category Theory are that hard to understand.\nIn any case I would like to remove some of the gate keeping in the part of\nCategory Theory that intersects with the field of Computer Science.\nAlthough some of these concepts are not entirely necessary for industry work I\ndo find understanding some of this can be a great help in tackling and thinking\nabout problems differently.\n\nIntroduction\nBefore reading I do always like specifying what exactly you're about to get\nyourself into.\nHere are the sections\n1. A functor is a burrito\n2. A monad is a functor\n3. What is a monad?\n4. Why do I care?\n5. Why should you care?\n\nAs you might have noticed these sections are also kind of a TLDR.\nAdditionally, since we will talk about Category Theory, a category is just a\ncollection of objects with morphisms between them.\nGraphically, we can draw this as arrows between dots.\nFor us, computer scientists, the \"objects\" will always be the types in our\nprogramming language of our choice, and the \"morphisms\" are just functions\nbetween those types.\nWe don't really care about other categories unless you go very deep into\nCategory Theory, which we will not do.\nAn example of this would be:\n\nIn this case, we have a function that takes an  and returns a\n.\nIn our category we will see this as an arrow being drawn from the dot that says\n to the dot that says  and that arrow's name will be .\n\nAnother example could be:\n\nIn which case our category would look like:\n\nA functor is a burrito\nDon't worry I will explain what a functor is in a moment.\nI want you to keep in the back of your mind the idea of a burrito: a tortilla\nfilled with deliciousness inside.\n\nIn Category Theory, we define a \"functor\" as a mapping between categories.\nBut remember, since we're computer scientists, we only care about the category\nof types and functions.\nThat means a functor for us would go from the category of functions and types\nback towards the category of functions and types.\nIt would look exactly like the second example in the introduction, where\n is our functor, and  is the category of types and\nfunctions.\n\nBut what does it mean to \"go from the category of types back to the category\nof types\"??\n\nLet's just assume we already have a functor that does this and let's call it\n.\nHow does  look like and what does it do?\nWell this functor , in order to actually be a functor, needs to take\nobjects, types in our case, and map them to other objects, also types in this\ncase.\nAdditionally, it needs to take a function between those types and map it to\nanother function, but we will see this later.\nLet's focus on the first part, mapping types to other types.\nWhere have we seen this before? ...\nA function that takes in a type as a parameter and outputs a type.\nThis seems very similar to:\n\nIn this case, ,  and  take in a type  and output a\nnew type, ,  and  respectively.\nThis means that a functor must be a wrapper around a type...\nA burrito if you will.\nSo every time you think about wrapping some type, remember, this is a functor.\nSome extra notation, that will be useful in a moment, is to call a type  that\ngets wrapped with our example functor  as .\n\nSecondly, our functor  has to take a function  between two types ,\n and map it to a function called  that goes between  and .\nSince we are defining a new \"mapping thingamabob\" that has to happen, this means\nwe need to define a new function.\nLet's call that function  for no particular reason!\nOur setup will now look like the following:\n- a function:  that takes a  and produces an \n- a function:  that takes an  and produces a .\n- a type: .\n\nOur setup looks like this:\n\nThe idea behind  is that it puts the input side of  inside the \nbox that has an  in it,  will transform that  into a  inside that\n box, and that is what we want  to do.\nKind of like this:\n\nFunctors are very common in category theory.\nThey might have a scary name but they are actually very simple building blocks\nused for other more complex category theory things.\nFor us computer scientists, they are just burritos!\n\nA monad is a functor\nFor this we will have to tackle two concepts:\n- endofunctor\n- monoid\n\nBoth are very simple, don't worry.\nAn endofunctor is a functor that goes from the same category to itself.\nFor us computer scientists, all our functors are endofunctors.\nIt would be impossible to create a functor that is not an endofunctor in our\nsituation.\nAdditionally, a monoid is a category that has 1 object.\n\nI would like to spend a moment to develop some intuition on monoids.\nSince a monoid is a category that has only 1 object, all of the morphisms come\nand go from the same, singular, object.\nIn our category of types and functions we can create a monoid.\nThe second example of the introduction is a monoid!\nAdditionally, I want you to think what would happen if we kept adding functions\nto that monoid.\nWe would have a single type with a huge set of functions we can compose!\nThe intuition in this case is: a monoid is a way to think about composing\nfunctions.\n\nWhat is a Monad?\n\nLet's see what Wikipedia defines a \"monad\" as:\nIn concise terms, a monad is a monoid in the category of endofunctors of some\nfixed category.\n\nNo need to take this definition apart piece by piece, it is not necessary.\nThe idea behind the monad is that we have a way to construct a special \"monoid\".\n(Remember what I said about composition and monoids.)\nThe single object in this category will be our functor , which just so\nhappens to be an endofunctor.\nWe have a special morphism in this monoid that will ensure that we can compose\ntypes produced by this functor.\nWe will call this function  or  for no particular reason!\nThis function will take some type  and a function that produces another\ntype , and will produce a type .\n\nIn this case, a monad's special ability is just to make sure you can compose\ndifferent functions with this functor.\n\nLet's do an example.\nWe need a wrapper, let's use  from Rust as our functor!\nWe then have:\n\nThis makes more sense once we start using  to compose lots of these\n's together!\n\nThis looks prettier in Haskell:\n\nWhy do I care?\nI see people say:\nbut a monad is a burrito\n\nway too much online...\nI think that there is a far greater intuition that can be achieved behind\nthinking about monads as just composition, instead of as a \"burrito\".\nAdditionally, I think it would be interesting to see people use \"functor\" as\ncommon terminology when they're just referring to a type constructor/wrapper or\nwhatever you want to call that.\n\nWhy should you care?\nidk. but I hope this was cool to read about.\nAnyways, here's a JSON parser using lots of these concepts in just 100 lines of\ncode:\n{{}}",
  "title": "A Monad Is Not A Burrito"
}