Being visually honest with F#

It’s been a busy month, some top qual­ity con­fer­ences – Code Mesh, Build Stuff, FuncBy and NDC Lon­don – all cramped into the space of 4 weeks. It has been a blast, lots of talks and valu­able take­aways, and it was great to hang out with old friends and meet new ones. As soon as I find time I’ll put together some posts with my key take­aways from the conferences.

Dur­ing these con­fer­ences, Kevlin Hen­ney’s numer­ous talks have left a last­ing impres­sion on me. In his “Seven Inef­fec­tive Cod­ing Habits of Many Pro­gram­mers” talk at Build Stuff, he described the lack of visual hon­esty in code such as these:

pub­lic int howNotToLayoutMethodHeader(int firstArgument,

    string secondArgument)

and on what visual hon­esty means, he pre­sented a num­ber of quotes from Daniel Higginbotham’s excel­lent Clean Up Your Mess website:

To answer the ques­tion “What is clean design?” most suc­cinctly: a clean design is one that sup­ports visual think­ing so peo­ple can meet their infor­ma­tion needs with a min­i­mum of con­scious effort.”


You con­vey infor­ma­tion by the way you arrange a design’s ele­ments in rela­tion to each other. This infor­ma­tion is under­stood imme­di­ately, if not con­sciously, by the peo­ple view­ing your design.”


This is great if the visual rela­tion­ships are obvi­ous and accu­rate, but if they’re not, your audi­ence is going to get con­fused. They’ll have to exam­ine your work care­fully, going back and forth between the dif­fer­ent parts to make sure they understand.”

The quotes talk about lay­ing out infor­ma­tion so that their visual rela­tion­ships are obvi­ous and accurate.

So if you lay­out your method argu­ments in such a way that their visual rela­tion­ships are not accu­rate and you do that pur­pose­fully, then you’re in fact being dishonest.



As I sat there, I finally under­stood why F# pipes are so awe­some. I always knew it makes cleaner and more read­able code, it’s intu­itive, but I haven’t been able to find the words to explain why – the trou­ble with being able to under­stand some­thing with min­i­mum con­scious effort is that your con­scious mind can’t explain how it under­stood it.

Not any­more, now I finally under­stand it.


When we’re read­ing a piece of reg­u­lar Eng­lish text, we’re read­ing from left-to-right, then top-to-bottom. This con­ven­tion con­trols the flow of infor­ma­tion we receive as we read, so when we’re lay­ing out infor­ma­tion for peo­ple to con­sume, we lay them out in the order of left-to-right, then top-to-bottom.


But what about code?

When it comes to writ­ing nested func­tion calls, some­how this flow of infor­ma­tion has been reversed!


With F#’s pipes (which has been adopted in both Elm and Elixir by the way), we have finally man­aged to restore some san­ity and present sequence of func­tion calls in a way that matches the way we con­sume any other tex­tual information.


Visual hon­esty right before your eyes!



Clean Up Your Mess – A guide to Visual Design for everyone

NDC Oslo 2014 – Take­aways from keynote “it’s a write/read web”

NDC Oslo 2014 – Take­aways from “career reboot for the devel­oper mind”

Take­aways from Theo Schlossnagle’s talk on Scal­able Inter­net Architecture

Take­aways from Hewitt, Mei­jer and Szyperski’s talk on the Actor model

Take­aways from Gael Fraiteur’s mul­ti­thread­ing talk

Slides for CodeMesh, BuildStuff and FBy

Here are the slides for my talks at CodeMesh, Build­Stuff and Fby this year, enjoy!

It’s Conference Time!

Win­ter is upon us, but so is an excit­ing part of the year when lots of good tech con­fer­ences are hap­pen­ing all over the place!


CodeMesh was awesome

We had a great time at CodeMesh again this year, and enjoyed some amaz­ing ses­sions from some of the best peo­ple in the indus­try. Don’t worry if you couldn’t make it this time around, all the ses­sions were recorded, so keep an eye out for them on their web­site for when the videos are posted.


