Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming | Going Deep

Matthew Podwysocki is a senior consultant for Microsoft platform technologies in the D.C. area. He's been programming since he was a child and has a particular interest and passion for functional programming. Functional programming is all the rage these days. General purpose imperative languages (like C# and C++) are adding functional constructs to help improve software developer prodcutivity in an increasingly concurrent general purpose computing environment as notebooks and PCs with multiple processors are now the norm.

Matthew was in Redmond a few weeks ago, so we thought it would be awesome to invite Matthew into the the lair of our resident functional programming extremist (though I must say that Erik is mellowing out with age), high priest of the lamda calculus, category theorist and Expert to Expert host, Erik Meijer. Now, it's a little scary to be asked into Erik's den of functional orthodoxy (aka Erik's office) and be put to the task of explaining functional principals in a way that is widely accessible to developers who have little or no experience with thinking functional, but Matthew was up for the task and spends most of the time at Erik's whiteboard explaining important functional programming concepts (Haskell and F# are the languages used in the examples, but the language isn't that important - the concepts are), sharing some his very interesting history with us, waxing on future directions in programming, engaging us in a really interesting conversation. Great job, Matthew!

Enjoy!

Duration: 1:07:41

Follow the Discussion

Follow
Oops, something didn't work.

Try again?

Sign In to be begin to follow these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in. You need to be signed in to Channel 9 to use this feature.

Getting "follow" information

Stop following these comments

Start following these comments

What does this mean?
Following an item on Channel 9 allows you to watch for new content and comments that you are interested in and view them all on your notifications page.

Removing your "follow"

Setting up your "follow"

Did you know you can
sign up for email notifications?
- Subscribe to this comments

cdwatkins

Mar 24, 2009 at 3:42 PM

You talk alot about the Maybe monad, but you never mention the Nullable type in c# that I think is the same thing. Both say there might be a value or there might not be. The one thing I think c# does need is just to have a "pure" modifier (like the static modifier), which doesnt allow any side-effects by not allowing access to the global and local store (just like the static modifier doesnt allow access to the local store of the object). And then add a new type (like Action or Function) which would be a PureFunction, so that can you pass a pure function as an argument.
Jules.dot

Mar 24, 2009 at 5:39 PM

How are F# Asynchronous Workflows and Futures related? Could you implement asynchronous values with the same interface as futures/lazy values/promises?

For example, assuming we have a promise library with these operations:
1) p = new Promise() creates a new promise
2) p.value <- val assigns val as the value of the promise
3) p.value returns the value of the promise, or blocks the thread if nobody assigned a value yet
Pseudo code:
class Promise<T> {
private T _value;
private handle;

    public Promise() {
      handle = new ManualResetEvent(false)
}

public T value {
    get { handle.WaitOne(); return _value }
    set { _value = value; handle.Set() }
}
}
You could implement a download function like this:
download :: string -> Promise<Stream>
download url =
    let p = new Promise()
    let req = HttpWebRequest.Create(url)
    req.BeginGetResponse(res => p.value <- res) // ommited boilerplate to extract the stream here
    p
Use it like this:
let page1 = download "foo.com"
let page2 = download "bar.com"
print page1.value
print page2.value
You can extract a pattern. If you have a value of type a, but the value is asynchronous (like a web page); it's really a function that you give a callback to:
simple value: b
async value: Async<b> = (b -> ()) -> () // (b -> ()) is the callback
So it's a like a request in the above example: you don't have the actual web page, but you have a function that you can call (BeginGetResponse) and this function calls your callback when the web page arrives.

We can extract the pattern of taking an async value and producing a promise out of it.
async :: Async<b> -> Promise<b>
async ayncval =
    let p = new Promise()
    asyncval (val => p.value <- val)
    p
And implement download like this:
download url = async HttpWebRequest.Create(url).BeginGetResponse
Or if you don't support partial application:
download url = async (callback => HttpWebRequest.Create(url).BeginGetResponse(callback))
Why did the F# team go for asynchronous workflows instead of this approach?
N2Cheval Why not null?

Mar 24, 2009 at 8:15 PM

cdwatkins: I also was thinking about the NULLable type in alternative for the Maybe monad, except that it doesn't contain the exception information for why it failed.

Back to a more line of business view of things, Eric talks a lot about Haskell from the "everything functional" point of view, but where do you draw the line in the sand on what to use in the real ".Net" world; F# or Haskell? Especially as Haskell has the .Net libraries.

