<div dir="ltr">I&#39;m sure you&#39;ll get more sophisticated responses soon, but this blog post by John Carmack helped me understand the ideas and tradeoffs a bit. I&#39;m not sure everything in there is 100% correct or that I agree with everything, but I think it provides a pretty good overview.<div>

<br></div><div><a href="http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/">http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/</a><br></div><div><br></div><div style>I think Neil Toronto originally posted this to the list a while back, which is how I came across it.</div>

</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, May 22, 2013 at 10:24 AM, Lawrence Bottorff <span dir="ltr">&lt;<a href="mailto:borgauf@gmail.com" target="_blank">borgauf@gmail.com</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I posted the following question at stackoverflow and got 3 pluses and a star (favorite question) -- although only one response. I&#39;d really like to clear these issues up in my mind. Here goes:<div>

<br></div>
<div>----</div><div><br></div><div><div>I&#39;ve read some of the discussions here, as well as followed links to other explanations, but I&#39;m still not able to understand the mathematical connection between &quot;changing state&quot; and &quot;not changing state&quot; as it pertains to our functional programming versus non-FP debate. I understand the basic argument goes back to the pure math definition of a function, whereby a function maps a domain member to only one range member. This is subsequently compared to when a computer code function is given certain input, it will always produce the same output, i.e., not vary from use to use, i.e.i.e., the function&#39;s state, bzw. its domain to range mapping behavior, will not change.</div>


<div><br></div><div>Then it get foggy in my mind. Here&#39;s an example. Let&#39;s say I want to display closed, block-like polygons on an x-y field. In typical GIS software I understand everything is stored as directed, closed graphs, i.e. a square is four &quot;vectors,&quot; their heads and ends connected. The raw data representation is just the individual Cartesian start and end points of each vector. And, of course, there is a &quot;function&quot; in the GIS software that &quot;processes&quot; all these coordinate sets. Good. But what if we represent each polygon in a mathematical way, e.g., a rectangle in the positive x, negative y quadrant might be:</div>


<div><br></div><div>Z = {(x,y) | 3 &lt;= x &lt;= 5, -2 &lt;= y &lt;= -1}</div><div><br></div><div>So we might have many Z-functions, each one expressing an individual polygon -- and not being a whiz with my matrix math, maybe these &quot;functions&quot; could then be represented as matrices . . . but I digress.</div>


<div><br></div><div>So with the usual raw vector-data method, I might have one function in my code that &quot;changes state&quot; as it processes each set of coordinates and then draws each polygon (and then deals with polygons changing), while the one-and-only-one-Z-function-per-polygon method would seem to hold to the &quot;don&#39;t change state&quot; rule exactly -- or at least not change memory state all that much. Right? Or am I way off here? It seems like the old-fashioned, one-function-processing-raw-coordinate-data is not mutating the domain-range purity law really. I&#39;m confused.... But the many individual polygon Z-functions method would seem to hold a perfect picture of state in memory -- no? Then I was reminded of my days (1980s) in Cartography when an object-oriented GIS package (written in Smalltalk) was being discussed. Everyone dismissed it as ludicrous because it tried to have exactly that: all the cartographic objects (roads, areal, symbols, polygons, etc.) in live memory at once. But isn&#39;t this ultimately what FP wants?</div>


<div><br></div><div>Another avenue of my inspiration came from reading about a new idea of image processing where instead of slamming racks of pixels, each &quot;frame&quot; would be represented by one big function capable of quasi &quot;gnu-plotting&quot; the whole image: edges, colors, gradients, etc. Now I ask, Is this germane? I guess I&#39;m trying to fathom why I would want to represent, say, a street map of polygons (e.g. city blocks) one way or the other. I keep hearing functional language advocates dance around the idea that a mathematical function is pure and safe and good and ultimately Utopian, while the non-FP software function is some sort of sloppy kludge holding us back from Borg-like bliss.</div>


<div><br></div><div>But again, more confusing is memory management vis-a-vis FP versus non-FP. What I keep hearing (e.g. parallel programming) is that FP isn&#39;t changing a &quot;memory state&quot; as much as, say, a C/C++ program does. Is this like the Google File System (or my Smalltalk GIS example) where literally everything is just sitting out there in a virtual memory pool, rather than being data moved in and out of databases, bzw. memory locations? Somehow I sense all these things are related. Therefore, it seems like the perfect FP program is just one single function (possibly made up of many sub-functions like nesting Russian dolls) doing all tasks -- although a quick glance at any elisp code seems to be a study of programming schizophrenia on this count.</div>


</div><div><br></div><div>----</div><div><br></div><div>It would be nice to hear some of your thoughts on this.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>LB</div></font></span></div>
<br>____________________<br>
  Racket Users list:<br>
  <a href="http://lists.racket-lang.org/users" target="_blank">http://lists.racket-lang.org/users</a><br>
<br></blockquote></div><br></div>