# Upcoming F# book and event deals

Since I submitted my PhD thesis in December, I had a little bit of time to finish some of the things that I wanted to do for a really long time, but never quite found time to actually do them. This included getting the R provider to work on Mac and also creating a new web site for my various functional programming trainings and books. I even have a nice domain name:

The page also discusses a couple of business reasons for looking into functional programming. So, if you're a business person wondering why you should send your developers on an F# course, the site has the answers for you too! (Or if you are developer and need a page for your boss.) The other place to check out is the official F# Software Foundation web page is another great resource and the testimonials hosted there.

The page has some information about the various trainings we're offering at fsharpWorks and about the two F# books I co-authored (Real-World Functional Programming and brand new F# Deep Dives). I'm happy that we can offer some special deals on both the books and the F# FastTrack course in London, so if you're considering getting into F#, now is a good time!

Published: Friday, 27 March 2015, 12:16 PM
Tags: c#, f#, functional programming, talks

# Library patterns: Why frameworks are evil

In the previous article, I wrote about a couple of principles that I find useful when designing libraries in a functional style. This follows from my experience with building F# libraries, but the ideas are quite general and can be useful in any programming language. Previously, I wrote how multiple layers of abstraction let you build libraries that make 80% of scenarios easy while still supporting the more interesting use cases.

In this article, I'll focus on two other points from the list - how to design composable libraries and how (and why) to avoid callbacks in library design. As the title suggests, this boils down to one thing - build libraries rather than frameworks!

Published: Tuesday, 3 March 2015, 5:13 PM
Tags: f#, open source, functional programming

# Library patterns: Multiple levels of abstraction

Over the last few years, I created or contributed to a number of libraries including F# Data for data access, Deedle for exploratory data science with C# and F#, Markdown parser and code-formatter F# Formatting and other fun libraries such as one for composing 3D objects used in my Christmas blog post.

Building libraries is a fun and challenging task - even if we ignore all the additional things that you need to get right such as testing, documentation and building (see my earlier blog post) and focus just on the API design. In this blog post (or perhaps a series), I'll share some of the things I learned when trying to answer the question: What should a good library look like?

I was recently watching Mark Seemann's course A Functional architecture with F#, which is a great material on designing functional applications. But I also realised that not much has been written on designing functional libraries. For some aspect, you can use functional patterns like monads (see Scott Wlaschin's presentation), but this only answers a part of the question - it tells you how to design individual types, but not an entire library...

Published: Tuesday, 3 February 2015, 4:54 PM
Tags: f#, open source, functional programming

# FnuPlot: Cross-platform charting with gnuplot

There is a bunch of visualization and charting libraries for F#. Sadly, perhaps the most advanced one, F# Charting, does not work particularly well outside of Windows at the moment. There are also some work-in-progress libraries based on HTML like Foogle Charts and FsPlot, which are cross-platform, but not quite ready yet.

Before Christmas, I got a notification from GitHub about a pull request for a simple gnuplot wrapper that I wrote a long time ago (and which used to be carfully hidden on CodePlex).

The library is incomplete and I don't expect to dedicate too much time to maintaining it, but it works quite nicely for basic charts and so I though I'd add the ProjectScaffold structure, do a few tweaks and make it available as a modern F# project.

Published: Thursday, 15 January 2015, 5:58 PM
Tags: f#, fslab, data science

# Why you should learn F# in 2015 (and how)?

I guess that it might be a bit too late for adding to your list of new year's resulution now. But just if you still have an empty slot (or in case an originally taken slot has become available), your new year's resolution should be to get involved with F#!

Obviously, the goal of this blog post is to sell you some of my F# trainings and other materials - including the online course on F# in Finance and our FastTrack to F# course in London and New York and also the F# Deep Dives book. But to conceal this fact, I'm going to fill most of the blog post with useful information about F#, the F# Software Foundation and the F# community (but if you really just want to read about my courses, scroll down to the second section).

Published: Wednesday, 7 January 2015, 2:36 PM
Tags: c#, f#, functional programming, talks

# Composing Christmas with F#

