<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Functional Programming on Living Systems_</title>
    <link>https://livesys.se/tags/functional-programming/</link>
    <description>Recent content in Functional Programming on Living Systems_</description>
    <generator>Hugo</generator>
    <language>en-us</language>
    <lastBuildDate>Fri, 12 Feb 2021 16:24:00 +0100</lastBuildDate>
    <atom:link href="https://livesys.se/tags/functional-programming/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>Composability in functional and flow-based programming</title>
      <link>https://livesys.se/posts/composability-in-functional-and-flow-based-programming/</link>
      <pubDate>Fri, 12 Feb 2021 16:24:00 +0100</pubDate>
      <guid>https://livesys.se/posts/composability-in-functional-and-flow-based-programming/</guid>
      <description>&lt;!-- raw HTML omitted --&gt;&#xA;&lt;p&gt;An area where I&amp;rsquo;m not so happy with some things I&amp;rsquo;ve seen in FP, is&#xA;composability.&lt;/p&gt;&#xA;&lt;p&gt;In my view, a well designed system or langauge should make functions (or&#xA;other smallest unit of computation) more easily composable, not less.&lt;/p&gt;&#xA;&lt;p&gt;What strikes me as one of the biggest elephants in the room regarding&#xA;FP, is that typical functions compose fantastically as long as you are&#xA;working with a single input argument, and a single output for each&#xA;function application, but as soon as you start taking multiple input&#xA;arguments and returned outputs though, you tend to end up with very&#xA;messy trees of function application. Even handy techniques such as&#xA;currying tend to get overly complex if you want to handle all the&#xA;possible downstream dataflow paths in a structured way.&lt;/p&gt;</description>
    </item>
    <item>
      <title>FBP inspired data flow syntax: The missing piece for the success of functional programming?</title>
      <link>https://livesys.se/posts/fbp-data-flow-syntax/</link>
      <pubDate>Thu, 16 Jul 2015 17:13:00 +0200</pubDate>
      <guid>https://livesys.se/posts/fbp-data-flow-syntax/</guid>
      <description>&lt;p&gt;&lt;p class=&#34;image&#34;&gt;&#xA;    &lt;img src=&#34;selection_288.png&#34; alt=&#34;&#34;  /&gt;&#xA;&lt;/p&gt;&#xA;&lt;/p&gt;&#xA;&lt;p&gt;Often when I suggest people have a look at &lt;a href=&#34;http://www.jpaulmorrison.com/fbp/&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Flow-based&#xA;Programming&lt;/a&gt;&#xA; (FBP) or &lt;a href=&#34;https://en.wikipedia.org/wiki/Dataflow&#34; target=&#34;_blank&#34; rel=&#34;noopener&#34;&gt;Data&#xA;Flow&lt;/a&gt;&#xA; for one reason or another,&#xA;people are often put off by the strong connection between these concepts&#xA;and graphical programming. That is, the idea that programs will be&#xA;easier to understand if expressed and developed in a visual notation.&lt;/p&gt;&#xA;&lt;p&gt;This is unfortunate, since I think this is in no way the core benefit of&#xA;FBP or Data Flow, although it is a nice side-effect for those who prefer&#xA;it. For example, I personally mostly prefer working with text over a&#xA;graphical notation, for productivity reasons.&lt;/p&gt;</description>
    </item>
  </channel>
</rss>
