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 <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 ul!
timately 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
