Comment Feed for Channel 9 - Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programminghttp://video.ch9.ms/ch9/835c/c06466b8-aa22-44f9-9ff4-4d9d8d6f835c/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-o_100.jpgChannel 9 - Erik Meijer and Matthew Podwysocki - Perspectives on Functional ProgrammingMatthew 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&#43;&#43;) 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 enSat, 25 May 2019 14:53:54 GMTSat, 25 May 2019 14:53:54 GMTRev9Re: Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming
posted by cdwatkins]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633735313360000000
Tue, 24 Mar 2009 22:42:16 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633735313360000000cdwatkinsRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional ProgrammingFor example, assuming we have a promise library with these operations:

1) p = new Promise() creates a new promise2) p.value <- val assigns val as the value of the promise3) p.value returns the value of the promise, or blocks the thread if nobody assigned a value yet

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.

Why did the F# team go for asynchronous workflows instead of this approach?

posted by Jules.dot

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633735383950000000
Wed, 25 Mar 2009 00:39:55 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633735383950000000Jules.dotRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional ProgrammingBack 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?

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736383500000000
Thu, 26 Mar 2009 04:25:50 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736383500000000MatthewPodwysocRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional ProgrammingYour 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.

posted by MatthewPodwysoc

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736389900000000
Thu, 26 Mar 2009 04:36:30 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736389900000000MatthewPodwysocRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional ProgrammingAs 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.

posted by MatthewPodwysoc

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736392670000000
Thu, 26 Mar 2009 04:41:07 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736392670000000MatthewPodwysocRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming
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!)

posted by danielearwicker

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736795650000000
Thu, 26 Mar 2009 15:52:45 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736795650000000danielearwickerRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming
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.

posted by sylvan

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736873880000000
Thu, 26 Mar 2009 18:03:08 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633736873880000000sylvanRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming
[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.

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 regardshec

posted by hecUngravity

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633744732440000000
Sat, 04 Apr 2009 20:20:44 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633744732440000000hecUngravityRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional ProgrammingThe 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

]]>
https://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633770459390000000
Mon, 04 May 2009 14:58:59 GMThttps://channel9.msdn.com/Shows/Going+Deep/Erik-Meijer-and-Matthew-Podwysocki-Perspectives-on-Functional-Programming#c633770459390000000perfRe: Erik Meijer and Matthew Podwysocki - Perspectives on Functional Programming
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.