I like what Matthew said about all a programmer really wants to do is a put/get and have the syntactic sugar handle the boiler plate coding for the processing of the exception. Even with Haskell (while I've not touched it since for some time) I haven't see how easy it is to process exceptions. It appears that it's designed for a perfect world that doesn't have exceptions. Is that really the case?
littleguru <3 Seattle

Mar 25, 2009 at 3:33 AM

I hope Erik wears glasses during his lectures here on Channel 9. And he definitively needs a beard!!

I loved this interview! Great stuff guys... keep on teaching.
aL_ Kinect ftw

Mar 25, 2009 at 5:01 AM

dont forget the elbow-pached tweed jacket

awsome stuff! what i really like about erik is the uncondecending tone of all his interviews, its only about relaying understanding looking forward to more of those conceptual talks
vieillevigne

Mar 25, 2009 at 2:21 PM

Regarding Haskell and exceptions, may I suggest Real World Haskell chapter 19? You might also want to read Simon Marlow's paper on extensible exceptions, the latter being realized in GHC 6.10.1.
N2Cheval Why not null?

Mar 25, 2009 at 8:05 PM

Thanks for that viellevigne, it was very interesting. It leads me to think why we could not have inline Haskell or F#?

Real World Haskell
MatthewPodwysoc

Mar 25, 2009 at 9:22 PM

Thanks! I had a lot of fun doing this talk. I hope we captured a bit of what I like to talk about on my blog and during my talks at various conferences. Hopefully I'll be around here again!
MatthewPodwysoc

Mar 25, 2009 at 9:25 PM

Well, there are two ways about handling failures. There is the use of the Maybe Monad which states that you have Just the value or Nothing at all. But sometimes, we want to be a bit more explicit than that. For example, we may want an error message, or in the case of F#, the actual exception itself, or the return value from the function. If you use the Async.Catch function from the F# Async Workflows, it is exactly that which either returns the computed value or the exception should one occur.
MatthewPodwysoc

Mar 25, 2009 at 9:36 PM

In a way the Maybe is like the Nullable type, but it's a bit more than that since it's a unifying type which says what has a value and what does not for both reference types and value types.

Your thoughts around pure actions and purity is interesting, but since C# is a first class object oriented language with many imperative features, it's hard to bolt on such concepts as immutability (deep and/or shallow), purity, side effect free functions and so forth. With the utilization of Code Contracts for .NET 4.0, we could get part of the way there, but for the most part, any checks for purity are mostly just suggestions and not enforced. Instead, concepts such as these belong in its own language, for which F# is well suited on the .NET platform. Although there are projects to bring Haskell to interoperate with .NET hs-dotnet.
MatthewPodwysoc

Mar 25, 2009 at 9:41 PM

The approaches are similar and both the Task Parallel Library and Async Workflows were originally developed mostly independently and for different reasons and have different audiences. There are certain things that TPL cannot do that F# async workflows can such as multiple downloads without any blocking threads. Promises block at the .Value property call.

As for unifying TPL and Async Workflows remain to be seen and it may happen. I can't speak for the F# team on this one although we do like to talk often enough.
danielearwicker I used to be language agnostic, now I'm language atheist

Mar 26, 2009 at 8:52 AM

Given that reference variables can already be null or else point to something useful, don't they already have what is needed to represent the maybe monad? All that's lacking is the convenience of bind. An extension method can act as the bind operation and that's all you need, isn't it? Or have I missed something (I'm relatively new to Haskell!)
sylvan

Mar 26, 2009 at 11:03 AM

There is a very important difference, and it's that reference types don't prevent you from calling a method on something that's null.
In haskell, if you try to pass a Maybe String to a function that accepts a String, you'll get a type error. In C# every reference typ can be null, which means that a function that takes a string may have to make do with a null instead. There's no way of saying that you do not want to accept a null reference to a method (and get static checking for that) because there is no notion of "non-nullable references" in C#.

It seems that a lot of people, including Tony Hoare who invented null pointers and members of the C# design team IIRC, now agree that "nullable by default" was a mistake, and that regular references should not be allowed to take a null value, instead you'd have to explicitly annotate a type with a ? (or something) to indicate that this reference may be null (and there would be some syntactic construct for "unpacking" a T? into two branches, one which gets passed a T and one which has to deal with what to do if the T? was null).

To bad that changing this would probably be way to cumbersome considering existing code (e.g. the entire framework!), but there's definitely value in being able to eliminate (statically) any chance of null pointer exceptions by just splitting the two concepts "reference" and "nullable" into two parts rather than conflating them into a single concept.
danielearwicker I used to be language agnostic, now I'm language atheist

Mar 27, 2009 at 4:29 AM

Yes, I saw that Hoare quote. That's the same conclusion I get to in that blog post, i.e. "It's not immediately obvious that it is [a bind function], because a Bind function talks to its caller in terms of values wrapped in the monad, but deals in "naked" values with the function passed to it. But IfNotNull uses ordinary reference variables in both situations. This is because there is a feature missing from C#. It ought to be possible to somehow tag a reference variable to say that it is definitely not null."

In Spec# they used MyRefType! (exclamation suffix) to mean non-nullable; so the default is wrong but they were aiming at backward compatibility with C#, so they had to go that way. And then they would just look for an if (myVar != null) and silently make myVar non-nullable within the truth block.

It looks like the closest we'll get to this in real C# is the Code Contracts library in CLR 4.0, but I really wish non-nullable was the default. Unfortunately it complicates the syntax in some areas (where should non-nullable instance fields in a class be initialized?) but it would surely have been worth it, as Hoare says.
Justin Bailey

Mar 27, 2009 at 1:54 PM

I ran out and got a copy of Intro to Functional Programming after watching this. I can't wait to see Erik's lectures. Always interesting!
danielearwicker I used to be language agnostic, now I'm language atheist

Mar 28, 2009 at 2:35 PM

I love the way Erik says "Func" at about 10 minutes into the video. It reminds me of the classic "Rock Me Amadeus" by Falco!
Charles Welcome Change

Mar 29, 2009 at 1:14 PM

Excellent. I've been reading my copy too. You'll see the first in the lecture series soon. Waiting for some white boards to arrive for use in the studio. The format for this will be different than my usual style. I plan on shooting these in our studio.

C
hecUngravity Hec

Apr 04, 2009 at 1:20 PM

Hello guys

this video on Perspectives on Functional Programming aside from being as totaly interesting as with all the other related videos had the nice thing of showing some recommended books to get more information on where to do more research on your own was fabulous.

I think it would be nice to add some way of letting c9 users to contribute on each videos pointing to other sources where to find information, like some webcasts, videos, articles, books (in the same post screen) so people can have a quicker access to other recommended material and shorten the time spent in searching for the correct information on the internet.

Great work your doing, i find it fantastic

best regards
hec
codebliss

Apr 07, 2009 at 9:45 AM

Thank you Erik Meijer and Matthew Podwysocki! =). I just began looking into F# (and even more recently, haskell) and felt like I wasn't understanding monads. While Brian Beckman's "Don't fear the Monads" gave me a great introduction to understand monads, your example completed the understanding for me.

The best part of the video, in my opinion, was how you revealed that C++ is like a giant state machine. I never thought of this, and this idea you presented made monads finally "click." As C++ is basically one giant state, in which it is assumed that each operation produces side effects, finally got it to fit in. My problem was that since I came from a mostly imperative background, I really didn't understand what pure really meant. If you were to ignore the current technological limitations such as division by zero, explaining what the tail of an empty list would be, etc, then there would never be a single issue arising from any operation in a pure haskell function!

Thanks again for the info, and especially for the maybe monad and C++ ideas. You guys explained it perfectly =D
perf

May 04, 2009 at 7:58 AM

It's always very interesting to see a video with Erik Meijer. Such a lively talking man!
A N Satrawala

May 30, 2009 at 12:40 AM

I am into moving into functional programming (Haskell, F#) for the last few months. I have read Expert F#, Real World Haskell etc.

I am liking the ideas and styles and started coding some fun stuff with great things there in F#.

I was disappointed by the quality (succinctness and clarity) of this video compared to other numerous videos which I have seen from c9 or msdn. (Maybee worst of all which I have seen) Sorry, Matthew and Eric, but I missed the flow and stopped watching the video in the middle.

I am sorry if I am rude but I got one point from this lecture that intellisence is some kind of bad thing. The examples could have been given either in pseudo code (without any reference to syntax) or with correct syntax of either F# or Haskell.
amir129

Nov 07, 2009 at 11:12 PM

does anyone know where i can find "Introduction to functional programming" book? amazon.com don't have.

Is this the correct ISBN #? 0134841891

cheers,

amir