This is great. Finally understand monads a little better. Definitely saving this for later.
Btw, that "chain" function is available natively in Javascript, as "flatMap". Monads aren't as mysterious as we make them look.
Functional programming jargon in plain English
21–30 of 191 posts
Re: Functional programming jargon in plain English
#22All these niche functional programming languages are an exercise in pseudo intellectualism Give me an object oriented language any day. The world is made of state and processes, (modern niche) functional programming goes too far to derecognise the value of state in our mental models The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain plac…
I guess you could also say that the world is made of state, state transitions and state derivations, and functional programming does a great job of making the latter two reliable.
Re: Functional programming jargon in plain English
#23These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…
Yes, but you're relying on the undefined concept of context. How do you define context?
"The idea" practically, is whatever resolves the polymorphism. So context is a compiler function from syntax->semantics.
Eg., `+` is polymorphic, `1 + 1` and `"1" + "1"`... the context is whatever implicitly resolves `+` to `ADD` or to `CONCAT`.
The utility of these ideas is, in practice, just they provide a syntax for different kinds of polymorphism. Eg., for monads, we're basically just telling the compiler to change its implementation of `;`
Re: Functional programming jargon in plain English
#24Earlier quoted context omitted.
Not as an "escape hatch" (that would be something more like `unsafePerformIO :: IO a -> a`), but as a principled way to compose (among other things) IO actions. A Haskell program executes the IO action at `Main.main`, which must have type `IO ()`. `putStrLn :: String -> IO ()` is a pure function - if you give it the same input, it always the same IO action as a result.
Monads are (for better or worse) contagious. So when one function calls a monad, then it needs to be included in the monad as well. It makes introducing memoisation to a file, randomisation, and memoisation not-to-a-file (without using lazy evaluation to express it) difficult. I don't know whether the alternatives (effect systems for instance) help with this. I personally don't use functional languages because I find…
Monads themselves aren't really contagious, it's the actions that would otherwise have side-effects that are, and also the fact they have to be executed in sequence.
This is also true for other things in other paradigms, such as async functions in javascript.
This is a good thing, however. In imperative programming, you have invisible temporal coupling. In pure-FP you have the same coupling, but it's exposed.
Re: Functional programming jargon in plain English
#25These definitions don't really give you the idea, rather often just code examples.. "The ideas", in my view: Monoid = units that can be joined together Functor = context for running a single-input function Applicative = context for multi-input functions Monad = context for sequence-dependent operations Lifting = converting from one context to another Sum type = something is either A or B or C.. Product type = a recor…
> Functor = context for running a single-input function No a functor is a "function" over types that can transport the arrows: (A -> B) -> (F A -> F B) for a covariant functor (A -> B) -> (F B -> F A) for a contravariant functor With the sum and product there is also the exponential: B^A = functions from A to B
In my simple language, `F` is that context. And (A->B) is a single-argument function.
// Int -> Float
oneArgFn(x) = x + 1.1
// List of Int -> List of Float
ctxOneArgFn(xs) = ListFunctor(oneArgFn, xs) //ie., map()Re: Functional programming jargon in plain English
#26This is great. Finally understand monads a little better. Definitely saving this for later.
Why do monads come up so often when people talk about FP? Is it a meme or are they really an important and difficult to understand concept?
There is a myth that "monads" are magical insights of some sort -- it's not.
Difficult to understand: likely yes because the myth is not groundless. What "monads" capture is how to combine things with a lot of ceremony: (0) the things that we want to combine are sharing some structure/properies (1) we can inspect the first thing before deciding what the second thing is (2) we can inspect both before deciding what is the resulting combination. What requires a lot of thought is appreciating why "inspect, decide, combine" are unified in a single concept.
Important: indeed, because in Haskell-like languages monads are pervasive and even have syntactic primitives. It's also extremely useful when manipulating concepts or approaching libraries that implement some monadic behaviour (e.g. promises in JS) because the "mental model" is rigorous. If you tell someone a library is a monadic-DSL to express business rules in a specific domain, you're giving them a headstart.
Some final lament: there's a fraction of people who found that disparaging (or over-hyping) the concept was a sure-fire way to yield social gain. Thus, when learning the concept of monads, one situational difficulty that we should not understate is that one has to overcome the peer-pressure from their circle of colleagues/friends. Forging one's understanding and opinions takes more detachment than the typical tech job provides.
Re: Functional programming jargon in plain English
#27All these niche functional programming languages are an exercise in pseudo intellectualism Give me an object oriented language any day. The world is made of state and processes, (modern niche) functional programming goes too far to derecognise the value of state in our mental models The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain plac…
> The world is made of [...]
Either define concretely what the world is made of (i.e. particles and what they do), or don't use this sentence. Currently you just say "wow this is so abstract, it's actually ". Turns out neither paradigm has anything to do with real life, they have their own niches and their own place within different contexts.
Re: Functional programming jargon in plain English
#28All these niche functional programming languages are an exercise in pseudo intellectualism Give me an object oriented language any day. The world is made of state and processes, (modern niche) functional programming goes too far to derecognise the value of state in our mental models The good thing about functional programming is stressing to avoid side effects in most of the code and keep it localised in certain plac…
Doesn't every mainstream language these days allow you to pick what style you want according to the situation?
Re: Functional programming jargon in plain English
#29No post body was provided.
Re: Functional programming jargon in plain English
#30It would be cool if this also told you why you might want to do the thing it’s describing.