Thoughts on F Sharp

F# is an attempt to bring a functional programming language (based on ML) to the .NET framework. It seems to have Microsoft blessing, with support out of the box in Visual Studio 2015 (now free for personal use). I thought I’d give some initial impressions of the language, mainly coming from a Haskell perspective. I am happy to be corrected, as I’m still quite new to the language.

I quite like F#, but the main impression I get is that whatever I want to do, there’s two or more separate ways to do it, and no obvious way to choose between them. F# is, very clearly, the result of stitching together two programming systems: the Object-Oriented Programming [OOP] of .NET and the Functional Programming [FP] of the ML language. Much like Java post-generics (with its “int” and “Integer”) or Windows 8 with its tablets-meets-desktop, systems like this often have quite glaring joins. And especially if you come from neither a .NET nor an ML background, you are just left a bit bamboozled as to which you should be using. Where there is a reasonable set of rules to choose between int and Integer in Java, in F# it often just seems to come down to preference or convention. This multiplicity of approaches is especially evident in the type system.


Let’s start with lists. You can specify a list’s type in F# using the postfix syntax “int list” or the prefix syntax “List<int>”. Both mean the same thing and there’s no obvious reason to choose one or the other (this StackOverflow answer mentions a suggestion to use prefix for all except four types, but with no clear justification). Lists have some properties which can be accessed directly, like “myList.Head”. But there’s also a function you can call using “List.head myList” for the same purpose. The property is probably an OOP thing, the function is FP, but as a programmer who just wants to write some code, what’s the difference? The dividing line seems to vary depending on the origin of what you’re using: a C# class is going to have lots of member functions, an F# library will have lots of external functions, and your code will seemingly always end up with a mess of the two. When writing your own code, it’s often not clear which way you should lean, either.

The Class System

F# allows you to write classes which override other .NET classes, which makes for a potentially great marriage of functional programming with existing [OOP] .NET libraries. In the classes you define in F#, there’s multiple ways to define fields:

type MyClass2 =
  let readOnlyPrivateValue = 1
  let mutable readWritePrivateValue = 2
  [<DefaultValue>] val mutable private readWritePrivateValueNoInit : int
  [<DefaultValue>] val mutable readWritePublicValueNoInit : int
  member this.ReadOnlyPublicValue = 5
  member private this.ReadOnlyPrivateValue = 6
  member val ReadWritePublicValue = 7 with get, set
  member val private ReadWritePrivateValue = 8 with get, set

This StackOverflow answer suggests when to use each, but I was still left puzzled. I’m slowly getting the hang of it: let when you have an initial value, val when you don’t, mutable when you want to change it, but I’m not much wiser as to when to use member vs let/val — are they semantically equivalent if I’m not customising the get/set? For example, I found this code in another StackOverflow answer which does a “memberwise clone”. Will that clone my “let mutable” fields or just my “member” fields?

To define a member method you use a similar member syntax, but with brackets for any parameters. You also need an object reference, which you can see is also required for some field declarations but not others. It took me a while to understand the syntax:

type MyClass() =
  member MyClass.GetHundredA() = 100
  member x.GetHundredB() = 100
  member y.GetHundredC() = 100
  member whateveryoulikeiguess.GetHundredD() = 100

I thought the part before the dot was some reference to the class I was making the method for, hence I ended up using the class name (like the first member, above) because that made sense to me, and it compiled fine (not sure it should!). I saw people using “x” instead and thought it was a keyword. It turns out the first part, before the dot, is a name declaration for the “this” concept. So in the last method above, “whateveryoulikeiguess” defines a name to refer to what you would use “this” for in Java or C++. I’m not sure yet why they didn’t just swallow a keyword and always use “this”, and it still strikes me as a pretty weird syntax.

Data kinds

There’s many ways to define a data structure with a couple of members. If you want an int and string value pair, you could use:

type aPair = int * string
type anADT = Combo of int * string
type aRecord = {theInt : int; theString : string}
type aClass(i : int, s : string) =
  member this.TheInt = i
  member this.TheString =s
type aStruct =
      val theInt : int
      val theString: string

Quite the variety! Sometimes there’s a good reason to choose one or the other, but quite often you just stick your finger in the air and guess. (I tend towards the second one because it’s what I’d use in Haskell, but I suspect the third is the best choice.) Suddenly Java with its everything-is-a-class philosophy seems sensibly restrained.

