Slides from LambdaCon


Phew, finally back in famil­iar sur­round­ings of Lon­don after back-to-back con­fer­ences in Italy where I spoke about Elm and F# at Code­Mo­tion Rome and Lamb­da­Con. It was a great cou­ple of days, saw some inter­est­ing talks (I’ll write up some sum­maries later), met some old friends and made new ones.

Here are the slides for my Elm and F# talk at LambdaCon.

Slides and source code from other Lamb­da­Con talks is also avail­able on Github.


Next up, F# Exchange on 17th April!

Seven ineffective coding habits many F# programmers don’t have

This post is part of the F# Advent Cal­en­dar in Eng­lish 2014 project. Check out all the other great posts there!

Spe­cial thanks to Sergey Tihon for orga­niz­ing this.

A good cod­ing habit is an incred­i­bly pow­er­ful tool, it allows us to make good deci­sions with min­i­mal cog­ni­tive effort and can be the dif­fer­ence between being a good pro­gram­mer and a great one.

“I’m not a great pro­gram­mer; I’m just a good pro­gram­mer with great habits.”

- Kent Beck

A bad habit, on the other hand, can for­ever con­demn us to repeat the same mis­takes and is dif­fi­cult to correct.


I attended Kevlin Henney’s “Seven Inef­fec­tive Cod­ing Habits of Many Pro­gram­mers” talk at the recent Build­Stuff con­fer­ence. As I sat in the audi­ence and reflected on the times I exhib­ited many of the bad habits he iden­ti­fied and chal­lenged, some­thing hit me – I was cod­ing in C# in pretty much every case even though I also spend a lot of time in F#.

Am I just a bad C# devel­oper who’s bet­ter at F#, or did the lan­guage I use make a big­ger dif­fer­ence than I real­ized at the time?

With this ques­tion in mind, I revis­ited the seven inef­fec­tive cod­ing habits that Kevlin iden­ti­fied and pon­dered why they are habits that many F# pro­gram­mers don’t have.


Noisy Code

Signal-to-noise ratio some­times refers to the ratio of use­ful infor­ma­tion to false or irrel­e­vant data in a con­ver­sa­tion or exchange. Noisy code requires greater cog­ni­tive effort on the reader’s part, and is more expen­sive to main­tain.

We have a lot of habits which – with­out us real­is­ing it – add noise to our code. But often the lan­guage we use have a big impact on how much noise is added to our code, and the C-style syn­tax is big cul­prit here.

Objec­tive com­par­i­son between lan­guages are usu­ally dif­fi­cult because com­par­ing dif­fer­ent lan­guage imple­men­ta­tions across dif­fer­ent projects intro­duces too many other vari­ables. Com­par­ing dif­fer­ent lan­guage imple­men­ta­tions of a small project is achiev­able but can­not answer how well the solu­tions scale up to big­ger projects.

For­tu­nately, Simon Cousins was able to pro­vide a com­pre­hen­sive analy­sis of two code-bases writ­ten in dif­fer­ent lan­guages – C# and F# – imple­ment­ing the same application.

