For the (very) long answer please continue reading.
I didn’t want to write this article, but because of the recent terrorist attack in Paris I think I have to. There is a lot of sh*t happening out there. Fundamentalists use religion to implement their own world view (which of course includes the forceful removal of other-thinking people), atheists often joke about religions and do present religious views often as stupid, discussions about reversing the dividing of church and state are happening (e.g. in the US), people refusing to follow the law in giving gay marriage licenses because of religion, discussions about women, abortion, celibate and “family values”, “good” and “bad”, big contradictions about what’s written in “holy” texts and what people who say to follow them really do etc. Power misuse, child abuse, control, patriarchism, oppression, suppression, superstition, creationism, whatever you like, everything “bad” is somehow present in religions.
So on the first look, there are not really much positive things in there. Even on the second look it’s still very bad. So let’s get a bit deeper and get behind some of the mechanisms in religions. Maybe then we will be able to differentiate a bit better instead of throwing all into the same pot, cook it up and then feed this poisonous mish-mash into people just to be able to feel better than these pitiable misdirected creatures we are discussing with.
OK, did take some time since the last post, but I am really busy now.
Last time we looked at the general structure of the application in terms of threads and model/interface separation. For this post, I want to write a little bit about the protocol handling and parsing and how it evolved. While this is not the most central part of the application, it is the oldest and therefore I think good to show some historical development.
Ok, so the tool began as a command line application which could only receive telecommands and send back correct responses (which on itself is not as simple as it sounds). Also at that point in time I just more or less started learning Haskell while my main language at that time was C++, so of course the first solution was a lot C++ like. So let’s see how it goes.
There were numerous posts on reddit, SO and the like which were asking for how to architect real world Haskell applications. Well, this is my go at it for an in-house testing tool which is used extensively. I would not claim myself an advanced Haskeller, some of the code is probably not idiomatic Haskell (and also some parts are really, ah well, horrible), it’s (by it’s nature) very stateful (read: imperative), BUT… it works. It even worked out better than I thought initially…
How it came to this…
I am working in the space domain and I am mostly concerned with mission control systems, especially the ones from the ESA (European Space Agency) named SCOS-2000. What we needed was a tool to be able to test certain new features implemented in the mission control system with a closed-loop test. The standard tools that come with SCOS are quite limited (and buggy) and written quite verbosely in C++. So why not try to create one in Haskell?