Archives

Archives / 2008 / February

Adventures in F# - F# 101 Part 3

Friday, February 29, 2008
F#
2 Comments

#light

Read more...
IoC and the Unity Application Block Once Again

Tuesday, February 26, 2008
.NET C# Frameworks TDDBDD
27 Comments

namespace UnitySamples

Read more...
Thinking Inside the Box and Premature Optimization

Tuesday, February 26, 2008
ALT.NET DDD User Groups
1 Comment

At the last DC ALT.NET meeting, there was a good discussion regarding premature optimization. Anything that involves this brings me to a rather famous quote by a great computer scientist, Donald Knuth which states:

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil."

Don't Think Five Steps Ahead

The context of the conversation revolved around how when you learn a new language, you have a tendency to think inside the box and try not to prematurely optimize the code, instead, just meet the original intent of what you were trying to do as quickly and efficiently as possible and make it conform to the specification. For example, one person there was a .NET guy who knew nothing of Java until put on a project recently where it was exclusively used. This forced him to think more clearly about the problem and not just throw design patterns, caching solutions and so on. When we are familiar with a language and all of its nuances, it sometimes gets the better of us, and we start throwing frameworks in there that have done things for us in the past just because they seemed appropriate then. It rang very true for me as well when I did my first Ruby on Rails application and I saw that I didn't need to bring in X framework or Y framework and my solution did just fine without it. In fact, I thought it was a stronger piece because I didn't clutter it with frameworks and instead solved the direct domain problem at hand first.

It kind of reminds me of a conversation I once had with a developer which went like this:

Me: Why did you use x for this piece?
Him: Because it's always worked for me in the past.
Me: What problem does it solve? Did you have that problem this time around?
Him: Well, no, I was just thinking five steps ahead

So, basically what we can infer from this conversation is that the pain point just hadn't been hit yet. Instead, reflexively, we have a tendency to throw these things in there because at one point, for one particular project, we felt that pain. That's not to say that optimization is a bad thing, but once we start doing it, we need concrete measures for what the optimization is trying to fix and how well it does it. Another part to consider is how easy is it to read.

ADD with DDD

Some of the guidance for this can be traced back to Domain Driven Design. With this, you pay more attention to the model, the ubiquitous language and so on, and the frameworks in turn will come into play. Instead, many people put their frameworks first and try to get the domain model to fit around it. They are distracted by shiny things with their ADD to put the domain model first and then the frameworks. I know I've been guilty of it in the past and it's been a learning adventure when I was earlier in my career.

I'll be back next with a real technology post on IoC, Unity and all that, so stay tuned. Until next time...

Read more...
IoC and the Unity Application Block - Going Deeper

Friday, February 22, 2008
.NET ALT.NET C# Frameworks
8 Comments

namespace UnitySamples

Read more...

Adventures in F# - F# 101 Part 2

Friday, February 22, 2008

C# F#

3 Comments

Update: Added more topics

I know it's been a little bit too long since I began this series from when I continued, but plenty of distractions came up along the way. I intend to go a little deeper today into what functional programming means and why you should care. As always, check out my previous post on the matter here.

Getting Sidetracked

Last night at the DC ALT.NET meeting, Craig Andera and I discussed Lisp, F# and functional programming as a whole. His language of the year was Lisp and I thought that was an interesting choice of the language to learn, but when you think about it, most good things in programming lead back to SmallTalk and Lisp... I had been hearing a bit about IronScheme, the IronLisp rewrite, so of course I had to check it out. Maybe this will be one of my future languages to learn, but I had enough exposure during my college years to last a little bit, so it's on the plan anyways.

Basic Introduction

So, just in case you missed the idea of functional programming and what it means, I have a few posts on where you should start here:

But, if you really want the condensed version, Bart de Smet has a really nice introduction on functional programming in a series, although incomplete, which you can read here:

Now that I take it you have read that and caught up, let's continue onto today's part.

The Joys of Currying

Where we left off last time was just dealing with the basics of functions and the fact that they are treated as values much like any other "variable". Now let's get into a popular topic among functional programming, a concept called Currying. The term was invented back in the earlier days of functional programming after the early logician Haskell Curry. He's so good in fact that he got not only a functional programming style named after him, but a language named after him with Haskell. If you listen to the DotNetRocks Episode 310 with Simon Peyton-Jones, you can learn more about that.

