These are a few of our favourite things …

I have the pleasure of convening the module on “Developing as a Researcher in Higher Education” that is part of Kent's qualification for new staff. In the first session participants each gave a one minute presentation – excellent timekeeping, incidentally – on their research. It's fantastic to hear all these diverse topics, and the enthusiasm of the people working on them. Here's a selection

• how does stand-up comedy work?
• how to make a performance of taste (of wine)?
• how is performance affected by place 
• architecture (practitioner)
• how to capture what clients of software houses really want?
• how to improve the efficiency of wireless networks … adaptively
• what is the role of language in social work?
• micro-meteorites (≦2mm) … not least, how on earth do you find them?
• theoretical physics
• Bayesian decisions in mathematics
• theoretical syntax, and the disappearance of if/whether in Icelandic
• a new theoretical / jurisprudential platform for critical legal studies
• torture and the state, aboriginal art and constitutionalism
• use of cool materials (in architecture)
• what makes an action successful?
• Lea Valley Drift: bringing the immediately available city back into prominence
• Gender in International Cooperation
• Is there a pool of talented people being lost [to HE]?
• Sustainability Research in Business Practice and CSR
• Modelling faking in high stakes self-assessments and biases in assessments of others
• Napoleon, The Cardinal and the Prostitute
• Sociology of the Professions - particular focus is on equality, diversity and inclusion
• Political psychology, specifically: self-esteem and narcissism
• the brain basis of remembering

The only disappointing thing is that we don't really have time to talk about them in the sessions for the course.

REF Factory

