The goofy names are obfuscating factors for me. I should not need a graduate degree in math to understand programming concepts.
Yeah, that's a common complaint. It's somewhat a historical artifact: these ideas came into programming via category theory enthusiasts, who said "We should be able to use these great concepts in our programs!", and used the terms they were used to. We've sometimes discussed changing the names to something more intuitive, but by now the jargon has largely permeated the community, so we've gotten used to it.
(It's actually worse in some places, though. There are two competing category-theory libraries in Scala -- one of them not only uses the math terms, it favors the math *symbols*, so some programs look like something out of a textbook, which is great if you really grok the math and terrible if you don't. The other library has deliberately avoided getting as symbol-heavy, on the grounds that it's an unnecessary barrier to entry, and in general I think the Scala community has gotten more leery about Extreme Unicode in programs.)
as I was reading I was thinking "yeah, so, this is just map()... what's the big deal?". Does that mean I missed something
Nope, Functor really is that simple. It's just that the *abstraction* of map() turns out to be surprisingly useful -- there are many higher-order functions that you can then write for *any* Functor, so it's very useful to have the common concept.
Similarly, Monads are (as is alluded to in the original video) largely a fancy term for "types that have flatMap()", which is what is actually going on under the hood in those for comprehensions above. flatMap() is similar to map(), but means "map() over all the elements *and* flatten the resulting nested data structure". That notion of "flattening" makes sense in some data types, but not in others -- if it does make sense, you probably have a Monad.
And again, there are tons of things you can then do with *any* Monad, which turns out to be *hugely* useful. For example, there's a common pattern in modern Scala called "Tagless Final" (again, sorry for the jargon), which is where you write code that can run with any Monad -- the type of Monad gets set by the code calling it. So at runtime you can use something complex and asynchronous like Future (more or less -- Future is actually a little badly-behaved, but that's a different topic), but for unit testing you instead use a synchronous Monad that is easier to work with.
Though I grant that Future is a neat and novel concept that would make lots of ugly async code become more comprehensible.
Yeah -- it's one of the many reasons why writing browser code is actually easier in Scala.js than in native JavaScript. Composing complex AJAX operations is *vastly* easier with Futures than with callbacks. (Enough so that JS has now picked up a similar concept, which they call Promises.)
I think of LISP as a functional language (I realize it can be used in other ways)
No, that's entirely fair -- LISP was the first reasonably popular functional language (maybe the first functional language, period), long predating most of the rest. It's less fancy than something like Haskell, but the central concepts are there.
I don't think I'd ever heard the word "monad" until sometime in the last few years.
Yeah, I didn't really encounter it myself until I started getting serious about Scala in 2012, and I don't think I really *understood* it until about 2015 or so. The concept and term have existed for decades in the math world, and it's been around in the hardcore FP community (that is, Haskell) for a while, but it's only really started to permeate the wider programming community recently.
Although, that said, it shows up in unexpected ways. C#'s LINQ system, although syntactically based on SQL, is roughly a general framework for creating and using Monads, with a very different look-and-feel. This general notion is useful enough that folks are finding ways to leverage it...
no subject
Yeah, that's a common complaint. It's somewhat a historical artifact: these ideas came into programming via category theory enthusiasts, who said "We should be able to use these great concepts in our programs!", and used the terms they were used to. We've sometimes discussed changing the names to something more intuitive, but by now the jargon has largely permeated the community, so we've gotten used to it.
(It's actually worse in some places, though. There are two competing category-theory libraries in Scala -- one of them not only uses the math terms, it favors the math *symbols*, so some programs look like something out of a textbook, which is great if you really grok the math and terrible if you don't. The other library has deliberately avoided getting as symbol-heavy, on the grounds that it's an unnecessary barrier to entry, and in general I think the Scala community has gotten more leery about Extreme Unicode in programs.)
Nope, Functor really is that simple. It's just that the *abstraction* of map() turns out to be surprisingly useful -- there are many higher-order functions that you can then write for *any* Functor, so it's very useful to have the common concept.
Similarly, Monads are (as is alluded to in the original video) largely a fancy term for "types that have flatMap()", which is what is actually going on under the hood in those for comprehensions above. flatMap() is similar to map(), but means "map() over all the elements *and* flatten the resulting nested data structure". That notion of "flattening" makes sense in some data types, but not in others -- if it does make sense, you probably have a Monad.
And again, there are tons of things you can then do with *any* Monad, which turns out to be *hugely* useful. For example, there's a common pattern in modern Scala called "Tagless Final" (again, sorry for the jargon), which is where you write code that can run with any Monad -- the type of Monad gets set by the code calling it. So at runtime you can use something complex and asynchronous like Future (more or less -- Future is actually a little badly-behaved, but that's a different topic), but for unit testing you instead use a synchronous Monad that is easier to work with.
Yeah -- it's one of the many reasons why writing browser code is actually easier in Scala.js than in native JavaScript. Composing complex AJAX operations is *vastly* easier with Futures than with callbacks. (Enough so that JS has now picked up a similar concept, which they call Promises.)
No, that's entirely fair -- LISP was the first reasonably popular functional language (maybe the first functional language, period), long predating most of the rest. It's less fancy than something like Haskell, but the central concepts are there.
Yeah, I didn't really encounter it myself until I started getting serious about Scala in 2012, and I don't think I really *understood* it until about 2015 or so. The concept and term have existed for decades in the math world, and it's been around in the hardcore FP community (that is, Haskell) for a while, but it's only really started to permeate the wider programming community recently.
Although, that said, it shows up in unexpected ways. C#'s LINQ system, although syntactically based on SQL, is roughly a general framework for creating and using Monads, with a very different look-and-feel. This general notion is useful enough that folks are finding ways to leverage it...