Anyhow, the basic idea of Currying is to take a function with multiple arguments and transform it into a function that passes in only one argument, with the other arguments specified in the Currying function itself. So you can think of it as a function that calls another function and returns a function. You can think of it also as being a partial function. So, let's actually get down to it and write some F# code to show how to do this:

#light

let n = 10

let multiply a b = a * b

let multiplyByFive = multiply 5

let result = multiplyByFive 4

printfn "result = %i" result

So, what I accomplished above is that I had a function called multiply that takes two arguments, a and b. Then I created a currying function called multiplyByFive which curries the multiply function by supplying a five value. Then I can call the multiplyByFive curried function with a 4 and sure enough the result is 20.

As always, I'm always curious on how it looks through .NET Reflector to see how F# does its magic. So, let's crack that open and take a look. First let's look at the tree of Reflector to see what it creates for us:

Now as you can see, it created the multiply function. Then we also have a multiplyByFive FastFunc function. The functions get stored in the namespace free area and yet the main function gets placed elsewhere. Now, let's look at the function implementation itself.

From what you can see, it created a SampleFile class because I created a SampleFile.fs to create the curried functions.

For those of you who are C# buffs, well, you can also do the same in C# with the new anonymous function type, System.Func in .NET 3.5. Mads Torgersen, the C# Program Manager, noted on his blog quite a while ago asking the question, "Is C# Becoming a Functional Language?". This post was pretty great and it's unfortunate that he doesn't blog as much as he does. Remember kids, this isn't as pretty as F# because it's not what C# is really good at, but slowly but surely, functional programming paradigms are slowly seeping into C#.

namespace CSharpCurriedFunctions
{
    public static class CurriedFunctionExtensions
    {
        public static Func<A, Func<B, R>> Curry<A, B, R>(this Func<A, B, R> f)
        {
            return a => b => f(a, b);
        }

    }

    class Program
    {
        static void Main(string[] args)
        {
            Func<int, int, int> multiply = (a, b)=> a* b;
            Func<int, Func<int, int>> curriedMultiply = multiply.Curry();
            Func<int, int> multiplyByFive = curriedMultiply(5);

            Console.WriteLine("result = {0}", multiplyByFive(4));
        }
    }
}

If you're interested more in doing this with C#, I would suggest you head over to Dustin Campbell's blog and read the post about The Art of Currying. For those who want to learn more, well, Dustin should be at ALT.NET Open Spaces, Seattle and hopefully will submit an F# topic for us to get our heads around.

How useful is this in C#? Well, time will tell, but you could imagine having some search criteria for your repository using curried functions to "overload" with values. Anything is really possible, but as you can see, it's a lot cleaner in F# and that's where it really shines.

The Odd Tuple

When specifying arguments to any given function, you can specify them without parentheses much as you would in VB.NET should it be a subroutine. This is really helpful if you want to enable currying and such. But, you can also specify them as a tuple. For the math illiterate among you, that simply means a sequence of objects of a specified type. This you must put within parentheses. This makes you supply all arguments at once. A simple example of this would look like this:

#light

let add (a, b) = a + b

let result = add(3, 4)

printfn "result = %i" result

Pretty simple example and of course the result would be 7.

Where is the Returns Department?

As you may have noticed from the functions from above, I never really did specify any return type or return statement. Implicitly behind the scenes, F# does that for you. Basically when you define a function, you should indent with a tab and the last assignment becomes your return value. The return is implicit right after the indenting is ended. So, let's take a simplistic view of this:

#light

let addThings a b =
let c = a + b
sprintf "result = %i" c

let result = addThings 3 7

print_string result

