Editorial: Just a minute

The BBC Radio 4 comedy ‘Just a minute’ has been running since 1967. For those unfamiliar with it, the contestants are tasked to speak for one minute on a subject without hesitation, deviation or repetition. Points are awarded for speaking when the minute whistle blows, or for correctly spotting a failure to comply with the rules. “What does this have to do with an editorial for Overload ?” I hear you ask. A good question. Having recently stopped commuting to work I am now at home in time to catch some of the 18:30 broadcasts of Radio 4 comedy programmes. Previously I could find them on the BBC iPlayer, but I prefer the set time and structure of certain little rituals. Having an editorial at the front of Overload is presumably a ritual some readers pine for, though as ever I hope I may be forgiven for deviating somewhat, sometimes repeating myself and definitely hesitating as I try to gather my thoughts every two months and yet again fail to write an editorial. Perhaps you will award me the occasional point for making you chuckle from time to time though.

Constraints, such as banning hesitation, repetition, or deviation might seem to make things harder; however, this can actually aid creativity. For example, writing a short story for a competition with a strict limit on the number of words, or filling in a personal statement for a role with a strict limit on the number of characters (spaces did count apparently) gives a structure and something to aim for. Adding a deadline may also provide some impetus. Constraints and structure can be a good thing. Writing a short story is a vague requirement, whereas writing one in under 500 words, using ‘elephant’, ‘Plank constant’ and ‘denial of service attack’ might focus the mind enough to get the imagination firing.

If you are self-employed or conducting long term research, perhaps a PhD, then a change from set working hours and a list of tasks to complete, or from timetabled lectures and weekly homework can be a shock to the system. On paper, it might sound liberating. Just imagine being free to do whatever you want, when you feel like it. In practice, a high level of discipline is required to ensure you do not get distracted, say by listening to comedy programs or doing a random walk through the internet, and instead keep focussed on the task in hand. Finding some structure, or setting a timetable for yourself, can be useful in such circumstances. Now working with a (very) small start-up, I have found it useful to start the day with a coffee, of course, and to use the agile style daily stand-up format, just briefly. What were we doing? What do we plan to do today? What’s getting in the way? It is far too easy to start by looking at emails and so on, only to find two hours have vanished once some emails have been read, others deleted, links to articles have been followed, proclaiming exciting new programming languages and tools, surveys have sucked you in, and other distractions, or deviations, if you will, have stolen your time. What was I saying? Oh yes. Try to stay on target in the face of distractions and lack of formal structure. It is all too easy to be tempted to stay up far too late if you are in the middle of something interesting, without the need to be in the office by 9am sharp the next day. As a student, I frequently pulled all-nighters. I love having an interesting problem to get my teeth into, and there is usually no one much around to distract you in the middle of the night. However, irregular sleep patterns are not a good idea. I have personally found it really important to try to keep regular bed times, avoiding reading maths books before putting the light out. If I don’t, then I find it harder to get a proper night’s sleep. The interesting problem will still be there in the morning. If you are pulling an all-nighter for work, the bug will still be there in the morning. In both cases, you might be more effective after a good night’s sleep. It seems sleep/wake homeostasis and the circadian biological clock are important [ Body Clock ]. There have been suggestions that irregular sleeping patterns, including shift work, can lead to health problems. J Harrington provides an overview in the BMJ’s Occupational and Environmental Medicine magazine [ Harrington ].

As programmers, hopefully avoiding burning the midnight oil, we schedule many things, often automatically. Aside from keeping meetings in regular timeslots, to avoid the disruption of flash-mob style meetings intruding on moments when you were trying to concentrate on a complex problem, we may schedule server reboots, or scripts to run when code is committed, from checking it compiles to checking tests pass or perhaps to deployment if everything is ok. We may automatically, or manually, check that coding standards, another form of constraint, have been adhered to. Hopefully the occasional deviation will be allowed, otherwise developers have a tendency to find back doors and workarounds where officious gatekeepers are perceived to stand in the way of productivity. A known timetable, such as a linux startup sequence; bios, mbr, grub, kernel, init then runlevel, means we know what will happen in which order. This constraint makes it easy to set things up and troubleshoot if required. Every linux installation doing things in a unique and unpredictable order would cause chaos.

A programming language could be seen as a sequence of constraints. Either a compiler or interpreter will enforce the syntax of the language and refuse to do any more if you try the coding equivalent of free-form jazz where a type-name was expected. Some languages are stricter than others. The Haskell type system is strongly revered, purporting to be able to give you code that is correct, rather than defensive. Originally introduced to solve problems concerning to equality and other numeric operations, its powerful type classes now allow reasoning about correctness [ Hudak et al ]. At the extreme, some languages, such as Prolog, are purely based on constraints. Where an imperative approach would give step by step instructions and a declarative approach would declare what must be done, logic or constraint programming states constraints, or facts or rules, a solution must satisfy. This immediately lends itself to word puzzles like:

     SEND
  +  MORE
  -------
  = MONEY

