This important subject has got a lot of attention lately. I'll expect some interesting conversation here (or maybe part 2)...
With F# I have used the type mailboxprocessor, often called agent model.
I googled the differences between actors and agents, and the result was not completely in sync with this video. So what are the differences of these terms, or are they equivalent:
As far as I understand: the main difference of agents and actors (which both are implementations of message passing) is between the control: actors control themselves while agents are controlled from somewhere outside.
Hewitt said it would be a miss-understanding to see actors as event loop (OO-programmer may refer event loop as CQRS Event Sourcing), because actors know their internal state. Is that the only difference? From the outside view they are pretty close though, aren't they? For example: Reactive Extensions has this class ReplaySubject. I use it and it works. But do I know if it uses actor model or event loop inside...?
First of all, thanks, F#-team is making a great job. And these kind of videos are good to get a great language some attention.
But I have some small critics to these samples... Samples teach programmers so they shouldn't teach bad things. They should teach best practices, not tricks or hacks.
Tricks are good to know also... But maybe these samples could be divided to two sections: 1. howto, 2. tricks.
1. Why to teach programmers to use mutable state so much? There is a very good reason why mutable state is not default in F#.
2. Why using inline keyword in samples? Inline is usually just for interactive. Msdn says this: "you should avoid using inline functions for optimization unless you have tried all other optimization techniques". So why do we need this in basic samples? http://msdn.microsoft.com/en-us/library/dd548047.aspx
I'm F#-programmer, and one of those who thinks that Design Patterns are common "best practice" ways to manage object-oriented problems that doesn't exist in functional language.
I will give five stars to every talk about y-combinator.
The explanation of subject of how-to-make-a-next-item vs. what-is-the-formula is not trivial for basic mathematics school-teachers, so it may need more research.
But I wouldn't say that "generator function" (that makes next items) are plain easier. They may seem easier to construct (as their construction process is usually imperative), but... It doesn't mean that you will find the right pattern-match by accident.
Is this "not support for non-nullable-reference-type" a c# or clr feature?
Currently in enterprise software the case is often that we would need some common functionality without knowing the exact type. When we don't have higher order types this usually leads to reflection (and runtime-errors).