This Week at Skills Matter: 15 – 19 September

In the Brain of Allan Kelly


We’re delighted to welcome Allan Kelly tonight, as he joins us for his In The Brain talk exploring whether Agile practices can work outside of software development. Allan is a founding consultant with Software Strategy who work with companies to implement and deepen Agile methods. Tonight he will look at examples of Agile practices beyond software to see what lessons we can garner for knowledge workers in general.


Swift London return for their September talks covering Core Data, UX, UI CollectionView, APIs and Swift pedagogy. Featuring five speakers this week, these talks will cover a wide variety of topics for anyone interested in the Swift language – from all levels, beginner to expert. Register your spot now to join this friendly and very active group!

Join software developer and architect Goswin Rothenthal at this weeks F#unctional Londoners meetup, as he explores F# scripting for 3D geometry in the construction industry. Goswin’s custom software models are capable of integrating the entire design process from the initial geometry setout all the way down to the 2D information or mashinecode required for manufacturing. He recently used this process at Waagner Biro for the cladding of Louvre Abu Dhabi and before on the façades of COD-Macao and CityLife-Milano Towers at Zaha Hadid.


Join an adventure in F1 data, hear about the state of the Pentaho market and create Pentaho Sparks Apps with the Pentaho London user group on Thursday, as they’re joined by three exciting and experienced speakers – Nelson Sousa, Dan Keeley and Diethard Steiner.

Also on Thursday, the London Software Craftsmanship Community look at how to name things, with a solution to the hardest problem in programming by Peter Hilton. Adam Kosiński will then present an Swiss army knife for readable tests, in a talk about ideas and patterns to produce clean, readable and developer-friendly tests.

Guest Post: “Haskell gets static typing right”, Andres Löh

andres-lohThis is a guest post from Andres Löh, a long-time functional programming enthusiast. He started using Haskell in 1997 while being an undergraduate studying mathematics. He obtained his PhD on datatype-generic programming using Haskell from Utrecht University in 2004. Since then, he has continued to use Haskell in research and practice, including teaching various courses both to students and participants from industry. Since 2010, Andres is an independent Haskell consultant and partner at Well-Typed LLP.

Andres teaches both introductory or advanced Haskell courses at Skills Matter, and will also be running a special course on Haskell’s type system. If you would like more information, or would like to enquire about attending any of our courses, you can email us or call our team on 0207 183 9040.

Haskell gets static typing right

Statically typed languages are often seen as a relic of the past – old and clunky. Looking at languages such as C and Java, we’re used to writing down a lot of information in a program that just declares certain variables to be of certain types. And what do we get in return? Not all that much. Yes, granted, some errors are caught at compile time. But the price is high: we’ve cluttered up the code with noisy declarations. Often, code has to be duplicated or written in a more complicated way, just to satisfy the type checker. And then, we still have a significant risk of run-time type errors, because type casting is common-place and can fail at unexpected moments.

So it isn’t a big surprise that dynamically typed languages are now very fashionable. They promise to achieve much more in less time, simply by getting rid of static type checking.

However, I want to argue that we shouldn’t be too keen on giving up the advantages of static types, and instead start using programming languages that get static typing right. Many functional languages such as Scala, F#, OCaml and in particular Haskell are examples of programming languages with strong static type systems that try not to get in the way, but instead guide and help the programmer.

In the rest of this post, I want to look at a few of the reasons why Haskell’s type system is so great. Note that some of the features I’m going to discuss are exclusive to Haskell, but most are not. I’m mainly using Haskell as a vehicle to advertise the virtues of good static type systems.

1. Type inference

Type inference makes the compiler apply common sense to your programs. You no longer have to declare the types of your variables, the compiler looks at how you use them and tries to determine what type they have. If any of the uses are inconsistent, then a type error is reported. This removes a lot of noise from your programs, and lets you focus on what’s important.

