Sunday, July 28, 2013

Haskell and the Embedded Programmer

Can you really use Haskell for Embedded Programming? Well, if you define your embedded platform as (at least) an Intel Atom based computer with gobs of memory... then probably. (Yes, I know about GHC ARM, but has anyone deployed real world apps with it?)

Ignoring the really cutting edge (academic) features of the language, Haskell seems ideal for the embedded developer. What? Wait. Hear me out.

First, let's define the class of embedded I am talking about.  How about my home monitoring application ( The base station is headless and should run 24x7, so I classify it as "embedded".

It currently runs mostly Lua (it used to run Erlang) on Linux, but it could have been Java on Android OS for that matter. If you accept the notion of a garbage collecting dependent app can run on an embedded platform, then you've made the leap (for good or bad) to modern embedded development.

Unfortunately, all of these modern embedded systems don't seem to run all that well.  My Android phone pauses every once in a while (garbage collecting I suspect) and my Roku crashes after a few weeks of up time.  I am starting to worry about the stability of my home monitoring system (although it has run for a couple of months before I intentionally reboot it for upgrades, etc).   Not just due to garbage collection, mind you.

Now, Haskell also does garbage collection, but the compiler is backed with a lot of type checking and other supports for determinism. The idea is that if you code "safely" (say it with me: catch all of those potential exceptions -- they will bite you later if you ignore them), you have a better chance of avoiding run time errors.  Avoiding run time errors are very important for systems that run 24x7 with no head (display).

Erlang's "expect to crash" approach is a good meta level approach to embedded design, but if you don't have a careful design or code, recoveries from random crashes is not a good thing. Your embedded code needs to be correct. Every crash situation is bad. It is worse if the problem is due to bad code logic (and not a perfect storm of resource conflicts).

Haskell is no panacea, but I've done 3 projects in Haskell thus far (one embedded in a commercial system) and I haven't been bitten by any type-based run time problems.

So, Haskell (or a sane subset of) appeals to me for embedded development.  But when is it overkill? I haven't done a lot of sophisticated stuff with it (yet), so almost everything I've done could have just as easily been done with Erlang or Lua.

Haskell was a bear on some of these projects, but I'm finding the results encouraging.  I feel better about the resulting systems.  Maybe it is time to revisit using it for my Home Monitoring system.