As you may notice, when using the light syntax (#light), you cannot indent, instead just use two spaces and that should suffice. Anyhow, you may note, I was doing a simple addition and then my final assignment becomes my return value, which is using the sprintf function, which to you C buffs out there, should look familiar.

Conclusion

I've got a lot more on this topic quite frankly and still just covering the basics of your first F# program. There is so much to learn on this, but these are the basic building blocks you need to make that leap into functional programming. It's becoming more interesting year by year as our languages such as Ruby, C# and so on continue to drive towards functional programming, so it's important to grok the fundamentals. Next time, I hope to cover some recursion stuff, functions, lists and even operators (the really fun stuff). Until next time...

IoC and the Unity Application Block

Tuesday, February 19, 2008

ALT.NET Frameworks Microsoft

2 Comments

Update: Fixed code changed from CTP and More in the series:

As many people who read this would know, I'm a big fan of IoC containers, more in particular Castle Windsor and StructureMap among my favorites. Anyhow, lately, I've been playing with the Unity Application Block from Microsoft Patterns & Practices (P&P). Very recently, Grigori Melnik, the product manager for EntLib 4.0 and the Unity Application Block announced the February 2008 Unity CTP. Anyhow, it's been an active topic on the altdotnet list as well lately as noted here.

Basic Overview

If you're not familiar with the Unity Application Block, it was formerly the Dependency Injection Application Block. The application block itself is built upon the next version of ObjectBuilder. For a good overview of ObjectBuilder, check out Chris Tavares's blog on the Deconstructing ObjectBuilder series:

Back History

I don't think it's any secret to anyone that many people hated the original implementation of ObjectBuilder. I used it mostly in Composite Application Block (CAB) applications, but as well I've played with a few samples, enough to know it's too poorly documented to use in any type of system.

Below, I have a code sample of the original ObjectBuilder approach to build a singleton instance of a Logger object:

Builder builder = new Builder();
Locator locator = new Locator();

// Create lifetime container for holding singletons
ILifetimeContainer lifetimeContainer = new LifetimeContainer();
locator.Add(typeof(ILifetimeContainer), lifetimeContainer);

// Set my singleton policy for creating my logger
builder.Policies.Set<ISingletonPolicy>(new SingletonPolicy(true), typeof(Logger), null);

Logger logger = builder.BuildUp<Logger>(locator, null, null);

It's not the most fun code to write, nor was it very well documented. David Hayden, EntLib guru extraordinaire also had issues with it as noted here.

Another criticism lied in the fact that it was used in the EntLib, so it was hard for those to use another DI framework in its stead. One of the big reasons behind ALT.NET was that the community wanted to help drive openness within Microsoft in terms of allowing third-party products to integrate fully within Microsoft products.

Since then the EntLib team announced that they would open up a bit, but also, they were revamping ObjectBuilder as well, and now packaging it under the Unity Application Block. This of course was met with skepticism from such folks as Jeremy Miller (StructureMap), and Ayende (Windsor/Bindsor contributor). Of course to say, Ayende's objection was around the duplication of effort seen with Microsoft and the Open Source Community. See MSTest versus xUnit.NET versus MbUnit versus NUnit as an example of this. Jeremy Miller saw this as at last some openness within the P&P team, and I'd have to agree that they are consulting the outside community, which is great to see. It's great to see that P&P and others are actively involved with ALT.NET and the outreach efforts in the community. Others are a bit concerned because of many shops won't consider the other products such as StructureMap, Spring.NET, Windsor because Microsoft has an offering instead even though the others may be a bit more feature complete.

Taking it for a Test Spin

So, now that I got that other stuff out of the way, let's take things for a quick test spin. Let's walk through code how to do a basic setup using Dependency Injection with a constructor injection:

namespace UnitySample
{
    public interface ILogger
    {
        void Log(string value);
    }

    public class ConsoleLogger : ILogger
    {
        public void Log(string value)
        {
            Console.WriteLine(value);
        }
    }

    public interface ICustomerTasks
    {
        void SaveCustomer(Customer customer);
    }

    public class CustomerTasks : ICustomerTasks
    {
        private ILogger logger;

        public CustomerTasks(ILogger logger)
        {
            this.logger = logger;
        }

        public void SaveCustomer(Customer customer)
        {
            logger.Log("Customer Saved");
        }
    }

    public class Customer
    {
        public string FirstName { get; set; }

        public string AccountNumber { get; set; }
    }

    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer()
                .RegisterType<ILogger, ConsoleLogger>()
                .RegisterType<ICustomerTasks, CustomerTasks>();

            ICustomerTasks tasks = container.Resolve<ICustomerTasks>();
            tasks.SaveCustomer(new Customer());
        }
    }