Ignorance is Dangerous Bliss

F# has a feature shared with Haskell where it tries to warn you if you are discarding a return value. Let’s say you have some function to write a file, which takes a path, some content and returns a boolean for success:

// F#:
let writeFile (path : string) (content : string) : bool = ...
-- Haskell:
writeFile :: String -> String -> IO Bool

If you call this function without assigning the return value or otherwise using it, F# and Haskell will both give you a warning (I think Haskell may require a compiler flag to turn the warning on) that the return value is discarded:

// F#, gives warning:
writeFile "C:/log.txt" "Bad stuff happened" 
-- Haskell, gives warning:
writeFile "C:/log.txt" "Bad stuff happened" 

You can suppress this using the ignore/void functions respectively:

// F#, no warning:
ignore (writeFile "C:/log.txt" "Bad stuff happened")
-- Haskell, no warning:
void (writeFile "C:/log.txt" "Bad stuff happened")

But if you mess up and miss out a parameter, you get quite different results in each language:

// F#, missed parameter: compiles fine, no warning:
ignore (writeFile "C:/log.txt")
-- Haskell, missed parameter: compiler type error:
void (writeFile "C:/log.txt") 

I’ll avoid an in-depth discussion of type systems here, but Haskell’s type system (in particular, monads) saves you here from a mistake, while F# happily ignores the return value, which is a partially applied function that does nothing. Lesson: use ignore with great care!

Misc Notes

A few more brief notes:

  • I know this one comes from ML, but whoever came up with expressing a triple type as “int * string * float” needs to be put back in the box with all the other mathematicians. Haskell’s equivalent syntax “(Int, String, Float)” is much nicer and easier to remember.
  • I got caught out at one point by bracketing pattern matches. I had a type “type Position = Position (int * int)”. I wanted to pull the values out using:

    let Position (x, y) = calculatePos()
    printfn "Position: %d, %d" x y
    // Error above: x and y not found

    I’m not sure what F# thinks that code is doing, but it doesn’t give a compile error on the let binding. Turns out you need more brackets to achieve what I was aiming for:

    let (Position (x, y)) = calculatePos()
    printfn "Position: %d, %d" x y
  • I remember, many years back, when I learnt Java after using C++, it was very refreshing to not worry about declaration locations. No header files, no needing to have forward declarations of classes before using them — you just put each type in its own file and off you go. Haskell cannot have cycles in its module dependencies; if module A imports B then B cannot import A, even indirectly — but within each module, declaration order doesn’t matter. Thus it felt like a bit of a backwards step in F# to start worrying about declaration order within a file; you can’t use any function or value before you have declared it in the file.
  • So far, I find writing F# unexpectedly similar to writing modern Java. A lot of the streams or lambda code I’d now write in Java 8 is very similar to what I find myself writing in F# with Seq and fun. If Java were to add algebraic data types (aka discriminated unions) with pattern matching, and syntactic sugar for currying, the core of two languages don’t seem like they would be that far apart. I guess both are part of the recent convergence/smashing together of OOP and FP, but coming at the problem from different sides.

The Good

I’ve mainly talked about the bad and the ugly instead of the good here, but I do actually like F#! There’s several aspects that improve on Haskell. The convention to use the |> operator is good, meaning you write “source |> operation1 |> operation2 …” which I find more readable than Haskell’s conventional “operation2 . operation1 $ source”. Similarly, I prefer <<, or more often >>, as function composition rather than “.”. Records are nice and easy to use; if you know Haskell, you’ll understand what a relief writing myRecord.myField is. Similarly, the ability to stick printf/trace statements anywhere in your code is very welcome.

I’d still take Haskell over F# as a functional language given a free choice (for its purity and type system), but as a way to bridge the gap between FP and OOP (with a recognised VM and thus lots of libraries behind it), F# is a good language. I’ve complained a lot about the joins in the FP/.NET aspects here, but with most of them I can see the language designers’ quandaries which led to the compromise. I suspect you can’t get much better than this when trying to bolt FP on to an OOP framework and still retain easy interoperability. I should look at Scala again at some point as a comparison, but at least in .NET land, F# seems like a good choice of language, if you can just find a set of conventions that keep your code nice and tidy when you so often have multiple approaches to choose from.

Flash Boys