Of course, you are still allowed to provide explicit type signatures, and encouraged to do so in places where it makes sense, for example, when specifying the interface of your code.

2. Code reuse

Nothing is more annoying than having to duplicate code. In the ancient days of statically typed programming, you had to write the same function several times if you wanted it to work for several types. These days, most languages have “generics” that allow you to abstract over type parameters. In Haskell, you just write a piece of code that works for several types, and type inference will tell you that it does, by inferring a type that is “polymorphic”. For example, write code that reverses all the elements of a data structure, and type inference will tell you that your code is independent of the type of elements of the data structure, so it’ll just work regardless of what element type you use. If you write code that sorts a data structure, type inference will figure out that all you require to know about the elements is that they admit an ordering.

3. No run-time type information by default

Haskell erases all type information after type checking. You may think that this is mainly a performance issue, but it’s much more than that. The absence of run-time type information means that code that’s polymorphic (i.e., type-agnostic, see above) cannot access certain values. This can be a powerful safety net. For example, just the type signature of a function can tell you that the function could reorder, delete or duplicate elements in a data structure, but not otherwise touch them, modify them or operate on them in any other way. Whereas in the beginning of this post I complained that bad static type systems don’t allow you to do what you want because they’re not powerful enough, here we can deliberately introduce restrictions to save us (as well as colleagues) from accidental mistakes. So polymorphism turns out to be much more than just a way to reduce code duplication.

By the way, Haskell gives you various degrees of selective run-time typing. If you really need it in places, you can explicitly attach run-time type information to values and then make type-based decisions. But you say where and when, making a conscious choice that you gain flexibility at the cost of safety.

4. Introducing new datatypes made easy

In Haskell, it’s a one-liner to define a new datatype with a new name that has the same run-time representation as an existing type, yet is treated as distinct by the type system. (This may sound trivial, but surprisingly many statically typed languages get it wrong.) So for example it’s easy to define lots of different types that are all integers internally: counters, years, quantities, … In Haskell, this simple feature is often used to define safe boundaries: a specific type for URLs, a specific type for SQL queries, a specific type for HTML documents, and so on. Each of these types then comes with specific functions to operate on them. All such operations guarantee that whenever you have a value of this type, it’s well-formed, and whenever you render a value of this type, it’s syntactically correct and properly escaped.

5. Explicit effects

In virtually all programming languages, a function that performs some calculations on a few numbers and another function that performs the same calculations, but additionally sends a million spam emails to addresses all over the world, have exactly the same type, and therefore the same interface. Not so in Haskell. If a function writes to the screen, reads from the disk, sends messages over the network, accesses the system time, or makes use of any other so-called side effect, this is visible in its type. This has two advantages: first, it makes it much easier to rely on other people’s code. If you look at the interface and a function is effect-free, then you for example automatically know that it is also thread-safe. Second, the language facilitates a design where side effects are isolated into relatively small parts of the code base. This may seem difficult to achieve for highly stateful systems, but surprisingly, it usually is not: even interactive systems can usually be described as pure functions reacting to a series of requests with appropriate responses, and a separate driver that does the actual communication. Such separation makes it not only easier to test the program, but also facilitates the evolution of the program such, for example, to adapt it to run in a different environment. Haskell’s type system therefore encourages good design.

6. Types as a guide in program development

If you only ever see types as a source of errors, and therefore as enemies on your path of getting your program accepted, you’re doing them injustice. Types as provided by Haskell are an element of program design. If you give your program precise types and follow systematic design principles, your program almost writes itself. Programming with a strong type system is comparable to playing a puzzle game, where the type system removes many of the wrong choices and helpfully guides you to take the right path. This style of programming is supported by a new language extension called “Typed Holes” where you leave parts of your program unspecified during development, and obtain feedback from the development environment about what type has to go into the hole, and what program fragments you have available locally to construct a value of the desired type. Playing this kind of puzzle game is actually quite fun!

7. Programming on the type level

