Comments on: A monad in C# for simplifying WPF multi-threading for a more responsive GUI

By: Jacob Stanley

Jacob Stanley — Mon, 02 Nov 2009 05:56:20 +0000

@Fabrice – The variable names are not as important as the types in this case. In my opinion, adding more verbose variable names makes this harder to understand. If you really want to know how it works you need to study monads in general.

Wes Dyer wrote a good article on this topic for C# programmers: http://blogs.msdn.com/wesdyer/archive/2008/01/11/the-marvels-of-monads.aspx

By: Andrew

Andrew — Mon, 02 Nov 2009 01:48:51 +0000

Im curious how this is distinct from Eric Meijer’s Rx or First Class Events in F# (ie, Functional Reactive Programming)

By: Sadache

Sadache — Sat, 31 Oct 2009 12:01:36 +0000

I agree that implementation code is not explicit for non FPs. But you do not need to understand the implementation to use the monad. Same thing as for Linq for lists. Did you go through their implementation before using them? The wide majority don’t care…

By: Fabrice

Fabrice — Sat, 31 Oct 2009 11:44:58 +0000

“code here is simplified for clarity”
Not so sure about that.

I don’t really understand what your code does, but when I see code like the this, I just want to run away:

View SelectMany(this View m, Func k) { return () => k(m())(); }

What do U, T, m, and k mean?
If you want someone to use your code, you’d better use explicit names.

By: Jacob Stanley

Jacob Stanley — Sat, 15 Aug 2009 16:01:03 +0000

@Jonathan It’s adorable that you think the LINQ syntax is only for querying collections :) It was deliberately implemented in a way that isn’t tied to the list monad (IEnumerable) so that developers can use it in other useful ways.

By: Sadache

Sadache — Sun, 28 Jun 2009 22:45:00 +0000

@Jonathan I don’t know why you call this abusing. LinQ syntax is done to be used, it is a generic abstraction, a monadic syntax. WPF is a monad (continuation), so I don’t know why you call it abusing…

So with your explanation, should the presenter call Dispatcher.Invoke? This breaks abstraction boundaries as the presenter is not supposed to know about such implementation details. The thread unsafety should be expressed in the type system same as nulls. And this solution gives an opportunity to deal with it more safely. In my case the presenter will need to know only about View which is not a technology specific thing. More, I could implement a nice animation to be shown while working on another thread.

I really do not understand how you call removing all the boilerplate unsafe code and using a far cleaner syntax a stupid idea? Maybe you need to think about the practical advantages of the approach instead of criticizing MVP and my interpretation of it.

WPF monad let the user focus on interesting business stuff rather than the unintuitive signature of Invoke method!

By: Jonathan Allen

Jonathan Allen — Sat, 27 Jun 2009 19:03:02 +0000

That is stupid. There are plenty of ways to marshall information between the GUI and background threads without absuing the LINQ syntax. If explicit marshalling is too painful, a simple background worker object will do nicely. I dread to think about the poor sobs who have to maintain a program in which queries have side-effects.

The fact that you are having problems with thread ownership means one of two things. Either the Model-View-Presentor pattern is fundementally flawed or your interpertation of it is. Using the more traditional forms over data pattern, we never see this problem. Background threads quitely work on the data objects, the ‘model’ in MVC/MVP, and use events to notify the form that something has changed.

Design patterns are supposed to simplify things. If you find that they are making them more complicated, then don’t use them.