This blog post is a part of the awesome F# Advent Calendar (see the previous entry about writing algorithms in F# from Rick Minerich), so it inevitably needs a Christmassy theme. However, there is also going to be a serious theme for the blog post, which is domain-specific languages.

One of my favorite examples of Domain-Specific Languages is a simple OpenGL library that I wrote some time ago for composing 3D graphics in F#. You can see it in my NDC 2014 talk Domain Specific Languages, the functional way and I also used it for Solving Puzzles with F# earlier on this blog.

The nice thing about the library is that it is very simple, but is rich enough to demonstrate all the important concepts. In fact, the library is so easy to use that even 8 years old can do a talk about it. So, if you're spending Christmas with your family, perhaps you can go through this article with your children!

Published: Monday, 8 December 2014, 6:22 PM
Tags: f#, fun, functional programming

# New features and improvements in Deedle v1.0

As Howard Mansell already announced on the BlueMountain Tech blog, we have officially released the "1.0" version of Deedle. In case you have not heard of Deedle yet, it is a .NET library for interactive data analysis and exploration. Deedle works great with both C# and F#. It provides two main data structures: series for working with data and time series and frame for working with collections of series (think CSV files, data tables etc.)

The great thing about Deedle is that it has been becoming a foundational library that makes it possible to integrate a wide range of diverse data-science components. For example, the R type provider works well with Deedle and so does F# Charting. We've been also working on integrating all of these into a single package called FsLab, but more about that next time!

In this blog post, I'll have a quick look at a couple of new features in Deedle (and corresponding R type provider release). Howard's announcement has a more detailed list, but I just want to give a couple of examples and briefly comment on performance improvemens we did.

Published: Tuesday, 27 May 2014, 4:41 PM
Tags: f#, deedle, data science

# Welcome fsharpWorks & F# events

If you are following me or the #fsharp hashtag on Twitter, you might have already come across a link to fsharpWorks or one of the upcoming F# events organized by fsharpWorks. So, what is fsharpWorks and what are we planning for you?

Published: Tuesday, 20 May 2014, 2:47 PM
Tags: c#, f#, functional programming, talks

# Stateful computations in F# with update monads

Most discussions about monads, even in F#, start by looking at the well-known standard monads for handling state from Haskell. The reader monad gives us a way to propagate some read-only state, the writer monad makes it possible to (imperatively) produce values such as logs and the state monad encapsulates state that can be read and changed.

These are no doubt useful in Haskell, but I never found them as important for F#. The first reason is that F# supports state and mutation and often it is just easier to use a mutable state. The second reason is that you have to implement three different computation builders for them. This does not fit very well with the F# style where you need to name the computation explicitly, e.g. by writing async { ... } (See also my recent blog about the F# Computation Zoo paper).

When visiting the Tallinn university in December (thanks to James Chapman, Juhan Ernits & Tarmo Uustalu for hosting me!), I discovered the work on update monads by Danel Ahman and Tarmo Uustalu on update monads, which elegantly unifies reader, writer and state monads using a single abstraction.

In this article, I implement the idea of update monads in F#. Update monads are parameterized by acts that capture the operations that can be done on the state. This means that we can define just a single computation expression update { ... } and use it for writing computations of all three aforementioned kinds.

Published: Tuesday, 13 May 2014, 4:41 PM
Tags: f#, research, functional programming, monads

# What can programming language research learn from the philosophy of science?

As someone doing programming language research, I find it really interesting to think about how programming language research is done, how it has been done in the past and how it should be done. This kind of questions are usually asked by philosophy of science, but only a few people have discussed this in the context of computing (or even programming languages).

So, my starting point was to look at the classic works in the general philosophy of science and see which of these could tell us something about programming languages.

I wrote an article about some of these ideas and presented it last week at the second symposium on History and Philosophy of Programming. For me, it was amazing to talk with interesting people working on so many great related ideas! Anyway, now that the paper has been published and I did a talk, I should also share it on my blog:

One feedback that I got when I submitted the paper to Onward! Essays last year was that the paper uses a lot of philosophy of science terminology. This was partly the point of the paper, but the feedback inspired me to write a more readable overview in a form of blog post. So, if you want to get a quick peek at some of the ideas, you can also read this short blog (and then perhaps go back to the paper)!

