Learning FP the hard way: Experiences on the Elm language

You claim that this is reactive rather than imperative, but instead, it feels imperative instead of object oriented.

You still have your "setup method":

    Signal.map show (Signal.foldp update initShip inputSignal)

and your "handle updates method":

    updateVelocity newVel (updateShooting isShooting (applyPhysics dt ship))

And the distinction between "set the ship's position to ship.position + ship.velocity * dt" and "create a new ship similar to the old ship but the velocity is ship.position + ship.velocity * dt" seems like splitting hairs.

It's not OO, definitely—but it doesn't feel like you're doing anything differently than you would if this was a purely structural program, even if some of the details are different. If this was straight C, "update" would be a method that gets called 30 times per second, and "main" would get called when the game starts, and everything else would map pretty much line-for-line.

Similarly, the "functional-reactive" nature of it feel like an implementation detail, rather than a different way of thinking about the code—in your update method you still walk through the steps "was pressed? was ^ pressed? Move the ship. Fire your gun. Change your velocity." Maybe some of them don't need to be recalculated? Okay, but as the programmer you still need to describe the same steps, even if some of them get optimized away.

And honestly, even going through the same steps, it makes it harder to understand. Take your update function:

    updateVelocity newVel (updateShooting isShooting (applyPhysics dt ship))

Okay, so you have an applyPhysics method that takes a ship, and a dt. That's pretty clear. And it returns... something, and that something gets passed into updateShooting, and then what updateShooting returns gets passed into updateVelocity. You have to go elsewhere to read that, okay, applyPhysics and updateShooting both return ships. The same steps, written in a more imperative syntax:

    applyPhysics(ship, dt);
    updateShooting(ship, isShooting);
    updateVelocity(ship, newVel);

Which (a) makes it more clear that a ship gets passed into each method, but (b) also lets you pass in the more important parameter first, which aids readability, and (c) lets you list the methods in the order that they occur, rather than writing them in the reverse of the order they occur. To at least get the better argument order with Elm you'd have to write it:

    updateVelocity (updateShooting (applyPhysics ship dt) isShooting) newVel

Which is completely unreadable—you're reduced to counting parentheses to see which method "isShooting" gets passed into.

The biggest difference in thinking comes from the concept of signals. Initially when you hear that a signal is a value that changes over time it doesn't seem all that different from setting the state on an object. But actually a signal is more like an array in that it's also a collection of values except it's a collection of values over time. And crucially, like an array, a signal can be mapped over. If you look at the last line you see that 'main' is a signal of Elements, which we can assume is some type that elm knows how to display in the browser.

So a single instance of Element can be thought of as the browser's displayed state at a single point in time, in this case a single frame of the ship's movement animation. Each subsequent Element in the signal can be thought of as a transition from one browser state to the next, or from one animation frame to the next.

Now the key is that each Element in the Element signal is being mapped 1 to 1 with a Ship in the Ship signal. (The Ship signal is the return value of 'Signal.foldp update initShip inputSignal') In fact the whole application can be thought of as a transformation on an initial Ship and a signal of keyboard inputs, to producing a signal of Elements.

So in building this app the thought process might be that I first create an initial Ship and a signal of keyboard inputs to start. I want my app to update at 30fps, so I create a signal that samples the keyboard inputs signal at this interval. Now from this input signal I want to produce a signal of updated Ships. From the signal of Ships I want to produce a signal of Elements.

Finally you can see everything come together at the end, and it is quite descriptive. You want a signal of Elements. What is a signal of Elements? It is a mapping of a signal of Ships over the show function. What is a signal of Ships? It is a signal of inputs foldp'd over an update function (which gets passed the input and the most recent Ship). What is an input signal? It is a sampling of the user's keyboard inputs at a 30fps interval. Etc.

So we end up with descriptive functional code. There are no statements here, no loops, and no mutation, which means that we don't need to coordinate the order of execution with changes in the state of objects, which is a huge step forward in reducing the complexity of a program.