Erik Meijer's MSDN Channel 9 lecture series on functional programming

Channel 9 has asked Erik Meijer to do a ground-up introduction to functional programming, because he and other MS programmers have spoken so much about its influence on the design of Visual Basic .NET and C#.

C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 1 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 2 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 3 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 4 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 5 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 6 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 7 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 8 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 9 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals, Chapter 10 of 13
C9 Lectures: Dr. Graham Hutton - Functional Programming Fundamentals Chapter 11 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 12 of 13
C9 Lectures: Dr. Erik Meijer - Functional Programming Fundamentals Chapter 13 of 13

New videos will appear every Thursday, and Erik has hinted that he (or someone at Microsoft working for C9?) will be checking the video comments for feedback on what reviewers want to see more or less of. Such interactive aspect is sort of unique, since most "Computer Scientists create Discovery Channel"-style videos are filmed at huge conferences or user group meetings (i.e., Rich Hickey's Clojure TV and Simon Peyton Jones' talks). Probably the most widely watched lecture series on functional programming today is Abelson & Sussman's course on Scheme at MIT, which uses the wizard book (Erik says he is using Graham Hutton's Programming in Haskell).

The webpage mentions Channel 9 has arranged with Cambridge University Press to give everyone 20% off either hardcover or paperback [which isn't necessarily the best deal you can find on the net]).

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

some notes

In video 1, Erik mentions C# has no REPL, but he wished it did.

This isn't true. Miguel de Icaza wrote one for Mono awhile ago, and it is used to help develop Moonlight.

Edit: I forgot to mention Joseph Albahari's LinqPad as well.

F#

After using the incredible F# environment in VS, it's almost like going back to punch cards and batch jobs when programming without a REPL....well maybe not that bad ;)

does it a little bit disturb anybody else

that it took Microsoft of all things to get the wonders of fp across to a bigger community? i mean, it seems like the progression of C#, LINQ, F# has done more to introduce to and indoctrinate people in the goodness of good fp stuff than any previous attempts. funny.

I blame Sun

..but then again, I blame Sun for everything ;)

Doesn't matter...

...if it doesn't run on Linux, then it's at a substantial ($$$) handicap to be run at web-scale. There's a reason Twitter and LinkedIn are using Scala, and not F# (or even OCaml). That's where to place your chips.

It does run on Linux

I'm not placing my chips on Scala. Then again, I'm not "placing my chips" on F# either.

Yes

I've been using F# a bit lately, and I have rather mixed feelings about it, technically speaking. I'm rather skeptical that moving from C to .NET as the least-common-denominator for intra-process language interoperability really is an upgrade.

Politically speaking, I have mixed feelings about it. On the upside (and it is a big upside) I really do not think that F# competes with Lisp/ML/Haskell. My belief is that it won't siphon developers away from these languages but rather grow the size of the community considerably. So that really does get me excited. On the other hand, you do occasionally hear or read incredibly obnoxious remarks that FP was never ready for prime-time until F# came along. But the remarks of a few small-minded ignoramuses is a pretty small downside, really.

For whatever reason, this kind of story repeats itself over and over again: microcomputers are mere toys until IBM blesses them, perfectly good 64-bit architectures with existing code bases must be replaced with AMD x64 that didn't have a code base before we could move to 64 bits, etc etc.

On the other hand, you do

On the other hand, you do occasionally hear or read incredibly obnoxious remarks that FP was never ready for prime-time until F# came along. But the remarks of a few small-minded ignoramuses is a pretty small downside, really.

I think this just means that F# provided a sufficiently low barrier to entry, ie. familiarity with the featureful .NET base class libraries, that ordinary C# developers could jump ship with less effort than jumping to SML, OCaml or Haskell. The learning curve is just so much lower, which is valuable in itself; the conclusion that SML/OCaml/Haskell is therefore not ready for "primetime" does not follow, though there are some legitimate concerns in this direction, most notably, the difficulties surrounding dynamics, ie. dynamic code loading, serialization, etc. These are heavily used features of the JVM and .NET.

Familiarity and perception

I think this just means that F# provided a sufficiently low barrier to entry, ie. familiarity with the featureful .NET base class libraries, that ordinary C# developers could jump ship with less effort than jumping to SML, OCaml or Haskell. The learning curve is just so much lower, which is valuable in itself; [...]

This is certainly part of it. After all, I'm biased in my reservations about .NET because I know C much, much better, so for me personally the learning curve for F# is relatively higher than say, learning OCAML better. (as I've mostly worked with SML)

Of course, there is also the issue of simply being endorsed by Microsoft as a full citizen in their product line. If nothing else, it makes it a much easier sell to certain kinds of bosses and/or customers.

Every implementation has it's strengths and weaknesses; with few exceptions, dismissing any given implementation out of hand for every possible application is silly.

No need for name-calling

