Styles of programming
Friday, 1 June 2007
(Sorry for blogging in too technical terms, I’ll clean this up when I have time later)
Sean McGrath suggests that the audience for computer programs should be people, not computers.
I was most struck by the reference comparing novel writing to diary writing. I would like to add a third style, screenplay writing. OO programming and in particular event-based-programming is most reminiscent of screenplay writing, where it is not possible to see what the linear story line is. With all the state being held in the class, it can get very difficult to decipher what is going on.
Imagine reading a book in three chapters that go like this:
Chapter 1 (Romeo)
when seeJulietMotionless: kills himself
when seeJulietOnTheBalconey: climbs in
....
Chapter 2 (Juliet)
when forcedToMarrySomeOneElse: ...
Chapter 3 (main)
while (nextEvent)
{
juliet.processEvent(nextEvent)
romeo.processEvent(nextEvent)
}
Activity diagrams can help somewhat, but this is usually done on the documentation side. How do programmers express the intention behind the original program when OO enforces separation of concern, but flow of control is effectively very hard to and express.
Things are coming a full circle of course.
- RhinoScript aims to make web programming simpler by making the program logic run linearly. In spite of the callbacks.
- Enumerators / co-routines is another technique available
Possible future evolution:
- RhinoScript for message queues - again the idea is to linearize the storyline
- RhinoScript for windows forms - this is a hard one. Everytime I read a convoluted VB program, it usually has to do with event based programming. The language of the future will provide native support for messaging between threads. for example, I would like to be able to write this without worrying about tying up the windows message loop.
cancelButton.enable(new CancelledEvent()) try { while (! object.doSomething1()) { object.doSomething2() : : : : : } catch (CancelledEvent e) { ... clean up ... } } - A story style of programming should give less concern to exceptional conditions. I haven’t used SmallTalk but my understanding is that it drops messages it doesn’t understand. Perhaps AOP can help here, by crosscutting exception handling into the code, or perhaps more intelligent editors can mask out exception handling so that the program flow can be better understood?
I dont’ believe declarative programming is going to solve this little problem. The problem is declarative programming.