LexParse » .NET

C# Dynamic: The Downfall of Western Civilization

Mark — Wed, 11 Nov 2009 20:14:41 +0000

I’ve known about the new dynamic keyword in C# 4 for about a year now but really haven’t thought much about it. It’s suppose to be syntactic sugar for dealing with things like COM interop and objects from other DLR languages. This can be done now by using the existing reflection framework/library, but it can be tedious dealing with method name strings and the chain of method calls needed to get to the method invocation. Variables declared as dynamic bypass static type checking.

I came to the realization today this new keyword might well trigger the downfall of western civilization. Not only can this keyword be used for local variables, but also method parameters and return values. If you have experience working in Corporate America, you know that the there are plenty of developers out there who will abuse this keyword to no end. Can you imagine a ginormous, multi-thousand source file code base littered with dynamic!!! Methods that return dynamic!!! Methods that take dynamic!!! Does this not frighten anybody? I’m so scared. Am I alone? Can we stop this?

F# and Workflows (Monads)

Mark — Thu, 29 Oct 2009 14:41:53 +0000

Don’t let the name scare you. A monad is just something that represents one or more computations, a workflow. The need for monads came up in pure functional programming languages like Haskell where given a set of inputs, a function should return the same value every time. But what happens when you have a function that takes a filename and line number and returns a byte array of the data on that line in the file? Might it not return a different byte array between subsequent calls if the file changed? The solution: instead of executing the operations to read the file and return the data, the function creates a workflow(monad) that will do that. So what comes back from the function is a workflow, something that represents the operations to read from the file. In typical pragmatic form, Microsoft decided to use a better name for this in F#: Workflows. The stuff in the Workflow is called the compuation expression. These names make sense.

It turns out workflows are useful for other things like building Sequence Expressions and Async Workflows. The advantage is a syntactic sugar for creating what is usually a gobbledygook of disparate pieces of code to accomplish the same thing. You can create your own workflows by creating a type with a couple of important mothods: Bind, Delay, and Return. I really recommend watching Luca Bolognese’s presentation on F#. Its worth watching for the section where he discusses Async Workflows. Pretty amazing stuff.

If you come from the Lisp world, F# Sequence Expressions will seem familiar to you. In Clojure and Lisp they are called List Comprehensions but are essentially a specialized Monad/Workflow.

C#: .NET Generic Dictionary Improvement

Mark — Wed, 28 Oct 2009 18:30:53 +0000

Are you tired of doing the if(dict.Contains(key))… pattern? Extend Dictionary:

public static R ValueOrSomethingElse(this Dictionary Col, K Key, Func Transform, Func SomethingElse)
{
   if (Col.ContainsKey(Key))
      return Transform(Col[Key]);
   else
      return SomethingElse();
}

Example usage:

Dictionary BDays = new Dictionary();
...
BDays.ValueOrSomethingElse("Mark", d => d.ToString("MM/dd/yy"), () => "Unknown BirthDate");

The second parameter is a lambda for transforming the value if the key is found. The third parameter is a lambda to execute and return if the key is not found. I have the third parameter(something else) as a lambda in case the “something else” is an expensive operation.