On the other hand, you do occasionally hear or read incredibly obnoxious remarks that FP was never ready for prime-time until F# came along. But the remarks of a few small-minded ignoramuses is a pretty small downside, really.

That's below you, and not what Rauld said. Read again.

Re: name-calling

I was not referring to raould's remark in that sentence. The whole of my reply agrees with him. That remark was a tangential to the conversation, and I don't recall ever seeing the kind of remark that I referred to on LtU.

Compassion with Microsofts marketing department

A: F# what? What the f*** is this?
B: a functional programming language.
A: what about our other languages? Are they dysfunctional?
B: no it's just that in F# functions become pure or first class or something like that.
A: I don't understand.
B: I don't understand either but we shall sell it.
A: Oh...

silence

A: does anyone use those functional programming languages?
B: not that I'm aware of. No ... Yeah, computing scientists use them a lot and they have been a source of inspiration for LINQ!
A: Yeah, LINQ is cool. But scientists... I don't know.
B: We can say "F# is a revolution".
A: We always say this about everything but we don't sell our products to scientists.
B: Hmm...
A: What about "With F# functional programming is ready for prime time!"?
B: Wow, that's great! Now, all those office guys will listen.
A: The scientists will be offended but ...
B: ... but who gives a shit?
A: Done.

Can I play?

I'll start off with your initial A

A: F# what? What the f*** is this?
B. It's based off a language that eggheads in academia use
A. And why are we productizing this?
B. The same reason we spend lunch money to have a few guys work on .NET version of Ruby and Python
A. What's that?
B. Something the open sores play with on Linux
A. How does this make us money?
B. It probably won't, but remember when we got caught with our pants down in the mid 90s regarding the internet.

silence

A. So what's the difference between this and all these other new-fangled thingies that the eggheads are playing with?
B. We actually provide a proper environment to program in it.
A. Environment?
B. Yeah, we provide intellisense and all the other cool stuff that is in Visual Studio
A. Can't they just use Emacs?
B. Emacs????
A. Does any of this matter?
B. No, but we don't want to look like Sun and Java
A. Done.

+1 to parent. A

+1 to parent.

A contemporary language is considered beyond its syntax and a compiler, be it F# or Scala--really good tools are needed to support that language, which requires real resources. Any commercial company deciding to dedicate resources to functional programming should be considered a good affirmation of FP (disclaimer, I work for MS). FP can and should evolve beyond its ivory tower and specialty programming niche to become more mainstream.

Why FP getting more interest now? Multi-core, GPUs have changed the rules of the programming game and imperative doesn't cut it anymore. Many companies are looking at ways of dealing with this, and FP is becoming a major contender for the solution problem. This battle is very important, because the other primary contenders are C/C++-throwbacks (CUDA, OpenCL, HLSL Compute).

Basically, nobody realizes

Basically, nobody realizes how talented the folks at MS Research are. Only recently are a lot of long-term initiatives paying off (i.e., CHESS, Terminator). Craig Mundie seems to be doing a great job.

Why is this disturbing?

I'm not sure I understand exactly what evokes disturbance here. Can you elaborate? In terms of functional programming trickling into the mainstream general purpose programming community, well, it's trickling.... Microsoft entering the functional evangelism game means more of a sustained flood than a constant drip.

Charles

speaking for my self

[warning/apologies: longish, rantish...]

[edit: summary: NIH pisses me off!]

i worked at msft for just under 5 years, using C/C++/C#. of course i did not get a feel for the entire culture, and i was not working at the Redmond (mothership) site. but my opinion of the core culture was that i was not overly impressed with the day to day use of useful, important, or advanced techniques from the PLT arena. it did happen sometimes, but it was pretty rare. i am not that big a PLT nerd and yet i was the "roll our eyes at the haskell guy" receiver. :-) so i was surprised that it started happening at MSFT outside of MSR. good going, MSR!! keep it up.

it is disturbing to me in that (a) it took so long for PLT to get anywhere main-stream (b) there were so many opportunities for it before from "non-evil" if you will (i realize that is not really a relevant subject for LtU but it is in my thinking in this topic anyway) places which apparently for the most part utterly failed to gain traction (c) history is written by the juggernauts: the msft devs will claim they are doing this new wonderful thing that sorta nobody has apparently ever done before and we should love them for it.

i went though this with C#/.net; i was doing training as an MSFT employee to learn up on .net and i felt (and others in the class who were language nerds did too based on their comments in class at the time) that the attitude was "we just invented garbage collection! bow to us!" rather than "wow, there are these great ideas that have been out there for ever, that a zillion other people have done a lot of groundwork on, here we are standing on the shoulders of all those previous people, let us take a moment to think about them and thank them -- oh and we have a few additional Good New Ideas of our own that we modestly want to introduce to the world."