Next up, Build­Stuff in Vilnius

Con­sid­er­ing the jaw-dropping qual­ity of the line up – Udi Dahan, Eric Evans, Bart de Smet, Mark Ren­dle, Matthew Pod­wysocki, Pieter Hin­t­jens, Math­ias Bran­dewinder, Sasha Gold­shtein, Tomas Pet­ricek, Phil Trelford and Greg Young him­self, and so many more – Build­Stuff has gotta be one of the best value-for-money con­fer­ence around.

It’s not too late to get last minute tick­ets, and you can get 10% off the face price with the promo code CUI.

You can find the full sched­ule for the 3 days here, I’ll be giv­ing an extended ver­sion of my game econ­omy mod­el­ling with Neo4j talk on Fri­day, right before I head off to…


f(by) 14 in Belaurs

The recently announced f(by) con­fer­ence is the first func­tional con­fer­ence in Belarus, with two tracks cov­er­ing Scala, F#, Clo­jure, Erlang and Haskell.

Phil Trelford, Evelina Gabasova and me will be giv­ing talks on F#. I will be giv­ing a talk on tam­ing API com­plex­ity using F#-powered DSLs. In this talk, I’ll be draw­ing on my expe­ri­ence work­ing with AWS for the past 5 years and how we tack­led some of the com­plex­i­ties around their many APIs using both inter­nal and exter­nal DSLs and how F# makes

Ticket is avail­able via their web­site, and I have a 10% dis­count code avail­able on request.


NDC Lon­don

Back to Lon­don, NDC Lon­don will be hap­pen­ing from Dec 3rd-5th. Although this is the most expen­sive con­fer­ence on this list, it does have a rather impres­sive list of speak­ers – Don Syme, Uncle Bob, Bren­dan Eich, Jon Skeet, Dan North and Rob Con­ery to name a few, par­tic­u­larly if you’re in the .Net space.

Bryan Hunter has put together a great selec­tion of talks on func­tional pro­gram­ming (Bryan orga­nized the func­tional track for NDC Oslo this year, which had some great talks), and I’m hon­oured to be part of it.

Full agenda is avail­able here, I’ll be talk­ing about my adven­ture with Elm on Fri­day morn­ing. I aim to give the audi­ence a gen­tle intro­duc­tion to both Func­tion Reac­tive Pro­gram­ming and Elm. If time allows, maybe we’d even tweak the demo to be playable with the Myo armband Smile with tongue out


Cod­Mash in Ohio

imageFinally, I’ll be sign­ing off a busy cou­ple of months with Code­Mash, which is tak­ing place on Jan 6th-9th, in Ohio.

Again, F# is well rep­re­sented with Math­ias Bran­dewinder, Rachel Reece, Ryan Riley, Paul Bla­succi and myself all giv­ing talks on F#. Judg­ing by the list of accepted ses­sions there are some amaz­ing talks on a wide range of tech­nolo­gies, plat­forms and languages.

I’ll be giv­ing talks on:

  • mod­el­ling game econ­omy with Neo4j,
  • F# in social gam­ing, and
  • my adven­ture with Elm

All in all, there will be some 243 talks from 191 speak­ers for you to choose from! Although I’m not exactly look­ing for­ward to the snow­storm every­one tells me to be pre­pared for, I am def­i­nitely look­ing for­ward to Code­Mash (and my first visit to the US).


Hope to see you at some of these conferences Smile

Project Euler – Problem 68 Solution


Con­sider the fol­low­ing “magic” 3-gon ring, filled with the num­bers 1 to 6, and each line adding to nine.

Work­ing clock­wise, and start­ing from the group of three with the numer­i­cally low­est exter­nal node (4,3,2 in this exam­ple), each solu­tion can be described uniquely. For exam­ple, the above solu­tion can be described by the set: 4,3,2; 6,2,1; 5,1,3.

