The unreasonable effectiveness of declarative programming

Back in the day when I was making videogames (http://www.mysterystudio.com), I implemented something similar for my framework.

Most of the framework was declarative. There were Sprite objects that had an associated Image and a position (among other things). The onUpdate(dt) method of the "screen" didn't explicitly draw things on the screen, it only updated positions and other attributes of the Sprites, and the renderer would do the rest (back in the days of software rendering, it updated only dirty sections of the screen, etc).

Still, making programmatic animations was difficult, and for videogames you want things to look very nice (smooth movement, easing in and out, transparency effects, that kind of thing). There was a lot of { srcX, srcY, dstX, dstY, time } sets, for every thing that moved.

At some point I had an idea similar to what this blog proposes. I called them SpriteControllers, and they could be "attached" to a Sprite. The engine would call each SC's onUpdate(dt) method on every frame, and the SC would change the position, rotation, alpha, or tint of the Sprite.

By default all the attached SCs would work in parallel, so the next step was to have a SCSequence to run things in series. Also each SC was allowed to declare when it was "done". Some did (like linear motion from A to B), some never finished (like a pulsating glow).

It was a fun development in the sense that it made something that was very difficult to do by hand surprisingly easy, and took our games to the next level in terms of visual quality, just by adding a bunch of very short classes.

Making games was fun in a way. Alright, back to work. These protos aren't going to copy themselves into other protos by themselves!

In Haskell, one can make more general combinators in the following way:

   type Anim a = (Duration -> a, Maybe Duration)

   -- Linear interpolation
   linear :: Anim Duration
   linear = (id, Nothing)

   -- Sequencing
   seq :: Anim a -> Anim b -> Anim (Either a b)
   seq (f, Nothing) g = (\t -> Left $ f t, Nothing)
   seq (f, Just df) (g, dg) = 
        (\t -> if t  Anim b -> Anim (a, b)
   par (f, df) (g, dg) = (\t -> (f t, g t), max df dg)

   -- Constant
   pure :: a -> Anim a
   pure a = (const a, Nothing)

   -- EDIT: forgot delay
   delay :: Duration -> Anim ()
   delay d = (const (), d)

I know there's an Applicative in there, but I'm not sure where else this lies in the typeclass hierarchy.

EDIT: More fixes

EDIT: I should really test in GHCI before I post these things. But I'm lazy.

> IMHO in a declarative language your example should be an error. You defined x twice. Intentionally or not, this is confusing, for others and for you in a week when you have to look at the code again.

c'mon, this is an example in a forum post ! of course it doesn't make sense in real life. real life is

   distance := computeDistanceToCenterOfScreen(cursorPosition)
   text := "the current distance is: " + distance

but that just muddies the waters needlessly

> Also, why should the second binding override the first? You introduced a temporal dimension where later lines of code somehow override earlier lines of code.

yes, some languages work like that, but it's not the point - either you assume that you can update values in your declarative bindings like that, or you have to define your binding in terms of some external behaviour that will change in magic ways, which again would not be very nice to do as a simple forum post example

That looks neat. Making me fall in love with Haskell again which I want to avoid as I can’t use it at work ;)

You could add a monoid instance which would be useful (for one example) if the animation produces a matrix transform then you could combine two animations that produce transforms. For example a rotation and a move. I’m sure there are other good monoid animations. Strings would be a simple example I guess.

Interestingly, if you watch the Erlang: The Movie (https://www.youtube.com/watch?v=BXmOlCy0oBM) they use the term 'declarative programming' to refer to what we would now call 'functional programming'. It's an interesting way of thinking about it - these sort of declarative interfaces are very simple in languages with first class function support.