A Few Thoughts on the Readability of Code
I've been doing some code lately involving scheduling jobs using Akka. The Typesafe guys did a smart thing and built a simple scheduler into the ActorSystem, so unlike EJB, which took what a decade to get to where you could get a timer? But it does seem that the Scheduler in Akka is missing a pretty crucial feature: the D from ACID: Durability. If I want my Actor notified every hour, and then the ActorSystem is restarted, pretty sure the notifications are gone as well. There are some notes for implementers so it would be pretty easy to add.
Anyway, I was thinking about schedules the other day. If you were going to pick one aspect of programming that typifies the massively anti-linguistic bent of most programmers, you‘d be hard pressed to find a better example than the persistence of CRON‘s scheduling short hand. It blows my mind that this is still pretty much the dominant way to schedule things. You know, you‘ve seen it before, usually looking like this (this is from the documentation from Quartz, the feature-less dominant scheduler in the Java world):
So cron expressions can be as simple as this: “* “* “* “* ? “* or more complex, like this: “0/5 14,18,3–39,52 * ? JAN,MAR,SEP MON-FRI 2002–2010”
(How ironic is it that Textile, my way of doing syntactical shortcuts on here, is so stupid I can‘t get it to show the CRON syntax?? Hilarious… Disregard the quotes in there, without them the Textism plugin gets all befuddled…)
Could I figure out what these are trying to say? Yes. Does it make me feel good when I do? No. Frankly, if it makes you feel good, and you are a programmer, please do us all a favor and put yourself in a burlap sack and jump in the nearest river.
So I was thinking about readability and thought ‘what could be easier than something like ‘scraper.job on Saturday at 10:30‘? Nothing. Then I got excited. I thought, to handle repeats, we can stay within the existing linguistic conventions: just add an s to the day of the week. Programmers yap all the time about favoring convention over configuration. Folks, the largest receptacle of convention we have, as Chomsky et al have proven, is language.
At first, I built my scheduling request message with a Static Builder (a la Bloch) inside, and made it so I could give it a run time, and it would go ahead and schedule the next one, so on(Saturday).hour(10).minutes(30).build(). But then I realized, wait, move the date construction logic into my DateBuilder class and then just chain the two builders together.
Ultimately, readability in code occurs on two layers. Making the code so that programmers can read it is a different problem than making it easy for people to pickup (learn) a linguistic convention and feel comfortable with it. In the case of the former, Builders greatly increase readability of code, as do the labeled parameters in Objective C. But going beyond that ends up being kind of clunky. On the other hand, we have all made use of classes that have parse methods. Those make perfect sense to me. As I was doing this Builder exercise, I was thinking ‘might be a good idea to have the Director offer the parsing services.‘ Typically, the role of the Director is to merely hide the details of how the sausage is made. But isn‘t that precisely what we are after when we ask for greater readability? Clearly the CRON guys are after the usual goal: reduce typing and try and cover every single possible case. (It‘s like a programmer version of name that tune.) But that ends up being pretty silly because it also presumes that the scheduler doesn‘t have syntactic or contextual needs of its own. In fact, consider the idea of scheduling something around a plant. You might want to introduce other scheduling concepts, like sunrise and sunset, or opening time and closing time. In the Builder approach, you would have a stock time builder, then you would make different Directors that can support not only other syntactical convention, but perhaps even additional concepts like these, that are computed (sunrise/sunset) or looked up (open/close times).
While I was thinking about this, I saw this link on Twitter this morning: Programming About Dumbing Itself Down . It's so hard to argue with this. Programming should be about making things easier, but so that we can do more complex things not so we can get it down to the point where an ape can make messes faster.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)