where each unique letter corresponds to a unique digit, and the given sum is correct. Prolog and variants have successfully been used for expert systems and natural language programming (NLP). GOLEM is an expert system built on Prolog [ Muggleton ] which combines examples with rules supplied by experts that are combined into hypotheses. In turn these can then be transformed into rules, when validated against further data. NLP uses include representing a semantic web [ Wielemaker et al ], to combine disparate data from various sources allowing a ‘semantic search’ to find potentially related entries. Constraint programming can also be applied to planning problems readily. The constraints in these examples all form the basis of a problem that the language will attempt to solve. I suspect logic programming is rather more niche than functional programming. More generally, this little diversion has shown constraints can solve problems.

Forays into niche languages aside, unfamiliarity can be exciting and uncomfortable in varying measures. A holiday or a new job will offer novelty but the potential culture shock as you are re-orientated in unusual places is a reminder that the same-old run-of-the-mill routine had its benefits. Many C++ programmers, or users of any compiled language, find dynamic languages unnatural initially. Similarly going from the constraint of a strongly typed language to duck typing can be confusing. It is interesting to note that more freedom often tends to coincide with fear, to begin with. Eventually people tend to embrace these brave new worlds. As a kitten constantly looks out of the window, seemingly longing to explore, and then recoils in horror when the back door is finally opened after a few weeks, the constraints that we are used to provide a familiarity and sense of safety. This disruption, whether it be changing programming languages or paradigms, operating systems or going outside for the first time ever is a thing of note. Constraints help us to be creative, by knowing what to expect, catching mistakes early, communicating clearly, even if hesitating when we forget the exact keyword or syntax, but also can inspire deviation or disruption. What if C++ (03) didn’t require so much boilerplate just to output the contents of a vector? What if you introduced structure, via functions or submodules, to a coding language rather than having to trace goto s around to see what happened when? What if everything was an object? Maybe that’s a step too far. What if you didn’t use braces to delineate blocks, but used spacing instead, perhaps inventing a new language in the process? Constraints can help creativity, but so can questioning them.

The start-up culture has readily adopted the buzz-word ‘disruptive’. Clayton Christensen [ Christensen ] coined the phrase ‘disruptive innovation’ in 1995 to describe small new companies being able to release new services and products far more quickly than established companies thereby being able to take hold of the so-called ‘bottom of the market’ and eventually stir things up for the ‘big boys’. We see this happening with apps on mobile phones to book taxis, rather than hailing traditional Black Cabs, with noise about crypto-currencies stealing a market share off big banks, Amazon starting to threaten bookshops, and so on. Things do change and often small companies do disrupt the normal course of things with innovative ideas. I notice people are tending to just say ‘disruptive‘ rather than using the whole phrase ‘disruptive innovation’. Something got lost in the meme sharing. Something like the punk anthem ‘Smash it up’ [ The Damned ] conjures up the sense of pure disruption for disruption's sake. Disruptive innovation, on the other hand, may create new markets, or sustain existing products and services, by making them more efficient.

Sometimes rebellion for rebellion’s sake does hail a new beginning. Punk was a kick against the hippie movement or prog rock, giving short simple songs anyone could yell along to, or write themselves. It’s tempting to draw analogies between the punk rock movement and disruptive start-ups, though like most ideas it’s been done before. The Think Jar Collective offers such a parallel and reminds us that for all its disruption:

The punk movement and the music ate itself within a few years of its adrenaline and narcotic inspired inception. But punk morphed itself into new wave and gradually added itself into the mainstream of music.[ TJC ]

Uber and Amazon and the like are now becoming mainstream. New things do sometimes become old-hat. The abnormal might morph the world around itself until it becomes the new normal. This usually happens because people like the new ideas, rather than through clever marketing schemes.

References

[Body Clock] https://sleepfoundation.org/sleep-topics/sleep-drive-and-your-body-clock

[Christensen] http://www.claytonchristensen.com/key-concepts/

[The Damned] https://www.youtube.com/watch?v=YZ76LC_l8yk

[Harrington] http://oem.bmj.com/content/58/1/68.full

[Hudak et al ] ‘A History of Haskell: Being Lazy With Class’ Paul Hudak, John Hughes, Simon Peyton Jones, Philip Wadler. Proceedings of the third ACM SIGPLAN conference on History of programming languages , Pages 12-1–12-55, 2007 http://dl.acm.org/citation.cfm?id=1238856

[Muggleton] S. Muggleton and C. Feng, ‘Efficient induction of logic programs’, Inductive Logic Programming , Academic Press, pages 281–297, 1992.

[TJC] http://thinkjarcollective.com/articles/punk-rock-innovation/

[Wielemaker et al ] ‘Using Prolog as the fundament for applications on the semantic web’ Jan Wielemaker , Michiel Hildebrand2 , and Jacco van Ossenbruggen in Proceedings of the 2nd Workshop on Applicatiions of Logic Programming and to the web, Semantic Web and Semantic Web Services , p84–98, 2007 http://ftp.informatik.rwth-aachen.de/Publications/CEUR-WS/Vol-287/paper_1.pdf