Flash Boys is a book by Michael Lewis about high frequency trading and exploits of the [US] stock market. Lewis writes great books, and seems to have a knack for finding the interesting people to write about in any given scenario. I’d recommend all the other books of his I’ve read, especially Moneyball and The Big Short. He usually writes about finance, but Flash Boys is about the intersection of finance and computing, which is why I’m highlighting it here. From my point of view, Flash Boys is about what happens when a human system becomes an algorithmic computer system.

Way back when, the stock market was a totally human process, with clients instructing stockbrokers to buy or sell, and deals carried out between people on the trading floor. Gradually, technology was used to support this process, until now the transactions are carried out purely electronically, with stockbroker machines passing orders to the stock exchange machine, which puts together buyers and sellers into transactions. This has various consequences, which are covered in Flash Boys, which I wanted to highlight here.

Too Fast For Humans

The market now moves so fast that there is no opportunity for microscopic human oversight. Machines are programmed to execute client orders, or to use an algorithm to try to make profit in the market, but with microseconds (or less) per trade, even the machine’s controllers are at the mercy of its actions. Knight Capital famously lost 440 million dollars in 45 minutes due to computer error, and that could be seen as a generously long time over which the error occurred. With little opportunity to correct matters after the fact (unless you have sufficient influence to get the stock exchange to rollback your mistake), it is increasingly important for your machines and algorithms to be correct.

Having said that, one interesting detail seemed to be that on a microscopic level, the market is actually very inactive. As I understand, the machines don’t generally sit there trading continuously in stocks against each other. The market settles to an equilibrium, and it’s only when new information is received that it makes sense to trade. Thus the activity is still driven by human input: when a buyer wants to buy, probably because a person somewhere has issued an order, the trading activity kicks in before (see speed, below) and after the human-triggered order, then stops.

Speed Matters…

One of the themes in Flash Boys is how being the fastest earns you money. It is less about being fast to access a single stock exchange, but more about being fastest between two sources of information. If you know a large order for, say, Apple shares is incoming from a buyer, but you can get to the stock exchange before them, you can buy some Apple shares at the current price and then sell them on to the buyer for slightly more. Similarly, if you see the price for a stock increase in New York, and you can get that information to Chicago fast enough, you can again buy in Chicago, and thus buy shares which are almost immediately worth more than you paid for them. There are tales in Flash Boys of building the straightest fibre optic link possible (time being distance over speed, and speed being limited by the speed of light, less distance is key) and moving around machine rooms to be closest to the exit. Lewis characterises these practices as a tax on the real buyers and sellers in the market: the high frequency traders who perform this racing between exchanges are making money at the direct expense of those slower than them in the market.

…But Doesn’t Have To

For many technological dodges, there are technological solutions. A group that Lewis focuses on try to build an exchange immune to many of these practices by increasing the latency to their exchange. By slowing everyone’s access down, they can eliminate the advantages gained by spotting price differences between that exchange and others.

Some elements of trading really are an information war. Certain regulations, or just certain programmed behaviours, mean that a small order for a share being placed in Chicago is likely to be a sign of a subsequent order arriving in New York (if you want to buy lots of one share, you may have to visit many exchanges to find a buyer). Deterministic behaviours offer opportunities for exploitation by other players in the market; but also offer guarantees of reproducible behaviour.

A Black Box

One running theme is how little many of the players in the stock market seemed to know about the implications of the electronic system underlying it. Some stockbrokers and investors were having their orders exploited by high frequency traders for months or years before they figured out what was going on. There was a complete lack of human oversight of how the system as a whole worked, partly due to regulations that prevented certain information being public, and partly because there was a lack of technical understanding of how the system worked. Lewis describes how the technical staff went from being subservient to the brokers, to being the ones highly sought after to provide a market advantage.

The Trial

This theme of technical ignorance permeates into the trial of one programmer, Sergey Aleynikov, accused of stealing program code. Whether or not you consider him guilty, it is troubling how little the investigator, prosecutor and expert witnesses seemed to know about relatively basic technical concepts. The investigator apparently only arrested the programmer on the suggestion/order of Goldman Sachs. The part where the investigator found it suspicious that the programmer had put the code in a subversion repository is a face palm moment. (If, like me, you have your technical hat on by default and don’t immediately see the problem, recall the dictionary definition of subversion to see the investigator’s view. Interestingly, even a search for define:subversion on google won’t offer the dictionary definition, and will only show you links to download Subversion.) The trial was still rumbling on in the past few months, with Aleynikov convicted a second time (having been convicted and acquitted once already), and then acquitted a second time.


