<div dir="ltr">I'm sure you'll get more sophisticated responses soon, but this blog post by John Carmack helped me understand the ideas and tradeoffs a bit. I'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"><<a href="mailto:borgauf@gmail.com" target="_blank">borgauf@gmail.com</a>></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'd really like to clear these issues up in my mind. Here goes:<div> <br></div> <div>----</div><div><br></div><div><div>I've read some of the discussions here, as well as followed links to other explanations, but I'm still not able to understand the mathematical connection between "changing state" and "not changing state" 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'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's an example. Let'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 "vectors," 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 "function" in the GIS software that "processes" 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 <= x <= 5, -2 <= y <= -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 "functions" 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 "changes state" 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 "don't change state" 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'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'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 "frame" would be represented by one big function capable of quasi "gnu-plotting" the whole image: edges, colors, gradients, etc. Now I ask, Is this germane? I guess I'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't changing a "memory state" 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>