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:
- What can Programming Language Research Learn from the Philosophy of Science?
- Fairly minimalistic slides from my talk at the symposium
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)!
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 ;-).
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?
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.
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:
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 :-).
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.
ここ数年、日本のF# コミュニティは「F# Advent Calendar」というイベントを開催しています (2010年、 2011年、 2012年、 そして 今年)。 これはadvent dayごとに1人ずつ、F#に関連した何かしら興味深い記事を作成するというものです。 私は去年からTwitterでadvent calendarをチェックしていて、 今年からは私も参加しようと思い、記事を書きたいと申し出ました。 そうしたところ、数名の方からの協力を得ることができました。 @igeta には参加手続きの諸々とレビューを、 @yukitos にはこの記事の翻訳を、そして @gab_km には翻訳のレビューをしていただきました。 ありがとう！
けれども何についての記事を書くのがよいのでしょう？ 過去一年にわたって、F#コミュニティで開発されているF#のオープンソースライブラリやプロジェクトを いくつか紹介できるような記事がよさそうです。 それと同時に、日本に関連のあるトピックが何かないものでしょうか？ 少し考えてみたところ、以下のようなプランを思いつきました：
F# computation expressions are the syntactic language mechanism that is used by features like sequence expressions and asynchronous workflows. The aim of F# computation expressions is to provide a single syntactic mechanism that provides convenient notation for writing a wide range of computations.
The syntactic mechanisms that are unified by computation expressions include Haskell
notation and list comprehensions, C# iterators, asynchronous methods and LINQ queries,
for comprehensions and Python generators to name just a few.
Some time ago, I started working on an academic article to explain what makes computation expressions unique - and I think there is quite a few interesting aspects. Sadly, this is often not very well explained and so the general preception is more like this...
The hard part about successful open-source development is not putting the first version of your source code on GitHub. The hard part is what comes next. First of all, there are community aspects - making sure that the project fits well with other work in the area, engaging the community and contributors, planing future directions for the project and so on. Secondly, there is an infrastructural side - making sure that there is a package (on NuGet in the F# world), easy to run and useful tests and also up-to-date documentation and tutorials.
In this article, I want to talk about the infrastructural side, which is easier of the two, but nevertheless, difficult to get right! Fortunately, the F# community made an amazing progress in this direction, so let's have a look at some of the tools that make this possible...
In a recent StackOverflow question the poster asked about the difference between tupled and curried form of a function in F#. In F#, you can use pattern matching to easily define a function that takes a tuple as an argument. For example, the poster's function was a simple calculation that multiplies the number of units sold n by the price p:
1: let salesTuple (price, count) = price * (float count)
The function takes a single argument of type
Tuple<float, int> (or, using the nicer F# notation
float * int) and immediately decomposes it into two variables,
count. The other
alternative is to write a function in the curried form:
1: let salesCurried price count = price * (float count)
Here, we get a function of type
float -> int -> float. Usually, you can read this just as a
function that takes
int and returns
float. However, you can also use partial
function application and call the function with just a single argument - if the price of
an apple is $1.20, we can write
salesCurried 1.20 to get a new function that takes just
int and gives us the price of specified number of apples. The poster's question was:
So when I want to implement a function that would have taken n > 1 arguments, should I for example always use a curried function in F# (...)? Or should I take the simple route and use regular function with an n-tuple and curry later on if necessary?
You can see my answer on StackOverflow. The point of this short introduction was that the question inspired me to think about how the world looks from the C# perspective...
Full name: Tuples-in-csharp_.salesTuple
val float : value:'T -> float (requires member op_Explicit)
Full name: Microsoft.FSharp.Core.Operators.float
type float = System.Double
Full name: Microsoft.FSharp.Core.float
type float<'Measure> = float
Full name: Microsoft.FSharp.Core.float<_>
Full name: Tuples-in-csharp_.salesCurried
Exactly two weeks ago, I started a three month internship at BlueMountain Capital in New York. They have a technical blog and should be well known to the F# community thanks to the R type provider which was written by Howard Mansell (@hmansell). I'll have the pleasure of working with Howard on some more open source data-science related tools for F# (and C#). I'll write more about these when we have something to share, but if you want to contribute and help us, join the Data and Machine Learning working group at F# Foundation.
Aside from my work, I'm also happy to get involved with the great F# community in New York! We already have some events planned - Progressive F# Tutorials and FastTrack to F# are scheduled for September 16.-19. so you can become an F# guru in 4 days :-). But I'm also happy to have a chat with anyone interested in F# and perhaps do a lunch time talk, if you need to convince your colleagues or boss that F# is a good choice.
It has been some time since I last wrote about F# Deep Dives - a new project that I'm working on together with Manning, Phil Trelford and a number of F# experts, so I'd like to write a quick update. In summary, working on a book with more than 10 co-authors is more difficult than one would think (and 10 people cannot write a book in 1/10 of the time :-)), but now that the holidays are almost over, you can expect more frequent updates again!
As of this writing, the early-access [...] version had only Chapters 3 and Chapter 11, but the other topics [...] are juicy and meaty. [T]he prose from the MEAP edition is pretty easy to read already, despite the fact that it's early-access material. In particular, the Markdown parser they implement in chapter 3 is a great example of a non-trivial language parser, which is not an easy task (...).
As I mentioned, the book is unique in that it is not written just by me and Phil - each chapter is written by a real-world F# expert and many of them use F# in production. The disadvantage is that they are all busy people, but we have close to half of the planned chapters available already...
One of the most amazing aspects of mathematics is that it applies to such a wide range of areas. The same mathematical rules can be applied to completely different objects (say, forces in physics or markets in economics) and they work exactly the same way.
In this article, we'll look at one such fascinating use of mathematics - we'll use elementary school algebra to reason about functional data types.
In functional programming, the best way to start solving a problem is to think about the data types that are needed to represent the data that you will be working with. This gives you a simple starting point and a great tool to communicate and develop your ideas. I call this approach Type-First Development and I wrote about it earlier, so I won't repeat that here.
The two most elementary types in functional languages are tuples (also called pairs or product types) and discriminated unions (also called algebraic data types, case classes or sum types). It turns out that these two types are closely related to multiplication and addition in algebra...
Back in February, I attended the annual MVP summit - an event organized by Microsoft for MVPs. I used that opportunity to also visit Boston and New York and do two F# talks and to record a Channel9 lecutre about type providers. Despite all the other activities (often involving pubs, other F# people and long sleeping in the mornings), I also managed to come to some talks!
One (non-NDA) talk was the Async Clinic talk about the new
in C# 5.0. Lucian and Stephen talked about common problems that C# developers face when
writing asynchronous programs. In this blog post, I'll look at some of the problems from
the F# perspective. The talk was quite lively, and someone recorded the reaction of the
F# part of the audience as follows...
When F# 3.0 type providers were still in beta version, I wrote a couple of type
providers as examples for talks. These included the WorldBank type provider
(now available on Try F#) and also type provider for
XML that infered the structure from sample.
For some time, these were hosted as part of FSharpX and the authors of FSharpX also added a number of great features.
When I found some more time earlier this year, I decided to start a new library that would be fully focused on data access in F# and on type providers and I started working on F# Data. The library has now reached a stable state and Steffen also announced that the document type providers (JSON, XML and CSV) are not going to be available in FSharpX since the next version.
This means that if you're interested in accessing data using F# type providers, you should now go to F# Data. Here are the most important links:
Before looking at the details, I would like to thank to Gustavo Guerra who made some amazing contributions to the library! (More contributors are always welcome, so continue reading if you're interested...)
After a few years, I finally managed to find the time to attend the MVP Summit this year. The Summit is an annual event where people who are active in Microsoft technical communities come to the Microsoft headquarters to learn about new things (and, of course, tell them how they should be doing their job :-)). The Summit is a great place to meet interesting people (so if you're reading this and will be there, definitely get in touch!)
The good news - for those interested in F# - is that I'll be doing two F# talks on the way. I'll stop in Boston on February 13 and then in New York on February 25. I'll be talking about different topics (Google tells me that the distance is only 216 miles!)