Wikipedia points out several people claim that Lewis’s book gives an inaccurate and overly-negative view on high frequency trading; I don’t know enough details to judge. But as a book looking at what happens when a human system becomes a machine system, I found it fascinating. A recommended read if you want to consider the effects of computerisation on society. It’s also interesting to wonder what would be different in the book if all the people featured had had some computing education; what would have turned out differently? The trial might have reached a different verdict, the people may have sussed the stock exchange problems a little earlier, the stock trading rules may have been written slightly differently.

Blocks and Beyond Workshop

The Blocks and Beyond Workshop will be held in Atlanta in October, co-located with the VL/HCC conference. The workshop aims to look at research surrounding blocks programming (Scratch, Snap, etc), its effectiveness, and future developments improving or building on block based programming. The deadline, for 1-3 page position papers or <= 6 page short papers, is now two weeks away: Friday 24th July.

Here’s the overview of the workshop from the official site:

Blocks programming environments represent program syntax trees as compositions of visual blocks. This family of tools includes Scratch, Blockly,’s lessons, App Inventor, Snap!, Pencil Code, Alice/Looking Glass, AgentSheets/AgentCubes, etc. They have introduced programming and computational thinking to tens of millions, reaching people of all ages and backgrounds.

Despite their popularity, there has been remarkably little research on the usability, effectiveness, or generalizability of affordances from these environments. The goal of this workshop is to begin to distill testable hypotheses from the existing folk knowledge of blocks-based programming environments and identify research questions and partnerships that can legitimize, or discount, pieces of this knowledge. The workshop will bring together educators and researchers with experience in blocks languages, as well as members of the broader VL/HCC community who wish to examine this area more deeply. We seek participants with diverse expertise, including, but not limited to: design of programming environments, instruction with these environments, the learning sciences, data analytics, usability, and more.

I will be attending, and hope to see some interesting submissions and discussion around block-based programming and future derivatives. (I’m also on the program committee.) Submission details are on the site.

CAS Conference 2015 Roundup

Saturday saw the 7th annual CAS conference. In the time that it has been running (i.e. the lifetime of CAS), some pretty dramatic changes have occurred to Computing in schools [in England]. Computing has gone from a niche A-Level (ages 16–18) subject to having GCSEs (ages 14–16) to being in the national curriculum (ages 5–14), as of last September. It’s hard to gauge the mood from the generally-eager attendees, but there seemed to be a feeling that this was something of a crisitunity: lots of panic and problems (especially lack of teachers and lack of training), but also a very exiting time with a chance to shape the discipline in schools for years to come.


Paul Curzon’s opening keynote was excellent. He talked about how many bits it takes to encode letters of the alphabet. Sounds exciting, huh? But the key was how he motivated and contextualised it. He began by talking about locked-in syndrome, a terrible condition where people are almost entirely paralysed (e.g. by a stroke), retain their cognitive faculties, but are only able to perform tiny pieces of motor control, such as blinking their eyelid. Curzon looked at how you could communicate at all if you are only able to blink, and then looked at how you could optimise this communication (essentially, binary decision trees for the alphabet). A fairly dull information encoding task became a realistic and relevant issue which could make a difference to someone’s life. (Features that research has suggested help computing appeal to girls.) I’m sure many people in the room wanted to turn round and give the same talk to their pupils, which is a good sign.

An interesting new feature this year was the research stream, which looked at how teachers might engage with computing education research — by doing research themselves. I was taken with the high attendance and interest; Sue Sentance and others are doing a great job of driving this forward. I see some good opportunity there: teachers generally have very good questions and easy access to [pupil] participants, but perhaps lack the skills that researchers that can bring. It seems like a pairing of the two could potentially bring some interesting results. Especially in primary school: it’s worth remembering that England is one of the very few places worldwide that is delivering computing education nationally to all pupils at young ages, so we should make use of the opportunity to learn as much as we can (see also Sally Fincher’s recent article on the topic).