Haskell’s type system provides many advanced features that you don’t usually have to know about, but that can help you if you want to ensure that some complicated invariants hold in your program. Scarily named concepts such as “higher-ranked polymorphism”, “generalized algebraic datatypes” and “type families” essentially provide you with a way to write programs that compute with types. The possibilities are nearly endless. From playful things such as writing a C-printf-style function where the first argument determines the number of arguments that are expected afterwards as well as their types, you can go on to code that provides useful guarantees such as that mutable references that are available within one thread of control are guaranteed not to be accessed in a completely different context, arrays that can adapt to different internal representations depending on what type of values they contain, working with lists that are guaranteed to be of a specific length, or with trees that are guaranteed to be balanced, or with heterogeneous lists (where each element can be of a different type) in a type-safe way. The goal is always to make illegal inputs impossible to construct. If they’re impossible to construct by the type system, you can isolate sanity tests at the boundary of your code, rather than having to do them over and over again. The good thing is that these features are mostly optional, and often hardly affect the interface of libraries. So as a user, you can benefit from libraries employing such features and having extra safety guarantees internally. As a library writer, you can choose whether you’re happy with the normal level of Haskell type safety (which is already rather a lot), or if you want to spend some extra effort and get even more.

If my overview has tempted you and you now want to learn more about Haskell, you’re welcome follow one of my introductory or advanced Haskell courses that I (together with my colleagues at Well-Typed) regularly teach at Skills Matter. These courses do not just focus on the type system of Haskell (although that’s a significant part). They introduce the entire language in a hands-on way with lots of examples and exercises, as well as providing guidelines on how to write idiomatic Haskell and how to follow good development practices.

If you already know some Haskell and are particularly interested in the advanced type system features mentioned in point 7, we also offer a new one-day course on Haskell’s type system that specifically focuses on how far you can push it.

While It’s Compiling: Skills Matter Interviews Scott Wlaschin

While It’s Compiling is a series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next and get a chance to put your questions forward with our hashtag #whileitscompiling.

scott_square_300This week on While It’s Compiling, we talked to Scott Wlaschin. He is a consultant at, creator of and blogger on F# for Fun and Profit, and the author of Understanding Functional Programming. Scott will be giving a talk on Railway Oriented Programming at the Functional Programming eXchange 2014.

1. What attracted you to Functional Languages in the first place?

I like languages that have simplicity, elegance and power, and are fun to program in. Many years ago, I spent a lot of time using Smalltalk, which is one of my all time favourite languages, and until recently languages like C# and Python were my main focus. I am also a fan of static typing, so when I discovered that I could get the power of static typing in a low ceremony functional language like F# (thanks to type inference), I was thrilled.  Also, like many people, I was frustrated with the bloat of modern OO programming and all the buzzwords that you had to learn. I was working towards breaking my code into much smaller, immutable pieces anyway, but the standard OO languages did not make this easy – whereas this approach was naturally suited for FP.

2. What are you working on?