It is pos­si­ble to com­plete the ring with four dif­fer­ent totals: 9, 10, 11, and 12. There are eight solu­tions in total.


By con­cate­nat­ing each group it is pos­si­ble to form 9-digit strings; the max­i­mum string for a 3-gon ring is 432621513.

Using the num­bers 1 to 10, and depend­ing on arrange­ments, it is pos­si­ble to form 16– and 17-digit strings. What is the max­i­mum 16-digit string for a “magic” 5-gon ring?


(see full solu­tion here)


Before we go into details on the solu­tion, let’s first struc­ture the ques­tion in a way that’s easy for us to compute.

To con­struct the magic cir­cle, be it for a 3-gon or a 5-gon ring, we can slice up the num­bers into pairs – e.g. A => [1; 2], B => [3; 4], C => [5; 6], D => [7; 8], E => [9; 10] – and the prob­lem becomes find­ing ways in which the num­bers can be per­muted such that:

  1. a0 is the small­est amongst a0, b0, c0, d0, and e0
  2. the sums of a0 + a1 + b1, b0 + b1 + c1, … are the same

For exam­ple:



First, we’ll find the dif­fer­ent ways the num­bers 1 to 10 can be per­muted, and for each per­mu­ta­tion slice the num­bers into pairs:


(this makes use of a per­mute func­tion defined in the Common.fs source file in the solution).


Then we need a func­tion to sum a pair of num­ber with the last ele­ment in the adja­cent pair – e.g. a0 + a1 + b1:



For each per­mu­ta­tion, we need to check:

  1. if a0 is the small­est amongst the head elements
  2. if the sums of the groups of 3 – i.e. a0 + a1 + b1, b0 + b1 + c1, etc. – are the same


This pred­i­cate func­tion allows us to find arrange­ments that meet our cri­te­ria. All that’s left is to turn the result groups of 15 num­bers into 16/17-digit strings and find the max­i­mum (see full solu­tion below).


Here’s the full solution:



This solu­tion took 26s to exe­cute on my machine.

Project Euler – Problem 64 Solution


All square roots are peri­odic when writ­ten as con­tin­ued frac­tions and can be writ­ten in the form:


For exam­ple, let us con­sider ?23:


If we con­tinue we would get the fol­low­ing expansion:


The process can be sum­marised as follows:


It can be seen that the sequence is repeat­ing. For con­cise­ness, we use the nota­tion ?23 = [4;(1,3,1,8)], to indi­cate that the block (1,3,1,8) repeats indefinitely.

The first ten con­tin­ued frac­tion rep­re­sen­ta­tions of (irra­tional) square roots are:

?2=[1;(2)], period=1

?3=[1;(1,2)], period=2

?5=[2;(4)], period=1

?6=[2;(2,4)], period=2

?7=[2;(1,1,1,4)], period=4

?8=[2;(1,4)], period=2

?10=[3;(6)], period=1

?11=[3;(3,6)], period=2

?12= [3;(2,6)], period=2

?13=[3;(1,1,1,1,6)], period=5

Exactly four con­tin­ued frac­tions, for N <= 13, have an odd period.

How many con­tin­ued frac­tions for N <= 10000 have an odd period?


(see full solu­tion here).


Based on the algo­rithm on con­tin­ued frac­tions from Wikipedia, we can imple­ment the expan­sion algo­rithm as:


From the Wikipedia page:

The algo­rithm can also ter­mi­nate on ai when ai = 2 a0, which is eas­ier to implement.

which cor­re­sponds to the ter­mi­na­tion con­di­tion we have in the Repeat active pat­tern (which also checks if the accu­mu­la­tor is empty):


Also, this algo­rithm doesn’t work on num­bers that are per­fect squares, i.e. 4, 9, 16, … hence we need to exclude them when search­ing for our answer.

Here’s the solu­tion in full:



This solu­tion took 92ms to exe­cute on my machine.