[racket] Why functional?

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