I came away energised by the conference, as I do every time. It was nice for us to be able to show our work on Greenfoot 3 and frame-based editing and get some feedback. I was also amused to hear an esteemed computer scientist who took part in a Scratch activity bemoaning that its data model was poor, as you couldn’t easily perform the perfectly straightforward task of run-length encoding. It was suggested that they perhaps should have stuck to running cats around the screen. But it’s one of the great things about the conference that it brings together academics, teachers, teacher trainers, awarding bodies, professional software developers and more besides. I’m looking forward to more of the same at the CAS Scotland conference in November.

If you want to see more, take a look at Simon Johnson’s storify: part 1, part 2, part 3, part 4, part 5, and part 6. Phew!

The Paper History of Code Reading

How do you read code? It’s such a simple question that it seems obvious. You go to your IDE, select the class you’re interested in, and scroll up and down. You may also jump around the code using shortcut keys or mouse clicking to jump to the definition or usages of an identifier. There have been many papers over the years on improving the readability of code, but once you go back far enough, you start realising that a lot has changed. In 1986, Rambally tried different colouring schemes for keywords to enhance readability. They suggest reasons why this might not have been done before:

From Rambally's 1986 paper "The influence of color on program readability and comprehensibility" (ACM, public link), amusingly only available in black and white.
From Rambally’s 1986 paper “The influence of color on program readability and comprehensibility” (ACM, public link), amusingly only available in black and white.

Say what? Colour screens were becoming available at that time (quick digging shows CGA was 1981, and I believe Turbo Pascal 1.0 used colour in its launch in 1983; there were doubtless similar developments in Unix at that time), but the paper takes for granted that code is read on paper. This is referred to as an issue by Baecker and Marcus:

From Baecker and Marcus's 1986 paper "Design principles for the enhanced presentation of computer program source text" (ACM)
From Baecker and Marcus’s 1986 paper “Design principles for the enhanced presentation of computer program source text” (ACM)

Choice of font being dictated by its photocopyability is a long way from font choice on hi-res screens like Retina displays. This was a different era, and it means that some of the results are not necessarily applicable. For example, Miara et al summarise earlier work by Weissman as follows:

From Miara et al.'s 1983 paper "Program Indentation and Comprehensibility" (ACM, public link)
From Miara et al.’s 1983 paper “Program Indentation and Comprehensibility” (ACM, public link)

I think it’s safe to say that paper-page boundaries are no longer an issue with program reading!

Because of the paper focus, proposals for code navigation were also quite different. Where now we have things like outline views and jump-to-declaration, 30 years ago programmers were flicking backwards and forwards through piles of paper. So Oman and Cook’s idea of having a table of contents and an index must have been appealing, but the idea now of printing code into a book format is like asking for a hardcopy of wikipedia or a DVD of a youtube channel:

From Oman and Cook's 1990 paper "Typographic Style is More than Cosmetic"(ACM)
From Oman and Cook’s 1990 paper “Typographic Style is More than Cosmetic”(ACM)

It was also a different era of programming languages. I’m mainly looking in the mid 80s onward, so programs were entered via terminals not punched cards, but it’s the era of Pascal, FORTRAN and that whippersnapper C, maligned even then:

From Baecker's 1988 paper "Enhancing Program Readability and Comprehensibility with Tools for Program Visualization" (ACM)
From Baecker’s 1988 paper “Enhancing Program Readability and Comprehensibility with Tools for Program Visualization” (ACM)

This is historically amusing, given that C’s syntax was broadly copied into a very successful set of languages, like C++, Java, C#, Javascript and so on. The design of C was likely driven not so much by readability as by the Unix philosophy of reducing keystrokes. Just as you had “rm” instead of “remove”, you had “{” instead of “begin”. Languages tend to use shorter words for more frequent words, which reduces talking effort (less syllables) and writing and reading: less characters for the hand, and less width to travel for the eye. And what is shorter than one character? (Spoiler: zero characters! Dump those brackets…)

This era was also early in the structured programming era; several papers make mention of GOTO statements making the display of structured programming less effective.

Some of the papers, such as Miara et al.’s aforementioned study of indentation are using ALL CAPITALS MONOSPACE programs which are a bit horrendous to the modern eye. But the typography ideas were not all prehistoric; some of the pretty printing suggestions for the paper display of code were fairly advanced. I find it a bit too over the top, but Baecker and Marcus’ proposed display of code was an admirable effort at improvement:

From Baecker and Marcus's 1986 paper "Design principles for the enhanced presentation of computer program source text" (ACM)
From Baecker and Marcus’s 1986 paper “Design principles for the enhanced presentation of computer program source text” (ACM)

