Hacker News Reader

Comment by stonemetal | Hacker News Reader

traceability and testability. update world1 is traceable you know just by looking at it what it modifies (sure in the example given it is opaque since it is the entire world) but if you consider that update world is probably broken into update world.player update world.ai etc. Then it becomes easier to trace execution because there is no implicit state. The lack of implicit state also improves testability. I can create a world and send it to update and know that I don't have to do any implicit state priming.

View on HN

A large, complicated world state for a FP language is no simpler than a large complicated graphic of objects w/ inheritance hierarchies. You see, the inheritance hierarchies are the world state. In either system, you have to model the graph in your head to understand how it works. Complexity is the problem, not referential transparency.

Couldn't you do the same thing by just not using global variables in an imperative language? Then you get the benefits you're mentioning without lots of pointless data copying. You just pass a reference to the world object and you can see exactly what's being modified.

It is true that persistence is a default property of functional data structures but with a compiler or interpreter that isn't braindead you shouldn't get "pointless data copying" unless you hold and read both states after the transform. That is, it should be optimized away.

I stand corrected. Don't you still have to do lots of messing around (in comparison to an imperitive language) to simulate state though?

I am still new to functional programming, but so far it seems like I produce two kinds of code. Functions that gather state and functions that modify state. Say in the above example of update_world world1 all this would do is break apart the world data structure and forward the pieces to their respective update functions and then gather the parts in to a new world. The individual update functions either do the break and gather thing or they do the actual computation on a small entity or set of entities. This makes a large number of small easy to test functions that do the actual work and several "middle layer" functions that are easy to test with stubs.

Though it would be interesting hear how people who have been doing FP for a while handle it.

The pure functional world was pretty much impenetrable for me for that very reason ... until I encountered Monads in Haskell. Monads have changed the game completely by providing a very clean encapsulation of side effects in general. There are people who are trying to generalize it even further using what are called "arrows", but just groking Monads in Haskell will give you a new understanding, somewhat along the lines of what learning exterior calculus does to your view of traditional vector calculus.

>>without lots of pointless data copying. Think tail recursion. It is easily optimized. It presents a nice uniform interface that forces the right thing. Just look at .net the generated main. It replaces general global scope with an application object global scope that rather encourages "cheating".

Reply on news.ycombinator.com