haskell-ji

As a programmer, I find myself struggling with a lot of really mundane and stupid-looking issues like "how should I name my variables", or "should acronyms be kept upper case (XML), or smooshed down for easier CamelCasing (Xml)?" and finally "what order should my code go in?"

These questions do not so much keep me up and night, but cause me an inordinate amount of flip-flopping in my code. Not remembering my preference du jour, I'll sometimes do things four different ways in code and later on suffer because I forgot that in one bit of code, I had named something parseXML and in the other bit, I had named it xmlParse.

The good news is that things are settling down on at least one front. It seems that all the versions of Eric past and present are settling on a consensus on How To Lay Code Out. The result is a set of directional tips, akin to the kind of thing you learn when you are writing Chinese Hanzi (Japanese Kanji):

1. Types before code
2. High-level before low-level -- For example, generally using where instead of let...in, but also "higher-level" functions first, "detail" functions later
3. Input before output -- It's not that this was ever up for debate, it's just that sometimes, I'll write it the other way without realising that I'm doing it.
4. Odds and ends last -- At the very end of my code: an odds-and-ends section for all those little snippets of code you copy around but are that too small to justify making a library, e.g.

   buckets :: Ord b => (a -> b) -> [a] -> [ (b,[a]) ]
   buckets f = map (\xs -> (f (head xs), xs))
           . groupBy ((==) `on` f)
           . sortBy (compare `on` f)

   Do you have an odds-and-ends.hs file on your computer?
   

Notice that the tips are not always compatible with each other, but they do sort of point in the same general direction.

Phew, I'm glad I'm starting to get at least this bit sorted. I really hope it reduces the amount of pointless erician flip-flopping. It's no big deal -- civilisation does not collapse because of inconsistent case conventions -- but it is a nuisance. This kind of thing is on the order of silly American-style dates vs. European-style dates causing confusion, where we could all just be using International yyyy-mm-dd dates, and while we're at it, 24 hour time, the metric system and A4 paper...

As a programmer, I find myself struggling with a lot of really mundane and stupid-looking issues like "how should I name my variables", or "should acronyms be kept upper case (XML), or smooshed down for easier CamelCasing (Xml)?" and finally "what order should my code go in?"

These questions do not so much keep me up and night, but cause me an inordinate amount of flip-flopping in my code. Not remembering my preference du jour, I'll sometimes do things four different ways in code and later on suffer because I forgot that in one bit of code, I had named something parseXML and in the other bit, I had named it xmlParse.

The good news is that things are settling down on at least one front. It seems that all the versions of Eric past and present are settling on a consensus on How To Lay Code Out. The result is a set of directional tips, akin to the kind of thing you learn when you are writing Chinese Hanzi (Japanese Kanji):

1. Types before code
2. High-level before low-level -- For example, generally using where instead of let...in, but also "higher-level" functions first, "detail" functions later
3. Input before output -- It's not that this was ever up for debate, it's just that sometimes, I'll write it the other way without realising that I'm doing it.
4. Odds and ends last -- At the very end of my code: an odds-and-ends section for all those little snippets of code you copy around but are that too small to justify making a library, e.g.

   buckets :: Ord b => (a -> b) -> [a] -> [ (b,[a]) ]
   buckets f = map (\xs -> (f (head xs), xs))
           . groupBy ((==) `on` f)
           . sortBy (compare `on` f)

   Do you have an odds-and-ends.hs file on your computer?
   

Notice that the tips are not always compatible with each other, but they do sort of point in the same general direction.

Phew, I'm glad I'm starting to get at least this bit sorted. I really hope it reduces the amount of pointless erician flip-flopping. It's no big deal -- civilisation does not collapse because of inconsistent case conventions -- but it is a nuisance. This kind of thing is on the order of silly American-style dates vs. European-style dates causing confusion, where we could all just be using International yyyy-mm-dd dates, and while we're at it, 24 hour time, the metric system and A4 paper...

haskell-ji

fold diagram revisited?

z
|
f----1----f
|    :    |
f----2----f
|    :    |
f----3----f
|    :    |
f----4----f
|    :    |
f----5----f
     :    |
     []   z

z
|
f----1----f
|    :    |
f----2----f
|    :    |
f----3----f
|    :    |
f----4----f
|    :    |
f----5----f
     :    |
     []   z

fold diagram revisited?

riot is almost a Haskell mail client

In case anybody wanted to write a mail client in Haskell, I should point out that Tuomov's riot (Riot is an Information Organisation Tool) outliner

• provides a sort of mutt-like user interface and
  
• stores its outlines as mailboxes (using in-reply-to to treat outline ancestry as thread ancestry).

So that's some of the work done for you :-)

