[Haskell-beginners] Re: Applicability of FP unchanging things to
real world changing things
dev at mobileink.com
Mon Dec 14 11:54:53 EST 2009
On Sun, Dec 13, 2009 at 12:21 PM, Brent Yorgey <byorgey at seas.upenn.edu>wrote:
> On Sun, Dec 13, 2009 at 11:24:06AM +0100, Heinrich Apfelmus wrote:
> > In other words, the book in your example is not a real book, it's just a
> > few bytes in the computer that model it for the purpose of tracking
> > whether it's lent out or not. For instance, these few bytes can be a
> > unique ID and a possible lend function is
> > lend :: BookID -> Library -> Library
> I should also point out that people coming from an OO or imperative
> background often look at a function like this and think it looks
> incredibly inefficient --- why throw away the entire *library* and
> build a new one *from scratch* when all we want to do is modify one
> little part of it? This seems a huge price to pay for immutability!
> But this line of thinking confuses abstract semantics with concrete
> implementation (something that imperative programming unfortunately
> tends to encourage, in my experience). The runtime is free to
> implement operations like "lend" any way it likes, as long as the
> abstract semantics are preserved.
One of the turning points in learning the FP way is the realization that the
conception of "function" as a "machine" or "transformation process" is
misleading or even harmful. For most programmers coming from an imperative
language background that's going to mean returning to a more mathematically
pure notion of function, which means discarding the idea of mutating parts
of an object in favor of establishing relations among different "objects"
and letting the compiler worry about the gory details. Youschkevitch's
fascinating history of the
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners