

Functional programming explained ... IRC-style - gnosis
http://itmmetelko.com/blog/2008/02/23/functional-programming-immutable-objects-explained-irc-style/

======
Sapient
Quite a good explantion - the idea of having immutable data is a really
strange one to wrap your head around when you have been doing OO for most of
your career.

I'm just getting into clisp (I read somewhere that it is inevitable that
everyone on HN will eventually try lisp when they have been around long
enough) at the moment, and would like to try my hand at some Haskell later as
well, and one of the hardest things to do is to think of data in FP terms.

~~~
tumult
You think it's weird now, wait until you start building infinite lists or
writing recursive functions with no terminating case as part of your everyday
routine in Haskell :)

~~~
mapleoin
you can do that with python generators, too. These don't seem like the most
eccentric Haskell features to me.

~~~
tumult
Don't generators have to yield in order to return data?

And I never claimed these were eccentric features.

------
silentbicycle
FWIW, RobertFischer's blog is <http://enfranchisedmind.com/blog/>

------
alexgartrell
In a nut shell:

    
    
      <middayc-> I have to invert my brain from stuff I am used to and 
      then it all makes sense  
      <RobertFischer> Pretty much.
    

A very good read. Makes me want to do something besides C/C++ this afternoon.
FP actually stands for "Fantastic for Procrastination"

------
rufugee
Isn't the graph itself state? I mean, data structures of data
structures....but data is state by definition, right?

~~~
silentbicycle
Yes, but it's not being modified in place, so you can selectively re-use it.
Immutability is the big thing.

In FP, you typically "change" a data structure by creating a shallow copy of
it with a few parts replaced, but the rest just pointing back to the original
- nothing's changed directly, and when data is no longer used, it's eventually
garbage collected. (Typically, with a generational and/or copying collector,
whose costs are proportional to surviving data.)

This works better with trees and lists than it does arrays and hash tables,
because changes to those usually require adjusting _as a whole_. To add to the
head of a linked list, you can just create a new cell of [new value, head of
old list], which is very cheap. (Adding to the tail can be done with e.g. a
deque). At the same time, anything that adds to the list won't interfere with
other code that is holding a reference to the same list, or even accessing it
concurrently.

Probably the best way to learn about purely functional data structures is from
the book of the same name by Chris Okasaki.

~~~
krikor
Thanks for the book recommendation. Those are always much appreciated!

------
morphir
_< RobertFischer> A graph is a data structure of data structures._

Could anyone provide an example?