Most of my recent work has been on standard enterprise software: services, e-commerce, supply chain, etc. I am convinced that FP is not just for academics or scientists, but has a vital role to play in what I call “Boring Line Of Business Applications”. Recently I have set up a FP consulting company ( to focus on training in this area. I am also working on a book, “Understanding Functional Programming”, which approaches FP from a non-academic point of view.

3. Do you work in only FP languages, or does the project you are working on have some FP code and some OO/Procedure code? If so, how do they fit together?

I work in a mixture of C# and F#. They work extremely well together. Don Syme and the F# team have done a fantastic job integrating F# into the .NET and Visual Studio environment. Most businesses are reluctant to fully commit to a functional language, so the functional stuff does tend to be around the edges; testing, utilities, analytics, and so on.  However, some projects have been purely in F#, and these are attracting attention for being faster to deliver, higher quality, and lower maintenance than the equivalent C# projects.

4. What is one piece of advice you can give to new programmers?

To paraphrase Doug Englebart, programming languages are tools to augment your intellect and help you solve problems. So, you should add as many tools to your tool chest as possible! Learn a variety of different programming paradigms using the “purest” language possible; e.g. learn OO using Smalltalk, FP using Haskell, logic using Prolog, stack-based using Forth/Factor, etc. This will expand your horizons and help you appreciate the bigger picture. If you stick with only mainstream languages (C# or Java, say) you will end up with a narrow (and boring) vision of how programming languages can help you think. Also, as part of this journey, you will discover that people from 30 or 40 years ago had a lot of insight and wisdom. Don’t overlook their ideas just because they are old!

5. What would you like to ask the community?

I think the FP community is doing well right now — there is a lot of interest from newcomers and in general the community is very welcoming. However, I would ask the community to appreciate that as FP becomes more mainstream, it will also have to become less pure and academic.  We shouldn’t scare newbies off by insisting that they have to understand monads and all the other scary terminology before they can be productive. What other things could we do to lower the barriers to entry?

What can we do to make Functional Programming more accessible? Tweet us at #whileitscompiling or @skillsmatter 

Scott will be giving a talk on Railway Oriented Programming at the Functional Programming eXchange 2014.


While It’s Compiling: Skills Matter interviews Bodil Stokke

Bodil Stokke

While It’s Compiling is a series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter.

Find out who we’ll be interviewing next and get a chance to put your questions forward with our hashtag #whileitscompiling.

This week on While It’s Compiling, we talked to Bodil Stokke; a frequent conference speaker in the fields of Functional Programming and internet technologies, and co-organiser of three annual developer conferences in her home town of Oslo. We caught up with her to discuss what she’s been up to in the Functional world.

1. What attracted you to functional languages in the first place?

It was a gradual process. Python used to be my main language back in the 90s, and coming from things like C++ I approached it mostly through its OO capabilities. I’d been aware from the start of Python’s Functions being first class, but it took me a while to realise the implications of this. A few years in, I was so attached to the idea of first class functions that I couldn’t do without them.

This, along with industry trends, led inexorably to Javascript. Eventually, it led to Node replacing Python as my go-to runtime for personal projects. And, as all things Node must, it led to so much frustration I decided enough was enough and I was going to start using a real Functional language. This led to spending a few days learning the basics of Haskell—and even that brief exercise changed my perspective on programming forever. I ended up spending the next three years with Clojure, but knowing even a little Haskell makes you a better programmer in any language, especially another functional one. Clojure very effectively highlighted what in my mind is the core value of Functional Programming: structuring code through composition, not the peculiar OO notion of inheritance. These days, though, I’m less interested in Functional programming than I am in exploring the idea of type systems. Clojure and Haskell both seem dull in comparison to things like Idris.

 2. What are you working on?

I’ve got a long running project exploring programming language design where I’m trying to build a modern typed Lisp, called BODOL. I spend a lot of time evolving my Emacs setup, and have an ambition to turn Emacs into a proper desktop environment, so I can use it for absolutely everything. And for a living I write Javascript game engines using various Functional compile-to-JS languages, the goal being to reduce the time spent building each individual game to as close to zero as possible. Functional languages are fantastic for this, because they excel at abstraction in a way traditional OO can’t hope to rival.

3. Do you work in only FP languages, or does the project you are working on have some FP code and some OO/Procedure code? If so, how does that fit together?

 I try to avoid non-functional languages when possible, and when I do have to write actual Javascript, I do it in a strictly Functional style, even to the point of employing immutable data structures whenever I can. Mutable state is Satan’s handmaiden.

4. What is one piece of advice you can give to new programmers?

Two things stand out. First, read the paper “Out of the Tar Pit” by Moseley & Marks, or all your code will be awful and you won’t know why. Second, always ask yourself, “would Dijkstra have liked this?”

5. You’ve recently moved to London – have you experienced much of the FP community in the UK capital yet?

One of the reasons I moved here in the first place was the amazing Clojure community. The Haskell community is even more amazing—not so much because they’re great people (too early to tell, though I’m sure they must be) but because where else in the world do you regularly get almost 100 people attending a Haskell meetup?

6. What would you like to ask the community?

When will there be a London Idris Meetup?

Are you up to organizing a London Idris Meetup? Tweet us at #whileitscompiling or @skillsmatter 

Bodil will be giving a talk on how to Build Your Own LISP for Great Justice at the Functional Programming eXchange 2014.

While it’s Compiling: Skills Matter interviews Chris Marshall



While It’s Compiling is a new series of interviews with experts across a range of bleeding-edge technologies and practices, exclusive to Skills Matter. Be sure to subscribe to this blog for future interviews, or follow us on Twitter. You can see all earlier interviews in the series here.

Find out who we’ll be interviewing next, and get a chance to put your questions forward with the hashtag #whileitscompiling.

Chris MarshallFor the second part in this series, we caught up with Chris Marshall, one of the 22 Scala gold-badged users on StackOverflow. He has been programming commercially for 14 years, briefly in FORTRAN and Smalltalk, then Java (since 1999) and in Scala (since late 2008) after his patience finally wore out. With over 12 years financial IT experience, he has been in his dream job for GSA, a small, technology-driven hedge fund since 2006 and prior to that spent six years at JPMorgan working for the rates business.

In his spare time, he likes to fail to get through “The Essence of the Iterator Pattern”, which he has now managed almost 500 times.

1. What attracted you to functional languages in the first place?

I was initially attracted to Scala as  “better Java” (before project Lambda, when it seemed like adding closures to Java was being punted into the long grass). Having large quantities of IP invested in the JVM (i.e. lots of Java libraries), Scala fitted a few key requirements, namely that you had seamless Java interop (which I now realize is a double-edged sword and agree with Brian McKenna’s opinion that Java should be hidden behind an FFI, but I digress). It looked “familiar” (i.e. it wasn’t Clojure) and it had a “pedigree” (Martin & EPFL).

Starting to use scala sent me on a path of discovery about types and opened me up to an online community which has shown me new (and I would argue better) ways of doing things.

2. What are you working on?

I don’t get as much time coding these days, as we now have a large team of developers – but my main project this year is going to be a bitemporal API representing the “business entities” within GSA (trading books, business units, funds etc). We’ve discovered over the last few years that not having this is painful. On top of this, there is a lot of incremental development on our existing codebases, which number in the hundreds

3. Do you work in only FP languages, or does the project you are working on have some FP code and some OO/Procedure code? If so how does that fit together?

No – we have a lot of Java systems, both legacy and not-so-legacy. I’m still very wary of providing Scala APIs to external teams as well (because many of our APIs target non-specialists who work in languages like Matlab, so binary compatibility issues are likely to cause unhappiness), so if we needed something in that space, I would probably still opt for Java.

Neither do I write pure functional code – many of our systems are realtime, or up 24×5, so I might write small pieces of functional code which ultimately end up running in a non-functional system (for example, actor-based).

4. What is one piece of advice you can give to new programmers?

Don’t be lazy. Never, ever skimp on logging and spend time making sure your log messages are comprehensive and contain all the information you will want. Don’t write assertions without a descriptive error message (your invariants will often turn out to be anything but) and similarly with exceptions. You’ll just end up adding it later, after your systems have failed and you have unhappy users, so you might as well just do it properly now.

5. What would you like to ask the community?

Can someone please demonstrate the coding of a realtime, functional system in Scala? By “realtime”, I mean “constantly up and producing output” as opposed to a single calculation with a defined end result (or results).

Can you demo the coding of a realtime, functional system in scala? Tweet #whileitscompiling or @skillsmatter

Chris will be speaking at the Functional Programming eXchange 2014 about Wrapping an Imperative API in a Functional One. Tickets are available at Skills Matter