Published: Thursday, 10 April 2014, 6:16 PM
Tags: research, philosophy

# BREAKING: Open-source C# 6.0 released

At last, the long wait is fianlly over! After 4 years of waiting, the fully managed implementation of the C# compiler [codenamed "Roslyn"][roslyn] has been finally released. In the recent months, "Roslyn" has been slowly turning into [vaporware][vaporware], but thanks to the recent breakthrough, the team made an enormous progress over the last two months and even implemented a number of new C# 6.0 features.

The C# 6.0 compiler, together with the full source code has been released today!

UPDATE: In case you are reading this article later than on the day when it was published, let me just point out that this was released on 1 April 2014. Just to avoid any disappoinments. Have fun ;-).

Published: Tuesday, 1 April 2014, 3:24 PM
Tags: c#, fun, functional programming

# Solving fun puzzles with F#

Do you need to convince your friends & family that programming can be fun? For the last Christmas, I got a puzzle as a gift. It is a number of small cubes, joined together, that can be rotated and folded to form a bigger (4x4x4) cube.

We spent the last few days of the year with family and a couple of friends and I left the puzzle on the table. Every time I walked around, someone was playing with it without much success. In the end, I said that if noone solves it until 31 December, I'll write a program to do it. Which I did between 7 PM and 8 PM and, voilà, here is what I got...

So, how do you solve a puzzle in about 1 hour on New Year's eve?

Published: Tuesday, 25 March 2014, 3:27 PM
Tags: f#, fun, functional programming

# Advent Art: Generating Hokusai paintings

For the last few years, the Japanese F# community has been running the F# Advent Calendar (2010, 2011, 2012). Each advent day, one person writes an article about something interesting in F#. I have been following the advent calendar last year on Twitter and when the planning started for this year, I offered to write an article too. You might have noticed that I posted a Japanse version of the article in December as part of the advent calendar 2013.

A number of people helped to make this happen - @igeta arranged everything and helped with reviewing, @yukitos translated the article and @gab_km reviewed the translation. Thanks!

But what should I write about? It would be nice to look at some of the F# open-source libraries and projects that have been developing over the last year in the F# community. At the same time, can I relate the topic of the article to Japan? After some thinking, I came up with the following plan:

• First, we'll use the F# Data library and the Freebase to learn something about Japanese art. I should add that thanks to @yukitos the library now also has a documentation in Japanese.

• Then we'll pick one art work and try to recreate it in F#. Given my artistic skills, this part will definitely fail, but we can try :-).

• Finally, we'll use the FunScript project to turn our F# code into JavaScript, so that we can run it as a pure HTML web application that also works on mobile phones and other devices.

Published: Tuesday, 21 January 2014, 6:49 PM
Tags: f#, art, fractals, funscript, f# data

# Coeffects: The next big programming challenge

Many advances in programming language design are driven by some practical motivations. Sometimes, the practical motivations are easy to see - for example, when they come from some external change such as the rise of multi-core processors. Sometimes, discovering the practical motivations is a tricky task - perhaps because everyone is used to a certain way of doing things that we do not even see how poor our current solution is.

The following two examples are related to the work done in F# (because this is what I'm the most familiar with), but you can surely find similar examples in other languages:

• Multi-core is an easy to see challenge caused by an external development. It led to the popularity of immutable data structures (and functional programming, in general) and it was also partly motivation for asynchronous workflows.

• Data access is a more subtle challenge. Technologies like LINQ make it significantly easier, but it was not easy to see that inline SQL was a poor solution. This is even more the case for F# type providers. You will not realize how poor the established data access story is until you see something like the WorldBank and R provider or CSV type provider.

I believe that the next important practical challenge for programming language designers is of the kind that is not easy to see - because we are so used to doing things in certain ways that we cannot see how poor they are. The problem is designing languages that are better at working with (and understanding) the context in which programs are executed.

Published: Wednesday, 8 January 2014, 4:31 PM
Tags: research, coeffects, functional programming, comonads