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.
http://www.altdevblogaday.com/2012/04/26/functional-programming-in-c/ I think Neil Toronto originally posted this to the list a while back, which is how I came across it. On Wed, May 22, 2013 at 10:24 AM, Lawrence Bottorff <borg...@gmail.com>wrote: > 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: > > ---- > > 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. > > 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: > > Z = {(x,y) | 3 <= x <= 5, -2 <= y <= -1} > > 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. > > 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? > > 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. > > 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. > > ---- > > It would be nice to hear some of your thoughts on this. > > LB > > ____________________ > Racket Users list: > http://lists.racket-lang.org/users > >
____________________ Racket Users list: http://lists.racket-lang.org/users