The margin notes and boxes are displays of comments in the original source. I think it ended up too busy, and some of the horizontal gaps are too large, but they do things like get rid of the curly brackets, use proportional fonts, the code is mainly lower case in the source, and they even do things like variable size brackets for grouping and variable spacing in expressions. Ultimately, it was the move from reading on paper into the modern standard of reading on screen that killed off this avenue of code display, to be constrained by character terminals and low-resolution graphics systems for the next ten to fifteen years. With modern displays, though, it’s worth considering some of these ideas again. Finally, we should beware citations of studies from this era when talking about screen-based reading; the paper-based results from that era may well not transfer to screens.

The holes in computing education research

Sally Fincher (the head of the computing education research group I work in) has published a very interesting article (originally in CACM, public version available here) about the lack of good research in computing education, and her worries that much of our efforts to push computing into schools lacks backup from researchers on how best to actually teach computing (and programming in particular):

What is resolutely held common [between teaching computing/programming literacy and] traditionally formulated literacy is that these approaches are unleashed on classrooms, often whole school districts, even into the curriculum of entire countries—with scant research or evaluation. And without carrying the teachers. If we are to teach computing in schools we should go properly equipped. Alongside the admirable energy being poured into creating curricular and associated classroom materials, we need an accompanying set of considered and detailed programs of research, to parallel those done for previous literacies.

I really enjoyed the article, which challenges some of the rest of our approaches to delivering and researching computing education — I highly recommend reading it.

Having read it, you might well wonder why there is so little research into school programming education. There are several reasons for this. One is that computing education research is a small field even within computing, and compared to something like literacy research it is tiny indeed. Another problem is that until recently, computing education researchers had no compelling reason to look at teaching introductory programming to all school-age students, because nobody was trying to deliver such teaching; instead the researchers were mainly focused on the status quo of teaching programming to self-selecting undergraduates. (As an additional practical issue, it is famously hard to get funding to research computing education; computing research funding organisations haven’t generally viewed it as an important area, and it was considered too niche for education research funding organisations.)

There is a further issue in teaching programming. Many concepts in programming remain reasonably static (e.g. variables, functions, collections, iteration, recursion), but all around them there is innovation and evolution. You have people toying with different syntaxes, different representations (blocks, frames, text, etc), different frameworks to find out what might work better for teaching programming, with scant rigorous evaluation. For example, we know teaching syntax can be tricky, so a few researchers study better ways to teach syntax while others — like the Scratch team or our team — just try to build new tools that eliminate syntax as a consideration. It’s a tough field in which to stand still and take stock. But Fincher is right that it is very important to properly evaluate teaching approaches and tools.

I know that when I tell teachers I am a computing education researcher, they are usually interested in what research has to say, and often have very sensible questions: What language should I teach in? What order should I cover the concepts? Is blocks-based programming good for students long-term? How should you best manage the transition between blocks and text? Some of these are at least partly personal preference, but we have so little research on them that I am rarely able to give a good answer. The true answer is usually: no-one really knows, and my work makes it harder by trying to build new tools instead of evaluating existing tools.

Although it’s not just the educational part of computing that lacks these answers: a teacher may ask whether static or dynamic languages are best for teaching, while a professional developer may have the exact same question for professional use, and the research there is almost as bare.

I remember during my PhD, where I was creating new abstractions/libraries for concurrent programming, a researcher from another discipline asked how I would evaluate the new abstraction: would I get a bunch of programmers together and get some of them programming with an existing library, and some with mine and see who performed better according to some metric? I remember scoffing, and thinking: no-one does that. But now I realise that is a large problem with the study of programming. Similar to economists, many computer scientists are so convinced that our discipline is purely theoretical and abstract, that we forget that a good part of the discipline is distinctly anthropological. How can we study the programming of machines with so little consideration for the role of the programmer? Educationally and professionally, why do we build so many programming tools and languages without ever stopping to ask: do they actually help?

We’re looking to hire a web developer

Computing At School is an organisation supporting and promoting the delivery of computing in UK schools. Since 2012, our team at the University of Kent has maintained the CAS Community web site. We do this alongside our regular research work on BlueJ, Greenfoot and associated projects. This has lead to our time being stretched quite thinly, and unfortunately it is the CAS web site that has suffered a bit, with little active development in the past months. We’re looking to rectify this by hiring a web developer to focus their time on the CAS site. The link to apply is here:

