Posted By: Charles | Mar 24th @ 8:50 AM | 46,806 Views | 22 Comments
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
Rating:
4
0
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.
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
N2Cheval
Why not null?
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
littleguru
<3 Seattle
I hope Erik wears glasses during his lectures here on Channel 9. And he definitively needs a beard!! Big Smile

I loved this interview! Great stuff guys... keep on teaching.
aL_
aL_
Rx ftw
dont forget the elbow-pached tweed jacket Wink

awsome stuff! what i really like about erik is the uncondecending tone of all his interviews, its only about relaying understanding Smiley looking forward to more of those conceptual talks Smiley
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
N2Cheval
Why not null?
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
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!
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.
Microsoft Communities