Functional programming & immutable objects explained — IRC style
Saturday, February 23rd, 2008I was on #ocaml channel on irc.freenode.org. (btw - freenode hosts channels for a lot of popular languages and technologies). This was a while back when I started making OCaml SDL examples that you can find on this blog. I think this short IRC chat told me more about FP than anything I read before.
<hcarty> For the velocity vector example - one way to think about it would be to have your update function return a new “bullet” rather than modifying the old one.
<hcarty> But it’s a style choice, and OCaml lets you have it both ways
<middayc->
that is an interesting view (new bullet every time)
<Yoric[DT]> But OCaml is often able to optimize this “create a new bullet each time” to “reuse the same bullet”.
<RobertFischer> middayc- Whenever possible, use many small, rapidly-GC’ed data elements.
<RobertFischer> Ocaml is highly optimized for that kind of behavior.
<RobertFischer> All of your ex-Java (or whatever) training which says that “object creation is expensive” needs to go out the window.
<RobertFischer> You’re generally best off using records or tuples (as appropriate) and minimizing the amount of mutable data you have. This will give you the best performance in Ocaml.
<middayc-> aha … yes I was thinking about GC in that way
<RobertFischer> Thinking in terms of list/graph processing instead of message passing is also a major performance improvement.
<RobertFischer> So, when you have a bunch of sprites and a change in the moment in time, don’t think of telling each and every sprite to update itself — that’s the OO way to approach the problem.
<ita> does the use of closures instead of classes change anything speed-wise?
<middayc-> huh I have no idea what is list/graph processing …
<RobertFischer> Do you know what a graph is?
<middayc-> no
<RobertFischer> A graph is a data structure of data structures.
<middayc-> aha .. like a tree
<middayc-> like list is flat — a graph is structured?
<RobertFischer> Yes, where each node is a data structure. So a list of lists, a tree of lists, a tree of maps of lists of map-list tuples.
<RobertFischer> Whatever.
<ita> middayc-: {vertex, arcs}
<middayc-> aha … I begin to understand what you mean by list/graph processing vs object.update()
<RobertFischer> The more you can just tell OCaml (or any FP language), “Here’s how to process each element of that graph, and here’s the graph to process”, the better off you’ll be. See fold and iter of examples of that.
<middayc-> cool … you should write a book … you explain it in a way I can quickly understand
<RobertFischer> If you think of your state as a graph of elements, and can define a function which changes your state and returns the new graph of elements, then you’re going to be digging around at the best performance in Ocaml.
<RobertFischer> I’m doing a podcast and writing a blog.
<RobertFischer> I’ll work on a book later.
<middayc-> aha … a new graph each time?
<middayc-> I have to invert my brain from stuff I am used to and then it all makes sense
<RobertFischer> Pretty much.
Thanks guys for explaining it to me so well! Since then I wrote 3 examples of using SDL with OCaml and I used no mutable state and felt no need to use it. I like the code I wrote with this paradigm a lot. I will continue building a game in OCaml and see what happens next.


