Comments

thanks charles for all the super videos ... keep it going!

Recently did a poc with F# and Solver Foundation for an optimization model for part purchasing.

The model's input data comes in multiple Excel files.

F# came in really handy for the complex data manipulation that was required to take the source data and feed it to the solver foundation model.

Data manipulation is one of the areas where functional languages do exceptionally well. Such processing would have been untenable with Java (and even C# despite LINQ).

Suffice is to say that the PoC is very well received and has already saved the company mega bucks.

Very nice.

I could use the 'show' and 'freebase' samples for some internal demos coming up next month.

Will these be posted anywhere?

@AceHack:

F# has a DSL for monads called Computation Expressions so monads 'look' different in F#. Also, I think that once you have a monad implementation, the DSL makes it easier to use the implementation in your code.

So F# provides some extra language support for monads.

However, unlike Scala, F# does not have higher-kinded types so you cannot compose two monad implementations together (as easily).

I struggled with monads at first but then I realized that monads are really about function composition. Here is blog post that emphasizes this aspect of monads that may help with the understanding:

http://fwaris.wordpress.com/2011/07/30/understanding-monads/

Nice interview! Looks like C# is turning out to be a great language.

For now though, I am enjoying the succinctness of F# without losing anything. I have to admit learing F# was harder than I thought as I did not have a funcitonal programming background.

My question is more appropriate for the CLR team but I will ask anyway. It seems that OO-based platform (such as CLR and JVM) are not super optimized for symbolic computing (I learned while reading "F# for Scientists" by John Harrop). Are there any plans for supporting symbolic computing more efficiently? To be honest I don't even know what that even means in terms of CLR changes. I suspect it has to do with creation and garbage collection of extra objects that perhaps can be avoided if the CLR is further optimized for functional languages.

Considering that both CLR and JVM have added special support for dynamic languages (so that dynamic method dispatch is optimized) can something similar be done for F# and other functional languages (Scala and Clojure)?

Interesting classification of algorithms into linear, parallel, etc.

I suppose in future we will have to contend with quantum algorithms (as in quantum computing).

Here is an interesting talk on a quantum algorithm that is supposedly faster than its classical equivalent.

http://www.youtube.com/watch?v=gKA1k3VJDq8

Wonderful series!! I can see now where Greg is headed. He has yet to deliver the punch line so I am waiting in anticipation.

Two comments:

a) I think it would help to have a touch screen or something so that when the presenter 'points' to the screen, the pointer can be recorded in the screen capture as well.

b) Greg looks like he has been working way too hard. My suggestion is the have him in check into the nearest day spa for a full day of pamering. Go ahead Greg you have our permission.

For a practical example of monads (my first one!) see http://fwaris.wordpress.com/2010/11/08/a-monad-for-com-interop/

I think Greg's lectures are a wonderful education for us. Thanks to Greg and Charles. Please keep them coming!

It seems that Greg is a propnent of Scala and it is one of the languages on my list to learn.

The major issue with Scala is that the JVM does not support tailcall optimization (the CLR does).

Not having tailcall optimization is a serious limitation for functional languages. Scala does create loops out of simple recursive calls but in complex composition it can still run into stack overflow issues.

For an illustration of complex compostion involving tailcalls, see the monad implementation example in F# 2.0 language spec (http://research.microsoft.com/en-us/um/cambridge/projects/fsharp/manual/spec.pdf) page 60, definition of "catch".

Scala can't be a serious contender unless the JVM gets tailcalls - or it is ported to .Net.

F# async{} workflow (monad) and MailboxProcessor<'T> do much of what is being described here - except for retry of messages.

The F# workflow syntactic sugar makes writing async code almost like synchronous code.