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

David

David Kyrae

Niner since 2010

  • The Roslyn Project - Meet the Design Team

    @terrajobst: Yes, that's what I am referring to (Anders used the term persistent in the interview so I used it as well). Good to hear it's comming. Altho, I found out F# already has an implementation of an immutable map so I think I will stick to that in the mean time.
  • The Roslyn Project - Meet the Design Team

    Cool stuff.

    It would also be very nice if the persistent structures used in Roslyn were made available in the BCL. Would be very nice to have something like System.Collections.Persistent.PersistentDictionary<Key,Value>.

  • Orleans: A Framework for Scalable Client+Cloud Computing

    @felix9: Let's not resort to name calling ... but would be more fun if they actually called it Promise<T> Wink

    Also the distinction between AsyncCompletion and AsyncValue<T> seems not needed: could just use AsyncValue<Unit> for that. I think that getting someone in the team with more functional programming background would greatly help the project (this is in no way saying the project is bad). 

  • Orleans: A Framework for Scalable Client+Cloud Computing

    Cool stuff. 

    Can't wait to see it "finished" and integrated with LINQ/Rx/"await".

  • Bart De Smet: LINQ to Z3

    This is very nice.

    But what I am really looking forward to is LIM to "compiler service" when it comes out. It's going to be pretty cool to compose run time generated programs. And something tells me this is what Bart is secretly working on since his blog post about LINQ to Z3 is from April 2009 Smiley

  • Lucian Wischik: Inside VB.NET Async and Customizing Awaitable Types

    I really liked the last question, because I have run into small problems with it.

    It was actually Silverlight C# code and it went something like this...

    I had I SaveFileDialog and a method, that used a StreamWriter passed to an async method

    using (var writer = StreamWriter(dialog.OpenFile()))
    {
      WriteResults(writer, dialog.FilterIndex)
    }
    
    async void WriteResults(StreamWriter writer, int whatToExport)
    {
      if (whatToExport is something that isn't computed)
      {
         await TaskEx.Run(() => Compute(...))
      }
    
      // write the result here
      // Raises an exception, that the stream is closed
    }

    This was definitely some behavior I was not expecting. But of course when I think about it, it makes perfect sense that it happened. 

    Now, originally the method WriteResults only wrote the results and later came the need to compute additional values before the actual export. So I kinda artificially extended the WriteResults method using Async because the computation could take several seconds and later I wanted to add a progress bar and cool stuff like this. I admit it was a bad "design" decision to do it this way (like I should open the file after the results are available). Nevertheless, it also means that there are some hidden pitfalls when using Async and one should be careful where it's being used.

    So my suggestion is this: would it be possible to add a compiler warning if constructs like

    using (var x = ...)
    {
      SomeAsyncMethod(x);
    }

    are used?

  • Mads Torgersen: Inside C# Async

    Very nice stuff.

    Charles, you should get Mads together with Brian Beckerman/Bart de Smet/Eric Meier and do "Monads & Async jam" - it would be no fun if there were no monads Smiley

  • E2E: Brian Beckman and Erik Meijer - Co/Contravariance in Physics and Programming, 3 of n

    Glad you like the idea Smiley

  • E2E: Brian Beckman and Erik Meijer - Co/Contravariance in Physics and Programming, 3 of n

    Well I think it is relevant, because you need to go from the manifold to the coordinate system. Of course your manifold would be stronly typed (`landmark`) but then again so is xs (where T would be int, string, w/e).

     

    But I really think the important thing is going from {X} to {Y} and back as going from IE to IO.

  • E2E: Brian Beckman and Erik Meijer - Co/Contravariance in Physics and Programming, 3 of n

    First of all I would like to state that I am not a physicist and I have almost zero knowledge of cathegory theory, but I wanted to share my view on the issue as I've really found these sessions very inspiring (and also some others, particularly what Bart de Smet is doing ... but I like you too, Brian and Erik Smiley ).

    I think there is no correspondence between this particular programming and physics sample. Let me explain why.

    Programming sample:

    We have functions f and g and we are exploring what happens to their composition after applying Select functor.

    Here are our types:

    g :: A -> B
    f :: B -> C                                
    Select :: IEnumerable<a> -> IEnumerable<b> -- maybe it should say (a->IE<a>)->(b->IE<b>), but I wanted to capture the essence
    xs :: A -> IEnumerable<A> -- lets assume xs is a monadic constructor or how that thing was called

    Composition (f o g) under Select...
    xs.Select(x => f(g(x))) -- gives us IEnumerable<C> (or C->IE<C>)

     

    And our covariance...
    xs.Select(x => g(x)) -- gives us IEnumerable<B>  (or B->IE<B>)
      .Select(x => f(x)) -- gives us IEnumerable<C> (or C->IE<C>)
     
    Notice that we are always in IEnumerable<a> monad.

    -------------------------------------------

    Now, to the physics sample:

    There is our manifold P and its coordinatization (hope I spelled it right) cx which goes to our coordinate system {X} (cx: P->{X}). In the programming example image of cx would be equivalent to xs, P would be A, and {X} would be IEnumberable<A>.
    Let's denote the image of cx as {X}<P>.

    Now, the physics example's covariance and contravariance was about dealing with how functions p and f behave under changing the coordinate system (let's call it ToY:{X}->{Y} and ToX:{Y}->{X}).

     

    -------------------------------------------

     

    But going from {X}<P> to {Y}<P> is fundamentally different than going from IEnumerable<A> to IEnumberable<B> (which is happening in our example). Going from {X}<P> to {Y}<P> is more like (in my opinion) going from IEnumberable<A> to IObservable<A>.

    In the physics sample we have transformations ToY :: {X} -> {Y} and ToX :: {Y} -> {X}. In the programming world we have ToObservable() (~ ToY) and ToEnumerable() (~ ToX). And what you can then explore is how certain functions behave under (after applying) ToObservable() and ToEnumberable(). Unfortunately in this programming example with Select there is no direct correspondence between programming's f and g, and physic's p and f (because in physics P is A. Then we can say that T is B and F is C. Then g_{programming} = p^(-1) and f_{programming} = ?). At this moment no example comes into my mind. But...

    ...the fundametal question is:

    Why do we want to change coordinate systems in physics?
    I am no physicist, but I believe that the answer is that because sometimes it's easier to calculate stuff in system {Y} instead of in system {X}.

    Well, and why do we want to change from IEnumerable to IObservable - because it's better to do some stuff in IO than in IE.

    Now this, I think, is a really beautiful and fundamental corrspondence.

    -------------------------------------------

    Of course might be completely wrong, just wanted to share my 2 cents Wink