@brianbec "GitHub: Source control for the masses" Nice!
Dec 29, 2011 at 6:08 AM
Brian - I dropped in the latest Maybe implementation and the performance improved slightly, but not enough to get excited by. It will have to stay "art" code - for now. There is a pull request in your GitHub queue to integration these changes, sourced from this repo: https://github.com/iSynaptic/DotNetExtensionsImproved
All - That said, it shouldn't deter anyone from using monads in general or the Maybe implementation. My team is using it in performance critical production code with no problems. It entirely depends on your use case. If you interacting with web services, databases, or other IO, using monads is most likely not going to have a detrimental impact. However, if you doing computationally intensive work, my suggestion is you profile your code to see where it is spending CPU cycles. You may, or may not, find that usage of monads isn't the biggest bottleneck.
Dec 25, 2011 at 3:35 PM
Brian - Thanks for the plug!
All - The implementation of the Maybe monad used in this project is a much older implementation. I've continued to improve it, adding operators, and I made a huge investment in improving the performance a number of months ago. I'm going to drop the latest version of the Maybe monad implementation into this project and see what the performance numbers come out as. I'll send Brian a pull request so you can see the results.
Beyond the Maybe monad implementation, I'm working on two others: Outcome and Result (which really derive from the Writer monad). My blog has an *older* post explaining the Maybe monad and it's implementation (I'm in the process of writing an updated post), and you can see the code for all of it on GitHub and try it out through Nuget. Watch my blog for more info on the Maybe, Outcome, and Result monad implementations.