[racket] (off) Purely Functional needs "One Memory/Massively Parallel"

On Fri, Feb 07, 2014 at 09:51:17AM -0600, Lawrence Bottorff wrote:
> AFAIK, recursion is must-do pillar of the functional style . . . and that
> is why tail recursion came along to solve the real-world problem of the
> overflowing stack. Likewise "I/O" is antithetical to functional . . . so,
> obviously, data needs to be somehow quasi "live" and not "off site," not
> discrete, not outside the domain/range function world. It seems like the
> whole functional paradigm is sitting there in the middle of the road
> staring at us, waiting for us to finally deal with this issue. .  .
> 
> . . . oh, and then I see a talk given by Gilad Bracha where he, like your
> typical snarky American put-down comedian, pooh-poohs the whole idea
> functional programming (
> http://www.infoq.com/presentations/functional-pros-cons). And there's Scala
> where the functional is like a dumb plow animal under the intelligent
> guiding hand of the object-oriented master. And so, to somebody like me
> trying to separate out all the propaganda, it's all very, very confusing.
> 
> I take it that you Racket folks are basically satisfied with how far you've
> adopted the functional paradigm and you don't see the need to sweat the
> whole "pure" thing. You're "realists" in the great American tradition. 

Use pure when pure is the better way, use impure when impure is the 
better way.  It's not up to the language to force you into one model or 
the outer.
 
> But
> then I'm hearing from the Haskell people (again, not openly for fear of not
> seeming realist) that the great benefit of pure functional is that, indeed,
> the world can at last be described with all the succinctness and exactness
> of mathematical formulae, i.e., math is code, code is math.

And Haskell is designed to force you into writing pure code.  This is 
fine for project where that fits.  But mandating it for projects where 
it doesn't fit is obsessive-compulsive extremism.  Not that 
research in that direction is necessarily useless, of course; it 
might well result in new technologies in the long run.  

> If you've ever
> seen "Structure and Interpretation of Classical Mechanics," you see Scheme
> being used throughout the book right along side all the typical math
> formulae. This was quite the eye-opener for me. It seemed like not the
> wedding, but perhaps the courtship of code and math, i.e., a real step
> forward away from math being taken to a slaughterhouse and chopped up to be
> eventually fried on processor barbecues.
> 
> So please take a break from "realism" and humor me with a few lines of
> response.
> 
> 
> 
> 
> On Wed, Feb 5, 2014 at 6:46 PM, Matthias Felleisen <matthias at ccs.neu.edu>wrote:
> 
> >
> > (1) Based on my experience, I suggest a 'theorem' that roughly says "there
> > is always more data to be put into memory than there is data and there is

Maybe "than there is memory?"

> > always more need for speed than there is realizable speed in our
> > processors."
> >
> > (2) I think FP can deal with I/O in a truly functional manner, but no, I
> > haven't seen an efficient implementation yet.

Machines are fast enough and big enough for  many applications, but
efficiency is still essential in many applications.  This will always 
be true.

> >
> >
> >
> >
> > On Feb 5, 2014, at 11:48 AM, Lawrence Bottorff wrote:
> >
> > > Please correct me if I'm way off base, but the whole issue of a purely
> > functional language being impractical because it should not "go outside"
> > the function (e.g. for IO) seems to hinge on the fact that there is (today)
> > a segmented, discrete, world out there where data and apis etc. reside
> > outside of your box running your program.

There is still a world out there.  with events and irreversible 
effects.  That's the  world where the computer user lives.  There are 
hacks to make the world *look* like a function (monads and such), but 
there will remain a need to interact.

THhis is a conceptual issue, and not just a memory shortage.
 
> > What if you had limitless live
> > memory and parallelism? Isn't the vaunted Google File System just this sort
> > of "One Memory/Massively Parallel" beast?

Still not limitless.  It is big enough, though, that a one percent 
improvement in efficiency may accomplish millions in savings.

> > If your purely functional program
> > were running in such a One Memory/massively parallel space, you could have
> > some Ueber-function encompassing the data, within which all your subsequent
> > functions could play. You could do anything and everything totally purely
> > functionally. Right? So with Haskell, everything is fine, functionally pure
> > -- until you have to go outside to interact with stuff outside your
> > program. So don't go "outside." Right?
> > >
> > > I'm coming at this from an old Cartography/GIS angle. Many years ago I
> > heard of a project to write GIS software in (then new) Smalltalk. But it
> > was deemed not feasible because the model was expected to bring into live
> > memory an entire mapping project with all its geographic classes
> > instantiated and ready to go . . . then you would do your work.

IIRC, I do believe the original smalltalk implementation had its own 
object-by-object implementation of virtual memory.

> > But of
> > course today, even on home machines, we measure memory in gigabytes.

and virtual memory in terabytes.

> > >
> > > Obviously, today's computing world is about dealing with lots and lots
> > of discrete things: machines, datasets, apis, etc. So, my specific question
> > is: Isn't purely functional really just waiting for One Memory/Massive
> > Parallel wherein all its supposed foibles are moot? The whole "sort-of"
> > functional world simply takes all the discretism for granted. But Isn't the
> > purely functional paradigm driving us toward a day when some sort of OM/MP
> > (virtual or real) is the rule?

I think we are moving to massively parallel computation, and some kind 
of huge memory.  A lot of our computing is already in that world.

But I think that's largely unrelated to functional programming, which 
ought to live or die depending on how well it expresses the algorithms 
that solve people's problems.

-- hendrik