And as you can see from this, on the console window, you should receive a "Customer Saved" message. So, that's using constructor injection. Instead, we could have easily done this through property setter injection which is another popular way of doing injection. Let's rewrite it just a bit to do that:

namespace UnitySample
{
    public class NullLogger : ILogger
    {
        public void Log(string value)
        {
            // Do nothing
        }
    }

    public class CustomerTasks : ICustomerTasks
    {
        private ILogger logger = new NullLogger();

        public void SaveCustomer(Customer customer)
        {
            logger.Log("Customer Saved");
        }

        [Dependency]
        public ILogger Logger
        {
            get { return logger; }
            set { logger = value; }
        }
    }
}

And if using the same program.cs as above, it should work just the same. These of course are really simple samples, but what most basic DI frameworks do. This is pretty easy to set up so far in my adventures. Now you could do like the other DI frameworks and be heavy on the XML configuration as well. It's not hard to set this up either. Below is a basic example of this XML configuration file:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
    <section name="unity"
             type="Microsoft.Practices.Unity.Configuration.UnityConfigurationSection,
                   Microsoft.Practices.Unity.Configuration" />
</configSections>
<unity>
    <containers>
      <container>
        <types>
          <type type="UnitySample.ILogger,UnitySample"
                mapTo="UnitySample.ConsoleLogger,UnitySample" />
          <type type="UnitySample.ICustomerTasks,UnitySample"
                mapTo="UnitySample.CustomerTasks,UnitySample" />
        </types>
      </container>
    </containers>
</unity>
</configuration>

Now that we got the XML config done, let's then reimplement our program.cs to handle this:

