[racket] Why functional?

Hi Lawrence, 

your little essay is fascinating and intriguing from the perspective of 'ideals' -- as in ideal FP and ideal OOP etc. I am sure 'philosophers' of programming languages with a sufficient technical understanding of your example could have a field day. 

The sentence concerning 'elisp' in your last paragraph worries me, however. Elisp -- like any Lisp, say Common Lisp or Racket -- is not a functional language in the purist's point of view. It supports direct, uncontrolled, and full-powered effects wherever and whenever a programmer wants it. Meaning, looking at Lisp code will not really help you tease out answers to your deep questions. Indeed, if we were to answer these questions here,  I am sure we would soon get into the fine details of when to use side-effects in Racket. 

Let me suggest an alternative then. Haskell is the language that most people consider the purest functional language of all. It does not even allow real exceptions to ensure that programs have certain mathematical properties that a 'fundamentalist mathematician' might argue they should have. The kind of question that you raise will fascinate the Haskell purists, and so I propose that you ask your question on their mailing lists.

Good luck -- Matthias





On May 22, 2013, at 12:24 PM, 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