Starting today, I'm posting all of my notes on my Elderly Monitoring system here: http://eldermonitor.blogspot.com/
All of the old home automation material will remain here, but look for new stuff on the new blog.
Friday, April 19, 2013
Thursday, April 04, 2013
A Pattern Language for Haskell System Programming?
Continuing on my previous blog entry (Haskell for the Working Programmer), it occurs to me that there needs to be a set of idioms to define a Haskell for System Programming. Or, perhaps more strongly: There needs to be a Pattern Language for developing System Programs using Haskell.
When I say System Programs, I am stretching the term a bit to mean an application that touches the real world a lot. That is, it isn't so much focused on doing a ton of data manipulation or business logic, but spends most of its time interacting with the system (hardware, OS, or network) at hand. This is the land of embedded development, network tools and server management. Haskell can play here, but I don't see a lot of literature about how to do this.
Haskell is a rich ecosystem for implementing cutting edge ideas. This is its academic heritage and it keeps the language healthy and forward looking. But for us working programmers, we can't always be interrupted from our tasks to explore new mind blowing techniques (e.g. "Okay, I grok Monads, so let's get some work done... whoa, wait... Arrows? I need to start using Arrows?").
So, you want to build Home Monitoring base station (something to collect sensor data, analyze it and perform some action or notification via the Internet). Oh, and it needs a built in web server for configuration.
How do you do this using Haskell?
That isn't quite a fair question. A Haskell newbie would not be advised to adopt such a big project until they've mastered the language a bit. So, let's ask again, but a little more focused:
I'm an Erlang/Clojure/ML/Scheme programmer (so I understand FP); I've played around with Haskell and now I want to implement my Home Monitoring base system. Where do I start?
That's better.
So, what is needed here is way to guide a developer towards their goal with just a subset of Haskell. (I've recently written over 3000 lines of Haskell for a commercial system. It doesn't sound like a lot, but since it was mostly system programming stuff, I leveraged lots of Hackage libraries and FFIs. In retrospect, I would say that I used a fairly small subset of advanced Haskell features to get the job done.)
An aside: I mentioned the phrase Pattern Language as opposed to Design Patterns. I don't want to bring up an old war in the Pattern Community (is there an active Pattern Community these days?), but I am talking about a group of related Patterns (or Idioms) that you can select to help you build a specific thing. Patterns in a Pattern Language are not adhoc. Each Pattern leads to one or more Patterns you may choose to help you build the thing. Check out the original source for further understanding and information. (I'm too lazy to find a great example of a software Pattern Language for system programming, but you can look at my own 1997 contribution to the community: A Pattern language for User Interface Design for the general idea of what I am talking about.)
Now, where were we? Subset of Haskell...
This subset of Haskell wouldn't be restrictive. By all means, if an advanced Haskell technique helps get the job done or makes the program more manageable, then use it. But Haskell has an ocean of ideas and new users are apt to drown in lieu of getting their project completed.
You don't need to master all of Haskell, just master what you need. Just by using Haskell (in particular the type system), you are already on your way to constructing correct system programs. (But, please remember to handle exceptions -- the monadic wrapped real world is full of unexpected behavior).
So, what next? I don't know. I am wondering if something like The School of Haskell would be a good place to start building such a pattern language (where examples could be not only listed but tried out).
When I say System Programs, I am stretching the term a bit to mean an application that touches the real world a lot. That is, it isn't so much focused on doing a ton of data manipulation or business logic, but spends most of its time interacting with the system (hardware, OS, or network) at hand. This is the land of embedded development, network tools and server management. Haskell can play here, but I don't see a lot of literature about how to do this.
Haskell is a rich ecosystem for implementing cutting edge ideas. This is its academic heritage and it keeps the language healthy and forward looking. But for us working programmers, we can't always be interrupted from our tasks to explore new mind blowing techniques (e.g. "Okay, I grok Monads, so let's get some work done... whoa, wait... Arrows? I need to start using Arrows?").
So, you want to build Home Monitoring base station (something to collect sensor data, analyze it and perform some action or notification via the Internet). Oh, and it needs a built in web server for configuration.
How do you do this using Haskell?
That isn't quite a fair question. A Haskell newbie would not be advised to adopt such a big project until they've mastered the language a bit. So, let's ask again, but a little more focused:
I'm an Erlang/Clojure/ML/Scheme programmer (so I understand FP); I've played around with Haskell and now I want to implement my Home Monitoring base system. Where do I start?
That's better.
So, what is needed here is way to guide a developer towards their goal with just a subset of Haskell. (I've recently written over 3000 lines of Haskell for a commercial system. It doesn't sound like a lot, but since it was mostly system programming stuff, I leveraged lots of Hackage libraries and FFIs. In retrospect, I would say that I used a fairly small subset of advanced Haskell features to get the job done.)
An aside: I mentioned the phrase Pattern Language as opposed to Design Patterns. I don't want to bring up an old war in the Pattern Community (is there an active Pattern Community these days?), but I am talking about a group of related Patterns (or Idioms) that you can select to help you build a specific thing. Patterns in a Pattern Language are not adhoc. Each Pattern leads to one or more Patterns you may choose to help you build the thing. Check out the original source for further understanding and information. (I'm too lazy to find a great example of a software Pattern Language for system programming, but you can look at my own 1997 contribution to the community: A Pattern language for User Interface Design for the general idea of what I am talking about.)
Now, where were we? Subset of Haskell...
This subset of Haskell wouldn't be restrictive. By all means, if an advanced Haskell technique helps get the job done or makes the program more manageable, then use it. But Haskell has an ocean of ideas and new users are apt to drown in lieu of getting their project completed.
You don't need to master all of Haskell, just master what you need. Just by using Haskell (in particular the type system), you are already on your way to constructing correct system programs. (But, please remember to handle exceptions -- the monadic wrapped real world is full of unexpected behavior).
So, what next? I don't know. I am wondering if something like The School of Haskell would be a good place to start building such a pattern language (where examples could be not only listed but tried out).
Wednesday, April 03, 2013
Haskell for the Working Programmer
There is a need for a book. I would call it "Haskell for the Working Programmer".
The audience would be, you guessed it, working programmers. Maybe even for working functional programmers. I already grok functional programming. I have been doing it for over a decade now. It is Haskell I'm trying to grok.
Sure, there is Real World Haskell, and it is great. But, it is also getting dated and perhaps the pacing is a bit too iterative for my tastes. That is, they start off with sub-optimal (naive) solutions to problems and then (in later chapters) proceed to make them better and better. Too much reading!
As a working programmer, I tend to learn better by studying and stealing exemplars.
Maybe I want a cookbook. Or, perhaps, what I am really looking for is a book that recognizes that my first goal is to compose a working program. Of course, I want to understand why something works, but maybe, just maybe, I want to see something (anything) work first!
Should I feel ashamed that I still haven't mastered Monads? (Sure, I've used them, debug them and have even constructed a few, but I can't say yet that I have mastered them -- at least not the theory). Can I call myself a Haskell programmer?
Read this: http://www.free-variable.org/2012/08/i-remember-the-time-before-monads/ by Paul Callaghan (you can skip down to the Monads section). It rings true.
In this way, I feel that Haskell is a bit like Perl. You can write lots of good, usable Perl without diving into the deep dark arts of Perl objects (bless them). And, you don't have to write a CPAN module to be a productive Perl programmer. The Perl community has accepted this (or at least seemed to). Do a google for Haskell and you'll find lots of computer science-y (aka research) blogs and perhaps a dozen or so explanations on why Monads are easy, how everyone uses them and then you feel dumb when you can't figure them out.
Haskell needs more Working Programmers. Erlang seems to have snagged them all and it was the Monad that scared them away.
P.S.
If you live in the DC area and want to meet with (at least one) Working Programmer, consider joining the DC Area Haskell Users Group and help make it a reality.
The audience would be, you guessed it, working programmers. Maybe even for working functional programmers. I already grok functional programming. I have been doing it for over a decade now. It is Haskell I'm trying to grok.
Sure, there is Real World Haskell, and it is great. But, it is also getting dated and perhaps the pacing is a bit too iterative for my tastes. That is, they start off with sub-optimal (naive) solutions to problems and then (in later chapters) proceed to make them better and better. Too much reading!
As a working programmer, I tend to learn better by studying and stealing exemplars.
Maybe I want a cookbook. Or, perhaps, what I am really looking for is a book that recognizes that my first goal is to compose a working program. Of course, I want to understand why something works, but maybe, just maybe, I want to see something (anything) work first!
Should I feel ashamed that I still haven't mastered Monads? (Sure, I've used them, debug them and have even constructed a few, but I can't say yet that I have mastered them -- at least not the theory). Can I call myself a Haskell programmer?
Read this: http://www.free-variable.org/2012/08/i-remember-the-time-before-monads/ by Paul Callaghan (you can skip down to the Monads section). It rings true.
In this way, I feel that Haskell is a bit like Perl. You can write lots of good, usable Perl without diving into the deep dark arts of Perl objects (bless them). And, you don't have to write a CPAN module to be a productive Perl programmer. The Perl community has accepted this (or at least seemed to). Do a google for Haskell and you'll find lots of computer science-y (aka research) blogs and perhaps a dozen or so explanations on why Monads are easy, how everyone uses them and then you feel dumb when you can't figure them out.
Haskell needs more Working Programmers. Erlang seems to have snagged them all and it was the Monad that scared them away.
P.S.
If you live in the DC area and want to meet with (at least one) Working Programmer, consider joining the DC Area Haskell Users Group and help make it a reality.
Subscribe to:
Posts (Atom)