In case anybody wanted to write a mail client in Haskell, I should point out that Tuomov's riot (Riot is an Information Organisation Tool) outliner

• provides a sort of mutt-like user interface and
  
• stores its outlines as mailboxes (using in-reply-to to treat outline ancestry as thread ancestry).

So that's some of the work done for you :-)

riot is almost a Haskell mail client

iterative committing

A few weeks ago, I saw this interesting complaint about distributed revision control advocacy:

But really, to read some of these articles, you'd think 99.9% of OSS contributions come from people who live on planes, only get 10% uptime on their broadband at home, and are incapable of spending the five minutes required to install something like Subversion locally for use with side projects.

This particular complaint resonated with me because I've always had a slight feeling that all this talk of airplanes and intermittent online access is missing the point.

I think what would help these discussions is to introduce the idea that there are really two ways to be disconnected: the involuntary way that most people talk about, and the voluntary way which is the really interesting one.

To be involuntarily disconnected is to be literally or technically offline. The universe prevents you from phoning home because it broke your wifi card or plunked you deep in an Amazonian rain forest. True, a distributed revision control system lets you continue hacking in the face of such adversity; but this fact isn't very convincing to some folks who are used to centralised revision control. How often in today's world are you really involuntarily offline? The trick is that sometimes your disconnectedness is entirely voluntarily. I don't really mean that in the sense of unplugging your cable modem and calling a moratorium on network access for the day. The minute you want to commit to a server and can't because of missing network access, you are offline involuntarily, even if this came as the result of a voluntary decision.

What I mean is that distributed revision control allows you to have pockets of deliberate disconnectedness from your peers. You want to work on something in little bits and pieces, you want to version control your work in progress, but you don't want to inflict your uncompleted work on your friends. A distributed VCS gives you a chance to step back for a moment and continue working with the benefit of version control. There are two alternatives to stepping back, neither of which are really acceptable. The first is to go ahead and commit your stuff with wild abandon, the consequences of which being that you pollute the change history with unfinished work and make life potentially difficult for your friends. The second alternative is NOT to commit your stuff at all, the consequences of which being that you lose the ability to track and log your your work as you go along.

A distributed revision control system gives you the choice of iterative committing. It doesn't really matter if you are online or offline actually. Sometimes you just want to commit something for your own sake and only later decide if the commits should be shared with the main repository or not. In the meantime you can choose to go back, undo a commit, redo a commit, undo all your intermediary commits and lump them all into one big commit, update from the main repository and then rework your commit in the new context. These are the choices that a distributed revision control system offers.

It's heartening to see that the idea of using a distributed VCS is catching on, that people are starting to adopt the likes of darcs, git, mercurial and bzr for their work. It means that the joy of iterative committing is spreading. Of course, I am partial to one of these systems in particular. Perhaps in a future article, I can describe what I think is the essential difference between darcs and our estimable competitors. I think I will call it iterative merging.

Happy committing in the meantime!

A few weeks ago, I saw this interesting complaint about distributed revision control advocacy:

But really, to read some of these articles, you'd think 99.9% of OSS contributions come from people who live on planes, only get 10% uptime on their broadband at home, and are incapable of spending the five minutes required to install something like Subversion locally for use with side projects.

This particular complaint resonated with me because I've always had a slight feeling that all this talk of airplanes and intermittent online access is missing the point.

I think what would help these discussions is to introduce the idea that there are really two ways to be disconnected: the involuntary way that most people talk about, and the voluntary way which is the really interesting one.

To be involuntarily disconnected is to be literally or technically offline. The universe prevents you from phoning home because it broke your wifi card or plunked you deep in an Amazonian rain forest. True, a distributed revision control system lets you continue hacking in the face of such adversity; but this fact isn't very convincing to some folks who are used to centralised revision control. How often in today's world are you really involuntarily offline? The trick is that sometimes your disconnectedness is entirely voluntarily. I don't really mean that in the sense of unplugging your cable modem and calling a moratorium on network access for the day. The minute you want to commit to a server and can't because of missing network access, you are offline involuntarily, even if this came as the result of a voluntary decision.

What I mean is that distributed revision control allows you to have pockets of deliberate disconnectedness from your peers. You want to work on something in little bits and pieces, you want to version control your work in progress, but you don't want to inflict your uncompleted work on your friends. A distributed VCS gives you a chance to step back for a moment and continue working with the benefit of version control. There are two alternatives to stepping back, neither of which are really acceptable. The first is to go ahead and commit your stuff with wild abandon, the consequences of which being that you pollute the change history with unfinished work and make life potentially difficult for your friends. The second alternative is NOT to commit your stuff at all, the consequences of which being that you lose the ability to track and log your your work as you go along.

