1. We are here at TechMesh 2012 in London, I’m sitting here with Tomas Petricek, so Tomas who are you?
Officially I’m currently a PHD student at the University of Cambridge. Before that or during that I’ve been doing various things with the F# language and the F# team in Microsoft Research, so I did two internships with the F# team and some contracting working on... I initially started working on a Web Programming for F# and translating F# to JavaScript but that was a long time ago before it was cool. Then I did some work on Reactive Programming on using F# with MonoDevelop and various other things, and at the moment I'm sort of partly still involved in the F# community doing various talks and my research is on Functional Programming so that might be applicable to F# as well.
I wrote a blog post, something like two weeks before RX was released, which was actually very similar to what they ended up doing, which was inspired by the F# event model which is, I guess that might be some motivation for RX, so yes, that is fairly related.
3. When you say F# event model, is there some specific thing in F#, what makes it special?
In F# events are first class values which means that event is a value you can pass around, you can if you have a button click you can get it as a value and pass it to a function, so you can rebuild all the normal functional combinators like map, filter, so you can write things like a mousedown filter if it’s in a certain range or in a square, then you get back a new event that is triggered only when the original is triggered and it matches the condition. So that is basically what RX does as well and in RX they had to introduce the IObservable type which is also something like an event treated as a value, but it’s kind of less obvious when you do it in C# because button click isn’t really a value, it's like a special language feature.
4. And I guess RX also ties that in with LINQ, is that built on top of that or with it?
RX implements the LINQ pattern, so you have like the usual higher order methods or functions that in F# you can use them in the normal sort of functional way using piping and in C# you get the query syntax.
I think in general there is like two different approaches to dealing with sort asynchronous and event based models. One is what RX is doing where you have some declarative combinators for filtering, projections, some sort of merging and so on, and that is useful if your problem matches one of their combinators, but I find it really hard to write my own sort of abstraction based on that, because you have just what is there, writing them yourself is quite hard. The other approach is what you get with F# Asynchronous Workflows and these days it’s also in C# where they have the new async, and there you can express things as maybe a state machine so you can write a sequential computation that repeatedly waits for some event and then does something, does some processing, updates or calculates a new state. And you can sort of implement many of the RX combinators using this style in an easy to understand way. So the two approaches you would probably want to combine them together and if you want to write something more complicated use the async or some actor or agent model if you have something that matches, some standard processing patterns that is already there, just use that.
Async Workflows are really trying to solve the problem you have with callback based API’s. Before you had that if you wanted to do asynchronous web request you had to write new WebRequest, then register handler or give it a callback, and that is making it really difficult because whenever you specify a callback, you get a new scope where you have to write... basically if you want to handle exceptions you have to write try/catch in every scope so you end up repeating try/catch for every single operation in your code. And Asynchronous Workflows are just sort of transforming your code into something that where this all happens automatically, and Computation Expressions are just a mechanism that makes that possible without saying... that is kind of the difference between C# 5 which has async but there is just async, they added async to the language because they thought async is a problem that we want to solve today. In F# you have, it’s done via a more general mechanism that can be used for some other programming patterns.
So that is an interesting question, it probably started like that, but when you look at the things that you can do in Computation Expressions, it’s more about taking your normal F# code and reinterpreting it, and what Haskell does with do, is that they let you reinterpret value binding. In F# you can define other constructs like for loops, exception handling, while loops, so you take your normal F# code, wrap it in an async block, and that means all the loops become asynchronous loops, all the exception handling can deal with asynchronously thrown exceptions, so we actually wrote a paper with Don Syme which looks at the features you get in F# and it turns out you can encode various other patterns that the Haskell people do, but they don’t have a syntax for it, and in F# you can encode the patterns with sort of nice user friendly syntax, so you don’t have to write things like +|+-> whatever, to express simple thing like composition.
Computation expressions are really just composing functions. So when you write your code using the block, it’s split into normal compiled F# functions and then the sort of computation expressions builder that defines the meaning runs these functions, and it can run them asynchronously or run them multiple times.
9. So basically is like an interpreter, it decides when to apply…..?
Yes, it’s kind of like interpreter but where interpret doesn’t mean there is some like dynamic thing happening, it's just compiled code calling the compiled functions, but asynchronously.
10. It’s sort of gluing them together?
Yes, it’s like design pattern if you like the word. It's just like Monad is a naughty word in the OO world, design patterns, but it's essentially design pattern for composing functions.
11. And these special syntactical constructs are in the F# grammar?
In F# 2.0 there is very well specified grammar extension which says: “You can reinterpret binding, you can reinterpret returning” and that can be, and you can then implement these operations provide your own glueing. In F# 3.0 there is actually querying extensions that is also using the same mechanism so you can write query {} and then inside this you can use sort of key words defined by the query language, so the query language can define groupBy, where, select, which is something you get in C# as well, but you can also define other things like take 10, or get the first one. So that is even more powerful extension in that direction.
In F# you don’t really do that usually because in sort of the Haskell land they use Monads to do things like state, exceptions, pretty much everything, interesting, you have to use a Monad. In F# when you use async there is really not that many things you can compose it with and if you want to do it, I wrote a library for doing asynchronous sequences which is, you can write asynchronous computation that maybe reads a file from the internet, but it returns maybe the data in kilobyte chunks as it goes, so logically that is a composed thing, but when you want to implement it, there is quite a few nontrivial decisions like how do I define it to give the user nice syntax, that is intuitive, should you use for to iterate over an asynchronous sequence, probably yes, that is a nice way to write it instead of saying do and then sort of having something that you don’t really understand without understanding quite deeply what is happening. I think in F# you don’t probably need to compose them and you can build one, that is sort of doing something interesting, but you will probably want to write it yourself and control how it works.
Type Providers are all about integrating data into the programming language. If you look at statically typed programming languages like F#, C#, Java, the types only talk about very basic things that you can create in the language, you have types for ints, you have types for objects that you define, but you don’t have types for things that you get from the world, from databases, from REST APIs, from JSON. So whenever you want to access some of these you have to use just a type that says: “This is JSON”, but that is not really describing the document structure. So with Type Providers there is sort of an extensibility model in the language where you can plug in your code, I quite like the analogy with the Hitchhiker's Guide to the Galaxy where the Babelfish is the sort of fish that you can stick into your ear and it will start translating for you into your brain waves and Type Providers are sort of some fish you can stick into your compiler and it will start translating the data, Schema for databases, REST, JSON whatever, into types that the language understands, that the tools understand, so when you say db. you get automatic completion for all the things that exist in the outer world that you want to work with.
It happens normally people distinguish between compile time and runtime but that is not really precise because in modern IDEs you also have sort of development time and in F# the compiler is running in the background when you edit your code to give you suggestions, give you type information. So the Type Provider has one part that runs during the edit time and during the compile time which accesses the data, provides the types and then the provider also generates some code that is sort of put into your program and that runs at runtime, but the provider itself doesn’t have to be executed at runtime, it's just when you edit your code it generates the type to give you hints, when you compile it generates the type to give you the executable code and when you run it you just run the executable code, which also means that there is no performance implication for this because it just generates normal code that directly does whatever you would do previously by hand, but it's generated for you.
15. It really tightly integrates the data into the workflow essentially?
Yes, it’s something you can’t quite understand or see the value until you play with it because my first experience was that I wrote a Type Provider for accessing the World Bank Database, and they have something like 8000 indicators about countries and it’s a huge dataset with interesting data but only when I, as a programmer, I opened my editor and I typed worldbank. and it gave me a list of all the countries and I picked some country and I typed the dot and I get a completion with 8000 options of data I can access, it sort of gives you more a data oriented way to write programs, you can explore the data in your editor and have some interesting ideas about what you can write using the data. If you normally access data you start Googling for what are the interesting things and you probably need some idea of what you want to do, but in F# if you have some Type Provider for World Bank or for Freebase which is sort of structured Wikipedia basically, you can just explore the data and suddenly you start getting ideas of what amazing applications you can do.
16. It saves you from having to have 20 tabs open and from copy pasting and things like that?
It saves you from having two monitors, one with documentation.
F# has been developed initially by Microsoft Research, nowadays it’s available under the Open Source Apache license, so there is actually quite active Open Source community around F# which is doing quite a few interesting things. There has been quite a lot of work on getting F# to work really well on Mono, so F# works on Mono, it also works on the Monodroid so you can write your Android apps in F#. So there is a lot of work in that direction. There is also MonoDevelop plugin for F# which uses the F# compiler under the cover, so you get pretty much the same things you would get in Visual Studio, it works with F# 3.0, so if you want to try Type Providers you can just get the latest version of Mono which comes with F# and install some plugin for MonoDevelop. That is one interesting project I think.
We are actually ultimate hipsters because when I first stated working on this it was in 2006, before it was cool, but that project is long time dead because the F# language changed quite a bit it and doesn’t work. But there is quite a few projects that try to do that more properly, not just for fun but to actually get something valuable out of it, so there is a commercial project called WebSharper which is a framework for doing web programming with F# that integrates with Facebook and all the mobile toolkits. So that is something that is production ready, works just fine, gives you the F# features.
20. But I guess they have some custom libraries for interacting with DOM and things like that?
Yes, they do, they have sort of form composition model. There is another project which is more recent and its a community Open Source thing called FunScript which is also translating F# to JavaScript but it uses the Type Provider model to give you basically access to JavaScript libraries, so that is something that I find very cool and that is what I talked about here during the conference. The idea is when you want to call something like jQuery or KnockoutJS, Angular whatever from F#, you really want to have the normal F# style sort of user developer experience, you want to have auto complete, you want to have static checking of types, and you can get that really easily because with Type Providers you can write a Type Provider that looks at some definition of the library or on some specifications and generates F# types to represent the library, so you can just say jQuery and hit dot and it gives you all the jQuery things like text, append and so on. The FunJS project comes with a Type Provider that uses the Microsoft TypeScript definition files and TypeScript is just a sort of language compiled to JavaScript with a bit of types. The interesting thing for us, for the F# people, is that they wrote all these definitions files that describe jQuery and other libraries, and they just define what is the type of the library of all the functions there and we can take that, import that and get nice F# API.
21. That is FunScript? That is definitely something to check out?
It’s still in the early days but I wrote all my samples today for it, using it for the conference, works pretty well, and you can combine it with the Type Providers as well, with a sort of data access. In one of the samples that I had, I combined this access to the jQuery API with a Type Provider that uses a startup called Apiary.io and they let you document your REST API’s and what we can do in F# is that we can import that documentation and give you a type based on that, so if you describe your REST API using that project, they give you a nice documentation, nice testing tools and API sort of development tools, but we can also use it from F# and give you typed view over your API for free pretty much.
22. You wrote a book, what is the title of the book?
It’s called “Real World Functional Programming” and the subtitle says with F# and C#.
24. Give us a quick blurb, how do you bring Functional Programming to the real world?
You don’t have to bring Functional Programming to the real world because it’s already there. In C# if you look at things like LINQ, that is Functional Programming, if you look at the Task Parallel library, that is something that has been done in Lisp, I don’t know, 2 centuries ago or whenever people starting doing Lisp, so ideas from the Functional Programming are used in practice in the real world. Sometimes there is a lot of ideas you can borrow from Functional Programming and they tend to work really nicely for data processing, Concurrency, Parallelism, or whenever you have some sort of difficult problem you want to solve. With the sort of more recent rise of functional languages that is really just giving you more weapons that you can use if you find that you really have some sort of algorithmic problem and you don’t want to write thousands of lines of C# code, that implements some algorithm which you can write in a functional way with hundred lines.
There is quite a few cases where the functional technologies in mainstream languages just stop being nice, when you have to use tuples in C# that is not something that you want to do. The other sort of area I think is that in C# you can use things like RX or LINQ, but writing them is actually not easy, if you try to write generic method in C#, you really need to buy a huge monitor because is just lines that says: “[lines of generic code]” and so on, so I feel with things like that you are sort of limited to what somebody else gives you, and if you use functional languages then suddenly all the library functions you start writing are more like domain specific languages that you can then use very easily to solve your problems. If you just do working with Collections and if LINQ gives you all the features, then you probably don’t need to switch to a functional language but as soon as you want to write something that is sort of more tailored to your problem domain, then it will be really hard to do it in a functional style, in something like C# and it will be very natural to write that functionally in say F#.
We are doing sort of F# training here in London for generally C# programmers or just in general anybody who is interested in Functional Programming and F#. There is actually quite a few people from various sort of financial organizations who work as scientists or write some computations, so I guess the entry barrier differs for different people, for people with sort of more math background, is generally very easy because it’s more mathematical. For C# programmers you sort of have to overcome some initial barrier because it has a little different syntax, you use different approaches to think about problems, but in F# the barrier is not too high because F# mixes object oriented and functional style, so many of the concepts that you use in C# you can also use in F#, it’s a great way to get into F# and at some point you’ll maybe start using more of a functional style but you can do the transition gradually which is I think what makes F# good programming language to learn if you are coming from the OO World.
27. Makes it approachable, it has your comfortable objects and you don’t have to rethink everything?
It’s also very convenient for interoperability because you can write some sort of functional core in the functional style and then or implement your business logic with pattern matching or something that is really powerful functional feature that you don’t get in other languages, but then you can wrap it in a nice class that the rest of your C# team will understand and can use without even knowing that it's not written in C#.
Yes, I think F# actually benefits from not being overly academic, it’s started as a research project, it's based on the OCaml language but it actually didn’t includes all the more advanced features of OCaml and instead merged more with the .NET style. It’s generally a very pragmatic language that lets you do whatever you want to do, whatever you need to do.
29. If I ask you what your favorite Monad is, do you have an answer?
Well my favorite Monad would be Asynchronous Workflows because Asynchronous Workflows if you talk to Haskell programmers and then you spend a lot of time explaining what it is, then they’ll finally say: “Yes, that is just a Continuation Monad”, but that is not really the perspective you get in F# because it’s solving some really important problem that you can’t solve otherwise, so in F# you don’t use Monads to do mutable state, because in Functional Programming you probably don’t want to do mutable state and if you want then in F# you have mutable variables. That is something you don’t really have to solve but with asynchronous programming that is sort of an area where there really was a problem and Asynchronous Workflows aren’t just a Monad, it’s more the library around it, and it’s also the nice integration with the rest of the language that let you write your code synchronously and the just wrap it in async block without rewriting everything to use the do notation instead of let or where.
30. I guess a final question, another preference, what is you favorite Catamorphism?
My favorite Catamorphism is Dogomorphism, it's just Catamorphism when you replace “Cat” with “Dog”. It sounds very scientific but I don’t think it exists. Somebody needs to invent that, but my favorite Monad is a Comonad as well, which is just a dual.
31. Care to explain [Comonads]?
Well then we would have to go the white board and I would have to brainwash you for an hour, but if you are interested in Comonads, you can read my recent paper.
32. If you give us the title we can googlify it.
I can give you a link [Editor's note: see Tomas' website for links to papers etc: http://tomasp.net/blog/] , but Comonads are something that might be interesting to researchers. I wouldn't use it in a programming language today, but it’s perhaps something that might give you some useful ideas in 10 or 5 years, that people can actually turn to something useful like Asynchronous Workflows takes some ideas from Monads but they're presented in a completed different way, so something like that might happen with other concepts coming from crazy mathematics.
Werner: That is a good topic to end on, it’s always good to end on Monads in functional discussion and thank you Tomas!
Thanks!