Writing the REF submission for Computing at Kent is drawing to a close, agonisingly slowly, but there we are … Now is the time to capture any insights about how it might have been done, and how it could be done next time (I'm not volunteering!). I'll write this now, and then finish revising my first publication for REF 2020: final copy is due to be with the ACM in a couple of days' time.

Kent made the decision to hold a full-scale pilot in 2012, so that we had been through the process of writing all the narrative sections, the impact case studies, and – in the case of computing and a few others – the 100 words accompanying each output, about 120 for us. This had some strong points, and it was particularly good in giving us a deadline by which we had to have written a first draft of everything, so that the last year has been a process of refining those drafts.

On reflection, though, it has – at least for me – meant that we (or I) have conflated two quite different processes:

• the process of marshalling the arguments, information and data, and 
• the process of writing that within the constraints of the 100 word limit, or the various templates.

I did have long drafts – essentially compilations of data and info – prior to the pilot, but since then, we've been working on drafts in the form of the final submission. What I'd do if we were doing this again is to keep the separation between the two until much later in the process, and work on the raw information and data until a much later point. Doing that means that we're able to get an overall view of all that might be pertinent, rather than selecting, and then re-selecting, which is what we've done. For example, I had included data on staff study leave in a draft of REF 5 in May, but that was removed in June, only to be re-introduced in November. 

The same applies to the 100 words, I think; a subject I discussed with another REF coordinator recently. Aiming to get all the pertinent information collected for each potential paper (with a few prompts about different kinds of info), and to keep that up to date and reviewed, would allow the final 100 words to be generated close to the deadline, rather than evolving over two years in many cases.

I realise that this may week be a case of the other person's grass always being greener, and that we would most likely find problems with this approach, but this is what I would try were I to do it again. In the case of the pilot submission, if we had to write it in that format, we should see it as a throw-away draft, and keep on marshalling until we write a new final draft from scratch.

Finally, the more I think about this, the more I think that this is very like a problem we come across in writing successful research grant applications. The most useful feedback on an application is at the stage where the ideas begin to be articulated clearly. One way of expressing this is as a “one pager” that summarises the essence of the ideas, the work packages, the methodology and the impact, all on one side of A4. As a reviewer it's possible to engage with this, and say “yes, but it would be so much better if you were to push it in this direction” – it's almost impossible to do this once it has been set in concrete in a complete application. In a roundabout way, that explains why I called this post “REF Factory” – Kent's well-regarded grant application training is called “Grants Factory”, a name coined by Andrew Derrington.

Is it viable or not? An exercise in estimation.

In the first year course at Kent, we're involving students in the Transformed by You competition set up by Kent Connects. The aim of this is to collect ideas for technology that can have a transformative effect on lives of people in Kent. Our students are working on a design exercise, but we've also used examples of this to talk about ethics: for example, what are the ethical questions raised by parents monitoring their children's movements, or employers keeping track of their employees?

Another theme of the course is to encourage students to estimate quantities: we started off trying to estimate the size of the lecture theatre, but concluded the session by trying to estimate the viability of three of the suggested projects:

• Live streaming of lectures onto the internet.
• An app to track buses in real time.
• An app to find the closest taxi for hire.

In thinking about this, we worked with a short set of prompts:

• Scope: University of Kent? Canterbury? Size? Coverage?
• What is needed (for it to operate)?
• Cost (above the software itself): capital / running? Income?
• Decision, with reasons.

The best solutions were definite: they fixed on a particular scenario, e.g. streaming lectures from the Canterbury campus at Kent, or the UniBus system of buses. Given that, making an assessment of what was needed - servers, webcams, GPS systems - followed, as did an estimate of costs, and then a justified decision: most of the well-documented solutions come in at about £10,000 capital costs, and perhaps £1,000 ongoing, leading to the decision that it is a viable proposal. Not all the solutions were as good as this.

One variation between solutions was scope: what can we take for granted, and what has to be supported explicitly? In the streaming example, do we have to pay for storage? for bandwidth? In the same example, would there be any income? [I think not!] We do record lectures, in fact, using Panopto, which gives us most of this functionality, but not in real time.

The bus example shows much more variability: fair enough, it's further away from people's experience. Even more so, the taxi example. The conclusion is that the bus app is viable, because the cost per GPS is small, and the number of buses constrained too; it clearly has a benefit, too. The taxi app is less clear: taxis belong to a number of companies, and without comprehensive sign up, it's less clear about the value. Is income going to be paid by taxi companies? Again, not clear.

The exercise was deliberately open-ended: perhaps too much so? The intended outcome is to give participants a mechanism for making rule of thumb estimates, when a reasoned estimate is better than a guess or a shrug of the shoulders. All part of being a professional. 

2001, 1968 and 2013 - reheating a blog post

I went to see 2001: A Space Odyssey one Saturday afternoon a few months ago, and drafted some notes: just found them again, so here goes …

First, all those childhood memories from when I first saw it. Was it really 1968, or a bit later? Whatever the case, I was a teenager coming to the end of a sci-fi infatuation. Despite moving on, we took for granted that by 2001 there would be moon bases, expeditions to Mars, and that space would be normalised.

Clarke and Kubrick tried so hard to make it as accurate as possible, and the wonderful HAL's legacy has a whole lot of stories about that. The most remarkable is of the two of them visiting Bell Labs and seeing hearing state-of-the-art speech synthesis: a computer sings "Daisy, Daisy" – just what HAL sings as he's being deconstructed by Dave. It's hard not to be moved by that.

The late 60s and 70s were a golden age for American film: 2001, Nashville, One Flew Over the Cuckoo's Nest, the Deer Hunter, and it's impossible to imagine that something like 2001 could be made now. Why?

First the speed of the thing: it's slow – with little dialogue – but the sound is so carefully done. Heavy breathing when Dave is in the spacesuit, some isolated conversations … and the music is only played on its own: you hear the music, and see how it works with the visuals: it's emphatically not used simply to pump up the adrenaline.

Then the visuals: remember then no one had even seen the earth from the moon (“earth rise”) when the film was made: it is mattes and models, but even though it's not photorealistic, it works. Way before CGI, but just as good!

HAL, as Stork suggests, is the real star of the film … one big brain, of course, and no PCs, but less anachronistic now (“internet of things”) than it was in 2001 itself.

And the actors? No famous lead players, but good old British character actors: Leonard Rossiter – Reggie Perrin – and Margaret Tyzack – Forsyte Saga – who also appears in A Clockwork Orange.

Of course, some things are “wrong”: there are no PCs, for instance, but the most noticeable is the prominent PAN AM logo on the space shuttle: Kubrick and Clarke were good on the science, but less on the economics …

From imperative to functional in Java 8: paper review

I have been writing functional programs for thirty years, first in KRC, then in Miranda, and more recently in Haskell and Erlang. In the past few years, though, something rather remarkable has been happening: the essentials of functional programming have been popping up in more “serious” mainstream languages: JavaScript, C#, C++ and now, with the advent of the 8th version of the standard, Java. What is this functional core that’s coming into these languages: the ability to compute functions as a part of the work of a program, and to pass these around as parameters or return values of other functions: closures as “first-class citizens” in Strachey’s words.

But why is this happening? As the authors of this fine paper explain, it is to exploit the parallelism that is now a feature of some many computing platforms, from smartphones and tablets, through laptops and desktops to servers and supercomputers. To give one example: mapping a function across a collection data structure is one of the key parallel patterns, providing the data analogue of a linear (control) pipeline.

Given the opportunity, how can we program using these new features? One possibility is to start from scratch with these new constructs, but a more attractive option is to refactor existing code to exploit these features: that is precisely the topic of this paper. The authors show how refactoring opportunities are identified, and what transformations need to be performed. Moreover, they anatomise some of the attendant difficulties: how are side-effects to be handled? how to deal with different scoping regimes between anonymous inner classes and closures? Their work is validated through a set of substantial case studies, and made available through the standard Net Beans distribution.

I would recommend this paper to anyone interested in exploiting the parallelism inherent in many standard programs, as well as anyone who would like to see a justification for machine-supported refactoring. Finally it is a remarkable vindication of getting students involved in research: two of the four authors took part as undergraduate summer interns.

This is a draft review for Computing Reviews of Crossing the Gap from Imperative to Functional Programming through Refactoring.

Computing trending at Kent

I was lucky enough to go to two quite different events at Kent today that would have been inconceivable just two years ago. This morning I spent time at the #kenthack and this afternoon at a Digital Humanities event … quite different, but both lots of fun.

The #kenthack was the brainchild of some computer science students, getting together collectively to hack out some new ideas, sustained by a heady mixture of sugar, saturated fats and salt (OK, sweets and doritos).

Nice ideas going around included a version of the old "helicopters" game, with a motion sensitive interface. Sorry I don't remember the name of the particular piece of kit, which is able to sense all 10 fingers and thumbs, up to about 50cm away, based on 3 IR sensors and an ARM chip. More info about the outcomes at www.kenthack.com. Great atmosphere, and refreshing to see people getting together to have fun coding.

This afternoon to the new "crit space" in the school of architecture for a digital humanities event, bringing together academics from architecture, history, english, archaeology, film studies, linguistics to talk about their research and teaching activities informed and and mediated by digital technologies.

Exciting to hear about what's going on. Highlights included

• using network visualisation of word counts and proximities to understand documents;
• how software has revolutionised the practice of linguistic analysis of real speech, and the repercussions for speech therapy;
• understanding the mental mapping and conceptualisation of space, time and software behaviour in game development software.

The talks were good, but as always, discussions over coffee were more fruitful. I hope we'll be able to build some links with the last project … exciting things to do with new APIs, and also with data mining of "big data" from programmers of different kinds. Also able to catch up with learning support staff from UELT to share our enthusiasm for panopto, but at the same time to bemoan the fact that we're unable to share any of our exciting teaching and learning initiatives and materials outside the university. Grr.

Commercial users of functional programming: call for tutorials

Commercial Users of Functional Programming (CUFP) is an annual meeting co-located with the International Conference on Functional Programming which this year will take place in Boston, MA, USA on 22-24 September 2013. CUFP aims to bridge the gap between academia and users applying functional programming in practice. CUFP provides high-quality practical tutorials covering state-of-the-art techniques and tools for functional programming.

We are seeking proposals for half-day tutorials to be presented during the first two days of the meeting, 22 and 23 September, with the main CUFP session on 24 September.

Among the suggested topics for tutorials are:

- Introductions to functional programming languages: in the past we have had introductions to Clojure, Erlang, F#, Haskell, ML, OCaml, Scala, Scheme and others.

- Applying functional programming in particular areas, including the web, high-performance computing, finance.

- Tools and techniques supporting state of the art functional programming.

Tutorial proposals should address the following points

- Title
- Abstract (about 100 words)
- Goals: by the end of this tutorial you will be able to …
- Intended audience: e.g. beginners, those with a working knowledge of X, …
- Infrastructure required: For example,
    - will participants need access to a particular system?
    - can they be expected to have this on a laptop, or does it need to be provided by the meeting?

and should be sent by email to

- Francesco Cesarini: francesco@erlang-solutions.com
- Simon Thompson: S.J.Thompson@kent.ac.uk

by 31 March 2013.