Why it might appeal: This is a good opportunity to further your technical skills and take the initiative to make identifiable contributions and really add something to a website used by thousands of teachers to share resources and improve the teaching of our own discipline: computer science. You will work at a university with the combined benefits of a large employer (big campus with lots of amenities) and a small team. We offer a non-commercial, relaxed environment, flexible on working hours, with no bureaucracy (no timesheets or tedious project management), but retaining a core dedication to getting the job done well. We are based in Canterbury, a pleasant historical city (but the students keep it lively) only a few miles from the coast and only one hour’s train journey from London.

Canterbury campus in summer, original photo by Stephen Train, CC BY-NC 2.0
Canterbury campus in summer, original photo by Stephen Train, CC BY-NC 2.0

Logistics: Closing date for applications is 26th April 2015, currently two weeks away, with interviews set for 5th May. The job is intended to be full-time, although we would also consider part-time working if that suited a candidate’s circumstances. Ideally, we would like a candidate to work in our offices in Canterbury, but we can also consider (UK-based) remote working with regular Canterbury meetings. The job is grade 6 in the university’s structure, which means a salary of 26–30k. It’s initially a one-year fixed term position, as we currently only have funding available for one year. More details on the post are available via the above link.

Technical skills: The website is written in Ruby on Rails, with a smattering of client-side Javascript/AJAX. We’re looking for what some call a “full stack developer”, although the stack is quite small. We’d ideally like someone who is familiar with doing the technical aspects of Rails and a little AJAX development, able to SSH into a Linux server and poke a cron job or log file, but also able to design decent enough webpages when needed, talk to users and other stakeholders about improvements to the site. But we realise that you never get a perfect candidate: we at least need someone who can program well, is familiar with the basics of web development, and can pick up whatever bits of Ruby on Rails and Javascript they need, quickly, while also being able to converse with users and fellow developers.

Other skills: The developer will work as part of a small team, primarily with Michael Kölling and me. We’ll decide priorities together, and I can advise on the structure of the site code and plan architecture of new features and so on, but we are looking for someone who can work effectively on their own, taking charge of the website and making a real difference to it and its users.

