FRP and a rule of thumb for implementing abstractions
Lately, I’ve been trying to write a custom drawing program that makes it easier for me to create teaching videos about Haskell. While doing so, I stumbled upon a rule of thumb for implementing abstractions that might be worth sharing here.
The custom drawing program is written in Haskell, of course. In particular, I’m using wxHaskell as the GUI library, which gave me much grief at times. For instance, I found out that wxHaskell lacks support for “toggle buttons”, and for a moment, I considered using Cocoa instead. But as alluring as that may be for GUIs, I simply refuse to use any language that is not purely functional; I prefer to spend my time with Haskell and making a small improvement to the Haskell ecosystem.
Likewise, I’m not willing to use traditional mutable state for organizing my GUI and bow to the giant spaghetti code monster. Instead, I want to use functional reactive programming (FRP). The problem with FRP is that, while the core idea is very clear, there is a great tension between semantics and resource usage, and no definitive Haskell library for doing FRP has emerged yet. Should I write my own? But I need to get things doneTM, and it is unrealistic for me to solve this unsolved problem in a short amount of time; so why take the risk?
This is where the rule of thumb comes in:
You don’t have to implement abstractions in full generality.
While abstractions are the programming technique and should be used in abundance, some abstractions can be so expressive that they become really difficult to implement. One example of this phenomenon is FRP, another instance is the Haskell language itself, even. I would count the so far unsuccessful attempts of implementing software transactional memory in languages with mutable state among that, too.
But! I don’t have to implement the holy grail of FRP, I only have to implement a small, flexible subset that serves my needs. While I might have to resort to mutable state occasionally, I still greatly benefit in the places where my FRP model applies. This is a realistic prospect.
In the same spirit, screw the toggle buttons. I’m going to write a tiny drawing combinator library on top of wxHaskell and draw my own buttons with as many toggles as I desire. Here a screenshot.
