Your banana example made me think of this quotation: ❝Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad.❞ -Miles Kington Excellent talk.
Very nice! I think just by intuition here, that one does not imply the other. Practically, someone could be wise about something without fully understanding and vise versa.
I backed out of this conference last minute while 2 other co-workers went, if I had known MPJ was speaking I would not have cancelled my trip. God damnit!
Funny enough, I have this policy that I should be able to drop my computer in a lake and continue working right away after walking into the nearest store and buying a new Macbook. If I had done that, I could have lent someones laptop and logged right into slides.com and continued. :)
As I was following this talk, I kept thinking of the things that are doing the work as "functors." Those things -- map and mapTree -- are doing all the work. They are joining the dumb functions like capitalize, and the dumb data structures, into data structures with applied functions. Seems like they need a name. Higher order functions?
Love you MPJ! Just a slight correction -- Promises and Monads differ in important ways. I've been noodling on Monads in JS for a bit and found a Promise-alternative called "Fluture": github.com/fluture-js/Fluture/wiki/Comparison-to-Promises#practical-differences Fluture provides a "Future" monadic structure which can (should?) be used instead of Promise. Practical differences: 1) Promises conflate `map` and `flatMap` into `then` whereas they should be distinct. In a true monadic structure (like a `Future`), `flatMap` would allow "chaining" into a different monadic structure (such as an `Either` aka `Result` or a `Maybe` aka `Option`). `Promise.resolve('hello').then(...)` always returns the same Promise container. 2) Promises are eagerly evaluated and are not cancellable. Futures are lazy and must be invoked by a caller which is responsible for handling success / failure. 3) Promises violate functor laws of composition. Now, I know that sounds a bit "foo foo" but it's important. Those laws are the "magic" which ensures algebraic data structures behave predictably for downstream users.
If something as wacky as a Promise is legitimately a Functor and Monad (even though it doesn't have explicit .map or .flatMap interfaces), then Array and Tree are as well, no? In that you can add .flatMap to Array if you want, and also to Tree, if you want. That JS doesn't do this out of the box doesn't restrict what these types are capable of in theory (and in prototype modifying practice!).
Right: what the methods are called doesn't restrict what they are, though it does limit their interoperability with other types if everything calls .map something different. .then for Promises is not a lawful Monad interface, since it inspects the result and behaves differently depending on whether it's a .thenable or not.
well.. the Javascript Promises has a botched implementation.. lol.. if it was implemented like Task/Futures then you would have a monad that directly follows the laws. github.com/fluture-js/Fluture/wiki/Comparison-to-Promises
There are no functors or monads in JS because the language is dynamically typed and hence you can not restrict what types a mapper function f :: X -> Y, i.e: it could return varying types. In addition, even if f :: X -> Y, the function f must be pure, otherwise there's the possibility of the functor law: F(g o f) = F(g) o F(f) being violated. For example, if f is a function that prints to the console, and g does as well, then the order of side effects will not be preserved.
In a strict sense that is true, but it doesn't mean you cannot make a monadic acting function, you just wouldn't have the guarantees by the type system to know if anything in the program is acting as intended.
Mazdak Farrokhzad I know this isa very old comment, but when implementing monad in js you could check 'value instanceof Monad' (assuming the implemented 'types' using classes you used are extended from a base Monad class) . Major problems I see with this is performance when you don't need the result, i.e. >>. and with asynchronous functions. However, this run time type checking is not ideal and I think it's better to just discipline yourself to follow the monoidal rules. You won't have strong static types but you'll still be able to use the design patterns offered by monads
Did you bother clicking on the "Berry" link? en.wikipedia.org/wiki/Berry_(botany) "In botanical terminology, a berry is a fleshy fruit without a stone produced from a single flower containing one ovary" Congratulations, you learned something today!
Your banana example made me think of this quotation: ❝Knowledge is knowing that a tomato is a fruit. Wisdom is not putting it in a fruit salad.❞ -Miles Kington
Excellent talk.
Very nice! I think just by intuition here, that one does not imply the other. Practically, someone could be wise about something without fully understanding and vise versa.
OMG it's MPJ from fun fun function before he was UA-cam famous!!
I backed out of this conference last minute while 2 other co-workers went, if I had known MPJ was speaking I would not have cancelled my trip. God damnit!
A great talk, thx!
Whew, at 9:17 you _almost_ spilled that water on top of your MacBook. 💦
But despite fearing for your laptop, I really enjoyed the talk. 👍
Funny enough, I have this policy that I should be able to drop my computer in a lake and continue working right away after walking into the nearest store and buying a new Macbook. If I had done that, I could have lent someones laptop and logged right into slides.com and continued. :)
Haha. Excellent policy! Thank you for the inspiration.
funfunfunction you're my new hero
AHAHA .. for a second he thought he was on his channel.. look at 25:01 he smiled and was about to laugh controlled it somehow..
As I was following this talk, I kept thinking of the things that are doing the work as "functors." Those things --
map and mapTree -- are doing all the work. They are joining the dumb functions like capitalize, and the dumb data structures, into data structures with applied functions. Seems like they need a name. Higher order functions?
Love you MPJ! Just a slight correction -- Promises and Monads differ in important ways. I've been noodling on Monads in JS for a bit and found a Promise-alternative called "Fluture": github.com/fluture-js/Fluture/wiki/Comparison-to-Promises#practical-differences
Fluture provides a "Future" monadic structure which can (should?) be used instead of Promise.
Practical differences:
1) Promises conflate `map` and `flatMap` into `then` whereas they should be distinct. In a true monadic structure (like a `Future`), `flatMap` would allow "chaining" into a different monadic structure (such as an `Either` aka `Result` or a `Maybe` aka `Option`). `Promise.resolve('hello').then(...)` always returns the same Promise container.
2) Promises are eagerly evaluated and are not cancellable. Futures are lazy and must be invoked by a caller which is responsible for handling success / failure.
3) Promises violate functor laws of composition. Now, I know that sounds a bit "foo foo" but it's important. Those laws are the "magic" which ensures algebraic data structures behave predictably for downstream users.
Thanks for demystifying then!
Why are Bacon, RX or Highland "hispter libraries"??
everything is a hipster library
If something as wacky as a Promise is legitimately a Functor and Monad (even though it doesn't have explicit .map or .flatMap interfaces), then Array and Tree are as well, no? In that you can add .flatMap to Array if you want, and also to Tree, if you want. That JS doesn't do this out of the box doesn't restrict what these types are capable of in theory (and in prototype modifying practice!).
Bluebird promises do have map and flatMap.
Drew Tipson they dont have to be called map or flatMap. They can be called then
Right: what the methods are called doesn't restrict what they are, though it does limit their interoperability with other types if everything calls .map something different.
.then for Promises is not a lawful Monad interface, since it inspects the result and behaves differently depending on whether it's a .thenable or not.
Yes, Array would be monads in they implemented flatMap-
well.. the Javascript Promises has a botched implementation.. lol.. if it was implemented like Task/Futures then you would have a monad that directly follows the laws.
github.com/fluture-js/Fluture/wiki/Comparison-to-Promises
Streams:
ua-cam.com/video/2jp8N6Ha7tY/v-deo.htmlm3s
There are no functors or monads in JS because the language is dynamically typed and hence you can not restrict what types a mapper function f :: X -> Y, i.e: it could return varying types. In addition, even if f :: X -> Y, the function f must be pure, otherwise there's the possibility of the functor law: F(g o f) = F(g) o F(f) being violated. For example, if f is a function that prints to the console, and g does as well, then the order of side effects will not be preserved.
In a strict sense that is true, but it doesn't mean you cannot make a monadic acting function, you just wouldn't have the guarantees by the type system to know if anything in the program is acting as intended.
Mazdak Farrokhzad I know this isa very old comment, but when implementing monad in js you could check 'value instanceof Monad' (assuming the implemented 'types' using classes you used are extended from a base Monad class) . Major problems I see with this is performance when you don't need the result, i.e. >>. and with asynchronous functions. However, this run time type checking is not ideal and I think it's better to just discipline yourself to follow the monoidal rules. You won't have strong static types but you'll still be able to use the design patterns offered by monads
when you call mapTree - reverse the arguments or it won't work
Is flatMap the same as reduce?
no, reduce is similar to fold
But Bananas are, botanically speaking, a fruit.
Nope - en.wikipedia.org/wiki/Banana
Did you bother clicking on the "Berry" link? en.wikipedia.org/wiki/Berry_(botany)
"In botanical terminology, a berry is a fleshy fruit without a stone produced from a single flower containing one ovary"
Congratulations, you learned something today!
Great scientific research
totally ruined it, congrats!
interesting topic but had to stop watching because the attempts at humour were too jarring