[racket] Why functional?

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.racket-lang.org/users/archive/attachments/20130522/f349e9e2/attachment.html>