namespace UnitySample
{
    class Program
    {
        static void Main(string[] args)
        {
            IUnityContainer container = new UnityContainer();

            // Load from config file
            UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
            section.Containers.Default.GetConfigCommand().Configure(container);

            ICustomerTasks tasks = container.Resolve<ICustomerTasks>();
            tasks.SaveCustomer(new Customer());
        }
}

Wrapping it Up

So, as you can see, it's pretty easy to get started. This of course is the 1000 ft overview of what it can do. Competition is a good thing when it comes to creating these frameworks. Choice is a wonderful thing... I am especially encouraged by P&P's openness to the community, as well as some in the community to give back and give feedback to Microsoft for these frameworks. Without one, the other cannot become stronger. I'm encouraged from the early signs of Unity and I've enjoyed the samples and playing with it as much as I have. Give it a try and better yet, give feedback to the team...

Until next time...

Adventures in F# - F# 101 Part 1

Monday, February 11, 2008

3 Comments

Update: Added more topics

In some previous posts, I pointed you to a bunch of links to help get me started. I'm still working on some more thorough examples, but this time around I'm going to walk you through the F# 101 much like I did with Spec#. What we first need to understand is the key differences between imperative and functional programming.

I've really enjoyed Robert Pickering's book Foundations of F# and Don Syme's Expert F# book as they both give a good overview of not only the language, but the uses. It's a lot for some stuck in the imperative world to think about functional programming, but these books do their job well.

So, today I'd like to cover the following topics:

Hello World Sample
#light
Functions == Values basics

Hello World Example

As I like to do with most languages, I know it sounds trite, but Hello World, especially in .NET languages is interesting, especially how they translate in IL through Reflector. F# is especially interesting in this case as it is a functional language built on top of a imperative framework such as the CLI and C#.

So, let's walk through a simple example. First, of course you need to have F# installed which can be found here. Then go ahead and create a new F# project, which should be under the Other Project types. By default, it will not give you any classes as part of your project. So, go ahead and add an F# Source File. It will give you the extension of .fs by default. I went ahead and created a class called HelloWorld.fs. Get rid of the default text that is in there, and it is plenty, and just put in the following code:

#light

print_endline "Hello World"

As you can see from the simple example above, we've put in the #light directive. I'll cover what that means shortly. But anyways as you can notice it calls a default global function called print_endline. I always like to look at what the code compiles to in Reflector to IL, so let's take a look at that.

What's really interesting to see from the above, by default, it created the main function for us without us explicitly doing so. Also, it notes that we are calling an OCaml function. If you look through Reflector and the FSharp.Compatibility.dll, you'll notice it takes a few things from OCaml as its base.

Where to Turn

As always, if you have problems, the specification and the books help out well with this. If you should get lost, the information F# specification is very good at defining the language and can be found here.

Stay in the #light

From the above example and many other examples you will see from me, you'll notice the #light directive at the top of every source file. What this does is that it makes all whitespace significant. This directive allows you to omit such things as begin, end, in and the semi-colon. When defining functions and so on, you indent your code to make it fall under that scope implicitly by using that directive.

Identifiers, Keywords and Literals

In F#, it's important to realize that variables, aren't really variables, more like identifiers. In pure functional programming, it's fundamental to understand that once a "variable" is assigned, it is immutable. However, if using F# an imperative way of thinking, then it can be.

To make a simple assignment, just use the simple let keyword such as this:

#light

let message = "Hello World"
printfn "%s" message

One of these identifiers can be either either just a simple value, or even a function, since these functions are values as well. I'll cover that more shortly in the next section.

#light

let rec fib n = if n < 2 then 1 else fib (n-2) + fib(n-1)
printfn "%i" (fib 10)

I think this example went a little too far with adding recursion, but you get the point that it's pretty easy to define a function much as you would with any old "variable". Also, you may note, I'm not returning anything from this function, but in fact I am returning the Fibonacci sequence that I asked for.

If you also note the keywords, there are a lot of direct mappings from C# to F#, but it's also interesting that it has a list of reserved keywords for future use such as mixin. Now, if we finally brought mixins to .NET, well, then I'm all for it.

Of the types that exist in F#, the only ones to note that are completely different are:

bigint - Microsoft.FSharp.Math.BigInt
bignum - Microsoft.FSharp.Math.BigNum

It's interesting to know that the .NET framework's BigInteger class is internal, yet these are publicly available. Both of these are rational large integers just in case you need that kind of thing.

Functions == Values?

Once again, like I said above, functions and values are one in the same in the pure functional programming stance. You noticed that in my functions, I'm not returning anything, nor is it imperative that you do so explicitly. This boggles many of OO mindsets, I'm sure and there are a lot of things in FP that an OO person may have problems with.

Let's walk through another simple function, but this time, we'll implement that main function and look at the results through Reflector.

#light

let rec fib n = if n < 2 then 1 else fib (n-2) + fib(n-1)
let print x = printfn "%i" x

let x1 = fib(10)
let x2 = fib(20)

let main() =
print x1;
print x2

main()

From the above sample, I created two functions, a recursive Fibonacci sequence function from above, and I also created a print function which calls the native printfn function which is a variation of the printf function with a newline at the end. For those who are curious about what it looks like in Reflector, let's take a look, and this time in C#. Instead of pasting a bunch of screenshots, it's much easier to paste it below the pieces we're interested in.

fib function:
public static int fib(int n)
{
    if (n < 2)
    {
        return 1;
    }
    return (fib(n - 2) + fib(n - 1));
}

print function:
public static void print(int x)
{
    Pervasives.printfn<FastFunc<int, Unit>>(new Format<FastFunc<int, Unit>, TextWriter, Unit, Unit>("%i")).Invoke(x);
}

main function:
public static void main()
{
    print(get_x1());
    print(get_x2());
}

So, as you can see, it's doing much like we think it would be, as it fit everything into our HelloWorld class. The more interesting pieces are how C# and F# functions differ. It's just interesting to see how FP fits on top of an imperative programming framework.

Next time, I'll cover more with functions such as Currying, Tuples, Recursion, Scopes and so on. Plus I need to talk about the interop story here which is strong between F# and C# as well. There's a lot to cover and quite frankly, it's making me stronger as well to go over this time and time again.

Conclusion

This is the first post in the series. As you can see, I have plenty to cover in the next installment. If you like the series and so on, subscribe and keep coming back. Until next time...