oh well. at least it is happening at all. (although that kinda sucks because there goes one of my secret weapons!)

This doesn't reflect my

This doesn't reflect my experience, spend any amount of time with the Microsoft PLT guys and you'll find that they are pretty well versed with what's out there, most of them are strong PLT'rs with well known backgrounds (e.g., Erik Meijer). Your experience in the classes was probably with professional teachers who in general are getting paid to teach to the mostly clueless. You weren't the intended audience, and in general I try to avoid those classes like the plague, because I'm pretty sure I would react in a similar way.

I'm going to guess that a lot of the recent FP promotion coming out of Microsoft is aimed at Microsoft's core developer audience, which hasn't been very accepting of FP in the past. They are catering the message to this audience, and again this audience is definitely not you or me. But expanding the FP tent is good for everyone as it will eventually give us PLT'rs more of an audience for our work.

i don't disagree

i guess another way of saying what i feel is that MSR is very different from the rest of MSFT, and it is good that MSR is getting things out to the world, but it is annoying that it goes through the "we invented this all on our own!" NIH filters that i think MSFT has in spades.

but i'm not contributing anything PLTy here, so i'll shut up now.

"Laziness" never explained...

So, first I applaud EM for this series. I've watched the first two.

But if I didn't really "grok" strict vs. lazy evaluation (to the extent I do), his mentions of how Miranda, Haskell, etc. implement pure, lazy functional programming would've been _lost_ on me. I think a lot of his viewers really don't understand why laziness is so important.

(I'm not taking a stand on strict vs. lazy per se, but that at least people ought to be _exposed_ to the lazy evaluation side of things. FP is important in doing this.)

I sometimes mention to my programmer friends the "Star Trek" interpretation of this point. I talk about how a Captain Kirk might give an instruction to "Computer" (!!) to consider the set of all prime numbers, how Computer would crunch for a while, and then "overload" with a "That does not compute!" error, perhaps with an episode-saving puff of smoke coming out of Computer.

My friends laugh, because they know deep down that "the set of all prime numbers" does not actually require iterating them all (!) and only then proceeding to the next step. They know that math is basically _lazy_, that a name for something is not the same thing as evaluating that something completely. (Topologists understand this point even more clearly, and I often think Haskell is fundamentally a topology language. The work of Martin Escardo and others comes to mind.)

When I show them a bunch of examples with list comprehensions, guards, and other lazy-centered tools from Haskell, their reaction is often "Yeah, this is how things ought to be. So, why aren't all languages like this as a default?"

I think Erik never got into why laziness is so important, and so missed a big part of why the lazy, functional languages are so interesting.

But, hey, it's still nice to see _ANY_ such lecture series on FP.

--Tim May

Lazyness will be the subject

Lazyness will be the subject of a lecture in its own right later on (chapter 12).

reality is tricky

Doing things explicitly and as soon as they are mentioned is a nice way to let the programmer be able to predict what on earth their program will actually do when it runs. There's a fair bit of wailing and gnashing of teeth over "oh this laziness just blind-sided me" I feel, even if it is so very appealing from a math/purity standpoint.

There's a fair bit of

There's a fair bit of wailing and gnashing of teeth over "oh this laziness just blind-sided me" I feel

Not about semantics in a pure language...

not sure i follow/agree

cf. reported confusion in Haskell; maybe the semantics are defined but are too confusing and liable to change for mere mortals to keep correctly in mind all the time?

Don't be hasty about laziness

It can be difficult to reason about pervasive laziness in some cases, but it's also difficult to assess that properly from the perspective of intuitions and preconceptions gained from working mostly with strict languages. A lot of the "confusion" about laziness seems to be due to that bias.

Haskell shows quite clearly that both laziness and strictness are useful, in the same program, so if your conclusion about confusion due to laziness is that laziness should be avoided, I'd disagree.

Instead, I think that languages and tools could help more with managing laziness. Don't forget that Haskell is a testbed for this kind of thing, and that approaches to dealing with it are evolving.

The runtime semantics are

The runtime semantics are fairly important; not sure what you mean by 'semantics'. As I write programs for people to run, I need to know around when my program terminates (and if it does). Laziness is a syntactic boon for many control patterns... but, apparently, also a curse. The concurrent discussion on SequenceL and my experience with transparency ('lifting') in FRP are similar: global transformations give you a lot, but often at a steep expense that we are too quick to trivialize.

Both...

...call-by-value (and call-by-name) have compositional performance models: you can calculate the performance of an expression in terms of the performance of its subterms.

This is not true of call-by-need, since the run time of an expression depends on whether or not its thunk has been evaluated already, or not. In other words, you have to reason about aliasing in order to reason about performance!

Updated

I've updated the OP to fill-in the rest of the series.

List of books mentioned in the lecture

Does anybody have the list of books shown in the Video 13 of the FP lecture series ?