If you have any questions, feel free to contact me ( Please pass this on to friends or colleagues who might be interested.

Greenfoot 3, at SIGCSE

Most of the BlueJ/Greenfoot team will be headed to Kansas City next week, for the SIGCSE 2015 conference. We’ll be doing a Raspberry Pi demo at 3pm on Thursday in the exhibit hall, and we’ll be presenting a new paper on our Blackbox data on Saturday morning at 9am in room 2502A (more on that in a future post). But the event we are most excited about is our Greenfoot event, 5:30pm on Friday night in room 2502B, where we plan to demo and launch a public preview of Greenfoot version 3.0.0.

What’s New In Greenfoot 3?

We’ve continued to refine the existing parts of Greenfoot: we’ve added generics to the right places in our Greenfoot API, and we’ve switched to automatic compilation, so the Compile button will be a thing of the past. By far the biggest development in Greenfoot 3 is that we have added a totally new editor (which will sit alongside the existing editor), with a new way to edit programs. We’re calling it frame-based editing: roughly speaking, it is a hybrid of block-based editors like Scratch, and text-based editors like Greenfoot’s Java editor. The intention is that it takes the best parts of block-based editing (easy manipulation by dragging, avoidance of syntax errors) but marries them with the best parts of text-based editing (keyboard control, less tedious dragging for program creation and expression manipulation, easier management of longer programs).

The new Greenfoot 3 editor.  The look is not too far different from Greenfoot 2, but how you use it is quite different.
The new Greenfoot 3 editor. The look is not too far different from Greenfoot 2, but how you use it is quite different.

I’ll be posting a lot more details about the new editor after SIGCSE (for now, we’re busy focusing on testing the release ahead of the conference), but if you’re coming to SIGCSE: do come join us on Friday night to take a look. There’s even free food and drinks!

How to spell program

The word program has various meanings. The common meaning is this one, from the Oxford English Dictionary (OED):

An advance notice describing any formal proceedings, as an entertainment, a course of study, etc.

This word is spelled “program” in the US, and “programme” in the UK: one OED example usage is “The dance programme featured four works”. Fine. However, the word program also has a special meaning in our domain: a computer program, which is programmed by programmers. Over to OED again:

Noun: A series of coded instructions and definitions which when fed into a computer automatically directs its operation in performing a particular task.

Verb: To write a computer program.

Let’s be clear: this sense of the word is now spelt program, not programme, even in the UK. Even the OED admits it (in its definition of the verb above, and the note on the noun: “Now usu. in form program”). But that doesn’t stop various UK organisations from trying the British spelling:

  • Telegraph, Nov 2013: “This has discouraged software developers from writing programmes for Android”.
  • UK government, this week (Dec 2014): “In schools, a new GCSE in computer science [will cover] the most up-to-date issues including writing code, designing programmes…”.
  • The Guardian have recently got the hang of it — using programme in 2005 (“one programme can infringe many different patents at once”), but updating to program by 2012 (“Coderdojo inspires kids to program”).

Why does this matter? It bothers me because I’m a nitpicking pedant, but I think it’s also a culture signifier. Using phrases like “to programme a computer” or “writing a computer programme” shows that the person has never actually been involved with programming, or else they would realise that all programmers have adopted the US spelling (the US being quite big in computing, apparently). It always suggests someone writing about something they don’t know much about. So, if you want to avoid this, update your style guides: program, not programme.

Expressive Whitespace

Do you know the operator precedence rules in the programming languages that you use? Given an expression like this one in Java:


Can you say how it will be parsed? (Never mind that the semantics may be meaningless; the parser doesn’t care about semantics.) Generally, programming environments give very little help in improving readability of expressions; the expression will be displayed exactly as above. You do get bracket-match highlighting if you have brackets (and some would argue that you should always bracket expressions for extra clarity). But maybe the display of expressions can be further improved in other ways.

Designers tend to use whitespace for grouping items — for example, grouping related columns in tables. And in fact, a lot of programmers do tend to omit the whitespace around high precedence (tightly bound) operators while putting it in around lower precedence operators. You are much more likely to see this:

dist * Math.sqrt(x*x + y*y)

Than this equally spaced version:

dist * Math . sqrt (x * x + y * y)

Or this devilishy spaced version:

dist*Math . sqrt(x * x+y * y)

If the rule that most people follow is simply to have whitespace inversely proportional to the precedence of the operator, surely we could automate this in a programming editor.

Dynamically varying whitespace

Consider this expression, without spaces:


Using the parse tree of this expression, we can assign smaller whitespace to operators nearer the leaves (higher precedence operators which bind more tightly) than operators nearer the root (lower precedence operators):


It is now more obvious at a glance how the expression should be read, compared to the unspaced original. Not only is the display clearer, but if the editor takes charge of putting the whitespace in expressions, the user can save keystrokes by never having to insert spaces in expressions in the first place. They can enter the unspaced version above, and the editor displays it as the second version automatically.

Choosing the amount of space

One design question is whether the width of whitespace is solely determined by absolute operator precedence — i.e. plus always has the same amount of whitespace around it — or whether it is determined by the relative precedence of the operator in the chosen expression. In the absolute case, the complete expression “2 * 3” will be spaced differently to “2 + 3”, which to me seems odd. In the dynamic case, you get spacing readjustment: if you take “2+3” and add “*4” on the end, the + will get more space added to reflect that its dynamic precedence has changed. That is:




While re-spacing as you edit is visually disturbing, I think this is the right thing to do — the addition of *4 has changed the semantics of the existing expression (it is not “(2+3)*4” but rather “2+(3*4)”) so respacing it to reflect the altered semantics seems correct.

Longer expressions

There is a limit to how long an expression this technique can make readable — our earlier terrible expression:


Becomes a bit better when space is varied:


But I think in that case, there’s only so much that spacing can do — you really should add some brackets.


I’ve discussed a way that programming editors could be smarter about whitespace when displaying expressions: dynamically varying the whitespace around operators based on their relative precedence in the expression. This is likely to be included in a new editor we’re currently working on for our Greenfoot system. I note that this scheme does vary the width of spaces in your editor, which may upset some users. But while fixed-width spacing is useful for aligning the left-hand edges of lines of code, I’m less convinced that it matters within the line of code.

Addendum: a colleague points me to this work which mentions a similar system for mathematical equations (page 6). It’s interesting that this idea has been implemented in mathematics but not yet caught on in programming.