Functional programming explained ... IRC-style | Hacker News Reader

Functional programming explained ... IRC-style

itmmetelko.com

62 pointsgnosis13 comments

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.

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 :)

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

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

And I never claimed these were eccentric features.

Take a look at Parsec sometime.

Sure, you can do parsers in any language, but the monadic/combinator structure is a little bit eccentric and a lot amazing.

Heh, one step at a time... Those sound like they can produce headaches.

FWIW, RobertFischer's blog is http://enfranchisedmind.com/blog/

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"

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

yes, but you don't modify it in this case.

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.

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

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

Could anyone provide an example?

Reply on news.ycombinator.com