I've been reading a lot of stuff about functional programming lately, and I can understand most of it, but the one thing I just can't wrap my head around is stateless coding. It seems to me that simplifying programming by removing mutable state is like "simplifying" a car by removing the dashboard: the finished product may be simpler, but good luck making it interact with end-users.
Just about every user application I can think of involves state as a core concept. If you write a document (or a SO post), the state changes with every new input. Or if you play a video game, there are tons of state variables, beginning with the positions of all the characters, who tend to move around constantly. How can you possibly do anything useful without keeping track of changing values?
Every time I find something that discusses this issue, it's written in really technical functional-ese that assumes a heavy FP background that I don't have. Does anyone know a way to explain this to someone with a good, solid understanding of imperative coding but who's a complete n00b on the functional side?
EDIT: A bunch of the replies so far seem to be trying to convince me of the advantages of immutable values. I get that part. It makes perfect sense. What I don't understand is how you can keep track of values that have to change, and change constantly, without mutable variables.
Using some creativity and pattern matching, stateless games have been created:
as well as rolling demos:
and visualizations:
Bear in mind: functional languages are Turing complete. Therefore, any useful task you would perform in an imperitive language can be done in a functional language. At the end of the day though, I think there's something to be said of a hybrid approach. Languages like F# and Clojure (and I'm sure others) encourage stateless design, but allow for mutability when necessary.
By using lots of recursion.
Tic Tac Toe in F# (A functional language.)
Here's how you write code without mutable state: instead of putting changing state into mutable variables, you put it into the parameters of functions. And instead of writing loops, you write recursive functions. So for example this imperative code:
becomes this functional code (Scheme-like syntax):
or this Haskellish code
As to why functional programmers like to do this (which you did not ask), the more pieces of your program are stateless, the more ways there are to put pieces together without having anything break. The power of the stateless paradigm lies not in statelessness (or purity) per se, but the ability it gives you to write powerful, reusable functions and combine them.
You can find a good tutorial with lots of examples in John Hughes's paper Why Functional Programming Matters.
For highly interactive applications such as games, Functional Reactive Programming is your friend: if you can formulate the properties of your game's world as time-varying values (and/or event streams), you are ready! These formulae will be sometimes even more natural and intent-revealing than mutating a state, e.g. for a moving ball, you can directly use the well-known law x = v * t. And what's better, the game's rules written such way compose better than object-oriented abstractions. For example, in this case, the ball's speed can be also a time-varying value, which depends on the event stream consisting of the ball's collisions. For more concrete design considerations, see Making Games in Elm.
This is very simple. You can use as many variables as you want in functional programming...but only if they're local variables (contained inside functions). So just wrap your code in functions, pass values back and forth among those functions (as passed parameters and returned values)...and that's all there is to it!
Here's an example: