October 26, 2009

Functional programming, monads: links

Recently I started paying much more attention to functional programming - this happened after a long talk with one really clever guy at our city's developers forum. Let's call him "Amateur Programmer" (this is his real nickname translation; I'll use "AP" to refer to him further). Certainly, he isn't amateur at all, moreover, he made few good talks at our users group. So... We've been discussing lots of topics related to software development in "is this good or bad" fashion, and our view was quite different on almost any different point. I'll list few examples:
  • I think granting the people a simple way of developing their own DSLs is generally bad. Not because DSLs are unnecessary, but because such an opportunity may lead to an explosion of count of DSLs in applications, and consequently, to explosion of count of absolutely crazy ways of writing programs (language design is complex!). So e.g. I don't pay much attention to Oslo's M, as well as JetBrains' MPS. Obviously, not because they're useless, but because they are intended for pretty small subset of developers and companies. In short, I like the beauty of C# (with lots of exceptions :) ), and generally I would prefer to avoid dealing with any home-made language. AP was strongly protecting DSLs.
    Side note: later I understood we're actually talking and even thinking about the same, but our origin points are different. So as it frequently happens, the truth was in the middle.
  • I'm OOP fan. AP is FP (functional programming) fan; moreover, he generally exposed a point that OOP is wrong way of software development at all. That was pretty strange, because I knew he programs mainly on C#. On the other hand, my view on FP was nearly the following: "it must be used when it really matches the task best; but I can't admit I'd use it without OOP practices". Moreover, I clearly understand that e.g. concurrent programming is where FP looks is the best match.
    Side note: the same :)
There were other less interesting topics - e.g. we've been discussing RUP, UML, complexity of LINQ provider implementation and so on. What's the most important is that he gave a link to monadic parsers combinators in C#. I read this article and felt there is really something new for me. In fact, I felt there is a very generic concept (monad) I know almost nothing about. Moreover, we touched HaskellDB (AP's point was: HaskellDB is in fact, LINQ analogue in Haskell, and since it is just 200Kb, implementing LINQ translator must be much simpler in Haskell, so FP rules). What was really important for me here is that I discovered that Erik Meijer (known as architect of LINQ) was one of its co-authors - take a look at slide 6 here.

So this was enough for me to start looking up everything related to monads, F#, Haskell and FP in general. I was even astonished a bit I was ignoring this field for all the years I graduated from the university. That's what takes some of my free time during last 2 weeks ;)

My current conclusions are:

1. FP is what you must start studying right now - I think clearly understanding monads is what I'd call minimum here. Speaking shortly, FP times have came. Its upcoming application areas:
  • Asynchronous programming. Likely, you know, that pure FP programs are intrinsically concurrent, because there are no side effects. Take a look as async monad in F# as well. If you aren't sure if async programming is really important, think what's increasing during last 5 years: the count of CPU cores, or CPU frequency. Free lunch is over.
  • Monads. They're native for FP languages, and provide really powerful abstraction for dealing with side effects safely. I was quite surprised to know that e.g. IEnumerable<T> is just a particular implementation of monad. Since I'm not feeling myself fully comfortable in this area, I'll just give you some links related to further. But I can promise you it will be at least really interesting to study this.
  • Integrated DSLs. Functional style favors building DSLs integrated into a "host language" (i.e. fully based on its syntax). You may look at LINQ as DSL built for dealing with sequences in C#; Rx Framework is the same DSL built for events. You shouldn't build neither a king of execution platform for such a language, nor compiler, its libraries and so on, but you may use all the stuff offered by the host platform there. Obviously, that's great. That's the "truth in the middle" about DSLs I was talking about :)
2. Haskell is highly recommended language to start from - every FP guru talks mainly on this language, so you'll need it to understand even C9 videos related to FP and monads ;)

3. F# also worth studying - at least because it is primary functional language on .NET. It is quite close to pure FP languages by offered features (but it can interact with imperative ones via .NET platform), but nearly as fast as C#. Likely, you won't need it on practice - C# is "functional enough", and as all of us seen, it constantly moves to functional direction (btw, that's one more reason to study FP fundamentals). Likely, C# will anyway be the mainstream language on .NET. But this does not depreciate F# - it's simply useful to know and understand it.

4. It's simply wrong to set OOP oppositely to FP, so don't worry much about usability of your existing knowledge. Contemporary FP languages supports all you know in OOP (F# and Haskell are not exceptions here). But they push you to use a bit different way of thinking about programs you write. FP is opposite to imperative programming (which really becomes less and less interesting), and OOP is a kind of extension to both of these techniques allowing you to describe real world entities more conveniently. That's the second "truth in the middle" I was talking about.

The most interesting part - the links:

Free lunch is over. That's for those ones who isn't fully convinced programming techniques we use now are going to change. Not in future - they're changing right now.

So you're curious, what is a monad? Here is a very short answer @ stackoverflow explaining this. At least this will give you a kind of short introduction. To fully understand why they have appeared in FP and bind the description with practice, take a look at the description of IO in Haskell.

Let's bind this to your existing C# knowledge now. The Marvels of Monads and Functional .NET - LINQ or Language Integrated Monads? - good articles to start from. You'll learn that IEnumerable<T> is just a particular example of monad, but LINQ syntax in C# allows you to deal with generally any others of them.
    I suspect now you are either even more interested, curious and eager to learn, or have already decided to leave this for some future studying (btw, that's pretty reasonable as well). So if you're facing #1 case, here are great C9 videos explaining this:
    Finally, you should take a look at the following categories at Channel 9:
    Have a nice trip ;)

    P.S. If you work @ Xtensive, the videos can be found at "\\Storage\Media\Video\IT\Functional Programming".