The appli­ca­tion was non-trivial (~350k lines of C# code) and the num­bers speak for themselves:




Not only is the F# imple­men­ta­tion shorter and gen­er­ally more use­ful (i.e. higher signal-to-noise ratio), accord­ing to Simon’s post it also took a frac­tion of the man-hours to pro­vide a more com­plete imple­men­ta­tion of the requirements:

“The C# project took five years and peaked at ~8 devs. It never fully imple­mented all of the contracts.

The F# project took less than a year and peaked at three devs (only one had prior expe­ri­ence with F#). All of the con­tracts were fully implemented.”

In sum­mary, by remov­ing the need for { } as a core part of the lan­guage struc­ture and not hav­ing nulls, F# removes a lot of the noise that are usu­ally found in C# code.


Visual Dis­hon­esty

“…a clean design is one that sup­ports visual think­ing so peo­ple can meet their infor­ma­tional needs with a min­i­mum of con­scious effort.”

- Daniel Higginbotham

When it comes to code, visual hon­esty is about lay­ing out your code so that their visual rela­tion­ships are obvi­ous and accu­rate.

For exam­ple, when you put things above each other then it sig­ni­fies hier­ar­chy. This is impor­tant, because you’re show­ing your reader how to process the infor­ma­tion you’re giv­ing them. How­ever, you may not be aware that’s what you’re doing, which is why we end up with problems.

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 designs. 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.”

- Daniel Higginbotham

Take the sim­ple mat­ter of how nested method calls are laid out in C#, they betray every­thing we have been taught about read­ing, and the order in which infor­ma­tion needs to be processed has been reversed.

image image

For­tu­nately, F# intro­duced the pipeline oper­a­tor |> which allows us to restore the visual hon­esty with the way we lay out nested func­tions calls.


In his talk Kevlin also touched on the place­ment of { } and how it affects read­abil­ity, using a rather sim­ple technique:

image  image

and by doing so, it reveals inter­est­ing prop­er­ties about the struc­ture of the above code which we might not have noticed:

  1. we can’t tell where the argu­ment list ends and method body starts
  2. we can’t tell where the if con­di­tion ends and where the if body starts

These tell us that even though we are align­ing our code, its struc­ture and hier­ar­chy is still not imme­di­ately clear with­out the aid of the curly braces. Remem­ber, if the visual rela­tion­ship between the ele­ments is not accu­rate, it’ll cause con­fu­sion for your read­ers and they need to exam­ine your code care­fully to ensure they under­stand it cor­rectly. In order words, you cre­ate addi­tional cog­ni­tive bur­den on your read­ers when the lay­out of your code does not match the pro­gram structure.

Now con­trast with the following:

image image

where the struc­ture and hier­ar­chy of the code is much more evi­dent. So it turns out that place­ment style of { } is not just a mat­ter of per­sonal pref­er­ence, it plays an impor­tant role in con­vey­ing the struc­ture of your code and there’s a right way to do it.

“It turns out that style mat­ters in pro­gram­ming for the same rea­son that it mat­ters in writing.

It makes for bet­ter reading.”

- Dou­glas Crockford

In hind­sight this seems obvi­ous, but why do we still get it wrong? How can so many of us miss some­thing so obvious?

I think part of the prob­lem is that, you have two com­pet­ing rules for struc­tur­ing your code in C-style lan­guages – one for the com­piler and one for humans. { and } are used to con­vey struc­ture of your code to the com­piler, but to con­vey struc­ture infor­ma­tion to humans, you use both { } and indentation.

This, cou­pled with the eager­ness to super­fi­cially reduce the line count or adhere by guide­lines such as “meth­ods shouldn’t be more than 60 lines long”, and we have the per­fect storm that results in us sac­ri­fic­ing read­abil­ity in the name of read­abil­ity.


So what if you use space for con­vey­ing struc­ture infor­ma­tion to both the com­piler and humans? Then you remove the ambi­gu­ity and peo­ple can stop fight­ing about where to place their curly braces!

The above exam­ple can be writ­ten in F# as the fol­low­ing, using con­ven­tions in the F# community:

image  image

notice how the code is not only much shorter, but also struc­turally very clear.


In sum­mary, F#’s pipes allows you to restore visual hon­esty with regards to the way nested func­tion calls are arranged so that the flow of infor­ma­tion matches the way we read. In addi­tion, white­spaces pro­vide a con­sis­tent way to depict hier­ar­chy infor­ma­tion to both the com­piler and human. It removes the need to argue over { } place­ment strate­gies whilst mak­ing the struc­ture of your code clear to see at the same time.


Lego nam­ing

Nam­ing is hard, and as Kevlin points out that so often we resort to lego nam­ing by glu­ing com­mon words such as ‘cre­ate’, ‘process’, ‘val­i­date’, ‘fac­tory’ together in an attempt to cre­ate meaning.

This is not nam­ing, it is labelling.

Adding more words is not the same as adding mean­ing. In fact, more often than not it can have the oppo­site effect of dilut­ing the mean­ing of the thing we’re try­ing to name. This is how we end up with gems such as con­troller­Fac­to­ry­Fac­tory, where the mean­ing of the whole is less than the sum of its parts.



Nam­ing is hard, and hav­ing to give names to every­thing — every class, method and vari­able — makes it even harder. In fact, try­ing to give every­thing a mean­ing­ful name is so hard, that even­tu­ally most of us sim­ply stop car­ing, and lego nam­ing seems like the lazy way out.


In F#, and in func­tional pro­gram­ming in gen­eral, it’s com­mon prac­tice to use anony­mous func­tions, or lamb­das. Straight away you remove the need to come up with good names for a whole bunch of things. Often the mean­ing of these lamb­das are cre­ated by the higher order func­tions that use them —, Array.filter, Array.iter, e.g. the func­tion passed into is used to, sur­prise sur­prise, map val­ues in an array!

(Before you say it, yes, you can use anony­mous del­e­gates in C# too, espe­cially when work­ing with LINQ. How­ever, when you use LINQ you are doing func­tional pro­gram­ming, and the use of lamb­das is much more com­mon in F# and other functional-first languages.)


Lego nam­ing can also be the symp­tom of a fail­ure to iden­tify the right level of abstractions.

Just like nam­ing, com­ing up with the right abstrac­tions can be hard. And when the right abstrac­tion is a piece of pure func­tion­al­ity, we don’t have a way to rep­re­sent it effec­tively in OOP (note, I’m not talk­ing about the object-orientation that Alan Kay had in mind when he coined the term objects).

In sit­u­a­tions like this, the com­mon prac­tice in OOP is to wrap the func­tion­al­ity inside a class or inter­face. So you end up with some­thing that pro­vides the desired func­tion­al­ity, and the func­tion­al­ity itself. That’s two things to name instead of one, this is hard, let’s be lazy and com­bine some com­mon words together and see if they make sense…

pub­lic inter­face ConditionChecker


    bool CheckCondition();


The prob­lem here is that the right level of abstrac­tion is smaller than an “object”, so we have to intro­duce another layer of abstrac­tion just to make it fit into our world view.


In F#, and in func­tional pro­gram­ming in gen­eral, no abstrac­tion is too small and func­tions are so ubiq­ui­tous that all the OO pat­terns that we’re so fond of can be rep­re­sented as func­tions.

Take the Con­di­tionChecker exam­ple above, the essence of what we’re look­ing for is a con­di­tion that is eval­u­ated with­out input and returns a boolean value. This can be rep­re­sented as the fol­low­ing in F#:

type Con­di­tion = unit –> bool

Much more con­cise, wouldn’t you agree? And any func­tion that matches the type sig­na­ture can be treated as a Con­di­tion with­out hav­ing to explic­itly imple­ment some interface.


Another com­mon prac­tice in C# and Java is to label excep­tion types with Excep­tion, i.e. Cas­tEx­cep­tion, Argu­mentEx­cep­tion, etc. This is another symp­tom of our ten­dency to label things rather than nam­ing them, out of lazi­ness (and not the good kind).

If we had put in more thought into them, than maybe we could have come up with more mean­ing­ful names, for instance:



In F#, the com­mon prac­tice is to define errors using the light­weight excep­tion syn­tax, and the con­ven­tion here is to not use the Excep­tion suf­fix since the lead­ing excep­tion key­word already pro­vides suf­fi­cient clue as to what the type represents.



In sum­mary, whilst F# doesn’t stop you from lego nam­ing things, it helps because:

  • the use of anony­mous func­tions reduces the num­ber of things you have to name significantly;
  • being able to model your appli­ca­tion at the right level of abstrac­tion removes unnec­es­sary lay­ers of abstrac­tions, and there­fore reduce the num­ber of things you have to name even further,
  • it’s eas­ier to name things when they’re at the right level of abstraction;
  • con­ven­tion in F# is to use the light­weight excep­tion syn­tax to define excep­tion types with­out the Excep­tion suffix.



In his pre­sen­ta­tion, Kevlin showed an inter­est­ing tech­nique of using a tag cloud to see what pops out from your code:

image           image

Com­pare these two exam­ples you can see the domain of the sec­ond exam­ple sur­fac­ing through the tag cloud – paper, pic­ture, print­ingde­vice, etc. whereas the first exam­ple shows raw strings and lists.

When we under abstract, we often find our­selves with a long list of argu­ments to our methods/functions. When that list gets long enough, adding another one or two argu­ments is no longer significant.

“If you have a pro­ce­dure with ten para­me­ters, you prob­a­bly missed some.”

- Alan Perlis

Unfor­tu­nately, F# can’t stop you from under abstract­ing, but it has a pow­er­ful type sys­tem that pro­vides all the nec­es­sary tools for you to cre­ate the right abstrac­tions for your domain with min­i­mal effort. Have a look at Scott Wlaschin’s talk on DDD with the F# type sys­tem for inspi­ra­tions on how you might do that:


Unen­cap­su­lated State

If under-abstraction is like going to a job inter­view in your pyja­mas then hav­ing unen­cap­su­lated state would be akin to wear­ing your under­wear on the out­side (which, inci­den­tally put you in some rather famous circles…).


The exam­ple that Kevlin used to illus­trate this habit is dan­ger­ous because the inter­nal state that has been exposed to the out­side world is muta­ble. So not only is your under­wear worn on the out­side for all to see, every­one is able to mod­ify it with­out your con­sent… now that’s a scary thought!

In this exam­ple, what should have been done is for us to encap­su­late the muta­ble list and expose only the prop­er­ties that are rel­e­vant, for instance:

type Recent­lyUs­edList () =

    let items = new List<string>()

    mem­ber this.Items = items.ToArray() // now the out­side world can’t mutate our inter­nal state

    mem­ber this.Count = items.Count


Whilst F# has no way to stop you from expos­ing the items list pub­li­cally, func­tional pro­gram­mers are very con­scious of main­tain­ing the immutabil­ity facade so even if a F#’er is using a muta­ble list inter­nally he would not have allowed it to leak outside.

In fact, a F#’er would prob­a­bly have imple­mented a Recent­lyUs­edList dif­fer­ently, for instance:

type Recent­lyUs­edList (?items) =

    let items = default­Arg items [ ]

    mem­ber this.Items = List.toArray items

    mem­ber this.Count = List.length items

    mem­ber this.Add newItem =

        let newItems = newItem::(items |> List.filter ((<>) newItem))

        Recent­lyUs­edList newItems


But there’s more.

Kevlin also touched on encap­su­la­tion in gen­eral, and its rela­tion to a usabil­ity study con­cept called affor­dance.

“An affor­dance is a qual­ity of an object, or an envi­ron­ment, which allows an indi­vid­ual to per­form an action. For exam­ple, a knob affords twist­ing, and per­haps push­ing, whilst a cord affords pulling.”

- Wikipedia

If you want the user to push, then don’t give them some­thing that they can pull, that’d be bad usabil­ity design. The same prin­ci­ples applies to code, your abstrac­tions should afford the right behav­iours whilst make it impos­si­ble to do the wrong thing.


When mod­el­ling your domain with F#, since there are no nulls it imme­di­ately elim­i­nates the most com­mon ille­gal state that you have to look out for. And since types are immutable by default, once they are val­i­dated at con­struc­tion time you don’t have to worry about them enter­ing into an invalid state later.

To make invalid states un-representable in your model, a com­mon prac­tice is to cre­ate a finite, closed set of pos­si­ble valid states as a dis­crim­i­nated union. As a sim­ple example:

type Pay­ment­Method =

    | Cash

    | Cheque of ChequeNumber

    | Card     of Card­Type * CardNumber

Com­pared to a class hier­ar­chy, a dis­crim­i­nated union type can­not be extended and there­fore invalid states can­not be intro­duced at a later date by abusing/exploiting inheritance.


In sum­mary, F# pro­gram­mers are very con­scious of immutabil­ity so even if they are using muta­ble types to rep­re­sent inter­nal state it’s highly unlikely for them to expose their muta­bil­ity and break the immutabil­ity facade they hold so dearly.

And because types are immutable by default, and there are no nulls in F#, it’s also easy for you to ensure that invalid states are sim­ply un-representable when mod­el­ling a domain.


Get­ters and Setters

Kevlin chal­lenged the nam­ing of get­ters and set­ters, since in Eng­lish ‘get’ usu­ally implies side effects:

“I get married”

“I get money from the ATM

“I get from point A to point B”

Yet, in pro­gram­ming, get implies a query with no side effects.

Also, get­ters and set­ters are oppo­sites in pro­gram­ming, but in Eng­lish, the oppo­site of set is reset or unset.


Sec­ondly, Kevlin chal­lenged the habit of always cre­at­ing set­ters when­ever we cre­ate get­ters. This habit is even enforced and encour­aged by many mod­ern IDEs that gives you short­cuts to auto­mat­i­cally cre­ate these get­ters and set­ters in pairs.

“That’s great, now we have short­cuts to do the wrong thing.

We used to have type lots to do the wrong thing, not anymore.”

- Kevlin Henney

And he talked about how we need to be more cau­tious and con­scious about what can change and what can­not.

“When it is not nec­es­sary to change, it is nec­es­sary not to change.”

- Lucius Cary


With F#, immutabil­ity is the default, so when you define a new record or value, it is immutable unless you explic­itly say so oth­er­wise (with the muta­ble key­word). So to do the wrong thing, i.e. to define a cor­re­spond­ing set­ter for every get­ter, you have to do lots of extra work.

Every time you have to type the muta­ble key­word is another chance for you to ask your­self “is it really nec­es­sary for this field to change”. In my expe­ri­ence it has pro­vided suf­fi­cient fric­tion and forced me to make very con­scious deci­sions on what can change under what conditions.


Unco­he­sive Tests

Many of us have the habit of test­ing meth­ods – that is, for every method Foo we have a Test­Foo that invokes Foo and inspects its behav­iour. This type of test­ing cov­ers only the sur­face area of your code, and although you can achieve a high code cov­er­age per­cent­age this way (and keep the man­agers happy), that cov­er­age num­ber is only superficial.

Meth­ods are usu­ally called in dif­fer­ent com­bi­na­tions to achieve some desired func­tion­al­ity, and many of the com­plex­i­ties and poten­tial bugs lie in the way they work together. This is par­tic­u­larly true when states are con­cerned as the order the state is updated in might be sig­nif­i­cant and you also bring con­cur­rency into the equation.

Kevlin calls for an end of this prac­tice and for us to focus on test­ing spe­cific func­tion­al­i­ties instead, and use our tests as spec­i­fi­ca­tions for those functionalities.

“For tests to drive devel­op­ment they must do more than just test that code per­forms its required func­tion­al­ity: they must clearly express that required func­tion­al­ity to the reader. That is, they must be clear spec­i­fi­ca­tion of the required functionality.”

- Nat Pryce and Steve Freeman

This is in line with Gojko Adzic’s Spec­i­fi­ca­tion by Exam­ple which advo­cates the use of tests as a form of spec­i­fi­ca­tion for your appli­ca­tion that is exe­cutable and always up-to-date.


But, even as we improve on what we test, we still need to have suf­fi­cient num­ber of tests to give us a rea­son­able degree of con­fi­dence. To put it into con­text, an exhaus­tive test suit for a func­tion of the sig­na­ture Int –> Int would need to have 2147483647 test cases. Of course, you don’t need an exhaus­tive test suit to reach a rea­son­able degree of con­fi­dence, but there’s a lim­i­ta­tion on the num­ber of tests that we will be able to write by hand because:

  • writ­ing and main­tain­ing large num­ber of tests are expensive
  • we might not think of all the edge cases

This is where property-based auto­mated test­ing comes in, and that’s where the F# (and other QuickCheck–enabled lan­guages such as Haskell and Erlang) com­mu­nity is at with the wide­spread adop­tion of FsCheck. If you’re new to FsCheck or property-based test­ing in gen­eral, check out Scott Wlaschin’s detailed intro­duc­tory post to property-based test­ing as part of the F# Advent Cal­en­dar in Eng­lish 2014.



We pick up habits – good and bad – over time and with prac­tice. Since we know that prac­tice doesn’t make per­fect, it makes per­ma­nent; only per­fect prac­tice makes per­fect, it is impor­tant for us to acquire good prac­tice in order to form and nur­ture good habits.

The pro­gram­ming lan­guage we use day-to-day plays an impor­tant role in this regard.

“Pro­gram­ming lan­guages have a devi­ous influ­ence: they shape our think­ing habits.”

- Dijk­stra

As another year draws to a close, let’s hope the year ahead is filled with the good prac­tice we need to make per­fect, and to ensure it let’s all write more F# :-P


Wish you all a merry xmas!



F# Advent Cal­en­dar in Eng­lish 2014

Kevlin Hen­ney – Seven inef­fec­tive cod­ing habits of many programmers

Andreas Selfik – The pro­gram­ming lan­guage wars

Simon Cousins – Does the lan­guage you use make a dif­fer­ence (revisited)

Cod­ing Hor­ror – The best code is no code at all

F# for Fun and Profit — Cycles and mod­u­lar­ity in the wild

Being visu­ally hon­est with F#

Ian Bar­ber – Nam­ing things

Joshua Bloch – How to design a good API and why it matters

Null Ref­er­ences : the Bil­lion dol­lar mistake

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