A distributed revision control system gives you the choice of iterative committing. It doesn't really matter if you are online or offline actually. Sometimes you just want to commit something for your own sake and only later decide if the commits should be shared with the main repository or not. In the meantime you can choose to go back, undo a commit, redo a commit, undo all your intermediary commits and lump them all into one big commit, update from the main repository and then rework your commit in the new context. These are the choices that a distributed revision control system offers.

It's heartening to see that the idea of using a distributed VCS is catching on, that people are starting to adopt the likes of darcs, git, mercurial and bzr for their work. It means that the joy of iterative committing is spreading. Of course, I am partial to one of these systems in particular. Perhaps in a future article, I can describe what I think is the essential difference between darcs and our estimable competitors. I think I will call it iterative merging.

Happy committing in the meantime!

iterative committing

timesheet helper

I wish there was a simple, no-fuss command line timesheet helper in the spirit of cabal-install and twidge. The kind of interactions I imagine are:

09:00 # timesheet start work draft 3 of the paper
10:00 # timesheet start darcs dwn
10:45 # timesheet start work regression test for ppack
12:00 # timesheet stop
12:30 # timesheet start darcs roadmap
13:15 # timesheet start work regression test for ppack
16:30 # timesheet start darcs patch review
17:00 # timesheet start work meeting
18:30 # timesheet stop

18:30 # timesheet summary
Today 2008-11-07
-------------------
darcs: 2h
work: 6h 30m

18:30 # timesheet details
Today 2008-11-07
-------------------
darcs: 2h
* dwn: 30 m
* roadmap: 45m
* patch review: 45m
work: 6h 30m
* draft 3 of the paper: 1h
* regression test for ppack: 4h
* meeting: 1h 30m

(Note the assumption here that you are never working on two tasks at the same time; clocking in to a new task automatically clocks you out of an old one). The key to this application is simplicity. In its present state, gpe-timesheet (0.32) uses too many confirmation dialogues to be really useful. Loggr is nice and simple, but if I close my browser window, I lose track of things. Another property I would like to have is for the application to be forgiving to mistakes. If it stored timesheets in a simple text format, for example, I could just edit out my mistakes in a text-editor.

For Haskellers, I also wish that we had a common library for writing command line applications with subcommands and switches. This would be useful for darcs, cabal-install, twidge, this timesheet application, and more.

I wish there was a simple, no-fuss command line timesheet helper in the spirit of cabal-install and twidge. The kind of interactions I imagine are:

09:00 # timesheet start work draft 3 of the paper
10:00 # timesheet start darcs dwn
10:45 # timesheet start work regression test for ppack
12:00 # timesheet stop
12:30 # timesheet start darcs roadmap
13:15 # timesheet start work regression test for ppack
16:30 # timesheet start darcs patch review
17:00 # timesheet start work meeting
18:30 # timesheet stop

18:30 # timesheet summary
Today 2008-11-07
-------------------
darcs: 2h
work: 6h 30m

18:30 # timesheet details
Today 2008-11-07
-------------------
darcs: 2h
* dwn: 30 m
* roadmap: 45m
* patch review: 45m
work: 6h 30m
* draft 3 of the paper: 1h
* regression test for ppack: 4h
* meeting: 1h 30m

(Note the assumption here that you are never working on two tasks at the same time; clocking in to a new task automatically clocks you out of an old one). The key to this application is simplicity. In its present state, gpe-timesheet (0.32) uses too many confirmation dialogues to be really useful. Loggr is nice and simple, but if I close my browser window, I lose track of things. Another property I would like to have is for the application to be forgiving to mistakes. If it stored timesheets in a simple text format, for example, I could just edit out my mistakes in a text-editor.

For Haskellers, I also wish that we had a common library for writing command line applications with subcommands and switches. This would be useful for darcs, cabal-install, twidge, this timesheet application, and more.

timesheet helper

official darcs blog!

Darcs weekly news has moved! It will now be hosted on the official darcs blog at http://blog.darcs.net.

The latest entry, darcs weekly news #10 has been posted on the new blog.

Darcs weekly news has moved! It will now be hosted on the official darcs blog at http://blog.darcs.net.

The latest entry, darcs weekly news #10 has been posted on the new blog.

official darcs blog!

darcs hacking sprint - Team Brighton Day 2

Ganesh and Ian, slurpies and curl


More Important Looking Things for the whiteboard (faster slurpies, courtesy of Ganesh)


Team Brighton. (having worked out the auto-timer on Eric's camera)


Sprint on!


Sprint wrap-up later...

Ganesh and Ian, slurpies and curl


More Important Looking Things for the whiteboard (faster slurpies, courtesy of Ganesh)


Team Brighton. (having worked out the auto-timer on Eric's camera)


Sprint on!


Sprint wrap-up later...

darcs hacking sprint - Team Brighton Day 2