Entries:
Comments:
Posts:

Loading User Information from Channel 9

Something went wrong getting user information from Channel 9

Latest Achievement:

Loading User Information from MSDN

Something went wrong getting user information from MSDN

Visual Studio Achievements

Latest Achievement:

Loading Visual Studio Achievements

Something went wrong getting the Visual Studio Achievements

Comments

Tuomas Hietanen Thorium
  • Hewitt, Meijer and Szyperski: The Actor Model (everything you wanted to know, but were afraid to ask)

    Hi, nice video!

    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:

    • Actors
    • Agents
    • Message passing
    • Mailboxprocessors

    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...?

     

  • Tao Liu: F# Design Patterns

    Hello,

    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.

     

  • C9 Lectures: Graham Hutton - How To Be More Productive

    I will give five stars to every talk about y-combinator. Wink

    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.

     

  • Brian Beckman: Hidden Markov Models, Viterbi Algorithm, LINQ, Rx and Higgs Boson

    I also would prefer F#.

    But how about using ReSharper with C#?

     

  • F# 3.0: data, services, Web, cloud, at your fingertips

    Where do I get this Samples.DataStore.Freebase.dll ?

  • F# 3.0: data, services, Web, cloud, at your fingertips

    Nice. So will F# 4.0 focus on presentation? Wink

    How about transactions with type providers?

     

  • Anders Hejlsberg: Questions and Answers

     

    • 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).
  • Design Fundamentals for Developers

    You can watch this video also from Microsoft Toolbox tutorials.

  • C9 Lectures: Yuri Gurevich - Introduction to Algorithms and Computational Complexity, 2 of n

    As far as I understand, although functions and algorithms have the same "interface", the difference is that algorithms have(/include) states and functions does not, am I right?


    Both can have multiple sub-algorithms/functions.

    The problem of the sameness is just that we can't define the precise captured begin and end states of the algorithms,

    If the universe is the "main state"... The evolution is just an algorithm, state transforming to another through various sub-states.

    We can use monadic bind to combine functions, so that is also true to algorithms, right? (like in the PDC presentation of F# 3.0, which shows the similarity between compilers and search engines.)

  • C9 Lectures: Greg Meredith - Monadic Design Patterns for the Web 3 of n

    Nice lecture!

    Sounds like this key-value database algorithm to go back in time to resolve transactions is NP-complete, so I wonder if it really works in a large bank. Smiley

    ---

    That A => IOU(IOU(A)) will not guarantee IOU(IOU(A)) => A, can be seen with the type system: The input and output types of the function "=>" will be different.

    Speaking of types... Lecture's description of programming language hits some pain points of C#:

    interface ProgrammingLanguage 
    {  
     IEnumerable<Command> Keywords<Command>() where Command : Func<Command, Command>;
    }

    where the actual Command should be an option type of Func, Action or a Type, right?