No Nonsense Monad & Functor - The foundation of Functional Programming by César Tron-Lozai 

flatmap

@@joachimdietl6737 thanks

And, Type is a set of values

😅🙃

slideshare

Yes it's definitely not meant to be a haskell talk nor be %100 correct. I think what you describe is a great follow up to this talk. My observation is that showing this kind of detail too early scare people off learning about functional programming. So I tried to remove as much technical/mathematical detail from the talk.

@@Phoenix736 wow! hi! great talk, btw! that makes sense about too much detail; it's a big problem in any kind of learning process. how do you feel about fronting function _application,_ (i.e., ($) ≈ () ≈ (=). in other words, I was down in the business logic of my program trying to do a series of transformations on some data that would have already produced by that point in the program. this *seems* fundamentally similar to the example you gave with ... .someMethod(...).someOtherMethod(...) I have no idea how an audience-esp. the kind of audience you're giving this talk to-would get that, though.

That's the natural direction functions are written in when they're nested. If you saw "f(g(h(x)))", you would immediately know that it means to first apply h, then g, then f. So, "f >=> g >=> h" preserves that structure.

@@calunsagrenejr I know where it comes from, but I claim that prefix notation of functions works well only when not nesting function, so making a new notation based on the most unintuitive use of math notation is not gonna be intuitive. Postfix notation is clear and intuitive though: you have some things, and then you change them some way. f(g(h(x))) vs (((x)h)g)f In programming the first gives birth to functional notation: f (g (h x) ). Thr second results in a much nicer concatenative notation: x h g f

@@aleksandersabak In response to you saying "making a new notation...", it isn't new. What is described in the video is called a "Kleisli category", which is decades old - around the 1960s. The fish notation itself seems to be younger though - at most the 2010s, but I don't know the paper/document it was first introduced in. As for programming, I think you can't say in absolute terms that postfix is better than prefix, or vice versa. That's like saying decimal is better than binary - they're equivalent systems that can achieve the same things, and switching from one to the other won't break any mathematical laws (though there would be quite an adjustment period for humans). To me at least, calling a function with the argument first is highly jarring. I'd rather see "f(x)" than "x f". The popular programming languages of today favor the former. Also, this may be inconsequential, but in your example, if you wanted to compose "h g f" after "g", you would need some extra notation to check that "g h g f" is a function definition, while "x h g f" is a function application. Function composition is the point of all of this, so I think that should be a key consideration to the notation too. Finally, there is a "left fish" operator in Haskell (), so it sounds like you might favor that one because of its directionality.

@@calunsagrenejr what you're saying is absolutely right and I'm just heavily biased towards postfix. I didn't make it very clear what parts of my comments are opinions. Also, it's not inconsequential that if I wanted to compose "h g f" after "g" in languages that make heavy use of postfix notation (by which I meam concatenative languages) I would just write "g h g f" and it would make as much sense as "x h g f" because in those languages values are functions that take state and produce state with a value appended to it, so they can be composed as normal. Every function isdefined as a function composition that is then applied to the initial state producing an output state. State is usually represented as a stack, so for example "1" in Forth or Factor is a function that puts an integer 1 on the stack.

@@aleksandersabak I see, thanks for clarifying. For myself, to clarify what I meant by "inconsequential", it was just that it may be trivial to this conversation, rather than trivial in general. I think we would very quickly agree that differentiating between "g h g f" and "x h g f" would be easy on a technical level - I would just prefer to have explicit syntax that differentiates function definition from function application, but this is just an opinion of mine. I raised it just because I felt postfix would be inconvenient for me to read if that differentiation wasn't explicit in the syntax.

If File content changed you have Side effects

@@jakobgross8184 - Or it's a new input - different perspective. But, I agree. It's all just a viewpoint in a way, but I think all input should be passed in. That's the only easy way to track it anyways.

Yes, it's a side effect.

@@noahwilliams8996 - yeah, I guess in that all IO is a side effect ...

I assume your question was asking what would happen if flatmap were applied: Example 1 Expands to Optional which if flatmap is called with an id function (a -> a) the result will be Optional i.e. Optional("OK")l the outer wrapper Optional was removed. id function is a function that does nothing; it returns the same input value it was given unchanged. Example 2 Also expands to Optional. the ? being whatever type you provided to Java i.e. it would be same as Optional.empty() Example 3 Is more complex because Either is a type with two generic types; one type for left and one type for right; assuming the inner types are both string, then the extended type would expand to Either -- to apply the default flatmap would not be possible, because the default flatmap is built as a mapping over the right type only... you would need flatmapL; a flatmap for mapping over the left type; which if used with an id function (a -> a) would return Either .right("OK") . Example 4 Expands to type Either> -- again the ? indicate that the compiler would not be able to infer the types; however if flatmap is called with an id function (a -> a) the result will be Either -- the default flatmap will be called which is the same as flatmapR (as flatmap for the right type)

Turing Complete just means it can do everything that a turing machine could do. a simple test is to implement a turing machine in it. Lambda Calculus was made even before turing machine was made and is turing complete. and yup, most reputable purely FP languages are turing complete cuz otherwise, like you said, why bother. as for why we need monad? we dont. its a pattern that makes our lives easier. dont like it? dont use it.

@@keokawasaki7833 it's not about my personal feelings. I like monads as idea, as a game of mind. But I need to make decision for the team. What I really want to find out: will use of monads speed up development process or it will slow it down? Time is money. And I've seen a lot of bad code with monads in my current projects. So, should we train people to use monads the proper way or is it just the nature of monads? So I started search for this "proper way", but right now I doubt that this proper way even exist. Thanks for your comment I can now refer to lambda calculus as "prehistorical technology" :)

@@firstnamelastname2298 your search seems futile to me cuz most discussions of monads tend to care more about the "beauty of it" instead of project management. But the best advice I can think of is to treat monad as a design pattern. And we already know how to deal with those. Train people about the pattern; overusage turns patterns into anti pattern; tell the team to be consistent. I personally have never used monads in team project so I am more than interested to see the bad usage of monads that you talk of

@@keokawasaki7833 in short: devs tend to use monads (especially optionals) to silently drop unexpected result. They do the same with exceptions, but it's much easier to search for "catch {}". We have a lot of legacy code and mix of every possible methodology. Theoretically, it would be nice to have a function completely covered with unit tests and monads can help with that. Unfortunately, I need them not to help, but to force. Something like that happen quite often: Optional a = getA(): Optional b = getB(); return a?.Value + b?.Value; At the end of the day we can have something like "function works but only if some piece of hardware is broken, and something fall to default value". I understand that monads should not be used like that and they designed to avoid fall to default value, but people use them for the exact opposite.

Because of a lot of people find Haskell scary and there are 999 talks on how to do Monad with Haskell. The goal of this talk was to explain monad to those who thinks it is not for them

You should maybe watch the rest of the talk :D

@@jmfcad Nah he said it's perfect right there. Just because he then goes into promise-chaining hell at the end and calls that more perfect has nothing to do with this.

Yeah so this is call sarcasm 😅 I have seen this sort of code in a lot of code years, many years after Optional was released. Which is why I'm making fun of this

Yes this is a toy example used for educational purposes. Of course this is over engineered but the goal is to explain a concept, not write performant code

The presenter of course was joking here. Of course these nested if-statements aren't beautiful, they are ugly, that's why he simplifies it even further using monads.

ikr, i was totally thrown off by java. i haven't watched the video yet, the beginning is making me question lol

Indeed