<story><title>Red and blue functions are a good thing</title><url>https://blainehansen.me/post/red-blue-functions-are-actually-good/</url></story><parent_chain><item><author>simiones</author><text>Don&amp;#x27;t monads in themselves have the same problem of introducing &amp;quot;coloring&amp;quot; (where each monad is a different color) , so that functions which work for one monad won&amp;#x27;t work with easily compose with functions which work with another monad?&lt;p&gt;For example, isn&amp;#x27;t it true that you can&amp;#x27;t easily compose a function f :: a -&amp;gt; IO b with a function g :: b -&amp;gt; [c] (assuming you don&amp;#x27;t use unsafePerformIO, of course)?&lt;p&gt;Of course, there will be ways to do it (just as you can wrap a sync function in an async function, or .Wait() on an async function result to get a sync function), and Haskell&amp;#x27;s very high level of abstraction will make that wrapping easier than in a language like C#.</text></item><item><author>willtim</author><text>And why restrict oneself to just two colours? Haskell monads also allow one to abstract over the &amp;quot;colour&amp;quot;, such that one can write polymorphic code that works for any colour, which I think was the main objection from the original red&amp;#x2F;blue post.&lt;p&gt;Microsoft&amp;#x27;s Koka is an example of a language that further empraces effect types and makes them easier to use:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;koka-lang.github.io&amp;#x2F;koka&amp;#x2F;doc&amp;#x2F;index.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;koka-lang.github.io&amp;#x2F;koka&amp;#x2F;doc&amp;#x2F;index.html&lt;/a&gt;</text></item></parent_chain><comment><author>lmm</author><text>&amp;gt; Don&amp;#x27;t monads in themselves have the same problem of introducing &amp;quot;coloring&amp;quot; (where each monad is a different color) , so that functions which work for one monad won&amp;#x27;t work with easily compose with functions which work with another monad?&lt;p&gt;I&amp;#x27;d say that monads surface a problem that was already there, and give you a vocabulary to talk about it and potentially work with it. Composing effectful functions is still surprising even if you don&amp;#x27;t keep track of those effects in your type system (for example, combining async functions with mutable variables, or either with an Amb-style backtracking&amp;#x2F;nondeterminism function, or any of those with error propagation).&lt;p&gt;But yeah, monads are an incomplete solution to the problem of effects, and when writing composable libraries you often want to abstract a bit further. In the case of Haskell-style languages we have MTL-style typeclasses, or Free coproducts, or various more experimental approaches.</text></comment>
<story><title>Red and blue functions are a good thing</title><url>https://blainehansen.me/post/red-blue-functions-are-actually-good/</url></story><parent_chain><item><author>simiones</author><text>Don&amp;#x27;t monads in themselves have the same problem of introducing &amp;quot;coloring&amp;quot; (where each monad is a different color) , so that functions which work for one monad won&amp;#x27;t work with easily compose with functions which work with another monad?&lt;p&gt;For example, isn&amp;#x27;t it true that you can&amp;#x27;t easily compose a function f :: a -&amp;gt; IO b with a function g :: b -&amp;gt; [c] (assuming you don&amp;#x27;t use unsafePerformIO, of course)?&lt;p&gt;Of course, there will be ways to do it (just as you can wrap a sync function in an async function, or .Wait() on an async function result to get a sync function), and Haskell&amp;#x27;s very high level of abstraction will make that wrapping easier than in a language like C#.</text></item><item><author>willtim</author><text>And why restrict oneself to just two colours? Haskell monads also allow one to abstract over the &amp;quot;colour&amp;quot;, such that one can write polymorphic code that works for any colour, which I think was the main objection from the original red&amp;#x2F;blue post.&lt;p&gt;Microsoft&amp;#x27;s Koka is an example of a language that further empraces effect types and makes them easier to use:
&lt;a href=&quot;https:&amp;#x2F;&amp;#x2F;koka-lang.github.io&amp;#x2F;koka&amp;#x2F;doc&amp;#x2F;index.html&quot; rel=&quot;nofollow&quot;&gt;https:&amp;#x2F;&amp;#x2F;koka-lang.github.io&amp;#x2F;koka&amp;#x2F;doc&amp;#x2F;index.html&lt;/a&gt;</text></item></parent_chain><comment><author>pas</author><text>Yes, they do. (That&amp;#x27;s why there&amp;#x27;s the monad transformer.)&lt;p&gt;But this is fundamentally a very simple thing. If you use an async framework, you have to think inside that. It&amp;#x27;s just as fundamental as CPU architecture, or operating system. If you have an Intel CPU you need a corresponding motherboard. If you have Windows you need programs that use the Win32 API (or use the necessary translation layer, like WSL).&lt;p&gt;Similarly, if you use - let&amp;#x27;s say - libuv in C, you can&amp;#x27;t just expect to call into the kernel and then merrily compose that with whatever libuv is doing.&lt;p&gt;This &amp;quot;coloring&amp;quot; is a suddenly overhyped aspect of programming (software engineering).&lt;p&gt;And of course fundamentally both are wrappable from the other, but it&amp;#x27;s good practice to don&amp;#x27;t mix sync&amp;#x2F;async libs and frameworks and components. (Or do it the right way, with separate threadpools, queues, pipes, or whatnot.)</text></comment>