Archives
-
Functional Programming Unit Testing - Part 4
In our previous installment, we talked about bringing together the traditional xUnit tests and QuickCheck property-based tests together in a single cohesive step. For this installment, let's talk about test coverage.
-
Functional Programming Unit Testing - Part 3
In the previous post, we talked about using QuickCheck as opposed to traditional xUnit framework testing. This covered some of the arguments for using property-based testing for our pure algorithms and relegating the xUnit framework tests for the rest. The question then arises, how do we tie it all together?
-
Functional Programming Unit Testing - Part 2
In the previous post, we talked about some of the basics of functional programming unit testing. That post mostly focused around HUnit, which is a traditional xUnit testing framework. This time, let's focus on type-based property testing, which is to create specs which assert logical properties about a function, and then to generate data to test in an attempt to falsify these assertions, through the use of a tool called QuickCheck.
-
Functional Programming Unit Testing - Part 1
As you noticed from my last post regarding functional programming and unit testing, there is a bit to be discussed. Important to any programming language is not only the language, but the frameworks and tooling around it, such is the case with functional languages. Let's focus on the tooling around testing with functional languages.
-
F# + TestDriven.NET + xUnit.net = WIN
As you may notice on my blog lately, I've been focusing on design and functional programming lately. There is a lot to explore in terms of those two topics in the next series of blog posts especially around xUnit frameworks, QuickCheck and other ideas. But, first I want to turn my attention a combination that is working great for me as I develop solutions using F# which includes TestDriven.NET and xUnit.net.
-
[ANN] The Real World Haskell Book Club
As I was heading out the door last week for my Thanksgiving holiday, I noticed a package from Amazon on my front porch, which was the long awaited Real World Haskell book. If you have been following this book and its progress through their Real World Haskell blog, you should know the massive involvement of the community around it. Look no further than the thanks section to note all the reviewers for the book. -
Object Oriented F# - Encapsulation with Object Expressions
In the past, I've covered a bit about object oriented programming in F#. I'd like to come back to that series as there is much yet to cover on this topic. Last week, I spent some time with Erik Meijer at QCon and he and I both agreed that in some ways, F# is a better object oriented language than C# in some ways given some of the language flexibility.
-
Code Contracts - TDD in a DbC World
Lately, I've been talking about the new feature coming to .NET 4.0, Code Contracts, which is to bring Design by Contract (DbC) idioms to all .NET languages as part of the base class library. Last week, I attended QCon, where Greg Young, one of my CodeBetter cohorts, gave a talk titled "TDD in a DbC World" in which he talked about that they are not in conflict, but instead are complementary to a test first mentality. Both improve upon the usage of the other.
-
DC ALT.NET 11/25 - Web Testing Frameworks
The November meeting for DC ALT.NET will be on November 25th, 2008 from 7PM-9PM. Check out our site and our mailing list for more information as it becomes available. This month, John Morales will be facilitating a discussion on web testing frameworks which includes Selenium, Watir and WatiN among others. Once again, I'd like to thank Cynergy Systems, Inc for sponsoring this month's event.
-
Functional .NET 4.0 - Tuples and Zip
Previously, when covering some of the additions to the .NET 4.0 Framework such as optional and named parameters, some of the other additions have caught my eye from the perspective of functional programming. Unlike .NET 3.5, this release is not as targeted towards functional programming as it is more towards dynamic programming and COM interoperability. But, there are a few items to note that we can soon take advantage of, including the Tuple type and the Zip operator function among other items.
-
.NET Code Contracts and TDD Are Complementary
After my recent post on the introduction of Code Contracts in .NET 4.0, I got some strong reaction that they would rather rely on TDD, or the better term, Example Driven Development specifications to ensure correctness. Instead, it's my intent to talk about how they can complement each other in some rather powerful ways, such as having contracts bound to interfaces instead of class instances to ensure uniform interaction. When we combine these two things together, the edge cases of our behaviors quickly melt away.
-
KaizenConf'08 Functional Programming Presentation Video
Last week, I provided a basic wrap up of my functional programming talk at the Continuous Improvement in Software Development conference (KaizenConf) in Austin. Little did I realize that I was indeed being filmed while I talked by Mark Leon Watson. So, without further ado, enjoy the first 20 minutes of my talk. I should emphasize though that it's not the official position that designers will never be there, but instead, it's not the highest priority. In time, they may come as needs arise.
-
Code Contracts for .NET 4.0 - Spec# Comes Alive
As I've said in many posts before, I'm a big fan of stating your preconditions, postconditions, invariants and so on explicitly in your code through the use of contracts in the Design by Contract Parlance. Spec# is a project that came from Microsoft Research as a language based upon C# to add Design by Contract features to the language. I've talked extensively on the subject in the past on this blog and previous blogs of mine especially around the time of the ALT.NET Open Spaces, Seattle event back in April of this year. The importance of making side effects well known is something that I mentioned briefly during my Approaching Functional Programming talk at KaizenConf. To be able to express and statically verify behavior is important in regards to side effects and method purity.
-
KaizenConf Wrapup - Approaching Functional Programming
This past weekend, I had the opportunity to attend and give a workshop at the Continuous Improvement in Software Development, or KaizenConf. I'm grateful to Scott Bellware and Dave Laribee for organizing this event. The tone and subject matter at this conference was both refreshing and interesting. This conference had a focus on continuous improvement through methodology, communication, as well as technology, which was a bit different than the ALT.NET Conferences, which had much more of a technology tilt. The conversations had not only in the sessions, but also the hallways in between were enlightening, and it was enjoyable to get so many perspectives on software development issues.
-
C# 4.0 - Named and Optional Parameters - Behind the Scenes
In my previous post, I talked very briefly about both named and option parameters. Now, I'd like to go a little deeper into the subject to see what this looks like underneath the covers. As before, we'll look at the limitations as well that we faced in the previous post.
-
Named and Optional Arguments in C# 4.0
Many interesting news is coming from PDC this week. Part of the announcements was around Visual Studio 2010 and the .NET Framework 4.0 CTP. Microsoft has made available, a Virtual PC Image preloaded with Visual Studio.
-
KaizenConf - Functional Programming – Is it a game changer?
Next week at the "Continuous Improvement in Software Development Conference" (KaizenConf), I will be giving a session called "Functional Programming - Is it a game changer?". In this discussion, I'll cover the basics of functional programming, moving from an imperative style to a functional style, and what benefits you get from it.
-
DC ALT.NET 10/2008 Recap - A Look at Kanban Software Development
Thanks to everyone who came out to the DC ALT.NET meeting on "A Look at Kanban Software Development" with Linda Cook. This was a great discussion about Kanban and continuous improvement with Lean Software Development techniques. Linda shared her experiences while working with her current customer about implementing Kanban. Continuous improvement was important and readily noticeable from the evolution of the Kanban boards. Her teams are using it with success and refining the processes to eliminate waste. It was really refreshing to hear about real stories in action. Topics such as these are important to DC ALT.NET as we talk about some of the challenges we face as software engineers, and how we find ways to improve.
-
Reminder - DC ALT.NET - 10/21/2008 - A Look at Kanban Software Development
Just as a reminder, the October meeting for DC ALT.NET will be on October 21st, 2008 from 7-9PM. Check the DC ALT.NET site and our mailing list for continuing updates and future meetings. This month, Linda Cook will be presenting "A Look at Kanban Software Development". I've been exploring a lot of Lean Software Development and Kanban, and this is an opportunity to explore the topic in depth with an established Lean/Agile coach. My CodeBetter compatriot, Dave Laribee had introduced Kanban to XClaim Software and has some really good information on the topic.
-
Functional .NET - Fighting Friction in the BCL with Directory.GetFiles
Very recently on a project, I was having significant issues with System.IO.Directory.GetFiles, in which I was getting an access denied message which prevented further crawling of certain directories. The performance issue was another issue that was detrimental. I wasn't happy either with the design of this API. Instead, I set out to fix some of these issues and come up with a design that I felt better addressed some of my concerns with some techniques from functional programming.
-
Functional C# - Implementing Async Computations in C#
Update: Removed Internal Constructor constraint on AsyncBuilder.
-
Functional .NET - LINQ or Language Integrated Monads?
As part of my talk at the Richmond Code Camp earlier in October, I had the opportunity to talk about how to implement functional aspects in C# 3.0. This talk revolved around such concepts as from mutable to immutable, from inheritance to functional composition, and the mind shift that is required. Part of this discussion involved very briefly a talk about monads. It's a very misunderstood part of computer science and one of the most powerful concepts to learn. Much like continuation passing style, this style is often maligned as a result. But, let's work to change that.
-
Richmond Code Camp 2008.2 - Functional C# Recap
Thanks to everyone who attended my session "Functional C# or how I lost the foreach and learned to love LINQ". This is still an ongoing passion of mine that I hope to expand upon in the upcoming posts. Some of these topics include favoring functional composition over inheritance and implementing patterns such as the Specification Pattern using these techniques. I'll be posting all code snippets from the functional posts up to date on the MSDN Code Gallery Functional C# Project.
Here are some resources that will be helpful in covering functional programming aspects as well as other topics covered:
Functional Programming -
ASP.NET MVC with NHaml - F# Edition
As part of some of my adventures with F#, I've seen a lot of interesting things coming from others with regards to SharePoint, ASP.NET and other technologies. This had me thinking of any possibilities and ramifications of using F# with ASP.NET MVC. Was it possible, and better question, what might make someone use this over their existing toolsets. Those are some of the questions to explore. But, in the mean time, let's take the journey of F# and ASP.NET MVC.
-
DC ALT.NET - 10/21/2008 - A Look at Kanban Software Development
The October meeting for DC ALT.NET will be on October 21st, 2008 from 7-9PM. Check the DC ALT.NET site and our mailing list for continuing updates and future meetings. This month, Linda Cook will be presenting "A Look at Kanban Software Development". I've been exploring a lot of Lean Software Development and Kanban, and this is an opportunity to explore the topic in depth with an established Lean/Agile coach. My CodeBetter compatriot, Dave Laribee had introduced Kanban to XClaim Software and has some really good information on the topic.
-
Upcoming Events - Richmond, Ruby DCamp and more
The next couple of months are pretty busy for me. There are several items worth noting whether I'm speaking or just plain attending. This is a great season for community events and chances for continuous improvement.
-
Emulating Java Enums in .NET - F# Edition
I'm not usually one to follow up replies from another's blog in my own, but some challenges need further analysis. Ayende posted earlier about emulating the behavior of Java Enums in .NET. Since the inception of C#, there has been a lot of back and forth between Java and C# in terms of features such as generics, attributes (annotations), foreach statements, and lastly enums. There are significant differences between the two, but let's see if we can bridge that gap.
-
Object Oriented F# - Creating Classes
In the past couple of posts, I covered extension everything in F#. This allows me to extend .NET types with such things as extension static and instance methods, properties, properties with indexers, events and so on. But, let's go back to the beginning and cover object oriented programming with F# from the ground up. I like to stress that F# is not only a first class functional language, albeit a more impure one than say Haskell, but it also treats imperative and object oriented code as first class citizens as well. To be able to mix and match for the appropriate programming style makes this a very powerful tool, to be able to use functional aspects with first class citizenship, but as well with imperative and object oriented, well, then the sky is the limit. With that, let's go over some of the things that make F# a player in this space.
-
DC ALT.NET - Building ASP.NET MVC Apps Wrapup
I want to thank Troy Goode for his presentation tonight at DC ALT.NET. He gave a great demo of how to build from scratch an ASP.NET MVC blog engine, which is a lot to ask given our two hour timeframe. And yet, he pulled it off nicely. As promised, Troy has posted his materials from the presentation here.
-
Reminder - DC ALT.NET - 9/24/2008 - Building ASP.NET MVC Applications
Just a reminder that the September meeting for DC ALT.NET will be on September 24th, 2008 from 7PM-9PM. Check out our site and our mailing list for more information as it becomes available. This month, Troy Goode will present on building applications with ASP.NET MVC. This will be a basic introduction, but also how to build practical applications, such as a blog engine using MVC. Download the latest bits, ASP.NET MVC Preview 5 and follow along as I will be.
I'd like to thank Cynergy Systems, Inc for sponsoring this month's event. As a side note, they are actively looking for experienced .NET developers with interest in WPF and Silverlight. So, if you're looking for a great company that is a leader in the Rich Internet Applications area and want to work in downtown Washington D.C., definitely check them out.
The information is as follows:
DateTime:
9/24/2008 - 7PM-9PM
Location:
Cynergy Systems Inc.
1600 K St NW
Suite 300
Washington, DC 20006
Show Map
Be there and hope to see a passionate crowd!
-
Herding Code Episode 18 - Functional Programming and F#
A couple of days ago, I had the pleasure of recording Episode 18 of Herding Code on Functional Programming and F#. The topic on their minds was around functional programming, and more in particular with some of the things I've been doing around the .NET space both C# and F#.
-
Functional C# - Pattern Matching
In the past, I've covered quite a bit of functional programming in C# 3.0 and how you can implement some of the basic constructs using the language. In preparation for the Richmond Code Camp coming up on October 4th, for which I'm planning to present "Functional C# -or- How I lost the foreach and learned to love LINQ", I'm revisiting some of the topics I've talked about in the past. One of those topics is pattern matching.
-
Object Oriented F# - More Extension Everything
In a previous post, I covered a few ways we can do extensions methods, properties, events and so on with F#. After a few chats, I realized I may have missed a couple of cases that I wanted to cover today. These two cases are extension operators and extension properties with indexers.
-
Side Effects and Functional Programming
One of my first posts at CodeBetter was in regards to side effects and how, when unmanaged, can be truly evil. Today, I want to revisit that topic briefly in regards to functional programming and managing side effects. When I was out in Redmond a couple of months ago, I had the opportunity to sit down with Erik Meijer to discuss functional programming among other topics. In there, we discussed a number of issues around managing side effects and state in your code, and how both C# and F# don't intrinsically support such a concept. Languages like Haskell, of course do with IO monads and other such monadic structures. Whether languages such as F# and Erlang are not pure functional programming languages is another matter, due to the fact that you don't have to declare when you are side effecting (reading a database, writing to console, spawning a process, etc).
-
Object Oriented F# - Extension Everything
A post by Jeremy Miller caught my eye this morning in regards to extension methods in Javascript. While I think that's pretty interesting, I don't think it's a real fair comparison. Instead, I want to revisit C# and even F# with regards to extension methods, because there are a few things I wanted to point out. This is the start of a series covering object oriented programming techniques and how they are used in F#. Note that F# is not only a functional language, but it is a general purpose programming language that supports functional, imperative and object oriented techniques. I hope this series is useful for pointing out that F# fits the need very nicely for object oriented constructs, which is seldom covered.
-
DC ALT.NET - 9/24/2008 - Building ASP.NET MVC Applications with Troy Goode
The September meeting for DC ALT.NET will be on September 24th, 2008 from 7PM-9PM. Check out our site and our mailing list for more information as it becomes available. This month, Troy Goode will present on building applications with ASP.NET MVC. This will be a basic introduction, but also how to build practical applications, such as a blog engine using MVC. Download the latest bits, ASP.NET MVC Preview 5 and follow along as I will be.
I'd like to thank Cynergy Systems, Inc for sponsoring this month's event. As a side note, they are actively looking for experienced .NET developers with interest in WPF and Silverlight. So, if you're looking for a great company that is a leader in the Rich Internet Applications area and want to work in downtown Washington D.C., definitely check them out.
The information is as follows:
DateTime:
9/24/2008 - 7PM-9PM
Location:
Cynergy Systems Inc.
1600 K St NW
Suite 300
Washington, DC 20006
Show Map
Be there and hope to see a passionate crowd!
-
FsTest Updated with F# CTP
Back in June, I announced the creation of FsTest, a testing Domain Specific Language for F#. Since that time, the F# team has released the September 2008 CTP, which finally gives F# full citizenship within Visual Studio with real project files. I felt it was time to update FsTest, and more in particular, FsxUnit, which uses xUnit.net as the back end for doing assertions. Go ahead and pick up the latest bits here from the CodePlex site.
-
Functional Programming Notables #1
Lately, there has been a lot of momentum around functional programming. While I was away on vacation for the past couple of weeks, I came across quite a few items that caught my eye. This isn't meant to be a link blog by any means, but to show that there is a bit of new information coming out around functional programming and what it means to you.
-
F# Releases September 2008 CTP!
Don Syme just announced today the F# Community Technical Preview (CTP) Release September 2008 which is now available for download as well the launch of the MSDN F# Developer Center. I've been playing with these builds lately and they are great improvements in usability as well as better integration into Visual Studio and MSBuild. Be sure to check out Don's post on the matter on how the language has evolved and the changes that have been made. Some of the big items I've that are part of the CTP include:
-
Reminder: DC ALT.NET - 8/28/2008 - Ruby with Jeff Schoolcraft
The August meeting for DC ALT.NET will be on August 28th, 2008 from 7-9PM. Check our site and our mailing list for continuing updates and future meetings. This month, Jeff Schoolcraft, ASP.NET MVP, will host a conversation on Ruby. This will include some Ruby demos, a little bit of Ruby on Rails, as well as approaching it from the ASP.NET mindset. This talk will go very nicely with our talk on ASP.NET MVC next month.
-
Async Computation Expressions - Resource and Exception Management
For the next part of my coverage of Asynchronous Computation Expressions, I'm going to talk about the things you get for free when you use them. I was reminded of this during a recent chat with Greg Young about how hard it was during asynchronous operations to notify the controlling thread of an exception. These asynchronous operations are meant to handle such things.
-
Aspects of Functional Programming in C# Presentation and Code Redux
I've continued to add to my Functional C# project as time goes along. This is intended to be a library of functional programming techniques in C# 3.0 and some demonstrations of moving from imperative style programming to a more functional programming style. This is an ongoing project and more will be added in time, and I may end up just putting them up not as samples, but as a library. But in the mean time, there are a lot of interesting topics that are being covered.
Some of the topics covered in these code projects are: -
Recursing on Recursion - Continuation Passing
In this continuing series of my back to basics, I've been talking about recursion, and various strategies around using it effectively. This includes covering the basic types of recursion, whether it be linear, binary, and tail. Then I took it a step further with topics on list recursion and memoization techniques. This is an ongoing part of my back to basics series in which I hope is a refresher for many who don't use these things on a daily basis.
-
Adding Async Operations to Asynchronous Computation Expressions in F#
Asynchronous Computation Expressions are an extremely powerful feature in F#. It's important to not only know how to use them, but also to extend the behavior so that other classes can bind and perform asynchronous behavior. What I want to show in this post is how easy it is to add this behavior to any custom web service that you may create.
-
DC ALT.NET - 8/28/2008 - Ruby with Jeff Schoolcraft
The August meeting for DC ALT.NET will be on August 28th, 2008 from 7-9PM. Check our site and our mailing list for continuing updates and future meetings. This month, Jeff Schoolcraft, ASP.NET MVP, will host a conversation on Ruby. This will include some Ruby demos, a little bit of Ruby on Rails, as well as approaching it from the ASP.NET mindset. This talk will go very nicely with our talk on ASP.NET MVC next month.
-
Task Parallel Library and Async Computation Expressions
Very recently, I've given a few talks on Asynchronous and Concurrent Programming in F#. In this talk, I gave a brief overview of the options you have when dealing with concurrency and asynchronous behavior. During these talks, I was asked a few times about where asynchronous computation expressions (workflows) fit and how it differs from doing things with the Task Parallel Library from the Parallel Extensions for .NET. There are some differences worth exploring and I'll post some code snippets to compare and contrast the two.
-
Recursing into Recursion - Memoization
When doing heavy computations through recursion, memoization becomes a pretty important topic. The idea behind memoization is to speed up your programs by avoiding repetitive calculations for previously processed function inputs. Let's go ahead and try a simple example using the ever so trite Fibonacci sequence as a quick example.
-
Reminder - DC ALT.NET Meeting 7/24/2008 - LINQ Deep Dive
Just as a reminder from the previous post, the July meeting for DC ALT.NET will be on July 24, 2008 from 7PM-9PM. Check out our site and our mailing list for more information as it becomes available. This month, K. Scott Allen, of OdeToCode and a co-host of Herding Code, will present a deep dive into LINQ and a code-along so that we can follow along. The intent is to go as deep as we can with LINQ to find out what works, what doesn't and how to use it effectively. So, bring your laptops and get ready...
LINQ
K. Scott Allen has recently recorded an episode on Herding Code dedicated to LINQ. It's well worth a listen as he talks about the following LINQ topics:
- What is it?
- How introducing LINQ to .NET changed the framework
- LINQ Providers
- LINQ to XML
- LINQ to SQL - how it’s different from EF, tips and tricks, when to use it
Special Thanks
Once again I'd like to thank Cynergy Systems, Inc for sponsoring this month's event. As a side note, they are actively looking for experienced .NET developers with interest in WPF and Silverlight. So, if you're looking for a great company that is a leader in the Rich Internet Applications area and want to work in downtown Washington D.C., definitely check them out.
Details
DateTime:
7/24/2008 - 7PM-9PM
Location:
Cynergy Systems Inc.
1600 K St NW
Suite 300
Washington, DC 20006
Show Map
Be there and hope to see a passionate crowd! And don't forget to bring your laptop!
-
Recursing into List Processing
Lately I've been getting back to basics with regards to recursion. This is a basic and essential skill, especially in the functional programming world. Today's dive will be into immutable lists and recursion. I'll do my best to provide the F# and C# equivalent to each call. This is in part of the back to basics and from here I'll move onto other subjects.
Let's catch up to where we are today:
Recursive List Processing
In the functional programming world, and especially in the functional programming world are singly linked immutable lists. Each of the items in the list is a cell with a reference to the next item in the list. For functional programming, unlike imperative programming, they are optimized for recursion. By that I mean that they have a head (the first item) and the tail (the rest of the list). F# has the use of this through the List<'a> class.
Let's walk through a simple example of how you might sum up all items in a list using recursion as well as one for calcuating the length of the list. In F# this is pretty simple, using pattern matching.
F#
#light module ListExtensions = let rec sum = function | [] -> 0 | h::t -> h + sum t let rec length = function | [] -> 0 | h::t -> 1 + length t [1..20] |> ListExtensions.sum |> print_any [1..10] |> ListExtensions.length |> print_any
This function above had a simple pattern matching over the list which said for an empty list, the result would be zero, else it would be the sum of the head and the calculation of the rest of the list and eventually winds its way down to the end of the list. Likewise inthe length, it adds 1 to the calculation of the length function until it winds down to nothing left in the list. In the base .NET libraries, we don't have a list like this, but it's actually not that hard to create one. Let's walk through a simple immutable linked list much like the List<'a> in F#.
Let's define in C# what something like that might look like. I'll start with something the way Wes Dyer had it but with a few changes:
public interface IImmutableList<T> : IEnumerable<T>
{
T Head { get; }
IImmutableList<T> Tail { get; }
bool IsEmpty { get; }
bool IsCons { get; }
}
As you can see, we have a head, a tail and a way to determine if this list is empty or if it is a cons. All very important pieces to the puzzle. This also inherits the IEnumerable<T> interface as well so that we can iterate this should we need to. Now, let's go into the implementation details of the immutable list.
public class ImmutableList<T> : IImmutableList<T>
{
public class EmptyList : ImmutableList<T> { }
public class ConsList : ImmutableList<T>
{
internal ConsList(T head, IEnumerator<T> enumerator)
{
Head = head;
this.enumerator = enumerator;
}
}
private static readonly IImmutableList<T> empty = new EmptyList();
IImmutableList<T> tail;
IEnumerator<T> enumerator;
public T Head { get; private set; }
public static IImmutableList<T> Cons(T head, IImmutableList<T> tail)
{
return new ConsList(head, tail.GetEnumerator());
}
public static IImmutableList<T> Cons(IEnumerator<T> enumerator)
{
return enumerator.MoveNext() ? new ConsList(enumerator.Current, enumerator) : empty;
}
public IImmutableList<T> Tail
{
get
{
if (enumerator != null)
{
tail = Cons(enumerator);
enumerator = null;
}
return tail;
}
}
public bool IsCons { get { return this is ConsList; } }
public bool IsEmpty { get { return this is EmptyList; } }
public static IImmutableList<T> Empty { get { return empty; } }
IEnumerator IEnumerable.GetEnumerator()
{
return ((IEnumerable<T>) this).GetEnumerator();
}
public IEnumerator<T> GetEnumerator()
{
for (IImmutableList<T> current = this; !current.IsEmpty; current = current.Tail)
yield return current.Head;
}
}
Now what I have done here is implemented two internal lists to represent a "cons" and one to represent an empty list. This helps when determining whether the list is empty or not without having to check references and whether something is null. Inside my ConsList<T>, I'm able to create a new instance of the ImmutableList<T> with the head value and the rest of the list.
The head of the list is just simply that, the first item. When the tail property is called, I create a new IImmutableList<T> with my enumerator by calling the Cons method. I also have properties which define and empty list, whether it is empty or whether it is a "cons". Like I said, there's nothing hard about this.
Then I'm able to define a Sum and Length methods much as above with something like this:
public static int Sum(this IImmutableList<int> list)
{
if (list.IsEmpty)
return 0;
return list.Head + Sum(list.Tail);
}
public static int Length<T>(this IImmutableList<T> list)
{
if (list.IsEmpty)
return 0;
return 1 + Length(list.Tail);
}
And then invoking this is pretty straight forward through the main method:
static void Main(string[] args)
{
var enumerator = Enumerable.Range(1, 10).GetEnumerator();
var list = ImmutableList<int>.Cons(enumerator);
var sum = list.Sum();
var length = list.Length();
Console.WriteLine("List sum : {0}", sum);
Console.WriteLine("List length :{0}", length);
}
But what about tail recursion when doing list processing? Let's walk through one more example of tail recursion with lists. In this example, I'm going to go ahead and return the last item in the list. It's a pretty simple and straight forward function which determines whether the list only has a head, or if it also has a tail, then recurse on the function again.
F#
#light
module ListExtensions =
let rec last = function
| [] -> invalid_arg "last"
| [h] -> h
| h::t -> last t
[1;5;3;2;6;] |> ListExtensions.last |> print_any
Now the C# version should look just as familiar to you. Basically instead of the pattern matching, which I'd love to have in C#, I'm using if statements to determine whether I'm returning the head, or the evaluation of the Last function again until I wind down to the head.
C#
public static T Last<T>(this ImmutableList<T> items)
{
if(items.IsEmpty)
throw new ArgumentNullException("items");
var tail = items.Tail;
return tail.IsEmpty ? items.Head : tail.Last();
}
var e1 = new List<int> {1,5,3,2,6}.GetEnumerator();
var items = ImmutableList<int>.Cons(e1);
var last = items.Last();
Console.WriteLine("Last item: {0}", last);
In the past I covered why tail recursion is important in my previous post. Unfortunately, the C# code won't do much for you uniless the compiler is optimized for tail calls, or you are using the x64 version of Windows. I have some of these samples in my Functional C# samples on MSDN Code Gallery.
Wrapping it Up
As you can see, recursion is a pretty interesting topic. One of the best ways to avoid mutable state in your programs is through recursion. I've shown some simple examples of where recursion can help to solve some of those issues. This will wrap up a lot of the discussions about recursion and then I'm moving into such topics as memoization, continuations and so on. The code samples will be available on the Functional C# Samples during this back to basics trip.
-
Learning Erlang - Erlang Gaining Momentum
You may have noticed that I've been talking a bit about concurrency and Erlang recently. I've started to notice that others are taking notice and giving Erlang another look. I've been a fan of the language for a while, although it is a functional language ala a Haskell, OCaml, F# and so on, it's key strengths doesn't come necessarily from that, but from how it handles concurrency. I'm really fond of the language succinctness and beauty using pattern matching, higher order functions and so on much as I have with F#.
Gaining Momentum
As I stated before, many people are starting to give Erlang another look. For more than 20 years since its inception around 1987, Erlang has received little notice outside of the telecomm industry from whence it came. Then in 1998, it was released as open source, but still not much momentum gathered around the language. But, then things started to change recently. Moore's law started to change, not from faster CPUs, but more cores to the CPUs. Our traditional methods of sequential imperative programming couldn't scale and utilize a lot of the machine this way.
Then we started thinking about locks, monitors, mutexes, but the programming model isn't exactly easy. And to boot, they tend to be a bit low-level for most pieces that we need. Instead, we need more constructs such as guaranteeing pure functions and this function is ok for concurrency at either a language level or at least a library level. Erlang is designed with this in mind, as it is a functional language, so functions are values, and values are immutable. But not only that, the isolation of the processes allows for lightweight processes with no shared state between them. This allows for a given process to fail without taking down the whole system, another important concurrency item that is important.
With this, companies started to take notice. As noted by a post by Chris Vertonghen in his post "Erlang, or Utility-computing vs. Appliance-computing", he notes a few items of interest such as:
- Amazon SimpleDB is built on Erlang
- IMDB switching from PERL to Erlang
- Facebook chat written in Erlang
- Google Gears using "Erlang-style" concurrency
Other places are also looking at Erlang. According to the GitHub blog, there is a project called egitd and is a replacement for the stock git-daemon that ships with git. Erlang is perfect for these massively concurrent systems with good failover capabilities.
Getting Started
Getting started in Erlang is pretty easy. Joe Armstrong's Programming in Erlang book tells you all you need to know on how to set it up. I downloaded the distribution from the Erlang site for the runtime and I used Eclipse with Erlide to run through the samples in the book. I had no issues setting it up and it's quite easy to use.
I highly recommend that you get Joe Armstrong's Programming Erlang book as well as check out the Pragmatic Programmer screencasts on Erlang which you can find here.
From the F# Perspective
I've stated before that Erlang-style messaging through mailboxes is already supported in F#. But, it's nowhere near as capable as Erlang. Let's hope these kinds of issues can be raised and added to the libraries. But, let's look at it from another perspective. If you know functional programming and F#, you shouldn't have trouble in Erlang whatsoever. In fact, I have a few examples of functions written in both Erlang and F# that do the same thing.
Pattern Matching
Pattern matching is pretty important in Erlang. Such constructs as for loops do not exist, instead relying on patterns instead to handle the basic control flow. Let's look at a simple area calculator written in Erlang.
-module(geometry)
-export(area/1)
area({rectangle, Width, Ht}) -> Width * Ht;
area({circle, R}) -> 3.14159 * R * R;
area({square, X}) -> X * X.
geometry:area({rectangle, 10, 5}).
geometry:area({circle, 1.4}).
geometry:area({square, 2.5}).
What this sample did was used a tuple to wrap up the type of rectangle, circle and square. Then I create multiple area functions that are my pattern. Then at the bottom, after compiling and exporting my functions through my module, I'm able to call the functions with the given values. How about in F#?
module Geometry =
type Shape = Circle of float | Rectangle of float * float | Square of float
let area = function
| Circle R -> 3.13159 * R * R
| Rectangle (Width, Ht) -> Width * Ht
| Square X -> X * X
Geometry.area (Geometry.Rectangle(10.0, 5.0))
Geometry.area (Geometry.Circle(1.4))
Geometry.area (Geometry.Square(2.5))
I changed the shape to be a discriminated union because overloading of functions to take different tuples is not allowed. Instead, I then switched to a union and pattern matched against that, thus giving the value. Let's move onto more quick examples on how they differ
Lists
Simple list processing is also pretty important. F# and Erlang are also quite similar in this respect as well. There are a few things F# doesn't have such as the remove operator, but for the most part, it's pretty comparable. Functional languages have much different collections than imperative ones, which are optimized for recursion. This includes the feature of the head, the first item in the list, and the tail, the rest of the list. Let's look at a simple sum function in Erlang.
-module(MyLists)
-export(sum/1)
sum([H|T]) -> H + sum(T).
sum([]) -> 0.
L = [1,3,10]
MyLists:sum(L)
What I am able to do is pattern match against the head and the tail of the given list to add the head value to the recursive call to the tail through linear recursion. Next, I'll take that same sample and port it to F# to show how little difference there is.
module MyLists =
let rec sum = function
| [] -> 0
| H::T -> H + sum(T)
let l = [1;3;10;]
let lResult = MyLists.sum(l)
Applying lambda expressions on top of lists is pretty simple as well. Here is a simple map function on a list in both Erlang and F#.
-import(lists, [map/2]).
L = [2,4,6,8,10].
LResult = lists.map(fun(x) -> x*x end, L).
And then in F#, to be able to do the map:
[2;4;6;8;10] |> List.map(fun x -> x * x)
As you can see, there are some differences, but for the most part, I haven't had any issues jumping between the languages. This was just meant to be a little exercise about how you can learn from each language. There is much to be learned from both languages, especially in regards to concurrency. I hope to cover more of that shortly.
Wrapping It Up
Functional languages such as Erlang and F# have a lot to offer in terms of concurrency oriented programming. I think now that Moore's law has changed in a way that standard sequential programming doesn't work as well, it's time to start discovering what the functional programming people and for that matter Erlang people have been talking about. This is meant to give you just a little kickstart to look at Erlang, and indeed F# for concurrency. But, not only that, but take the ideas from here and apply them to your other language of choice whether it be C#, Ruby, Python and so on.
The real keys to success for Erlang reside not only in the language itself, but also the frameworks around it, and the tooling, such as the IDEs, etc. Ruby became popular as a language due to the Rails framework although the tooling still isn't the best for it. How will Erlang grow in this area remains to be seen, but I am optimistic.
-
Aspects of Functional Programming in C# Presentation and Code
As noted before, I was scheduled to give a presentation on Aspects of Functional Programming in C# 3.0 yesterday at the Rockville .NET User Group (RockNUG). Unfortunately, before the presentations were to commence, the power went out and the event was scrapped for the evening. Instead, the intention is to reconvene next month at the same time to present again. So, I expect I'll be there once again the same time next month. In the mean time, I've decided to post my slide deck and code samples for all to see. I'll cover that more below.
Here are some resources that will be helpful in covering functional programming aspects:
Functional Programming
C# Futures
Functional Programming Aspects with C#
- Functional C# Revisited - Into the Great Void
- Functional C# - Unfolding Lists
- Functional C# - Learn from F# and LINQ
- Recursing into Linear, Tail and Binary Recursion
- Define Recursion - See Recursion
Podcasts
- .NET Rocks Episode 310 - Simon Peyton Jones on Functional Programming and Haskell
- .NET Rocks Episode 270 - Erik Meijer on LINQ
- Software Engineering Radio Episode 97 - Anders Hejlsberg
As I said before, I'm making the code available as I put it up on MSDN Code Gallery as the FunctionalCSharp project. This is intended to be a library of functional programming techniques in C# 3.0 and some demonstrations of moving from imperative style programming to a more functional programming style. This is an ongoing project and more will be added in time, and I may end up just putting them up not as samples, but as a library.
Some of the topics covered in these code projects are:
- Closures
- Currying
- Filter High Order Function
- Fold High Order Function
- Iterators
- Lazy Evaluation
- LINQ
- Lists (Immutable and Recursive)
- List Comprehensions
- Map High Order Function
- Memoization
- Monads
- Operators (Forward, Reverse, etc)
- Recursion
- Unfolding and Generators
My slide deck can be found here and my code snippets once again can be found here.
-
DC ALT.NET - 7/24/2008 - LINQ Deep Dive with Scott Allen
The July meeting for DC ALT.NET will be on July 24, 2008 from 7PM-9PM. Check out our site and our mailing list for more information as it becomes available. This month, K. Scott Allen, of OdeToCode and a co-host of Herding Code, will present a deep dive into LINQ and a code-along so that we can follow along. The intent is to go as deep as we can with LINQ to find out what works, what doesn't and how to use it effectively. So, bring your laptops and get ready...
I'd like to thank Cynergy Systems, Inc for sponsoring this month's event. As a side note, they are actively looking for experienced .NET developers with interest in WPF and Silverlight. So, if you're looking for a great company that is a leader in the Rich Internet Applications area and want to work in downtown Washington D.C., definitely check them out.
The information is as follows:
DateTime:
7/24/2008 - 7PM-9PM
Location:
Cynergy Systems Inc.
1600 K St NW
Suite 300
Washington, DC 20006
Show Map
Be there and hope to see a passionate crowd!
-
Recursing into Linear, Tail and Binary Recursion
In my previous post, I talked about some of the basics of recursion and why you might want to use it to your advantage. Today, let's dive a little deeper into the different kinds of recursion, including linear, tail recursion and finally binary recursion. This is in a series of back to basics covering recursion in some depth.
Starting Off
Where we left off is to take a simple imperative statement and make it not only recursive, but we could also hypothetically turn it into tail recursive as well. Let's start off with the simple, yet overused factorial example in a very imperative way using looping:
C#
public static int Factorial(int n)
{
var fact = 1;
var i = n;
while (i > 0)
{
fact = fact * i;
i--;
}
return fact;
}
F#
let factorial_imperative n =
let mutable fact = 1
let mutable i = n
while i > 0 do
fact <- fact * i
i <- i - 1
fact
So, what we're left with is mutation galore. That's perfectly ok in the imperative world, but it doesn't make sense to me in the functional world since we have such things as recursion. Functional languages make you go out of your way to make values mutable, because by default they aren't mutable at all.
Linear Recursion
Linear recursion is by far the most common form of recursion. In this style of recursion, the function calls itself repeatedly until it hits the termination condition. After hitting the termination condition, it simply returns the result to the caller through a process called unwinding. Most of my samples I posted in the previous post followed this way of recursion.
C#
public static int Factorial(int n)
{
if (n <= 1)
return 1;
else
return n * Factorial(n - 1);
}
F#
let rec factorial_linear n =
if n <= 1 then 1 else n * factorial_linear (n - 1)
As you noticed, the last call here is a calculation, which helps unwind itself to the termination condition of 1. Of course it's also guarded against negative input as well which would cause an infinite loop, which would be pretty bad. But with large input, this could be a problem.
Tail Calls
As I've mentioned before, it's pretty important to think about the stack when you do recursion. For the reasons of stack overflows, it's pretty important to mention. When you call an F# function, stack space is allocated and then freed when the function returns, or, when a tail call is performed. We have to be aware of this, because a very deep set of nested function calls will cause a StackOverFlowException to be thrown. Below is a simple example on how this can occur.
#light
let rec recursiveFunc i : unit =
if i >= 1000000 then
()
else
if i % 1000 = 0 then
printfn "Recursing at %i" i
recursiveFunc (i + 1)
printfn "Just called the function with %i" i
recursiveFunc 100
The above function actually recurses, but that's not the last thing the function does. It in turn calls a printf end line function to display the result. If you let this run, you'll get a nice StackOverFlowException and it will take down your F# Interactive (fsi) session. How do you fix this situation? Well, it's a topic called tail recursion which will expand upon this.
Tail Recursion
Tail recursion is a specialized form of the linear recursion where the last operation of the function happens to be a recursive call. The difference here is that in my previous samples, I've been calling functions which perform a calculation on the result of the recursive call. That could lead to stack overflows should the recursion get too deep. Instead, I don't want to do any work during the unwinding phase, just return the value from the function.
Let's take the above sample and make it tail recursive:
#light
let rec recursiveFunc i : unit =
if i >= 1000000 then
()
else
if i % 1000 = 0 then
printfn "Recursing at %i" i
recursiveFunc (i + 1)
recursiveFunc 100
All I had to do was get rid of the last statement and now the last statement is simply a calling of the function again with no work performed. If I run it through the F# interactive again, I get no problems at all, and it runs through smoothly. Let's refactor our factorial to be tail recursive in F#, and then look at a C# solution.
F#
let rec factorial_tail n =
let rec factorial_inner acc x =
if x <= 0I then acc
else factorial_inner (x * acc) (x - 1I)
factorial_inner 1I n
As you can see, the last calls to my recursive inner function is indeed tail recursive as no work is being done to the result of any calls. From there, my outer function should be able to call passing in the accumulator of 1 and the number we're passing in. Since I'm using BigInt, I don't have a problem with overflow either in regards to really large input. This is something that the .NET BCL was working on, but kept it internal in the System.Core.dll it seems. But, F# was nice enough to give us BigNum and BigInt implementations, as F# tends to be rather math centric.
The Problem with C# and Tail Calls
Now turning our attention to the C# counterpart to this, let's try our implementation of the above functionality in it. Instead of just another function, I'll inline the accumulator function inside as an anonymous function:
C#
public static ulong Factorial(ulong n)
{
Func<ulong, ulong, ulong> factorial_acc = null;
factorial_acc = (acc, x) =>
{
if (x <= 0) return acc;
return factorial_acc(x * acc, x - 1UL);
};
return factorial_acc(1UL, n);
}
But the problem is, is that this won't work on a 32 bit machine. Why you might ask? Well, as Jomo Fisher, an F# team member, points out in his post about recursion in three languages, the C# compiler does not do tail call optimization. Instead, all managed languages have a second opportunity to optimize through either NGEN or the JIT compiler. As it turns out, the x64 version of the JIT will optimize the tail call right now, whereas the 32 bit compiler will not. By default on your C# projects, it's targeted at AnyCPU which in my case since I'm running on a VPC, targets x86, will cause the overflow, whereas if I had been running on my base machine, it would have been ok.
This is another in the line of reasons why F# is the better language for recursion as well as functional programming fundamentals. C# will get you partially there, but there are things such as these which will trip up developers and leaving themselves nowhere to go. To which I say, pick the best language for the job at hand, whether it be F#, C#, Ruby, Python, Erlang, Haskell, JavaScript, etc.
Binary Recursion
Another form of recursion is binary recursion. This form of recursion has the potential for calling itself twice instead of once as with before. This is pretty useful in such scenarios as binary trees as well as the trite and overused Fibonacci sequence. Such an example is below:
let rec fibonacci n =
if n <= 2 then 1
else fibonacci (n - 1) + fibonacci (n - 2)
But what's interesting is that we could do this better through tail recursion through the use of our inner auxiliary function, such as this:
let fib n =
let rec fib_acc a b x =
if x <= 1 then b
else fib_acc b (a + b) (x - 1)
fib_acc 0 1 n
But, back to the point, here's another use of binary recursion to print out the values in a tree.
type Tree<'a> = | Leaf of 'a | Node of Tree<'a> * Tree<'a>
let rec printBinaryTreeValues t =
match t with
| Leaf x -> printfn "%A" x
| Node (l, r) ->
printBinaryTreeValues l // called once
printBinaryTreeValues r // called twice
printBinaryTreeValues (Node ((Node (Leaf "jeden", Leaf "dwa")), (Node (Leaf "trzy", Leaf "cztery"))))
As you can see from this example, I printed out the values from the binary tree, leaf by leaf using binary recursion.
Wrapping It Up
As you can see here, I've covered a bit of ground on more recursive algorithms. There is still yet more to be covered including processing of lists, unbalanced trees, continuations and so on. More on that soon! In the mean time, I hope you rediscover recursion and what it can do for you in terms of condensing code. But, it's also important to see where it makes sense and where it doesn't.
-
RockNUG Meeting - 7/9/2008 - Functional C#
Next week I will be presenting a lightning talk at the next Rockville .NET Users Group (RockNUG) on Functional C#. I've talked about this topic quite a bit recently on a couple of threads now:
- Functional C# Revisited - Into the Great Void
- Functional C# - Unfolding Lists
- Functional C# - Learn from F# and LINQ
- Currying
- Filter
- Map
- Option Types
- Tuples
- Folding and Unfolding
- Recursion
- Lazy Evaluation
- And more...
Anyhow, here are the details:
Date/Time:
Wednesday, July 9, 2008 - 6:30-9:00 PM
Location:
Montgomery College, Rockville
Humanities Building - Room 103
Rockville, MD
Directions
Hope to see you there!
-
Define Recursion - See Recursion
Lately, I've noticed a few blogs are doing the come back to basics post, such as Scott Hanselman's. I think that's an effort that should be lauded, because many have a tendency to go off on pretty advanced topics, yet not provide enough for those just starting to get the full context. So, with that, I'm going to dig into one piece of programming that should have been ingrained should you have been a CS major in college or at least took some courses.
Recursion
Recursion is one of those basic topics that come up time and time again as one of the core topics. It's not as often talked about in the imperative and object oriented world, but in the functional programming world, it matters a whole bunch. Not only to be able to describe what it is, but the benefits, and where you might be able to break your problem down into using it.
So, before we get too far, what exactly is it, and how do we get there? Basically recursion is to allow a function to call itself repeatedly during the body of that function. Most imperative languages from the C world use for loops, while loops and so on, so many times recursion isn't needed. Functional languages such as F#, allow for recursion, but makes them a special designation to enforce its behaviors.
When coming to a place such as Microsoft, understanding these concepts are key. Chances are you may get asked some of these questions, because people like me, when walking through complex structures, use recursive algorithms. It's a nice tool to have in the toolbox.
Let's first look at an example not using recursion, then move towards recursion. First start off with a pretty obvious one in computing a factorial:
public static int Factorial(int n)
{
int result = 1;
for (int i = 1; i <= n; i++)
result *= i;
return result;
}
To me, that's pretty horridly imperative. We can make the code much more concise through the use of recursion and not mutate state during the operation. With the proper attention of course to decrementing the counter so that we don't get into infinite loops. An important lesson to learn is to not recurse infinitely, but in a controlled manner towards termination through a technique called "Well Founded Recursion". Let's rewrite this to a much more manageable way:
C#
public static int Factorial(int n)
{
if (n <= 1) // Exit condition
return 1;
return n * Factorial(n - 1);
}
F#
let rec factorial n =
if n <= 1 then 1 else n * factorial (n - 1)
The basic idea is to break down your problems into smaller instances of the same problem. Sometimes, the last thing we do in this function is return the recursion of the function. This is called "Tail Recursion". Below is a simple example of tail recursion:
let rec last l =
match l with
| [] -> invalid_arg "l"
| [head] -> head
| head :: tail -> last tail
The above sample will ultimately give me the last item in a list since F# has pointers to the head of the list, we need to get the last one. We'll get more into tail recursion in the next post, but I thought I'd introduce it now. It's very important as well to know.
Let's take another example, this time walking a directory structure to lazily display all files in a directory. Of course we can note that the Directory.GetFiles already has the capability of getting all files in all folders, but for this exercise, let's pretend it doesn't exist. How might we do this? Let's try the lazy approach the first time around through IEnumerable<string>.
C#
public static IEnumerable<string> GetFiles(string rootPath)
{
foreach(var file in Directory.GetFiles(rootPath))
yield return file;
foreach (var directory in Directory.GetDirectories(rootPath))
foreach (var file in GetFiles(directory))
yield return file;
}
F#
let rec getFiles rootFolder =
seq {
for file in Directory.GetFiles(rootFolder) -> file
for dir in Directory.GetDirectories(rootFolder) ->> getFiles dir
}
What this allows me to do is recurse through a given directory hierarchy by first grabbing all the files and then going through a tail recursion through all the subdirectories. The F# way is a bit more concise through the use of Sequence Workflows, which I'll get to at another time. If you understand anything about F#, understanding workflows is by far one of the most important.
Mututal Recursion
Another interesting way to express recursion is to define them simultaneously by separating the definitions. This allows the functions to play off each other and work towards a deterministic end. The cannonical example of this is the odd/even sample. Let's walk through that quickly in both C# and F#:
C#
public static bool IsEven(int number)
{
if (number == 0)
return true;
else
return IsOdd(number - 1);
}
public static bool IsOdd(int number)
{
if (number == 0)
return false;
else
return IsEven(number - 1);
}
F#
let rec even n = (n = 0) || odd(n - 1)
and odd n = (n <> 0) && even(n - 1)
As you can see, I decrement the counter each time and call the complement function until I reach 0 and at that point, I can determine which one hits 0 and then it becomes apparent whether it is odd or even. F# goes a bit further to simplify this so that I can declare those functions as a pair through the use of the and keyword. Parsing of trees is particularly useful using mutual recursion. But just as easily, we could have done the above sequence without using recursion at all such as this:
public static bool IsEven(int number)
{
return number % 2 == 0;
}
public static bool IsOdd(int number)
{
return !IsEven(number);
}
So, that's not really a good example. instead, let's look at a Hofstadter Male-Female Sequences instead.
The pair of sequences is defined by Female(0) = 1 and Male(0) = 0 and
Female(n) = n - Male(Female(n - 1)
Male(n) = n - Female(Male(n - 1)
This is defined as the same way as before, but we recursively call in the Male to the Female and back to the male, whereas it's the opposite in the FemaleSequence method. This is just a simple implementation of the above algorithm in our C# and F# code respectively.
C#
public static int MaleSequence(int n)
{
if (0 == n)
return 0;
return n - FemaleSequence(MaleSequence(n - 1));
}
public static int FemaleSequence(int n)
{
if (0 == n)
return 1;
return n - MaleSequence(FemaleSequence(n - 1));
}
F#
let rec maleSequence n = if n = 0 then 0 else n - femaleSequence(maleSequence n - 1)
and femaleSequence n = if n = 0 then 1 else n - maleSequence(femaleSequence n - 1)
There are more examples out there, but in the mean time, there's plenty more to cover with recursion. Next, let's cover lists.
Walking Lists
Another thing we can do with recursion is the ability to walk lists. Most people think of lists as an ordered collection with a beginning and an end, with one right after another. How terribly imperative if you think that way... When we think of lists in a recursive way, we think of a list to have an item, and the rest of the list, or just an empty list. C# and the base class library does not have this of course defined in any meaningful way, so let's look at the F# version of a list.
module List =
val hd: 'a list -> 'a
val tl: 'a list -> 'a list
What that tells us is that the head item is the first, and the tail is the rest. Let's do a quick recursion to calculate the length of a list using some pattern matching:
let rec length l =
match l with
| [] -> 0
| head :: tail -> 1 + length tail
What I'm doing is pattern matching against the list. What the pattern matching allows me to do is short circuit if it's an empty list, else, I'm splitting the head and the tail, and adding one to the length of the tail call with the tail of the list. Let's look at another to concat a list of lists into a single list:
let listOfList = [[1;2;3;];[4;5;6;];[7;8;9]]
let rec concatList l =
match l with
| [] -> []
| head :: tail -> head @ concatList tail
There is much more to cover here and I'll do that in subsequent posts.
Why Recursion?
Now that we covered some of the basics, it's time to ask the question why. Why is recursion important and why use it? Well, to answer that lightly, in order to walk such things as trees, directories, and so on, it's an absolute essential. But, let's consider just a general functional programming question of why use it.
It's often the case that when people first start out with programming in F#, they are often in the imperative and OO mindset still. That's ok since F# allows for this, but there are better ways to accomplish in the functional mindset. Many times, people will port over their C# code directly to F# with the mutable variables or reference cells and leave an ugly mess. Some of that can be solved with recursion. Let's take a pretty naive example:
C#
public static void CountDown(int n)
{
while(n > 0)
{
DoOperation();
WaitSome();
n -= 1;
}
}
When translated directly to F# looks like this:
let countDown n =
let mutable localN = n
while localN > 0 do
DoOperation()
WaitSome()
localN <- localN - 1
What we've had to do is use reference cells so that we could change the value of n directly. From there, we have to use special operators to change and alias the value of n. Not the prettiest code. Not only that, but there is mutation galore, and I have to do extra work when creating a local iterating variable. instead, we should focus on recursion and look at the problem slightly differently.
let rec countDown n =
match n with
| 0 -> 0
| _ ->
DoOperation()
WaitSome()
countDown (n - 1)
What this allows me to do is get rid of the local mutables, but also helps me break my problems into smaller, more similar problems which can be recursed. This allows for better code reuse and maintenance I think.
Wrapping It Up
I'd like to spend some more time with tail recursion as I think it's pretty important. As well, I'll also talk about how you can do the same in C# as well (with a little work of course). But in the mean time, I hope I've demonstrated the simple act of recursion, when to look for it, and how to exploit it. Not all problems are ready for recursion, but when you find the right opportunities for them, it's quite powerful.
-
Reminder- DC ALT.NET Meeting - 6/24/2008 - Applied Functional Programming with F#
Just a reminder about tonight's DC ALT.NET meeting. I hope some from the FringeDC and the NoVA Language Group can make it out tonight as it's quite on topic.
The June meeting for DC ALT.NET has been set up for June 24th from 7-9PM. Check out our site and our mailing list as more information becomes available. Once again, I'd like to thank the Motley Fool for hosting the event as they did back in May. This month, I'll be covering Applied Functional Programming with F# as a continuation of the talks I've been giving lately. The beauty of this group like last month's topic of Lisp and this month's topic of F# is to step outside of the comfort zone, look to the outside for better approaches to doing things instead of the "What's new on MSDN" sessions that I hear about time and time again.
The information is as follows:
Location:
Motley Fool
2000 Duke Street
Alexandria, VA, 22314
Map Link
Applied Functional Programming with F#
Recently, I've been doing quite a few talks on the introduction to functional programming and F#. In this session, I hope to cover the basics in short order once again, but also to show the applicability of where this language really hits the right areas. Are we going to immediately flock towards F# and abandon C# and other languages for all of your coding needs? No, but we have definite areas where F# and functional programming excels.
With this talk, I plan to focus on the following:
- Functional Programming Basics
- Custom Workflows
- Async and Parallel Workflows
- Mailbox Processing
- Language Oriented Programming
- Quotations and Expression Trees
- Pattern Matching and Active Patterns
- F# with MPI and High Performance Computing
Going a Step Further
Since I've been covering concurrency with .NET lately, it has me thinking a bit about creating workshops to teach this on weekends. Instead the way we see Code Camps, Day of .NET events and so on, it's an aggregate of all sorts of topics, and not going as deep as I wish. So, instead, I'd like to rectify that situation to hold day long sessions to go deep in any given subject, much like they do with the Philly.NET group. More on this as I flush out the details, but I'd like to hear feedback if people are interested in this sort of thing.
Hope to see a great turnout tonight!
-
Announcing FsTest - A Testing DSL for F#
Over the past couple of months, I've been working on some language oriented programming concepts in F# to prove how Domain Specific Languages could work. This coincided with my lofty goals of working towards more Behavior Driven Development (BDD) frameworks and expressiveness that I think is needed to make them work. So, this led me down a road of looking first at assertion syntax. With that, it made me create FsTest which is now available on CodePlex. This is meant to be a beginning of a conversation on doing better assertions through functional programming and language oriented programming and by no means an end to it.
The Starting Point
During some of my research, I came across a now defunct project on Google Code called FsUnit. The idea behind this project was to put a syntactic wrapper around NUnit to make assertions a bit more readable and to use unique features to F# to make this happen. To be able to write such things as this for my assertions seemed powerful:
1 |> should (equal 1)
true |> should (be True)
And so on... Ultimately, I thought it could be improved and expanded, so I talked to the project owner, Ray Vernagus, and took some of the ideas and ran with them.
Looking at FsTest
I had a couple of issues with the code as it was. But, overall the ideas were quite sound. I also wanted to use xUnit.net as the back end testing framework as I'm pretty comfortable with it. The support for tests on static classes, and the ability to assert on throwing exceptions were some of the pluses that made me move in this direction. Listed below are some of the assertions that are supported:
Testing equality:
"foo" |> should equal "foo"
"foo" |> should not_equal "bar"
null |> should be Null
"foo" |> should be NonNull
"foobar" |> should contain "foo"
"foobar" |> should contain "hello"
Testing True/False:
true |> should be True
false |> should be False
Testing collections:
[1..10] |> should be NonEmpty
[] |> should be Empty
[1..10] |> should have 3
[1..10] |> should not_have 25
Exception Management:
throwsExceptionFunc |> should (throw_exception<ArgumentException>)
doesntThrowException |> should not_throw_exception
And some full examples might look like this:
#light
open System
open Xunit
open FsxUnit.Syntax
let throwsException() : unit =
raise(ArgumentException "Bad things!")
[<Fact>]
let throwsException_should_throw_exception() =
throwsException |> should (throw_exception<ArgumentException>)
[<Fact>]
let value_in_range_should_be_in_range() =
2 |> should be_in_range 0 100
It's a work in progress, but I feel that I have most of the assertion cases covered in this DSL. The ability through partially applied functions really shone when creating this library.
The Concepts Behind It
What makes this work syntactically is the use of the forward operator. I've covered this briefly in previous posts, but I'll elaborate on this again. This is one of the most important operators available to us in the F# language. This is the ability to invert the arguments in such a manner as the first argument is declared first and then the function statement is last.
This is how it's declared in F#:
let (|>) x f = f x
Which allows me to better express my intent and gives me the two advantages:
- Clarity of intent - allows you to perform various operations on the data in a forward chaining way such as:
let length = [1..10] |> List.map(fun x -> x * x * x) |> List.filter(fun x -> x % 3= 0) |> List.length
- Type inference - allows type information to flow from the left to the right and allows me to express my data first as part of my method. Shows better intention this way.
And similarly, something in C# would use extension methods to add a forward method, or maybe in this case a Should method which will then take a function as the second parameter, and then overload it as need be.
Using Actions might look something like this:
public static void Should<TArg1, TArg2>(this TArg1 arg1, Action<TArg1, TArg2> action, TArg2 arg2)
{
action(arg1, arg2);
}
And conversely to use the Func delegate might look like this:
public static TResult Should<TArg1, TArg2, TResult>(this TArg1 arg1, Func<TArg1, TArg2, TResult> func, TArg2 arg2)
{
return func(arg1, arg2);
}
public static void Contain<T>(IEnumerable<T> items, T item)
{
Assert.Contains(item, items);
}
And to use it would look something like this:
Enumerable.Range(1, 10).Should(Contain, 3);
But, I'm not necessarily a fan of that style of syntax. C# isn't quite a functional language which allows me to do such clever things with operators. I don't think it will ever gain that level of expresiveness required.
Instead, I created two functions that could be chained together such as the should function and the be function. This allows me to create some of the examples above. Let's take a look at each function:
let should f actual =
f actual
let be (f : 'a -> unit) actual =
f actual
So, that will allow me to express such things as:
true |> should be True
And the true function might look something like this:
let True condition =
Assert.True(condition)
As you can see, there isn't much to this, and covers most of the assertion scenarios that I've encountered.
Where To Go From Here?
So, where am I headed with this? For right now, I'm happy with the assertion syntax I've been able to achieve with the language. For the future, I'm looking at creating a more expressive way for doing BDD and the expresiveness of F# I think can handle such things. I've been following the Specs project for a little bit and I think they have a few good things going for them, although Scala isn't a functional language in the way that F# is, so I'm not sure how many lessons can be applied. Specter is another interesting one as well as Machine Specifications (MSpec) from the one and only Aaron Jensen.
I'd like to thank the F# team, Dustin Campbell and Harry Pierson (DevHawk) for their help on this as well. The team around F# is a wonderful team and I can't wait for the CTP of F# to ship. Makes me excited sometimes when working for Microsoft like I do.
But, in the mean time, feedback is appreciated. Tell me what works and what doesn't.
- Clarity of intent - allows you to perform various operations on the data in a forward chaining way such as:
-
Concurrency in .NET - Learning from Erlang
I'm finally getting back to my concurrency in .NET posts after a brief hiatus after I got sidetracked on various other functional programming issues such as some language oriented programming and functional C#. In the previous post, I talked about MPI in .NET and I need to get back to that one and address some of the issues raised in the next post in this series. But, in the mean time, let's focus on another area of concurrency through message passing. This time, let's bring Erlang into the picture.
Learning Erlang
For some of the upcoming talks about F# and functional programming I have planned, I will be putting a lot of the focus on concurrency programming through asynchronous and parallel mechanisms. F# is not only a well established functional programming language, but its libraries also lend well to concurrency oriented programming.
But, with these adventures, I've always wanted to reach outside my comfort zone and learn from a language that had concurrency in mind from the start. That made me turn my attention to Erlang. Some of my motivations came from not only learning a new language, which is always nice, but also to learn some of the concurrency and messaging patterns so that I can apply that to F#.
In my learnings, I've compiled a list of resources that can help you learn Erlang. This includes books, podcasts and screencasts that you might find helpful for a good deep dive into the language.
Podcasts
- Joe Armstrong - Software Engineering Radio Episode 89
Joe discusses the history of Erlang, the architecture, and why it is relevant today
- Programming Erlang: Software for a Concurrent World - Joe Armstrong
A book from the Pragmatic Programmer Series which is a comprehensive overview of the Erlang language which covers sequential, concurrent and distributed programming.
- Erlang by Example - Pragmatic Programmer Series
Kevin Smith leads a series of screencasts which cover creating a chat server using Erlang. So far there are some episodes posted on the following topics:- Sending and Receiving Chat Messages
- Messaging Clients by Nickname
- Distributing Clients in a Multi-node Environment
- Adding Store and Forward Capabilities
- Venkat Subramaniam on Functional Programming in Erlang - DNRTV
Venkat introduces the concepts of functional programming through the use of Erlang
Erlang Style Message Passing in F#
To bring this back to F# for just a moment, we can apply some of the lessons learned from Erlang to F#. Today we'll look at a simple kind of message processing called mailbox processing. This pattern is popular in the Erlang language and has been applied to F#. The mailbox is a message queue that you can scan for relevant messages to your message processing agents. The MailboxProcessor class controls this action and is defined in the Microsoft.FSharp.Control.Mailboxes namespace.
This will be a simple example of how to send and receive messages using a single mailbox processor. We can define a message type that will encompass our data. This usually comprises of a receive, a send, and a stop. But, the great thing is that it's not limited to that. We'll use async workflows (yet another post I need to do) to process the message itself, hence why you see the return! statements in there.
#light
open Microsoft.FSharp.Control.CommonExtensions
open Microsoft.FSharp.Control.Mailboxes
type Message = Phrase of string | Fetch of IChannel<string> | Stop
type MessageAgent() =
let agent = MailboxProcessor.Start(fun inbox ->
let rec loop (phrase : string) =
async {
let! msg = inbox.Receive()
match msg with
| Phrase item ->
return! loop(item)
| Stop ->
return ()
| Fetch replyChannel ->
do replyChannel.Post(phrase)
return! loop(phrase)
}
loop(string.Empty)
)
member x.Send(s) = agent.Post(Phrase(s))
member x.Stop() = agent.Post(Stop)
member x.Fetch() = agent.PostAndReply(fun replyChannel -> Fetch(replyChannel))
What I'm also doing is defining handling logic for each message type, the stop, the fetch and the receiving of a phrase. If it's a stop message, we return immediately, else if it's a phrase, we'll go ahead and loop on the given item, and once we're ready to fetch it, then we'll go ahead and post it. After that, I'll go ahead and expose three methods which will allow external access to sending and receiving messages, as well as stopping.
Now, that I have done the basic plumbing for handling messaging like this, then we can go ahead and start sending messages to it and receiving.
let agent = new MessageAgent()
agent.Send("Hello world!")
let result1 = agent.Fetch()
printfn "Message result1: %s" result1
agent.Send("Hello world again!")
let result2 = agent.Fetch()
printfn "Message result2: %s" result2
This is a pretty naive example and just to show the basics of how it could be used. I'm not going to pretend it's anywhere near as powerful as the Erlang message passing libraries, but it's a pretty good start.
Robert Pickering has a pretty good example of Erlang style message passing here. F# also comes with a sample using the MailboxProcessor for a program called ConcurrentLife which is located in the Samples directory of your F# installation.
Retlang
But, what about those in the C# world? Is there a solution? An interesting piece that came up during the look into concurrency in .NET led me back to Retlang, which is a takeoff on Erlang by the author Mike Rettig. I had looked at this previously when Ayende did a brief look back in November here. The framework itself borrows a few ideas from Scala in terms of the event-based actors. Let's take a look at a quick example of sending and receiving messages on it.
static void Main(string[] args)
{
IProcessContextFactory factory = new ProcessContextFactory();
factory.Start();
IProcessContext publisher = factory.CreateAndStart();
IProcessContext consumer = factory.Create();
consumer.Subscribe<int>(new TopicEquals("retlang"), (header, id) => Console.WriteLine(id));
consumer.Start();
for (int i = 0; i < 25; i++)
publisher.Publish("retlang", i);
publisher.Stop();
publisher.Join();
consumer.Stop();
consumer.Join();
factory.Stop();
}
Looks to be a well designed architecture and I'll continue to look at this a bit further. In the mean time, check out Mike's blog for more information.
Wrapping It Up
I hope this brief introduction will get you excited about looking at other functional programming languages and what they can do for you. If not to learn them and apply them in your daily work, but to understand the concepts behind them is rather powerful and should be part of your learning plan anyhow. These above examples of implementations in other languages should help you along.
But, what do I think of Erlang overall? It's too early to tell. Even though the language has been around for a while, it has seen a recent resurgance. With the Pragmatic Programmers throwing their weight behind the language, who's to say? But I think it'd take a bit to push this as yet another language with a virtual machine into the mix over say the JVM, CLR, and so on. Instead, maybe we'll see an implementation on top of .NET, or just applying the lessons learned from it such as we've seen in F#. It was funny to listen to Joe Armstrong think pretty much the same thing as maybe the language won't take off, but the ideas can and ultimately will.
- Joe Armstrong - Software Engineering Radio Episode 89
-
Functional C# - Learn from F# and LINQ
In the last installment of Functional C#, I covered a bit about creating delayed evaluation lists based upon unfolding constructs and generating lists from external resources. Those are some of the higher level high order functions you can do in C#, but let's look at a few more, plus those that are already available to us in .NET 3.5. We'll take samples from F# and show that some of them already exist in the base class libraries and you can use them today without having to reinvent any wheels.
Iterators
One of the most simple operations in functional programming is just the simple iterator. In F#, we have two ways of iterating through any given list or sequence, by index or through the enumerator. Below are simple examples in F# doing just that:
[1..10] |> List.iteri(fun i j -> printfn "%d - %d" i j) // By index
[1..10] |> List.iter(fun i -> printfn "%d" i) // By enumerator
If we inspect the List<T> class and the Array class, we'd find that we have methods that does the enumerating by using the enumerator that looks like this:
List<T>:
void ForEach<T>(Action<T> action);
Array:
static void ForEach<T>(T[] array, Action<T> action);
So, that I could iterate a list much like this:
Enumerable.Range(1, 10).ToList().ForEach(Console.WriteLine);
One thing I thought was critically missing from the IEnumerable<T> class was the ForEach or Iterate as the F#'er in me would say. Implementing one is pretty simple using the C# 3.0 techniques:
public static void ForEach<T>(this IEnumerable<T> items, Action<T> action)
{
if (items == null)
throw new ArgumentNullException("items");
if (action == null)
throw new ArgumentNullException("action");
foreach (var item in items)
action(item);
}
But, what about by index? IEnumerable<T> has no such concept of this, so it doesn't really do us any good to try. But, it works very nicely with IList<T> or System.Array. Let's do both just for grins.
public static void IterateIndex<T>(this T[] items, Action<int, T> action)
{
if (items == null)
throw new ArgumentNullException("items");
if (action == null)
throw new ArgumentNullException("action");
int lower = items.GetLowerBound(0);
int upper = items.GetUpperBound(0);
for (int idx = lower; idx < upper; idx++)
action(idx, items[idx]);
}
public static void IterateIndex<T>(this IList<T> items, Action<int, T> action)
{
if (items == null)
throw new ArgumentNullException("items");
if (action == null)
throw new ArgumentNullException("action");
for (int idx = 0; idx < items.Count; idx++)
action(idx, items[idx]);
}
And then we can do a simple iteration this way:
Enumerable.Range(1, 10).ToArray().IterateIndex((i, j) => Console.WriteLine("{0}-{1}", i, j));
Like I said, nothing too complex here. But, let's get more advanced, shall we?
Folding
In the functional programming world, the fold, also known as reduce and accumulate, is a family of high order functions that process a data structure in a given order and build up a return value. The data structure processed in this type of function is usually a list of some sort. They are pretty powerful which help you avoid a lot of looping and recursion in your code. These functions are in direct contrast to the unfold function that I talked about last time which took a function to generate a list.
In the F# world, we have a couple of ways about thinking about folds, we have support for both left and right folds. The Seq.fold function is applied from a left to right fashion as is the List.fold_left function. The List.fold_right function is the inverse which applies from the right to left. The Seq does not have this as it is a forward only evaluated collection much like IEnumerable<T>.
Some basic examples in F# would look like this:
[1..10] |> Seq.fold(fun acc x -> acc + x) 1
[1..10] |> List.fold_left (fun acc x -> acc + x) 1
Or using simple operator function such as sum would look like this:
[1..10] |> Seq.fold (+) 1
Where the basic structure is:
val fold_left : ('b -> 'a -> 'b) -> 'b -> 'a list -> 'b
The fold right example would look something like this:
List.fold_right max [3; 5; 7; 9; 1; 2;] System.Int32.MinValue
Where we'd want to get the maximum value from our given list, and the Int32.MinValue is our accumulator.
Where the basic structure is:
val fold_right : ('a -> 'b -> 'b) -> 'a list -> 'b -> 'b
So, how would we implement this in C#? Let's do a simple implementation of fold (or fold_left) in C#. It's a rather easy implementation. Let's first do one for IEnumerable<T> and then for IList<T>:
public static T Fold<T, U>(this IEnumerable<U> list, Func<T, U, T> func, T acc)
{
foreach(var item in list)
acc = func(acc, item);
return acc;
}
Enumerable.Range(1, 10).Fold((acc, x) => acc + x, 1);
And now for the IList<T> would look something like this:
public static T FoldLeft<T, U>(this IList<U> list, Func<T, U, T> func, T acc)
{
for (int index = 0; index < list.Count; index++)
acc = func(acc, list[index]);
return acc;
}
new List<int> { 1, 2, 3, 4, 5 }.FoldLeft((acc, x) => acc + x, 1);
Seems simple enough where we keep executing the function with the accumulator and the current item in the collection until we are complete. The same implementation can also be said for the FoldRight function which does the reverse of
public static T FoldRight<T, U>(this IList<U> list, Func<T, U, T> func, T acc)
{
for (int index = list.Count - 1; index >= 0; index--)
acc = func(acc, list[index]);
return acc;
}
int foldRight = new List<int> { 5,9,1,3,4,3 }.FoldRight((acc, x) => Math.Max(acc, x), int.MinValue);
Where the answer would be 9 as the maximum number.
But, wait! Don't we already have these things in .NET 3.5? With LINQ, the answer is yes, well, partly. Let's look at the Enumerable.Aggregate function:
public static TAccumulate Aggregate<TSource, TAccumulate>(
this IEnumerable<TSource> source,
TAccumulate seed, Func<TAccumulate, TSource, TAccumulate> func)
And an implementation might look like this:
Enumerable.Range(1, 10).Aggregate(1, (acc, x) => acc + x);
So, as you can see, it solves the Fold and FoldLeft operations, but does not cover the case of FoldRight, unless I were to somehow use the Reverse extension method also available on Enumerable class. But of course that could be bad if my collection were infinite...
Filtering
Another idea from F# is the filter function. This gives us the ability to filter a given collection by the criteria given. The function looks like this:
val filter : ('a -> bool) -> 'a list -> 'a list
And a simple implementation would look like this:
let mod3List = [1..100] |> List.filter(fun x -> x % 3 = 0)
But, how would we do something similar. Let's mock something up in C# using extension methods.
public static IEnumerable<T> Filter<T>(this IEnumerable<T> source, Predicate<T> func)
{
foreach (var item in source)
{
if(func(item))
yield return item;
}
}
Enumerable.Range(1, 100).Filter(x => x % 3 == 0);
That's great, but... we already have that in .NET 3.5 once again through LINQ, so no need to reinvent the wheel here either. Instead, let's look at the Enumerable.Where method:
public static IEnumerable<TSource> Where<TSource>(
this IEnumerable<TSource> source,
Func<TSource, bool> predicate)
And then I can write my function as follows:
Enumerable.Range(1, 100).Where(x => x % 3 == 0);
So, once again, the core libraries have a lot of the functional programming things in mind already that we can take advantage of. Let's look at one final one for this installment.
Mapping
The map function in functional programming is to take a function and apply it to each item in the collection. The function will look like this:
val map : ('a -> 'b) -> 'a list -> 'b list
let cubeList = [1..100] |> List.map(fun x -> x * x * x)
Now, let's prototype how this might look in the C# world to implement something like this:
public static IEnumerable<TResult> Map<T, TResult>(this IEnumerable<T> source, Func<T, TResult> func)
{
foreach (var item in source)
yield return func(item);
}
var cubes = Enumerable.Range(1, 100).Map(x => x * x * x);
But once again, .NET 3.5 and LINQ already solved this problem as well. The Enumerable.Select method already implements this very logic:
public static IEnumerable<TResult> Select<TSource, TResult>(
this IEnumerable<TSource> source,
Func<TSource, TResult> selector)
This allows me to rewrite my function so that it looks like this:
var cubes = Enumerable.Range(1, 100).Select(x => x * x * x);
Wrapping It Up
As I gave examples above, many of the functional programming functions that are a given in the FP world have already been implemented in .NET 3.5, albeit under different names. Once again, I'll emphasize that C# is an "ok" language to understand functional programming aspects and let's you get over one hop of the programming style without having to learn the new language. But, to get the full breadth of what functional programming can do for you in terms of pattern matching, type inference, generic functions, immutability and so on, F# is the real option in the .NET world.
-
Functional C# - Unfolding Lists
In a previous post, I talked about how I thought C# has some significant drawbacks from being considered a more functional language. But, that wasn't to exclude it as a language altogether, as it has some pretty useful features. Lately, when I have been talking about F# in my sessions, many people wonder why use F# and not just use the functional aspects of C#. They figure that sooner rather than later, C# will have most of those features anyways. That may be true to some extent, but C# will never be as expressive, nor flexible as F# as a functional language or for doing language oriented programming. My thinking is that C# should remain the mainstream OOP and slightly FP language that it is without trying to do too much at once such as becoming fully dynamic or fully functional.
But, that's not to stop us from having fun with trying to implement some of the features of the F# libraries in C#. In fact, that helps you gain the understanding of what it may be doing underneath the covers. I find it's easier sometimes to teach the fundamentals of functional programming through the use of C# for those in the imperative and OO mindset. Today, let's walk through a few samples of creating lists through functional programming techniques. But first, a correction.
Corrected on Currying
As I mentioned before, currying is the simple act of reducing a function with multiple arguments into a single argument high order function. I posted the typical example using the Func, but wasn't quite right on the Action one. My thanks to Alexey Romanov for pointing this out.
public static Func<TArg1, Action<TArg2>> Curry<TArg1, TArg2>(this Action<TArg1, TArg2> action)
{
return x1 => x2 => action(x1, x2);
}
Now with both of these currying becomes a bit more natural so that now I can do the following:
Action<IEnumerable<int>, int> contains = (x, y) => x.ShouldContain(y);
var curriedContains = contains.Curry();
var containedBy30 = curriedContains(Enumerable.Range(1, 30));
containedBy30(3);
Still, it's not as natural as I'd like it to be in terms of having to specifically mark is as a curried function instead of it being more natural.
Generating Lists Through Unfolding
This is probably one of the more difficult functions to understand. The goal of the unfold function is to create a delayed evaluation list. What we want is the ability to have a function evaluated repeatedly so that we can generate the items in our list. This evaluation function must return an option type (Option<A>) that can be either Some(x) or None as well as the need for tuples (Tuple<TArg1, TArg2>). But, in C#, we don't have those features. After consulting Dustin Campbell, I noticed that he already has done a bit of legwork in post his post "Apples and Oranges" to compare the performance of a C# and F# solution to a Project Euler problem. Let's look at a sample F# unfolding sample of creating an infinite Fibonacci sequence and then we'll look at how to implement in C#.
let fibs = Seq.unfold (fun (i,j) -> Some(i,(j,i+j))) (1,1)
What we obviously need are the Option<T> and Tuple<TArg1, TArg2> type which Dustin has provided in the download link for the post. I modified mine slightly to follow F# naming conventions for the Tuple to have Item1, Item2 and so on. Now, let's look at the actual implementation of the Unfold function. This function will start with the start value and then calculate the next value from the generator, yield the first item and reset the next item. This will keep on evaluating until the option type returns None which is equivalent to null in the imperative world.
public static IEnumerable<TResult> Unfold<T, TResult>(Func<T, Option<Tuple<TResult, T>>> generator, T start)
{
var next = start;
while (true)
{
var res = generator(next);
if (res.IsNone)
yield break;
yield return res.Value.Item1;
next = res.Value.Item2;
}
}
Now we can define the actual implementation. Let's go ahead and create that implementation using the Unfold function. As you can see, we're pretty much mirroring the F# code snippet word for word. As you may notice, the C# is a bit more verbose because it requires us to physically declare tuples.
var fibs= Unfold(x => Option.Some(Tuple.New(x.Item1, Tuple.New(x.Item2, x.Item1 + x.Item2))), Tuple.New(1, 1));
var first20 = results.Take(20);
Of course I could have done this without the Unfold function and just had a property with an infinite sequence, but I like this solution because it's quite nice and generic. Something like this though could have sufficed:
public static IEnumerable<long> Fibonacci
{
get
{
long i = 1;
long j = 1;
while (true)
{
yield return i;
long temp = i;
i = j;
j = j + temp;
}
}
}
But, then that leaves off the implementing the following section in a nice generic fashion.
Initializing Lists
Now that we understand the unfolding function, we can apply it to any number of operations. How about if we want to initialize a delayed infinite or finite list? We can reuse the logic from the Unfold to make this happen. First, let's look at some F# samples of how we might want to do this:
let allCubes = Seq.init_infinite (fun x -> x * x)
let tenCubes = Seq.init_finite 10 (fun x -> x * x)
The first example, I created a list of all cubes possible, and the second, I created a list of just the first 10. You must create a function which passes in the current iteration, and then you can use it to calculate your return value. Ok, so, how would we do this in C#? Well, let's just first put up the infinite list because it's easier to implement.
public static IEnumerable<T> InitializeInfinite<T>(Func<int, T> f)
{
return Unfold<int, T>(s => Option.Some(Tuple.New(f(s), s + 1)), 0);
}
What I'm doing is return an option type with a tuple of the current value and the next value. Then I seed the function with the starting value of 0. My function that I create is passing in the current index, so that I can increment it. That's pretty easy, but how about limiting it to an exact number of items to take?
public static IEnumerable<T> InitializeFinite<T>(int count, Func<int, T> f)
{
return Unfold<int, T>(s =>
{
if(s < count)
return Option.Some(Tuple.New(f(s), s + 1));
else
return Option<Tuple<T, int>>.None;
}, 0);
}
Now, what I've done is made sure that my index is less than the count specified and then return the next value, or else I return none. With this in place, I can then create the exact duplicates from F# from above:
var allCubes = InitializeInfinite(x => x * x);
var tenCubes = InitializeFinite(10, x => x * x);
Generating Lists
So, in the previous example, we have a way to create a nice list through an initialize function. But what if we want to create a list from some sort of cursor? This cursor could be anything from a stream, to a reader, etc. In F#, we have the generate and generate_using functions which allow us to specify the opening cursor function, the actual computation and then a closing cursor function. Let's look at a quick sample:
let htmlList = Seq.generate (fun () ->
File.OpenText(@"D:\Tools\Reflector\ReadMe.htm")) (fun x ->
if x.EndOfStream then None else Some(x.ReadLine())) (fun x ->
x.Close())
Here I am generating a list of text from a text file, while specifying the opening, calculating of the list, and then the closing. But, since my reader that I'm using supports IDisposable, let's go ahead and use the generate_using, which was created for just that.
let htmlList = Seq.generate_using (fun () ->
File.OpenText(@"D:\Tools\Reflector\ReadMe.htm")) (fun x ->
if x.EndOfStream then None else Some(x.ReadLine()))
There! A bit better. But, how do we do this in C#? Well, let's go ahead and use the Option type that we took from above. From there, we can pretty much go line for line with the F# version. What we want to do is continue executing until we get a None return value and at that point, clean up and then exit.
public static IEnumerable<TResult> Generate<T, TResult>(Func<T> opener, Func<T, Option<TResult>> generator, Action<T> closer)
{
T openerResult = opener();
while (true)
{
var res = generator(openerResult);
if (res.IsNone)
{
closer(openerResult);
yield break;
}
yield return res.Value;
}
}
Now that we have that defined, we can create the GenerateUsing function in much the same way by calling Generate and passing in a function that disposes of the resource.
public static IEnumerable<TResult> GenerateUsing<T, TResult>(Func<T> opener, Func<T, Option<TResult>> generator) where T : IDisposable
{
return Generate(opener, generator, x => x.Dispose());
}
Now, I have the ability to read in files nicely into my lists just by doing this with both the regular generate and generate_using:
var generatedResults = Generate(() => File.OpenText(@"D:\Tools\Reflector\ReadMe.htm"), x =>
{
if (x.EndOfStream)
return Option<string>.None;
else
return Option.Some(x.ReadLine());
}, x => x.Dispose());
generatedResults.ForEach(Console.WriteLine);
var generatedUsingResults = GenerateUsing(() => File.OpenText(@"D:\Tools\Reflector\ReadMe.htm"), x =>
{
if (x.EndOfStream)
return Option<string>.None;
else
return Option.Some(x.ReadLine());
});
generatedUsingResults.ForEach(Console.WriteLine);
The GenerateUsing function is a bit cleaner if we can help it, so that we don't have to worry about a function that closes the resource and instead, we could make a better assumption about the type and close it ourselves generically.
Wrapping It Up
As you can see, you can implement plenty using C# and its current constructs, especially in regards to creating lists. Is it the better approach over F#? No, but it will get you most of the way there as I have shown here with the addition of some more types which include the Tuple<TArg1, TArg2> and the Option<T> type.
The more important thing for you to remember is the bare concepts that this post covered. There are plenty more to learn in terms of recursion (tail, mutual, etc), folding and so on. But, ultimately, I need to get back and focused on my concurrency in F# posts, unless there is a big demand for more of these functional C# samples.
-
ICFP Programming Contest
With great excitement, Portland State University and the University of Chicago has announced the 11th annual International Conference on Functional Programming (ICFP) Programming Contest to be held from July 11th to July 14th, 2008. If you're not familiar with the contest, it is one of the most advanced and prestigious programming contests. It is a good chance to show off your programming skills, your favorite languages and tools, and your ability to work as a team as you tackle these hard problems. What's great about this is that you can have a team consisting of one or more people, from any part of the world, and with any programming language you so choose. The contest will begin at noon (PDT) on July 11th and all entries must be received by the organizers by July 14th at noon (PDT).
To me, this is a much more interesting than the International Obfuscated C Contest because we're actually trying to solve a problem, let alone in any language we so choose.
Years Past
In years past, there have been some pretty interesting contests. Last year's contest was an interesting one to help find a DNA prefix to help an alien, who was dropped onto Earth from an interstellar garbage collector, survive with the new climate. And the year before that was to analyze an ancient codex and universal machine. The list of previous contests can be found at the contest site.
This time around, it'd be great to see a few teams submit with F#!
-
DC ALT.NET Meeting - 6/24/2008 - Applied Functional Programming with F#
The June meeting for DC ALT.NET has been set up for June 24th from 7-9PM. Check out our site and our mailing list as more information becomes available. Once again, I'd like to thank the Motley Fool for hosting the event as they did back in May. This month, I'll be covering Applied Functional Programming with F# as a continuation of the talks I've been giving lately. The beauty of this group like last month's topic of Lisp and this month's topic of F# is to step outside of the comfort zone, look to the outside for better approaches to doing things instead of the "What's new on MSDN" sessions.
The information is as follows:
Location:
Motley Fool
2000 Duke Street
Alexandria, VA, 22314
Map Link
Applied Functional Programming with F#
Recently, I've been doing quite a few talks on the introduction to functional programming and F#. In this session, I hope to cover the basics in short order once again, but also to show the applicability of where this language really hits the right areas. Are we going to immediately flock towards F# and abandon C# and other languages for all of your coding needs? No, but we have definite areas where F# and functional programming excels. Some of these include asynchronous programming, parallel programming, metaprogramming, language oriented programming, messaging systems and so on. The list could go on and on. We'll explore some of the functional programming basics and some of these scenarios as we try to wrap our heads around this emerging, yet not new paradigm.
Be there and hope to see a great crowd!
-
Functional C# Revisited - Into the Great Void
Lately, I've been doing some functional C# in both user groups and on this blog. As the C# language has evolved it has definitely taken some functional programming aspects, such as high order functions, extension methods, LINQ and so on. But with that, there is a cost. Functional programming with C# tends to be verbose due to a number of things which include the lack of type inference on methods, void as not a first class citizen and so on. I'm going to explore a couple of those today in this post.
Into the Great Void
I conversed with Jimmy Bogard last week regarding some limitations I saw in the C# language and how F# is better suited to handling this issue. One thing that has frustrated me is the fact that the System.Void structure is not treated as a first class citizen, in that I cannot do the following:
Func<int, int, Void> equals = (x, y) => Assert.Equal(x, y);
I get the following error if I even try to do this:
System.Void cannot be used from C# -- use typeof(void) to get the void type object
And why is that exactly? The ECMA Standard 335, Partition II, Section 9.4 "Instantiating generic types" states:
The following kinds of type cannot be used as arguments in instantiations (of generic types or methods):
- Byref types (e.g., System.Generic.Collection.List`1<string&> is invalid)
- Value types that contain fields that can point into the CIL evaluation stack (e.g.,List<System.RuntimeArgumentHandle>)
- void (e.g., List<System.Void> is invalid)
let should f actual = f actual
let not_throw_exception actual =
Assert.DoesNotThrow(Assert.ThrowsDelegate(actual))
which compiles down to:
public static U should<T, U>(FastFunc<T, U> f, T actual)
public static void not_throw_exception(FastFunc<Unit, Unit> actual)
What this allows me to do is pass in a function that will return nothing, and yet, if I passed in a FastFunc<int, int> that would work too with the should function. Both of them are treated the same, yet not in C#. Instead, we are forced to differentiate
Func versus Action?
As we're forced to differentiate our functions, it makes it hard to generalize functional programming in C#. I feel at this point, C# can't be a first class functional language because we need to make this distinction. If we don't return a value, we must use the Action<T> whereas if we do return a value, we must use Func<TArg, TResult>. Let's look at some samples where we have to differentiate.
Let's first look at the forward operator function in C#. This is one we looked at last time:
F# example
let (|>) x f = f x
[1..10] |> List.map(fun x -> x * x)
C# version
public static TResult ForwardFunc<TArg1, TResult>(this TArg1 arg1, Func<TArg1, TResult> func)
{
return func(arg1);
}
- And -
public static TResult ForwardFunc<TArg1, TArg2, TResult>(this TArg1 arg1, Func<TArg1, TArg2, TResult> func, TArg2 arg2)
{
return func(arg1, arg2);
}
This allows me to do the following code:
var mapResult = Enumerable.Range(1, 10).ForwardFunc(x => x.Map(i => i * i));
var mulResult = 3.ForwardFunc((x, y) => x * y, 3);
Whereas if my methods returned void, I'd also have to create functions to match that as well, such as:
public static void ForwardAction<TArg1>(this TArg1 arg1, Action<TArg1> func)
{
func(arg1);
}
- And -
public static void ForwardAction<TArg1, TArg2>(this TArg1 arg1, Action<TArg1, TArg2> func, TArg2 arg2)
{
func(arg1, arg2);
}
And then I can accomplish this code:
true.ForwardAction(x => x.ShouldBeTrue());
Enumerable.Range(1, 10).ForwardAction((x, y) => x.ShouldNotContain(y), 3);
These of course are simplistic examples, and it just shows that you have to think a little bit about whether you return something or not. Not something you have to necessarily think about in F# or other functional languages. Currying is also pretty difficult using the Action delegate as well. It's not really a usable thing at this point. Feel free to correct me, however...
How could you curry an Action given that you curry any normal function such as this?
public static Func<TArg1, Func<TArg2, TResult>> Curry<TArg1, TArg2, TResult>(this Func<TArg1, TArg2, TResult> f)
{
return a1 => a2 => f(a1, a2);
}
Maybe something like this?
public static Action<TArg2> Curry<TArg1, TArg2>(this Action<TArg1, TArg2> func, TArg1 arg1)
{
return a2 => func(arg1, a2);
}
But of course this function can't scale as you add more parameters to this. So, this isn't really an ideal situation. Unless I'm missing something blindingly obvious.
Wrapping It Up
With these given limitations of the void type, lack of type inference on method signatures, etc, it's hard to take C# seriously as a full citizen in the functional programming sense. I think it's a rather large weakness to me. Instead, I think we should focus on languages which already make these semantics easy, such as Haskell, F# and so on for when you need functional programming. Sure, C# can support a lot of functional programming paradigms, but it doesn't quite feel natural.
-
RubyNation - August 1st-2nd
One of the interesting things happening in the Ruby community is the budding of regional Ruby conferences. The Washington DC area is a pretty strong area for Ruby and Ruby on Rails as we have two Ruby user groups, Northern Virginia Ruby Users Group (NovaRUG) and the DC Ruby User Group (DCRUG). With that, it was due time that DC got its own conference called RubyNation which will be held August 1st-2nd, 2008 in Herndon, Virginia. What's great about this conference is that they are just trying to cover expenses and doing it for the love of the technology.
They have a fantastic lineup of speakers which include:
- Neal Ford - Keynote
The debate between static and dynamic languages is a red herring, that the debate should be about Essence vs. Ceremony. Neal's keynote will illustrate the origins of these concepts, what they mean to modern software development, and why everyone is suddenly interested in dynamic languages like Ruby.
- Stuart Halloway - Closing Keynote
- David Bock - Tools for your Ruby Toolbox
Rails may be the framework that turned many of us on to Ruby, but if you are using it for all of your server-related Ruby projects, you probably have a hammer and are seeing every problem as a nail. There are a number of smaller, tighter solutions to problem in this space, including GServer (built into the Ruby libraries), StaticMatic (a tool for generating a static site, but with all the templating goodness), and Sinatra, a small server with an awesome DSL for restful web services. We will spend a little bit of time of each of these, seeing how you can use each for a project where you might have previously considered Rails.
- Giles Bowkett - Archaeopteryx: A Ruby MIDI Generator
Archaeopteryx generates MIDI via Ruby to drive prosumer studio music software. It can generate hyperkinetic DJ mixes, infinite streams of ambient music for meditation, and original drum and bass rhythms.
- Yehuda Katz - Living on the Edge
Yehuda will walk you through some of the most exciting advances on the frontiers of Ruby, and provide a tour guide to those who want to walk the dangerous path. By the time the talk is over, you should feel comfortable downloading a bleeding-edge git-repository and installing it.
- Glenn Vanderburg - The Culture of Innovation in Ruby
The Ruby community is a wellspring of innovation at the moment; many people are doing fascinating new things with tools, libraries, and exploring new ways to use the language. This talk will explore some of the reasons for that innovative culture, and discuss ways we can benefit from it and keep it healthy.
The event will be held at the Center for Innovative Technology (CIT) in Herndon, VA. If you're familiar with the area, you'll notice it is the upside down oddly shaped building. As you travel along Rt 28 or the Dulles Toll Road, you can't miss this building.
The address for the conference is:
CIT Complex
2214 Rock Hill Road
Herndon, Virginia 20170
Register today here! Looking forward to this event.
- Neal Ford - Keynote
-
Language Oriented Programming and Functional Unit Testing in F#
As I've covered earlier, I'm very interested in the unit testing and behavior testing story in F# and functional programming. And as I've indicated earlier, I'm pretty fascinated by Domain Specific Languages (DSLs) as well in this regard. In the past, I've posted about some of the interesting things that are coming from the DSL community, especially from the .NET community itself. I wanted to challenge myself to prove that F# can also produce very readable and powerful DSLs as well. I think with the language flexibility that F# offers, I should be able to get quite expressive
Starting with DSLs
In part of what has me fascinated by DSLs lately is the recent book activity from both Martin Fowler and Ayende. Martin has been posting his Domain Specific Languages Work In Progress and keeping us somewhat up to date on its progress. So far I've been rather impressed with the book and I hope it continues. Although I think fluent builders are nice, I don't think they sometimes have the expressiveness of DSLs that I'm looking for. Many of the samples are written in both Java and C#, and it gives you a pretty good idea where he's going. However, I don't find the intent to be as clear though as DSLs written in Ruby, Boo or F#.
Ayende on the other hand has been working on his books "DSLs in Boo" that is partially available online right now. It's been interesting to see how flexible the language is in regards to DSLs and seeing it twist in new ways is pretty interesting. The first chaper is available for free, so you can check it out for yourself.
But with this, I was seeing such opportunities when I've been experimenting with language oriented programmiing and F#. Where are there opportunities?
Language Oriented Programming and FsUnit
I recently came across a dormant project on Google Code called FsUnit, which was a syntactic extension to NUnit using the F# language semantics. This to me looked like a great example of language oriented programming with F# and some of its uses. There isn't much to this library, yet very powerful. Let's take a look at a few samples:
1 |> should (equal 1)
"two" |> should (notEqual "three")
[| 1 .. 10 |] |> should (contain 5)
What makes this possible and pretty easy to understand? That would be the use of the forward operator. I've covered this operator in the past, but I can't emphasize its importance in this regard. If you're not familiar with that post, let's go over the basics. The basic definition of this operator is that it's just function application in reverse.
The forward operator has a basic definition that looks like this:
let (|>) x f = f x
What this allows us to do is put the first argument last. Let's take a quick example of just a simple forward operator:
let newList = [1..10] |> List.map(fun x -> x + x)
What it essentially becomes is the following code:
let newList = List.map(fun x -> x + x ) [1..10]
This gives us a couple of advantages doing this which includes:
- Intent Clarity - Allows you to perform data transformations, iterations, filtering, etc in a forward chaining fashion
- Type Inference - Since we're chaining together methods, we can better type infer when we specify the data first to the functions that will flow across all of them.
Just as an aside, Chris Smith, of the F# team, follows up from his recent presentation on Language Oriented Programming with F#. It's well worth the time invested to look at the possibilities that F# as a language offers. I am also hoping to do some presentations on this in the future as there is a lot of ground to cover with this language.
Replicating with C#?
During some of my recent talks on functional programming and F#, I have come across some resistance to the language itself because many saw that they can replicate a lot of the behaviors in C# 3.0. Indeed that is the case with many things, but not so much with where I'm going. One of my many gripes with C# and in turn the BCL is the fact that they don't treat Void (or Unit to those F#'ers) as a first class citizen. Therefore, I'm stuck with either using a Func<TArg, TResult> delegate or the Action<T> delegate for many operations and never the two shall combine. Whereas in F#, I'm free to create FastFunc<TArg, TResult> delegates with a Unit return type which returns nothing. It's a thing of beauty and I didn't have to mangle my code to get there.
So, with that in mind, let's see if we can replicate the forward operator in C# to the extent that I did in F#. The concept isn't really hard at all when you think about it. We're just calling a function with the arguments reversed. Let's create one with an actual return type, because remember, we're forced into the paradigm of either returning something or not with C# and we must use different delegates for it.
public static TResult ForwardFunc<TArg1, TArg2, TResult>(this TArg1 arg1, Func<TArg1, TArg2, TResult> func, TArg2 arg2)
{
return func(arg1, arg2);
}
var result = 4.ForwardFunc((x, y) => x * y, 3);
What I've been able to do is not as clean as F#, but a little interesting. What I'm doing is taking the first argument, then a function to process it, and then finally pass in my second argument. Below that function is a quick and dirty example of how to use it. But what about those times I don't want to return a value? Well, we have an answer for that as well:
public static void ForwardAction<TArg1, TArg2>(this TArg1 arg1, Action<TArg1, TArg2> func, TArg2 arg2)
{
func(arg1, arg2);
}
Enumerable.Range(1, 10).ForwardAction((x, y) => x.ShouldContain(y), 3);
What I did is change the Func<TArg1, TArg2, TResult> to a simple Action<TArg1, TArg2> which has the same effect. From there, I was able to use the xUnit.net 3.5 extensions to show that the IEnumerable<T> contained the number 3. If you mix in currying to this equation things get interesting quickly. I hope those who attended my functional C# class got some inkling, but since then I've been exploring more aspects of it as well as lessons learned. But the overall story is that it's just not as expressive as F# and kind of clumsy.
Extending the Syntax
As you may see, there really isn't much to FsUnit. Instead, I would like to apply some of those lessons to xUnit.net instead because of allowing static tests and it better fits my needs at the moment. Instead of relying on the underlying unit testing framework to take care of a lot of the details, instead, I'm going to use functional programming aspects of currying to make my DSL look more readable.
The first piece of the puzzle that we need is the basis of getting started. Let's put down the should and a few housekeeping items:
#light
namespace FsXUnit
#R @"D:\Tools\xunit-1.0.1\xunit.dll"
module Extensions =
open Xunit
let should f actual =
f actual
What I have created is a module under the FsXUnit namespace called Extensions which will hold my methods. Then I can reference using a standard open statement such as open FsXUnit.Extensions. Then the should will be a partially applied function that will tie the functions together. Now we can start throwing our first functions at it. I'll mark each by section giving you a quick sample of each.
Equality
let equal expected actual =
Assert.Equal(expected, actual)
let not_equal expected actual =
Assert.NotEqual(expected, actual)
[<Fact>]
let equal_with_equal_values_should_be_equal() =
"foo" |> should equal "foo"
[<Fact>]
let not_equal_with_inequal_values_should_not_be_equal() =
"foo" |> should not_equal "bar"
Contains
let have expected actual =
Assert.Contains(expected, (actual :> seq<_>))
[<Fact>]
let sequence_should_have_2() =
[1..10] |> should have 2
Exception Handling
let throw_exception<'a when 'a :> exn> actual =
Assert.Throws<'a>(Assert.ThrowsDelegate(actual))
let throws_exception() : unit =
raise(System.ArgumentException "Bad things")
[<Fact>]
let function_should_throw_exception () =
throws_exception |> should (throw_exception<System.ArgumentException>)
This by no means is a complete list of things that you can do with this, but you get the idea.
Where To Go?
As I stated before, I think Scala Specs is an interesting framework for Behavior Driven Development (BDD), and with some of these techniques discussed, it could be rather possible to make a rather expressive framework. It's all about the time for tinkering at this point I suppose. But with all this tinkering I've been doing, I have to wonder to myself, whether we need another testing DSL, or should we more focus on a general purpose language that is best suited for testing, call it Test#, or Fact#, just to humor Brad Wilson... Is that where we should be headed?
-
The Unit Testing Story in F# Revisited
Last week I posted about some troubles I was having with the unit testing frameworks for F#. Today, Brad Wilson announced the release of xUnit.net 1.0.1 which addressed the change in the F# compiler as well as integration with ASP.NET MVC Preview 3 which was just released. As always you can find the latest bits on CodePlex. There was a change in the way F# was compiling the modules as static classes which was not expected in previous versions.
Running the Tests Again
Now, I'm able to run my functions just as before and the runner will now recognize them. Below is just a simple example of some unit tests to determine whether numbers are prime or not. I'm extending the System.Int32 to add a property to the instance to determine whether it is prime. Just to prove a point on how flexible F# really is, I'm also able to extend the Int32 class using static methods, something that you cannot do with C# and extension methods. More and more, I love the language itself and finding myself trapped sometimes by the limits of C#. But, that's sidetracking, so let's get to the unit tests.
#light
#R @"D:\Tools\xunit-1.0.1\xunit.dll"
open Xunit
let isPrimeNumber(i) =
let limit = int(sqrt(float(i)))
let rec check j =
j > limit or (i % j <> 0 && check(j + 1))
check 2
type System.Int32 with
member i.IsPrime
with get () = isPrimeNumber(i)
static member IsPrimeNumber(x) =
isPrimeNumber(x)
[<Fact>]
let IsPrime_WithPrimeNumber_ShouldReturnTrue() =
Assert.True((7).IsPrime)
[<Fact>]
let IsPrime_WithNonPrimeNumber_ShouldReturnFalse() =
Assert.False((21).IsPrime)
Assert.False(System.Int32.IsPrimeNumber(45))
And then when I run it through the GUI runner, I sure enough get two passing tests. It was asked of me last week at the Philly ALT.NET meeting about TDD with F# and I see no problem with this at all, and in fact I actively encourage it. But, you have to think about this in a different light when talking about objects and behaviors, and then turning around to functions and behaviors.
Getting Going with Gallio
As I mentioned last time, Jeff Brown has been hard at work to support the F# community as well. I was able to get the right build going of Gallio finally after there may have been some mixups with getting the latest code. Anyhow, I am now able to get these same tests to work, but using MbUnit version 3 and through the Gallio Icarus Runner. If you're not familiar with Gallio, it is an open platform of tools and runners that is extensible to all testing frameworks. Jeff Brown talked about it on Hanselminutes with Brad Wilson of xUnit.net fame, Roy Osherove and Charlie Poole of NUnit on the Past, Present and Future of Unit Testing Frameworks.
So, let's just modify the above code to migrate to Gallio with MbUnit version 3 and see how we do:
#light
#R @"D:\Program Files\Gallio\bin\Gallio.dll"
#R @"D:\Program Files\Gallio\bin\MbUnit.dll"
open MbUnit.Framework
let isPrimeNumber(i) =
let limit = int(sqrt(float(i)))
let rec check j =
j > limit or (i % j <> 0 && check(j + 1))
check 2
type System.Int32 with
member i.IsPrime
with get () = isPrimeNumber(i)
static member IsPrimeNumber(x) =
isPrimeNumber(x)
[<Test>]
let IsPrime_WithPrimeNumber_ShouldReturnTrue() =
Assert.IsTrue((7).IsPrime)
[<Test>]
let IsPrime_WithNonPrimeNumber_ShouldReturn_False() =
Assert.IsFalse((21).IsPrime)
Assert.IsFalse(System.Int32.IsPrimeNumber(45))
And we can notice through the Gallio runner that it's only detecting the MbUnit tests right now, unfortunately. Hopefully that issue will be resolved soon.
BDD Specs in F#?
F# is a pretty flexible language for unit testing and even BDD style. I wonder if we could take some lessons from the spec BDD framework for Scala and apply to F#. Just a thought...
If you're not familiar with specs, it's a BDD framework with some interesting syntax that I'm still coming to terms with. But the concept looks interesting. Take a look at a quick example and see if it speaks to you.
package podwysocki.specs
object scalaSpecExample extends Specification {
"A hello world spec" should {
"return something" in {
"hello" mustBe "hello"
}
}
}
As I've played around with Scala, this is a pretty interesting concept. I'm much more a fan of F# as a language, but still there are some interesting pieces to Scala. I'm also interested in using MSpec from Aaron Jensen at some point, but have a bit on my plate and other points of focus right now.
Wrapping It Up
In the mean time, we have another testing framework to consider. Me, personally, I prefer xUnit.net because of the functional aspects of Assert.Throws and so on. But, that option is up to you quite frankly. There is a good story to be told here with regards to unit testing and F# that is not to be overlooked.
-
Static versus Dynamic Languages - Attack of the Clones
Very recently there has been an ongoing debate between static and dynamically typed languages. Since it seems that there has been some Star Wars references, I thought I'd add my own. I originally wanted to cover this as part of the future of C#, but I think it deserves its own topic. There have been many voices in the matter and I've read all sides and thought I'd weigh in on the matter. I find myself with my feet right now in the statically typed community right now. I do appreciate dynamic typing and it definitely has its use, but to me the static verification is a key aspect. But, of course I do appreciate dynamic languages, especially those of the past including Lisp, Erlang, etc.
Here are some of the salvos that have been fired so far:
- Dynamic Languages Strike Back - Steve Yegge
- Return of Statically Typed Languages - Cedric Beust
- Guide You the Force Should - Ted Neward
- Revenge of the Statically Typed Languages - Greg Young
- A New Hope - Polyglotism - Ola Bini
The Salvos Fired
First, Steve Yegge posted a transcript from his talk at Stanford called "Dynamic Languages Strike Back". In this talk, he talks about the history of dynamic languages, the performance, what can be done, and the politics of it all. But at the end of the day, it comes down to the tools used. It was a pretty interesting talk, but of course dredge up some pretty strong feelings. In turn, you had responses from Cedric Beust coming out in favor of statically typed languages, and Ted Neward, Ola Bini and Greg Young analyzing the results of the two of them. I won't get into the me too aspect of it all, but I encourage you to read the posts, but also the responses as well.
I think Cedric lost me on the argument though is when he brought Scala into the argument. To me, it was kind of nonsensical to mention it in this case. And to mention that pattern matching is a leaky abstraction is unfortunate and I think very wrong. The thing that functional languages give us is the ability to express what we want, and not necessarily how to get it. Whether it puts it in a switch statement, an if statement, or anything else doesn't matter, as long as the decision tree was followed. I don't see any leakiness here. So, that was a bad aside on there. I'm not a huge fan of Scala either, but for entirely different reasons. First off, the type inference isn't really as strong as it should be and the syntax to me just doesn't seem to be as functional as I'd like. F# and Scala tackle the problems in vastly different ways.
Ola Bini, who has been advocating the polyglot programmer for some time, summed up the Steve versus Cedric posts very concisely in these two paragraphs:
So let's see. Distilled, Steve thinks that static languages have reached the ceiling for what's possible to do, and that dynamic languages offer more flexibility and power without actually sacrificing performance and maintainability. He backs this up with several research papers that point to very interesting runtime performance improvement techniques that really can help dynamic languages perform exceptionally well.
On the other hand Cedric believes that Scala is bad because of implicits and pattern matching, that it's common sense to not allow people to use the languages they like, that tools for dynamic languages will never be as good as the ones for static ones, that Java generics isn't really a problem, that dynamic language performance will improve but that this doesn't matter, that static languages really hasn't failed at all and that Java is still the best language of choice, and will continue to be for a long time.
It seems that many of the modern dynamic languages are pretty flexible, but also not as performance oriented as the ones in the past. Why is this? It's a good question to ask. And what can be done about it? Of course Ola takes the tact, and I think correctly so that the tooling won't be the same or as rich for dynamic languages as it is for statically typed. It simply can't be. But that doesn't mean that it needs those tools won't exist, they'll just be different. But at the end, Ola argues for the polyglot programmer and each language to its strength. He talks a bit more about this with Mike Moore on the Rubiverse podcast here.
Impedance Mismatch?
There was a topic discussed at the ALT.NET Open Spaces, Seattle fishbowl on the polyglot programmer which talked about the impedance mismatch between statically typed languages and dynamic ones. What's great is that Greg Young got together a session with Rustan Leino and Mike Barnett from Microsoft Research on the Spec# team, John Lam from the IronRuby team, and me. It was a great discussion which revolved around the flexibility that dynamic languages give you versus the static verification that you lack when you do that. And there is a balance to be had. When you look at that flexibility that Ruby and other dynamic languages give you, also creates a bit more responsibility for ensuring its correctness. It's a great conversation and well worth the time invested. But one of the benefits we're seeing from CLR and in turn the DLR is the interop story so that you could have your front end be Ruby, service layer in C#, rules engine in F#, Boo for configuration and so on.
Anders Hejlsberg on C# And Statically Typed Languages
As I noted earlier, Anders Hejlsberg was on Software Engineering Radio Episode 97 to discuss the future of C#. Although Anders has his foot firmly in the statically typed camp, he sees the value of dynamic dispatch. The phrase that was used and quite apt was "Static Programming but Dynamically Generated". I think the metaprogramming story in C# needs to be improved for this to happen. Doing Reflection.Emit isn't the strongest story for doing this, and certainly not easy.
Where I think that C# can go however is more towards making DSL creation much easier. Boo, F# and others on the .NET platform are statically typed, yet go well beyond what C# can do in this arena. Ayende has been doing a lot with Boo and making the language, although statically typed, very flexible and readable. Ruby has a pretty strong story here and C# and other languages have some lessons it can learn.
Another example is that Erlang is a dynamic language, yet very concurrent and pretty interesting. C# and other .NET languages can learn a bit from Erlang. I'm not sure Erlang itself will be taking off, as it would need some sort of sponsorship and some better frameworks before it could. F# has learned some of those lessons in terms of messaging patterns, but no in terms of recovery and process isolation just yet. I covered a bit of that on my previous post.
Wrapping It Up
It's a pretty interesting debate, and at the end of the day, it really comes down to what language meets your needs. The .NET CLR has a pretty strong story of allowing other languages to interoperate that nicely compliments the polyglot. But, I don't think that static typing is going the way of the dodo and I also don't think dynamic typing will win the day. Both have their places. Sounds like a copout, I know, but deal with it. I have a bit more to discuss on this matter, especially about learning lessons from Erlang, one of the more interesting languages that has seen a resurgence lately.
-
DC ALT.NET May Wrapup - Common Lisp and Applying Lessons Learned
Last night's DC ALT.NET meeting was a great success. We had Craig Andera, of PluralSight and FlexWiki fame, talk to us about Common Lisp and some of the lessons he learned. It was great to see the guys from the FringeDC group join us as well. I can definitely see a lot of overlap between the two groups as we both struggle to find new and innovative ideas for solving our hardest problems. We tend to look outside of our community to find what has worked and what hasn't worked for each community. Because at the end of the day, we're all developers with just different backgrounds. I want to thank the Motley Fool for hosting the event for us, and we'd love to come back if you'll have us.
The Presentation
Craig spent much of his summer vacation actually learning Common Lisp. The original idea was to learn Ruby, but why not go back to the grandfather of them all, Lisp. I remembered Lisp from back in the college years, but had forgotten most of it. It's very interesting to watch the presentation and learn how flexible of a language it is since we're just dealing with expression trees. I can definitely see where other languages got their heritage. All good things tend to come back to Lisp and SmallTalk!
Anyhow, the important features we covered were object oriented programming with Common Lisp Object System (CLOS), macros, defining properties and methods, and even the .NET interop story with IronScheme and others. It was a great time and I learned a lot. If you wish to grab his presentation notes, you can find them here.
Next time, I'll be presenting F#, so we'll keep on the functional programming style with some OOP mixed in, so I hope we see another great crowd for that. As always, join the mailing list here if you want to learn more.
-
What Is the Future of C# Anyways?
It was often asked during some of my presentations on F# and Functional C# about the future direction of C# and where I think it's going. Last night I was pinged about this with my F# talk at the Philly ALT.NET meeting. The question was asked, why bother learning F#, when eventually I'll get these things for free once they steal it and bring it to C#. Being the language geek that I am, I'm pretty interested in this question as well. Right now, the language itself keeps evolving at a rather quick pace as compared to C++ and Java. And we have many developers that are struggling to keep up with the evolution of the language to a more functional style with LINQ, lambda expressions, lazy evaluation, etc. There are plenty of places to go with the language and a few questions to ask along the way.
An Interview With Anders Hejlsberg
Recently on Software Engineering Radio, Anders Hejlsberg was interviewed about the past, present and future of C# on Episode 97. Of course there are interesting aspects of the history of his involvement with languages such as Tubro Pascal and Delphi and some great commentary on Visual Basic and dynamic languages as well. But, the real core of the discussion was focused around what problems are the ones we need to solve next? And how will C# handle some of these features? Will they be language constructs or built-in to the framework itself?
Let's go through some of the issues discussed.
Concurrency Programming
Concurrency programming is hard. Let's not mince words about it. Once we start getting into multiple processors and multiple cores, this becomes even more of an issue. Are we using the machine effectively? It's important because with the standard locks/mutexes it's literally impossible to have shared memory parallelism with more than two processors without at some point being blocking and serial.
The way things are currently designed in the frameworks and the languages themselves are not designed for concurrency to make it easy. The Erlang guys of course would disagree since they started with that idea from the very start. Since things are sandboxed to a particular thread, they are free to mutate state to their heart's content, and then when they need to talk to another process, they pick up the data and completely copy it over, so there is a penalty for doing so. Joe Armstrong, the creator of Erlang, covered a lot of these things in his Erlang book "Programming Erlang: Software for a Concurrent World ".
Mutable State
Part of the issue concerning concurrency is the idea of mutable state. As far back as I remember, we were always taught in CS classes that you can feel free to mutate state as need be. But, that only really works when you've got a nicely serial application where A calls B calls C calls D and all on the same thread. But, that's a fairly limiting thing idea as we start to scale out to multiple threads, machines and so on. Instead, we need to focus on the mutability and control it in a meaningful way through not only the use of our language constructs, but our design patterns as well.
In the C# world, we have the ability to create opt-in immutability through the use of the readonly keyword. This is really helpful to decide those fields that we don't really need to or want to modify. This also helps the JIT better determine the use of our particular variable. I'm not sure about performance gains, but that's not really the point of it all, anyways. Take the canonical example of the 2D point such as this:
public class Point2D
{
private readonly double x;
private readonly double y;
public Point2D() { }
public Point2D(double x, double y)
{
this.x = x;
this.y = y;
}
public double X { get { return x; } }
public double Y { get { return y; } }
public Point2D Add(Size2D size)
{
return new Point2D(x + size.Height, y + size.Width);
}
}
We've created this class as to not allow for mutable state, instead returning a new object that you are free to work with. This of course is a positive thing. But, can we go further in a language than just this? I think so, and I think Anders does too. Spec# and design by contract can take this just a bit further in this regard. What if I can state that my object, as it is, is immutable? That would certainly help the compiler to optimize. Take for example doing Value Objects in the Domain Driven Design world. How would something like that look? Well, let's follow the Spec# example and mark my class as being immutable, meaning that once I initialize it, I cannot change it for any reason:
[Immutable]
public class Point2D
{
// Class implementation the same
}
This helps make it more transparent to the caller and the callee that what you have cannot be changed. This enforces the behaviors for my member variables in a pretty interesting way. Let's take a look at the actual C# generated in Spec# for the above code. I'll only paste the relevant information about what it did to the properties. I'll only look at the X, but the identical happened for the Y as well.
public double X
{
[Witness(false, 0, "", "0", ""), Witness(false, 0, "", "1", ""), Witness(false, 0, "", "this@ClassLibrary1.Point2D::x", "", Filename=@"D:\Work\SpecSharpSamples\SpecSharpSamples\Class1.ssc", StartLine=20, StartColumn=0x21, EndLine=20, EndColumn=0x22, SourceText="x"), Ensures("::==(double,double){${double,\"return value\"},this@ClassLibrary1.Point2D::x}", Filename=@"D:\Work\SpecSharpSamples\SpecSharpSamples\Class1.ssc", StartLine=20, StartColumn=20, EndLine=20, EndColumn=0x17, SourceText="get")]
get
{
double return value = this.x;
try
{
if (return value != this.x)
{
throw new EnsuresException("Postcondition 'get' violated from method 'ClassLibrary1.Point2D.get_X'");
}
}
catch (ContractMarkerException)
{
throw;
}
double SS$Display Return Local = return value;
return return value;
}
}
What I like about F# and functional programming is the opt-out mutability, which means by default, my classes, lists, structures and so on are immutable by default. So, this makes you think long and hard about any particular mutability you want to introduce into your program. It's not to say that there can be no mutability in your application, but on the other hand, you need to think about it, and isolate it in a meaningful manner. Haskell takes a more hardline stance on the issue, and mutability can only occur in monadic expressions. If you're not aware of what those are, check out F# workflows which are perfectly analogous. But by default, we get code that looks like this and is immutable:
type Point2D = class
val x : double
val y : double
new() = { x = 0.0; y = 0.0 }
new(x, y) =
{
x = x
y = y
}
member this.X
with get() = this.x
member this.Y
with get() = this.y
end
So, as you can see, I'm not having to express the immutability, only the mutability if I so choose. Very important differentiator.
Method Purity
Method purity is another important topic as we talk about concurrent programming and such. What I mean by this is that I'm not going to modify the incoming parameters or cause some side effects, and instead I will produce a new object instead. This has lasting effects if I'm going to be doing things on other threads. Eric Evans talked about this topic briefly in his Domain Driven Design book on Supple Design. The idea is to have side effect free functions as much as you can, and carefully control where you mutate state through intention revealing interfaces and so on.
But, how do you communicate this? Well, Command-Query Separation gets us part of the way there. That's the idea of having the mutation and side effects in your command functions where you return nothing, and then queries which return data but do not modify state. Spec# can enforce this behavior as well. To be able to mark our particular functions as being pure is quite helpful in communicating whether I can expect a change in state. Therefore I know whether I have to manage the mutation in some special way. To communicate something like that in Spec#, all I have to do is something like this:
[Pure]
public Point2D Add(Size2D size)
requires size != null;
{
return new Point2D(x + size.Height, y + size.Width);
}
This becomes part of the method contract and some good documentation as well for your system.
Asynchronous Communication and Messaging
Another piece of interest is messaging and process isolation. The Erlang guys figured out a while ago, that you can have mutation as well as mass concurrency, fail safety and so on with process isolation. Two ideas come to mind from other .NET languages. An important distinction must be made between concurrency memory models between shared-memory and message passing concurrency. Messaging and asynchronous communication are key foundations for concurrent programming.
In F#, there is support for the mailbox processing messaging. This is already popular in Erlang, hence probably where the idea came from. The idea is that a mailbox is a message queue that you can listen to for a message that is relevant to the agent you've defined. This is implemented in the MailboxProcessor class in the Microsoft.FSharp.Control.Mailboxes namespace. Doing a simple receive is pretty simple as shown here:
#light
#nowarn "57"
open Microsoft.FSharp.Control.CommonExtensions
open Microsoft.FSharp.Control.Mailboxes
let incrementor =
new MailboxProcessor<int>(fun inbox ->
let rec loopMessage(n) =
async {
do printfn "n = %d" n
let! message = inbox.Receive()
return! loopMessage(n + message)
}
loopMessage(0))
Robert Pickering has more information about the Erlang style message passing here.
Now, let's come back just a second. Erlang also introduces another concept that Sing# and the Singularity OS took up. It's a concept called the Software Isolated Process (SIP). The idea is to isolate your processes in a little sandbox. Therefore if you load up a bad driver or something like that, the process can die and then spin up another process without having killed the entire system. That's a really key part of Singularity and quite frankly one of the most intriguing. Galen Hunt, the main researcher behind this talked about this on Software Engineering Radio Episode 88. He also talks about it more here on Channel9 and it's well worth looking at. You can also download the source on CodePlex and check it out.
Dynamic C#?
As you can probably note, Anders is pretty much a static typing fan and I'd have to say that I'm also firmly in that camp as well. But, there are elements that are intriguing such as metaprogramming and creating DSLs which are pretty weak in C# as of now. Sure, people are trying to bend C# in all sorts of interesting ways, but it's not a natural fit as the language stands now. So, I think there can be some improvements here in some areas.
Metaprogramming
Metaprogramming is another area that was mentioned as a particularly interesting aspect. As of right now, it's not an easy fit to do this with C#. But once again, F# has many of these features built-in to do such things as quotations to do some metaprogramming because that's what it was created to do, a language built to create other languages. Tomas Petricek is by far one of the authorities on the subject as he has leveraged it in interesting ways to create AJAX applications. You can read about his introduction to metaprogramming here and his AJAX toolkit here. Don Syme has also written a paper about leveraging Meta-programming with F# which you can find here. But I guess I have to ask the question, does C# need this or shouldn't we just use F# for what it's really good at and not shoehorn yet another piece onto the language? Or the same could be said of Ruby and its power with metaprogramming as well, why not use the best language for the job?
Dynamic Dispatch
The idea of dynamic dispatch is an interesting idea as well. This is the idea that you can invoke a method on an object that doesn't exist, and instead, the system figures out where to send it. In Ruby, we have the method_missing concept which allows us to define that behavior when that method that is being invoked is not found. Anders thought it was an intriguing idea and it was something to look at. This might help in the creation of DSLs as well when you can define that behavior even though that method may not exist at all.
In the Language or the Framework?
Another good question though is do these features belong in the language itself or the in the framework? The argument here is that if you somehow put a lot of constraints on the language syntax, then you might prematurely age the language and as a result, decline in usage. Instead, the idea is to focus on the libraries to make these things available. For example, the MailboxProcessor functionality being brought to all languages might not be a bad idea. Those sorts of concepts around process isolation would be more of a framework concept than a language concept. But, it's an interesting debate as to what belongs where. Because at the end of the day, you do need some language differentiation when you use C#, F#, Ruby, Python, C++, etc or else what's the point of having all of them? To that point I've been dismayed that VB.NET and C# have mirrored themselves pretty well and tried to make themselves equal and I wish they would just stop. Let VB find a niche and let C# find its niche.
Conclusion
Well, I hope this little discussion got you thinking as well about the future of C# and the future of the .NET framework as well. What does C# need in order to better express the problems we are trying to solve? And is it language specific or does it belong in the framework? Shouldn't we just use the best language for the job instead of everything by default being in C#? Good questions to answer, so now discuss...
-
F# and Unit Testing - Some New Developments
This past week, I've been focusing a lot of my attention on F# in terms of my presentations that I have been giving. I'm busy preparing for the Philly ALT.NET meeting tomorrow night on the very subject. An important aspect of some of the presentation has been unit testing. There is some good news and some not so good news when it comes to this. For those that have been following my pursuit of good unit tests in F# have known that xUnit.net has been a good option for being able to create static unit tests inside my classes instead of the pomp and circumstance of creating a new class and having member functions.
MbUnit Support for F#
Very recently Jeff Brown announced on his blog that he's now supporting tests without the requirement for the TestFixtureAttribute to be marked on your class in MbUnit. This is quite helpful for F# tests and has joined the ranks of xUnit.net in terms of giving me another tool in my toolbelt. There were other bugs that were filed that also were hindering good unit testing in F# that have been worked out as well.
So, I should be able to do this below and everything should just work:
#light
#R @"D:\Program Files\Gallio\bin\MbUnit2\MbUnit.Framework.dll"
open MbUnit.Framework
let FilterCall protocol port =
match(protocol, port) with
| "tcp", _ when port = 21 || port = 23 || port = 25 -> true
| "http", _ when port = 80 || port = 8080 -> true
| "https", 443 -> true
| _ -> false
[<Test>]
let FilterCall_WithHttpAndPort80_ShouldReturnTrue() =
Assert.IsTrue(FilterCall "http" 80)
But... this, is not the case. It doesn't recognize that my tests exist. Why?
The New F# Release
With the newest release of F#, version 1.9.4.15, there was a change made that took the classes that encapsulated the tests and made it a static class. So, if I were to look through .NET Reflector, it would look like this:
[CompilationMapping(SourceLevelConstruct.Module)]
public static class MbUnitTesting
{
// Methods
public static bool FilterCall(string protocol, int port) /// Method under test
[Test]
public static void FilterCall_WithHttpAndPort80_ShouldReturnTrue()
{
Assert.IsTrue(FilterCall("http", 80));
}
}
This can be a problem, due to the fact that through reflection, any static class is marked abstract due to the fact you cannot create an instance of these classes. This is a problem for the unit testing frameworks which cannot process abstract classes, yet. So, this is a work in progress, but there has to be some strategy to get around this, as we have no way in reflection to determine if it is a static class easily.
The Workaround
The workaround for the issue is pretty simple, which is to actually use classes when creating your unit tests in F#. I know it's a little bit of a pain, but the unit testing teams are aware of the issue and hopefully we'll have a fix soon enough. But, in the mean time, we'll have to create the classes such as this in MbUnit:
[<TestFixture>]
type MbUnitTests = class
new() = {}
[<Test>]
member x.FilterCall_WithHttpAndPort80_ShouldReturnTrue() =
Assert.IsTrue(FilterCall "http" 80)
end
or in xUnit.net
type XUnitTests = class
new() = {}
[<Fact>]
member x.FilterCall_WithHttpAndPort80_ShouldReturnTrue() =
Assert.True(FilterCall "http" 80)
end
Then the Gallio Icarus Runner is free to pick up the results and runs as expected. Like I said, hopefully the issue will be fixed soon.
-
NoVA Code Camp Wrapup and Thoughts
This past weekend was the Northern Virginia Code Camp in Reston, Virginia. There was a pretty good turnout for my two sessions which were the first two of the day. Unfortunately, I could not stay the whole day to attend some of the other sessions including fellow DC ALT.NET'er John Morales on NServiceBus, so I'll have to catch it soon enough because the ideas around it are pretty intriguing and I've played with TIBCO and a few others, so another tool in my toolbelt is not a bad thing. I did two sessions, one of Functional C# and the other was an introduction to F#. I'm not quite ready to post my slides as I have a few more presentations on the subject to give and I'm still tweaking them as I go, so they will be a bit more refined.
Lessons Learned For Me
Some of the things I came away with is that I need to schedule a little better. I would have much preferred to have the F# and Foundations of Functional Programming talk come first as it would give people more of a basis of what functional programming is and how it is expressed in a more pure functional language in F#. Next time I should be a bit more upfront about this and get the schedule changed accordingly. Two sessions in a row is a situation which could be improved as well.
Functional C#
The first talk I gave was on Functional C#. This was to take the ideas of the more pure functional programming of Haskell, OCaml and F#. To bring these ideas and apply them in a C# ish manner. Some of the things in functional programming languages such as pattern matching isn't an easy concept, so, there are things that can apply and some things that don't.
Some of these lessons include:
- Immutable types
Focus on immutable types and opt-out mutability instead of mutable by default and opt-in immutability such is the case in C# versus F#. Remember, I've been talking about this in context of multi-threaded, parallel programming where this is absolutely crucial to mutate in very controlled circumstances, putting them in isolation. This also applies to the Domain Driven Design world where I was coming from in regards to Value Objects and supple design.
- Side Effect Free (Pure) Functions
The idea here is to control the side effecting in your system. Ideally in the functional programming world, when you call such a function as myList |> List.map (fun x -> x * x) will return another list and not the list you gave it with mutated state. This is important once again as we get into the concurrent programming paradigm to focus on method purity and follow the Command Query Separation (CQS) principle. Once again, this has roots in Domain Driven Design as well when following Intention Revealing Interfaces and Supple Design.
- Functions as First Class Types
The delegate in the .NET world has made the function pointer a first class citizen. With the use of extension methods, generics and lambda expressions, we are now able to take full advantage of performing such critical computations as Reduce, Filter, Map and other High Order function operations. Other areas in this realm include Currying and partial application of functions.
- Lazy Evaluation
In functional programming we have the ability to specify infinite ranges, such as all Fibonacci numbers or some other number sequence. The last thing we'd want is to evaluate that and get the length. Haskell takes the approach of be lazy by default. But that's not practical in a framework like .NET when we want deterministic behavior in the execution order of our code. So, instead, languages like C# and F# are eager evaluators. But, that doesn't mean we cannot take advantage. In fact, when we talk about .NET 2.0 and beyond, such things as IEnumerable<T> is a somewhat lazy execution model when we only calculate when we call the MoveNext() function and so on for each value in the collection. So, when you think about it, LINQ follows that delayed execution model and is pretty powerful for doing large sequences and evaluation.
So, as you can see, there are quite a few lessons the C# developer can learn from functional programming and F#. The key really is when to apply this knowledge and marry the ideas of OOP and FP in a cohesive manner. Speaking of which, Anders Hejlsberg was recently on Software Engineering Radio Episode 97 to talk about the past, present and future of C#. In there, he talked about some of the more functional programming ideas that have been incorporated into C# and a focus on immutability, and how we can make concurrent programming easier. Definitely not time to stick a fork in C# just yet, as I think there are plenty of ideas yet to come to express some of these problems a little bit better. In my ext post, I'll dive a little deeper into Anders' appearance on SE Radio and some of the interesting things going on around static versus dynamic typing.
Introduction to F#
My second talk for the day was on an introduction to functional programming with F#. This was more of my bread and butter presentation on explaining functional programming as I have with my Adventures in F# series. From this presentation, I focused on many of the 101 level aspects of functional programming and how they are implemented in F#. Of course there was some deviation as I explored some of the features that are more library based and exclusive to F# (async workflows, quotations, etc).
Often, the question comes up with the value proposition of F#. Yes, many can get behind many of the ideals of the language and would rather have C# adopt most of these features and not have to learn another language. This to me strikes me as a bit sad that many people are not stretching their wings outside of their comfort zone of the MSDN help files and their language of choice. Learning a new language with a new paradigm is essential to learning. This doesn't mean learning C# coming from VB.NET, but instead, gravitating towards functional programming with a language that fully supports it (F#, OCaml, Haskell, Erlang, Lisp/Scheme, etc), or towards a dynamically typed language (Ruby, Python, etc). Then once you have fully understood and become more fluent in said paradigms, you can learn those lessons and help express your solutions to your problems in more interesting ways.
But, back to F# for a moment here. What is the value of F# and why use it?
- Concurrency Programming Is Hard
It is hard, and don't let anyone fool you otherwise. With locks, mutexes and so on, it is literally impossible on a dual processor machine to have a concurrent program. Period. Instead, with a focus on immutability, side effect free functions, asynchronous workflows, the ideas of concurrent programming becomes a bit easier. Without the first two, concurrency is quite difficult. Messaging is first class through the use of the Mailbox patterns and lessons learned from Erlang.
- Representing Data Can be Hard
With the ideas of tuples, records and discriminated unions, F# gives you a powerful new way of representing your data succinctly. Then to be able to use such techniques as pattern matching against them makes for an even more compelling case.
- Creating Other Languages Is Hard
F# has a firm foundation as a language used to create other languages. With first class support of lexer generators and yacc parsing, tokenizing and parsing becomes a bit easier. Also, the inclusion of quotations as a part of the libraries make it possible for really interesting metaprogramming constructs, such as Tomas Petricek's journey into AJAX and metaprogramming.
Teaching Versus Speaking
D'arcy Lussier had an interesting post which took at Scott Bellware tweet about teachers versus speakers. It's a pretty good post, but I enjoy the comments a bit more on the subject. So, when you get up in front of that podium, just think, are you just another speaker, or are you being a teacher? Is it a dialog or death by PowerPoint?
Wrapping It Up
It was another great experience at this code camp, but I think the one hour sessions just aren't enough sometimes to fully get into any particular subject. I sometimes leave a session wanting, not because the presentation wasn't good, but there wasn't enough time to fully express the full intent of it. I could have gone on and on for hours about functional programming and F# for quite some time as I barely scratched the surface. Maybe in the future, there will be a better venue for this, but I hope to get more in depth in future iterations.
Don't forget that I'll be at Philly ALT.NET this Wednesday night for an F# presentation and then Thursday night is the DC ALT.NET meeting in Alexandria on Applying Lessons Learned from Common Lisp with Craig Andera!
- Immutable types
-
DC ALT.NET - 5/22/2008 - Applying Lessons Learned from Lisp
The May meeting of DC ALT.NET has been scheduled for May 22nd from 7-9PM. Check out our mailing list and site for more information as it becomes available. If you're in the Washington DC area, come check us out. This month, we're having Craig Andera, of FlexWiki fame, speak about applying lessons learned from learning Lisp and how to be a better programmer because of it. That's one of the true strength's of the DC ALT.NET, or even the ALT.NET movement as a whole, as we look outside our .NET community to the outside world to find better ways to solve problems and apply lessons learned from each community, and Lisp is one of those communities. Dave Laribee, Jeremy Miller and Chad Myers spoke about this on the first episode of the ALT.NET Podcast with Mike Moore. If you haven't listened to it yet, I highly recommend that you do.
Applying Lessons Learned from Lisp
There has been a lot of talk and some hype (deserved and undeserved) around functional programming lately, partly due to looking for ways for expressing parallel applications and multi-core scenarios. Some might find it interesting that functional programming has its roots back in the 1950s, well before Object Oriented Programming, yet has been relegated mostly to the research community mostly.
Back in 1958, John McCarthy from MIT designed Lisp and has been a mainstay in the Artificial Intelligence field for a long time after that. Since that time, there have been quite a few Lisp dialects to pop up due to the fact that many of the universities and labs did not share their information before everyone was connected to ARPANET. Two that have really emerged since then are Common Lisp, an attempt to standardize the Lisp variants into one, and Scheme. Lisp is a strongly typed dynamic language, meaning that if when it is interpreted, the function does not exist, an exception will be thrown. By it's nature, it is a functional language with such elements as lists, lambdas and so on. Some of the interesting additions to Lisp is the Common Lisp Object System (CLOS) which adds OOP functionality to the Common Lisp language. It's a bit different than what we think of OOP in C++, C#, Java and other OO langauges.
In the .NET world, we have IronLisp and IronScheme. IronLisp has been deprecated in favor of IronScheme going forward. That's the beauty of .NET is to build these dynamic languages on top of the DLR with relative ease, truly speaks to how flexible the type system and CLR are. To make OOP and FP first class citizens within the .NET space is also pretty interesting as well.
Back to Lisp, if you want to hear more, you should check out Dick Gabriel's appearance on Software Engineering Radio Episode 84 on Common Lisp. Dick has been a noted authority in the Lisp space for some time and is the organizer for OOPSLA back in 2007. It's one of their better episodes, so I'd encourage you to listen to it. I know I did, but then again, I have a pretty long commute, so I have time to listen to these things.
Who We Are
So, as I said, I run the DC ALT.NET group which meets monthly to discuss ways of bettering ourselves. You won't find us doing what most other user groups do in the area and is more of an intimate environment for learning and discussion. Typically we have the first hour for the topic of discussion, this month being Lisp, and then the second hour is Open Spaces, so it encourages everyone to speak and bring a topic they are passionate about. As always, we're looking for sponsors to help us out along the way. Since we're in the Washington DC area, and traffic can be bad, we tend to move from month to month to accommodate. That may change in the future as we grow, but for now, it works nicely. So, if you're in the DC area, come check us out. And, hopefully I'll get Dave Laribee to stop by before too long as well...
Where I'll Be
In addition to the meeting next week, I will be speaking at the Philly ALT.NET group meeting on May 21st on F# and an introduction to Functional programming. This should be a great session and I hope there will be a good crowd for it. Also, this weekend is the NoVA Code Camp in which I have two sessions, "Introduction to F# and Functional Programming" and "Improve Your C# with Functional Programming Ideas". Look forward to seeing everyone at those events!
-
Concurrency with MPI in .NET
In my previous post, I looked at some of the options we have for concurrency programming in .NET applications. One of the interesting ones, yet specialized is the Message Passing Interface (MPI). Microsoft made the initiative to get into the high performance computing space with the Windows Server 2003 Compute Cluster Server SKU. This allowed developers to run their given algorithms using MPI on a massive parallelized scale. And now with the Windows Server 2008 HPC SKU, it is a bit improved with WCF support for scheduling and such. If you're not part of the beta and are interested, I'd urge you to go through Microsoft Connect.
When Is It Appropriate?
When I'm talking about MPI, I'm talking in the context of High Performance Computing. This consists of having the application run within a scheduler on a compute cluster which can have 10s or hundreds of nodes. Note that I'm not talking about grid computing such as Folding@Home which distributes work over the internet. Instead, you'll find plenty of need for this in the financial sector, insurance sector for fraud detection and data analysis, manufacturing sector for testing and calculating limits, thresholds and whatnot, and even in compiling computer animation in film. There are plenty of other scenarios that are out there, but it's not for your everyday business application.
I think the real value comes with .NET to be able to read from databases, communicate with other servers with WCF or some other communication protocol, instead of being stuck in the C or Fortran world which the HPC market has been relegated. Instead, they can cut down on the code necessary for a lot of these applications by using the built-in functions that we get with the BCL.
MPI in .NET
The problem has been to run these massively parallel algorithms left us limited to Fortran and C systems. This was ok for most things that you would want to do, cobbling together class libraries wasn't my ideal. Instead, we could use a lot of the things that we take for granted in .NET such as strong types, object oriented and functional programming constructs.
The Boost libraries were made available for MPI in C++ very recently by the University of Indiana. You can read more about it here. This allowed the MPI programmer to take advantage of many of the C++ constructs that you can do in regular C, such as OOP. Instead of dealing with functions and structs, there is a full object model for dealing with messaging.
At the same time as the Boost C++ Libraries for MPI were coming out, the .NET implementation has been made available based upon the C++ design through MPI.NET. It's basically a thin veneer over the msmpi.dll which is the Microsoft implementation of the MPICH2 standard. For a list of all operation types supported, check the API documentation here for the raw MSMPI implementation. This will give you a better sense of the capabilities more than the .NET implementation can.
What you can think of this is that several nodes will be running an instance of your program at once. So, if you have 16 nodes assigned through your scheduled job, it will spin up 16 instances of the same application. When you do this on a test machine, you'll notice 16 instances of that in your task manager. Kind of cool actually. Unfortunately, they are missing a lot of the neat features in MPI which includes "Ready Sends", "Buffered Sends", but they have included nice things such as the Graph and Cartesian communicators which are essential in MPI.
You'll need the Windows Server 2003/2008 HPC SDK in order to run these examples, so download them now, and then install MPI.NET to follow along.
Messaging Patterns
With this, we have a few messaging patterns available to us. MPI.NET has given us a few that we will be looking at and how best to use them. I'll include samples in F# as it's pretty easy to do and I'm trying to get through on the fact that F# is a better language for expressing the messaging we're doing instead of C#. But, for these simple examples, they are not hard to switch back and forth.
To execute these, just type the following:
mpiexec - n <Number of Nodes You Want> <Your program exe>
Broadcast
A broadcast is a a process in which a single process (ala a head node) sends the same data to all nodes in the cluster. We want to be efficient as possible when sending out this data for all to use, without having to loop through all sends and receives. This is good when a particular root node has a value that the rest of the cluster needs before continuing. Below is a quick example in which the head node sets the value to 42 and the rest will receive it.
#light
#R "D:\Program Files\MPI.NET\Lib\MPI.dll"
open System
open MPI
let main(args:string[]) =
using(new Environment(ref args))(fun _->
let commRank = Communicator.world.Rank
let intValue = ref 0
if commRank = 0 then
intValue := 42
Communicator.world.Broadcast(intValue, 0)
Console.WriteLine("Broadcasted {0} to all nodes", !intValue)
)
main(Environment.GetCommandLineArgs())
Blocking Send and Receive
In this scenario, we're going to use the blocking send and receive pattern. This will not allow the program to continue until I get the message I'm looking for. This is good for times when you need a particular value before proceeding to your next function from the head node or any other particular node.
#light
#R "D:\Program Files\MPI.NET\Lib\MPI.dll"
open System
open MPI
let main (args:string[]) =
using(new Environment(ref args))( fun _ ->
let commRank = Communicator.world.Rank
let commSize = Communicator.world.Size
let intValue = ref 0
match commRank with
| 0 ->
[1 .. (commSize - 1)] |> List.iter (fun i ->
Communicator.world.Receive(Communicator.anySource, Communicator.anyTag, intValue)
Console.WriteLine("Result: {0}", !intValue))
| _ ->
intValue := 4 * commRank
Communicator.world.Send(!intValue,0, 0)
)
What I'm doing here is letting the head node, rank 0, to do all the receiving work. Note, that I don't care particularly where the source was, nor what the tag was. I can specify however, if I wish to go ahead and receive from a certain node and of a certain data tag. If it's a slave process, then I'm going to go ahead and calculate the value, and send it back to the head node of 0. The head node will wait until it has received that value from any node and then print out the given value. The methods that I'm using the send and receive are generic methods. Behind the scenes, in order to send, the system will go ahead and serialize your object into an unmanaged memory stream and throw it on the wire. This is one of the fun issues when dealing with marshaling to unmanaged C code.
Nonblocking Send and Receive
In this scenario, we are not going to block as we did before with sending or receiving. We want the ability to continue on doing other things while I sent the value, while the other receivers might need that value before continuing. Eventually we can force getting that value from the node through the communication status, and then at a certain point, we can set up a barrier so that nobody can continue until we've hit that point in our program. The below sample is a quick sending of a multiplied value and letting it continue. The other nodes will have to wait until that broadcast comes, and then we'll wait at the barrier until the job is done.
let main (args:string[]) =
using(new Environment(ref args))( fun _ ->
let commRank = Communicator.world.Rank
let commSize = Communicator.world.Size
let intValue = ref 0
if commRank = 0 then
[1 .. (commSize - 1)] |> List.iter (fun _ ->
Communicator.world.Receive(Communicator.anySource, Communicator.anyTag, intValue)
Console.WriteLine("Result: {0}", !intValue))
else
intValue := 4 * commRank
let status = Communicator.world.ImmediateSend(!intValue,0, 0)
status.Wait() |> ignore
Communicator.world.Barrier()
)
main(Environment.GetCommandLineArgs())
Gather and Scatter
The gather process takes values from each process and then sends it to the root process as an array for evaluation. This is a pretty simple operation for taking all values from all nodes and combining them on the head node. What I'm doing is a simple calculation of gathering all values of commRank * 3 and sending it to the head node for evaluation.
let main (args:string[]) =
using(new Environment(ref args))( fun e ->
let commRank = Communicator.world.Rank
let intValue = commRank * 3
match commRank with
| 0 ->
let ranks = Communicator.world.Gather(intValue, commRank)
ranks |> Array.iter(fun i -> System.Console.WriteLine(" {0}", i))
| _ -> Communicator.world.Gather(intValue, 0) |> ignore
)
main(Environment.GetCommandLineArgs())
Conversely, scatter does the opposite which takes a row from the given head process and splits it apart to be spread out among all processes. In this exercise I will go ahead and create a mutable array that only the head node will modify. From there, I will scatter it across the rest of the nodes to pick up and do with whatever they please.
let main (args:string[]) =
using(new Environment(ref args))( fun e ->
let commSize = Communicator.world.Size
let commRank = Communicator.world.Rank
let mutable table = Array.create commSize 0
match commRank with
| 0 ->
table <- Array.init commSize (fun i -> i * 3)
Communicator.world.Scatter(table, 0) |> ignore
| _ ->
let scatterValue = Communicator.world.Scatter(table, 0)
Console.WriteLine("Scattered {0}", scatterValue)
)
main(System.Environment.GetCommandLineArgs())
There is an AllGather method as well which performs a similar operation to Gather, but the results are available to all processes instead of the root process.
Reduce
Another collective algorithm similar to scatter and gather is the reduce function. This allows us to combine all values from each process and perform an operation on them, whether it be to add, multiply, find the maximum, minimum and so on. The value is only available at the root process though, so I have to ignore the result for the rest of the processes. The following example shows a simple
let main (args:string[]) =
using(new Environment(ref args))( fun _ ->
let commRank = Communicator.world.Rank
let commSize = Communicator.world.Size
match commRank with
| 0 ->
let sum = Communicator.world.Reduce(Communicator.world.Rank, Operation<int>.Add, 0)
Console.WriteLine("Sum of all roots is {0}", sum)
| _ ->
Communicator.world.Reduce(Communicator.world.Rank, Operation<int>.Add, 0) |> ignore
)
main(Environment.GetCommandLineArgs())
There is another variation called the AllReduce which does very similar operations to the Reduce function, but instead makes the value available to all processes instead of just the root one. There are more operations and more communicators such as Graph and Cartesian, but this is enough to give you an idea of what you can do here.
LINQ for MPI.NET
During my search for MPI.NET solutions, I came across a rather interesting one called LINQ for MP.NET. I don't know too many of the details figuring the author has been pretty aloof as to providing the complete design details. But it has entered a private beta if you do wish to contact them for more information.
The basic idea is to provide provide some scope models which include for the current scope, the world scope, root and so on. Also, it looks like they are providing some sort of multi-threading capabilities as well. Looks interesting and I'm interested in finding out more.
Pure MPI.NET?
Another implementation of the MPI in .NET has surfaced through PureMPI.NET. This is an implementation of the MPICH2 specification as well, but built on WCF instead of the MSMPI.dll. Instead, this does not rely on the Microsoft Compute Cluster service for scheduling and instead, uses remoting and such for communication purposes. There is a CodeProject article which explains it a bit more here.
More Resources
So, you want to know more, huh? Well, most of the interesting information is out there in C, so if you can read and translate it to the other APIs, you should be fine. However, there are some good books on the subject which not only provide some decent samples, but also some guidance on how to make the most of the MPI implementation. Below are some of the basic ones which will help on learning not only the APIs, but the patterns behind their usage.
- Parallel Programming With MPI - Peter Pacheco
- MPI: The Complete Reference - Marc Snir
- Patterns for Parallel Programming - Timothy Mattson
Wrapping It Up
I hope you found some of this useful for learning about how the MPI can help for massive parallel applications. The patterns learned here as well as the technologies behind them are pretty powerful to help you think about how to make your programs a bit less linear in nature. There is more to this series to look at thinking of concurrency in .NET, so I hope you stay tuned.
-
Thinking in Concurrently in .NET
In recent posts, you've found that I've been harping on immutability and side effect free functions. There is a general theme emerging from this and some real reasons why I'm pointing it out. One of the things that I'm interested in is concurrent programming on the .NET platform for messaging applications. As we see more and more cores and processors available to us, we need to be cognizant of this fact as we're designing and writing our applications. Most programs we write today are pretty linear in nature, except for say forms applications which use background worker threads to not freeze the user interface. But for the most part, we're not taking full advantage of the CPU and its cycles. We need not only a better way to handle concurrency, but a better way to describe them as well. This is where Pi-calculus comes into the picture... But before we get down that beaten path, let's look at a few options that I chose. Not that these aren't all of them, just a select few I chose to analyze.
Erlang in .NET?
For many people, Erlang is considered to be one of the more interesting languages to come out of the concurrent programming field. This language has received little attention until now when we've hit that slowdown of scaling our processor speed and instead coming into multi-core/multi-processor environments. What's interesting about Erlang is that it's a functional language, much like F#, Haskell, OCaml, etc. But what makes it intriguing as well is that it's not a static typed language like the others, and instead dynamic. Erlang was designed to support distributed, fault-tolerant, non-stop real-time applications. Written by Ericsson in the 1980s, it has been the mainstay of telephone switches ever since. If you're interested in listening to more about it, check out Joe Armstrong's appearance on Software Engineering Radio Episode 89 "Joe Armstrong on Erlang". If you want to dig deeper into Erlang, check out the book "Programming Erlang: Software for a Concurrent World" also by Joe Armstrong, and available on Amazon.
How does that lead us to .NET? Well, it's interesting that someone thought of trying to port the language to .NET on a project called Erlang.NET. This project didn't get too far as I can tell, and for obvious impedance mismatch reasons. First off, there is a bit of a disconnect between .NET processes and Erlang processes and how he wants to tackle them. Erlang processes are cheap to create and tear down, whereas .NET ones tend to be a bit heavy. Also the Garbage Collection runs a bit differently instead of a per process approach, the CLR takes a generational approach. And another thing is that Erlang is a dynamic language running on its own VM, so it would probably sit on top of the DLR in the .NET space. Not saying it's an impossible task, but improbable the way he stated.
Instead, maybe the approach to take with an Erlang-like implementation is to create separate AppDomains since they are relatively cheap to create. This will allow for process isolation and messaging constructs to fit rather nicely. Instead, we get rid of the impedance mismatch by mapping an Erlang process to an AppDomain. Then you can tear down the AppDomain after you are finished or you could restart them in case of a recovery scenario. These are some of the ideas if you truly want to dig any further into the subject. I'll probably cover this in another post later.
So, where does that leave us with Erlang itself? Well, we have the option of integrating Erlang and .NET together through OTP.NET. The original article from where the idea came from is from the ServerSide called "Integrating Java and Erlang". This allows for the use of Erlang to do the computation on the server in a manner that best fits the Erlang style. I find it's a pretty interesting article and maybe when I have a spare second, I'll check it out a bit more. But, in terms of a full port to .NET? Well, I think .NET languages have some lessons to learn from Erlang, as it tackled concurrent programming as the first topic instead of most imperative languages bolting it on after the fact.
MPI.NET
The Message Passing Interface (MPI) approach has been an interesting way of solving mass concurrency for applications. This involves using a standard protocol for passing messages from node to node through the system by the way of a compute cluster. In the Windows world, we have Windows Compute Cluster Server (WCCS) that handles this need. CCS is available now in two separate SKUs, CCS 2003 and CCS 2008 for Server 2008. The Server 2008 CCS is available in CTP on the Microsoft Connect website. See here for more information. You mainly find High Performance Computing with MPI in the automotive, financial, scientific and academic communities where they have racks upon racks of machines.
Behind the scenes, Microsoft implemented the MPICH2 version of the MPI specification. This was then made available to C programmers and is fairly low level. Unfortunately, that leaves most C++ and .NET programmers out in the cold when it comes to taking advantage. Sure, C++ could use the standard libraries, but instead, the Boost libraries were created to support MPI in a way that C++ could really take advantage of.
After this approach was taken, a similar approach was taken for the .NET platform with MPI.NET. The University of Indiana produced a .NET version which looked very similar to the Boost MPI approach but with .NET classes. This allows us to program in any .NET language now against the Windows CCS to take advantage of the massive scalability and scheduling services offered in the SKU. At the end of the day, it's just a thin wrapper over P/Invoking msmpi.dll with generics thrown in as well. Still, it's a nice implementation.
And since it was written for .NET, I can for example do a simple hello world application in F# to take advantage of the MPI. The value being is that most algorithms and heavy lifting you would be doing through there would probably be functional anyways. So, I can use F# to specify more succinctly what types of actions and what data I need. Here is a simple example:
#light
#R "D:\Program Files\MPI.NET\Lib\MPI.dll"
open MPI
let main (args:string[]) =
using(new Environment(ref args))( fun e ->
let commRank = Communicator.world.Rank
let commSize = Communicator.world.Size
match commRank with
| 0 ->
let intValue = ref 0
[1 .. (commSize - 1)] |> List.iter (fun i ->
Communicator.world.Receive(Communicator.anySource, Communicator.anyTag, intValue)
System.Console.WriteLine("Hello from node {0} out of {1}", !intValue, commSize))
| _ -> Communicator.world.Send(commRank,0, 0)
)
main(System.Environment.GetCommandLineArgs())
I'll go into more detail in the future as to what this means and why, but just to whet your appetite about what you can do in this is pretty powerful.
F# to the Rescue with Workflows?
Another topic for discussion is for asynchronous workflows. This is another topic in which F# excels as a language. Async<'a> values are really a way of writing continuation passing explicitly. I'll be covering this more in a subsequent post shortly, but in the mean time, there is good information from Don Syme here and Robert Pickering here.
Below is a quick example of an asynchronous workflow which fetches the HTML from each of the given web sites. I can then run each in parallel and get the results rather easily. What I'll do below is a quick retrieval of HTML by calling the Async methods. Note that these methods don't exactly exist, but F# through its magic, creates that for you.
#light
open System.IO
open System.Net
open Microsoft.FSharp.Control.CommonExtensions
let fetchAsync (url:string) =
async { let request = WebRequest.Create(url)
let! response = request.GetResponseAsync()
let stream = response.GetResponseStream()
let reader = new StreamReader(stream)
let! html = reader.ReadToEndAsync()
return html
}
let urls = ["http://codebetter.com/"; "http://microsoft.com"]
let htmls = Async.Run(Async.Parallel [for url in urls -> fetchAsync url])
print_any htmls
So, as you can see, it's a pretty powerful mechanism for retrieving data asynchronously and then I can run each of these in parallel with parameterized data.
Parallel Extensions for .NET
Another approach I've been looking at is the Parallel Extensions for .NET. The current available version is for the December CTP and is available here. You can read more about it from two MSDN Magazine articles:
What I find interesting is Parallel LINQ or PLINQ for short. The Task Parallel library doesn't interest me as much. LINQ in general is interesting to a functional programmer in that it's a lazy loaded function. The actual execution of your LINQ task is delayed until the first yield in GetEnumerator() has been called. That's definitely taking some lessons from the functional world and pretty powerful. And add on top of that the ability to parallelize your heavy algorithms is a pretty powerful concept. I hope this definitely moves forward.
Conclusion
As you can see, I briefly gave an introduction to each of these following areas that I hope to dive into a bit more in the coming weeks and months. I've only scratched the surface on each and each tackle the concurrency problems in slightly different ways and each has its own use. But I hope I whetted your appetite to look at some of these solutions today.
-
Your API Fails, Who is at Fault?
I decided to stay on the Design by Contract side for just a little bit. Recently, Raymond Chen posted "If you pass invalid parameters, then all bets are off" in which he goes into parameter validation and basic defensive programming. Many of the conversations had on the blog take me back to my C++ and early Java days of checking for null pointers, buffer lengths, etc. This brings me back to some recent conversations I've had about how to make it explicit about what I expect. Typical defensive behavior looks something like this:
public static void Foreach<T>(this IEnumerable<T> items, Action<T> action)
{
if (action == null)
throw new ArgumentNullException("action");
foreach (var item in items)
action(item);
}
After all, how many times have you not had any idea what the preconditions are for a given method due to lack of documentation or non-intuitive method naming? it gets worse when they don't provide much documentation, XML comments or otherwise. At that point, it's time to break out .NET Reflector and dig deep. Believe me, I've done it quite a bit lately.
The Erlang Way
The Erlang crowd takes an interesting approach to the issue that I've really been intrigued by. Joe Armstrong calls this approach "Let it crash" in which you only code to the sunny day scenario, and if the call to it does not conform to the spec, just let it crash. You can read more about that on the Erlang mailing list here.
Some paragraphs stuck out in my mind.
Check inputs where they are "untrusted"
- at a human interface
- a foreign language program
What this basically states is the only time you should do such checks is at the bounds when you have possible untrusted input, such as bounds overflows, unexpected nulls and such. He goes on to say about letting it crash:
specifications always say what to do if everything works - but never what to do if the input conditions are not met - the usual answer is something sensible - but what you're the programmer - In C etc. you have to write *something* if you detect an error - in Erlang it's easy - don't even bother to write code that checks for errors - "just let it crash".
So, what Joe advocates is not checking at all, and if they don't conform to the spec, just let it crash, no need for null checks, etc. But, how would you recover from such a thing? Joe goes on to say:
Then write a *independent* process that observes the crashes (a linked process) - the independent process should try to correct the error, if it can't correct the error it should crash (same principle) - each monitor should try a simpler error recovery strategy - until finally the error is fixed (this is the principle behind the error recovery tree behaviour).
It's an interesting approach, but proves to a valuable one for parallel processing systems. As I dig further into more functional programming languages, I'm finding such constructs useful.
Design by Contract Again and DDD
Defensive programming is a key part of Design by Contract. But, in a way it differs. With defensive programming, the callee is responsible for determining whether the parameters are valid and if not, throws an exception or otherwise handles it. DbC with the help of the language helps the caller better understand how to cope with the exception if it can.
Bertrand Meyer wrote a bit about this in the Eiffel documentation here. But, let's go back to basics. DbC asserts that the contracts (what we expect, what we guarantee, what we maintain) are such a crucial piece of the software, that it's part of the design process. What that means is that we should write these contract assertions FIRST.
What do these contract assertions contain? It normally contains the following:
- Acceptable/Unacceptable input values and the related meaning
- Return values and their meaning
- Exception conditions and why
- Preconditions (may be weakened by subclasses)
- Postconditions (may be strengthened by subclasses)
- Invariants (may be strengthened by subclasses)
So, in effect, I'm still doing TDD/BDD, but an important part of this is identifying my preconditions, postconditions and invariants. These ideas mesh pretty well with my understanding of BDD and we should be testing those behaviors in our specs. Some people saw in my previous posts that they were afraid I was de-emphasizing TDD/BDD and that couldn't be further from the truth. I'm just using another tool in the toolkit to express my intent for my classes, methods, etc. I'll explain further in a bit down below.
Also, my heavy use of Domain Driven Design patterns help as well. I mentioned those previously when I talked about Side Effects being Code Smells. With the combination of intention revealing interfaces which express to the caller what I am intending to do, and my use of assertions not only in the code but also in the documentation as well. This usually includes using the <exception> XML tag in my code comments. Something like this is usually pretty effective:
/// <exception cref="T:System.ArgumentNullException"><paramref name="action"/> is null.</exception>
If you haven't read Eric's book, I suggest you take my advice and Peter's advice and do so.
Making It Explicit
Once again, the use of Spec# to enforce these as part of the method signature to me makes sense. To be able to put the burden back on the client to conform to the contract or else they cannot continue. And to have static checking to enforce that is pretty powerful as well.
But, what are we testing here? Remember that DbC and Spec# can ensure your preconditions, your postconditions and your invariants hold, but they cannot determine whether your code is correct and conforms to the specs. That's why I think that BDD plays a pretty good role with my use of Spec#.
DbC and Spec# can also play a role in enforcing things that are harder with BDD, such as enforcing invariants. BDD does great things by emphasizing behaviors which I'm really on board with. But, what I mean by being harder is that your invariants may be only private member variables which you are not going to expose to the outside world. If you are not going to expose them, it makes it harder for your specs to control such behavior. DbC and Spec# can fill that role. Let's look at the example of an ArrayList written in Spec#.
public class ArrayList
{
invariant 0 <= _size && _size <= _items.Length;
invariant forall { int i in (_size : _items.Length); _items[i] == null }; // all unused slots are null
[NotDelayed]
public ArrayList (int capacity)
requires 0 <= capacity otherwise ArgumentOutOfRangeException;
ensures _size/*Count*/ == 0;
ensures _items.Length/*Capacity*/ == capacity;
{
_items = new object[capacity];
base();
}
public virtual void Clear ()
ensures Count == 0;
{
expose (this) {
Array.Clear(_items, 0, _size); // Don't need to doc this but we clear the elements so that the gc can reclaim the references.
assume forall{int i in (0: _size); _items[i] == null}; // postcondition of Array.Clear
_size = 0;
}
}
// Rest of code omitted
What I've been able to do is set the inner array to the new capacity, but also ensure that when I do that, my count doesn't go up, but only my capacity. When I call the Clear method, I need to make sure the inner array is peer consistent by the way of all slots not in the array must be null as well as resetting the size. We use the expose block to expose to the runtime to have the verifier analyze the code. By the end of the expose block, we should be peer consistent, else we have issues. How would we test some of these scenarios in BDD? Since they are not exposed to the outside world, it's pretty difficult. What it would be doing is leaving me with black box artifacts that are harder to prove. Instead, if I were to expose them, it would then break encapsulation which is not necessarily something I want to do. Instead, Spec# gives me the opportunity to enforce this through the DbC constructs afforded in the language.
The Dangers of Checked Exceptions
But with this, comes a cost of course. I recently spoke with a colleague about Spec# and the instant thoughts of checked exceptions in Java came to mind. Earlier in my career, I was a Java guy who had to deal with those who put large try/catch blocks around methods with checked exceptions and were guilty of just catching and swallowing or catching and rethrowing RuntimeExceptions. Worse yet, I saw this as a way of breaking encapsulation by throwing exceptions that I didn't think the outside world needed to know about. I was kind of glad that this feature wasn't brought to C# due to the fact I saw rampant abuse for little benefit. What people forgot about during the early days of Java that exceptions are meant to be exceptional and not control flow.
How I see Spec# being different is that since we have a static verification tool through the use of Boogie to verify whether those exceptional conditions are valid. The green squigglies give warnings about possible null values or arguments in ranges, etc. This gives me further insight into what I can control and what I cannot. Resharper also has some of those nice features as well, but I've found Boogie to be a bit more helpful with more advanced static verification.
Conclusion
Explicit DbC constructs give us a pretty powerful tool in terms of expressing our domain and our behaviors of our components. Unfortunately, in C# there are no real valuable implementations that enforce DbC constructs to both the caller and the callee. And hence Spec# is an important project to come out of Microsoft Research.
Scott Hanselman just posted his interview with the Spec# team on his blog, so if you haven't heard it yet, go ahead and download it now. It's a great show and it's important that if you find Spec# to be useful, that you press Microsoft to give it to us as a full feature.
-
Command-Query Separation and Immutable Builders
In one of my previous posts about Command-Query Separation (CQS) and side effecting functions being code smells, it was pointed out to me again about immutable builders. For the most part, this has been one area of CQS that I've been willing to let break. I've been following Martin Fowler's advice on method chaining and it has worked quite well. But, revisiting an item like this never hurts. Immutability is something you'll see me harping on time and time again now and in the future. The standard rules I usually do is immutable and side effect free when you can, mutable state where you must. I like the opt-in mutability of functional languages such as F# which I'll cover at some point in the near future instead of the opt-out mutability of imperative/OO languages such as C#.
Typical Builders
The idea of the standard builder is pretty prevalent in most applications we see today with fluent interfaces. Take for example most Inversion of Control (IoC) containers when registering types and so on:
UnityContainer container = new UnityContainer();
container
.RegisterType<ILogger, DebugLogger>("logger.Debug")
.RegisterType<ICustomerRepository, CustomerRepository>();
Let's take a naive medical claims processing system and building up and aggregate root of a claim. This claim contains such things as the claim information, the lines, the provider, recipient and so on. This is a brief sample and not meant to be the real thing, but just a quick example. After all, I'm missing things such as eligibility and so on.
public class Claim
{
public string ClaimId { get; set; }
public DateTime ClaimDate { get; set; }
public List<ClaimLine> ClaimLines { get; set; }
public Recipient ClaimRecipient { get; set; }
public Provider ClaimProvider { get; set; }
}
public class ClaimLine
{
public int ClaimLineId { get; set; }
public string ClaimCode { get; set; }
public double Quantity { get; set; }
}
public class Recipient
{
public string RecipientId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
public class Provider
{
public string ProviderId { get; set; }
public string FirstName { get; set; }
public string LastName { get; set; }
}
Now our standard builders use method chaining as shown below. As you note, we'll return the instance each and every time.
public class ClaimBuilder
{
private string claimId;
private DateTime claimDate;
private readonly List<ClaimLine> claimLines = new List<ClaimLine>();
private Provider claimProvider;
private Recipient claimRecipient;
public ClaimBuilder() {}
public ClaimBuilder WithClaimId(string claimId)
{
this.claimId = claimId;
return this;
}
public ClaimBuilder WithClaimDate(DateTime claimDate)
{
this.claimDate = claimDate;
return new ClaimBuilder(this);
}
public ClaimBuilder WithClaimLine(ClaimLine claimLine)
{
claimLines.Add(claimLine);
return this;
}
public ClaimBuilder WithProvider(Provider claimProvider)
{
this.claimProvider = claimProvider;
return this;
}
public ClaimBuilder WithRecipient(Recipient claimRecipient)
{
this.claimRecipient = claimRecipient;
return this;
}
public Claim Build()
{
return new Claim
{
ClaimId = claimId,
ClaimDate = claimDate,
ClaimLines = claimLines,
ClaimProvider = claimProvider,
ClaimRecipient = claimRecipient
};
}
public static implicit operator Claim(ClaimBuilder builder)
{
return new Claim
{
ClaimId = builder.claimId,
ClaimDate = builder.claimDate,
ClaimLines = builder.claimLines,
ClaimProvider = builder.claimProvider,
ClaimRecipient = builder.claimRecipient
};
}
}
What we have above is a violation of the CQS because we're mutating the current instance as well as returning a value. Remember, that CQS states:
- Commands - Methods that perform an action or change the state of the system should not return a value.
- Queries - Return a result and do not change the state of the system (aka side effect free)
Immutable Builders or ObjectMother or Cloning?
When we're looking to reuse our builders, the last thing we'd want to do is allow mutation of the state. So, if I'm working on the same provider and somehow change his eligibility, then that would be reflected against all using the same built up instance. That would be bad. We have a couple options here really. One would be to follow an ObjectMother approach to build up shared ones and request a new one each time, or the other would be to enforce that we're not returning this each and every time we add something to our builder. Or perhaps we can take one at a given state and just clone it. Let's look at each.
public static class RecipientObjectMother
{
public static RecipientBuilder RecipientWithLimitedEligibility()
{
RecipientBuilder builder = new ProviderBuilder()
.WithRecipientId("xx-xxxx-xxx")
.WithFirstName("Robert")
.WithLastName("Smith")
// More built in stuff here for setting up eligibility
return builder;
}
}
This allows me to share my state through pre-built builders and then when I've finalized them, I'll just call the Build method or assign them to the appropriate type. Or, I could just make them immutable instead and not have to worry about such things. Let's modify the above example to take a look at that.
public class ClaimBuilder
{
private string claimId;
private DateTime claimDate;
private readonly List<ClaimLine> claimLines = new List<ClaimLine>();
private Provider claimProvider;
private Recipient claimRecipient;
public ClaimBuilder() {}
public ClaimBuilder(ClaimBuilder builder)
{
claimId = builder.claimId;
claimDate = builder.claimDate;
claimLines.AddRange(builder.claimLines);
claimProvider = builder.claimProvider;
claimRecipient = builder.claimRecipient;
}
public ClaimBuilder WithClaimId(string claimId)
{
ClaimBuilder builder = new ClaimBuilder(this) {claimId = claimId};
return builder;
}
public ClaimBuilder WithClaimDate(DateTime claimDate)
{
ClaimBuilder builder = new ClaimBuilder(this) { claimDate = claimDate };
return builder;
}
public ClaimBuilder WithClaimLine(ClaimLine claimLine)
{
ClaimBuilder builder = new ClaimBuilder(this);
builder.claimLines.Add(claimLine);
return builder;
}
public ClaimBuilder WithProvider(Provider claimProvider)
{
ClaimBuilder builder = new ClaimBuilder(this) { claimProvider = claimProvider };
return builder;
}
public ClaimBuilder WithRecipient(Recipient claimRecipient)
{
ClaimBuilder builder = new ClaimBuilder(this) { claimRecipient = claimRecipient };
return builder;
}
// More code here for building
}
So, what we've had to do is provide a copy-constructor to initialize the object in the right state. And here I thought I could leave those behind since my C++ days. After each assignment, I then create a new ClaimBuilder and pass in the current instance to initialize the new one, thus copying over the old state. This then makes my class suitable for sharing. Side effect free programming is the way to do it if you can. Of course, realizing that it creates a few objects on the stack as you're initializing your aggregate root, but for testing purposes, I haven't really much cared.
Of course I could throw Spec# into the picture once again as enforcing immutability on said builders. To be able to mark methods as being Pure makes it apparent to both the caller and the callee what the intent of the method is. Another would be using NDepend as Patrick Smacchia talked about here.
The other way is just to provide a clone method which would just copy the current object so that you can go ahead and feel free to modify a new copy. This is a pretty easy approach as well.
public ClaimBuilder(ClaimBuilder builder)
{
claimId = builder.claimId;
claimDate = builder.claimDate;
claimLines.AddRange(builder.claimLines);
claimProvider = builder.claimProvider;
claimRecipient = builder.claimRecipient;
}
public ClaimBuilder Clone()
{
return new ClaimBuilder(this);
}
Conclusion
Obeying the CQS is always an admirable thing to do especially when managing side effects. Not all of the time is it required such as with builders, but if you plan on sharing these builders, it might be a good idea to really think hard about the side effects you are creating. As we move more towards multi-threaded, multi-machine processing, we need to be aware of our side effecting a bit more. But, at the end of the day, I'm not entirely convinced that this violates the true intent of CQS since we're not really querying, so I'm not sure how much this is buying me. What are your thoughts?
-
Adventures in F# - F# 101 Part 9 (Control Flow)
Taking a break from the Design by Contract stuff for just a bit while I step back into the F# and functional programming world. If you followed me at my old blog, you'll know I'm pretty passionate about functional programming and looking for new ways to solve problems and express data.
Where We Are
Before we begin today, let's catch up to where we are today:
- Part 1 - Basic functional programming
- Part 2 - Currying and Tuples
- Part 3 - Scope, Recursion and Anonymous Functions
- Part 4 - History of F#, Operators and Lists
- Part 5 - Pattern Matching
- Part 6 - Lazy Evaluation
- Part 7 - Creating Types
- Part 8 - Mutables and Reference Cells
A Survey of .NET Languages And Paradigms
Joel Pobar just contributed an article to the latest MSDN Magazine (May 2008) called "Alphabet Soup: A Survey of .NET Languages And Paradigms". This article introduces not only the different languages that are supported in the .NET space, but the actual paradigms that they operate in. For example, you have C#, VB.NET, C++, F# and others in the static languages space and IronRuby, IronPython among others in the dynamic space. But what's more interesting is the way that each one tackles a particular problem. The article covers a little bit about functional programming and its uses as well as dynamic languages. Of course the mention is made that C# and VB.NET are slowly adopting more functional programming aspects over time. One thing I've lamented is the fact that VB.NET and C# are too similar for my tastes so I'm hoping for more true differentiation come the next spin. Instead, VB would be really interesting as a more dynamic language and not just one that many people just look down their noses at. Ok, enough of the sidetracking and let's get back to the subject at hand.
Control Flow
Since F# is a general purpose language in the .NET space, it supports all imperative ways of approaching problems. This of course includes control flow. F# takes a different approach than most functional programming languages in that the evaluation of a statement can happen in any order. Instead, in F#, we have a very succinct way of doing it in F# with the if, elif, else statements. Below is a quick example of that:
#light
let IsInBounds (x:int) (y:int) =
if x < 0 then false
elif x > 50 then false
elif y < 0 then false
elif y > 50 then false
else true
What I was able to do is to check the bounds of the given integer inputs. Pretty simple example. As opposed to many imperative languages, when you are returning a value from the if, all subsequent elif or elses must also return values. This makes for balanced equations. Also, if you return a value from an if, then you are also forced to have an else which returns a value.
Although F# is using type inference to determine what my IsInBounds method returns, I cannot go ahead and return one type in an if and another different type in the elif or else. F# will complain violently, as it should because that's really not a good design of a function. Below is some code that will definitely throw an error.
#light
let IsInBounds (x:int) (y:int) =
if x < 0 then "Foo"
elif x > 50 then false
elif y < 0 then false
elif y > 50 then false
else true
As I said before, the equations must be balanced. But of course if your if expression returns a unit (void type for those imperative folks), then you aren't forced to have and else statement. Pretty self explanatory there.
Let's move onto the for loops. The standard for loop is to start at a particular index value, check for the terminate condition and then increment or decrement the index. F# supports this of course in a pretty standard way, but by default, the index is incremented by 1. You must note though that the body of the for loop is a unit type (void once again) so, if you return a value, F# won't like it. Below is a simple for loop to iterate through all lowercase letters.
#light
let chars = [|'a'..'z'|]
let PrintChars (c:array<char>) =
for index = 0 to chars.Length - 1 do
print_any c.[index]
PrintChars chars
But, if I tried to return c from the for loop, F# will complain, but it will allow it to happen. It's just a friendly reminder that it's not going to do anything with that value you specified. I could also specify the for loop with a decrementer, so let's reverse our letters this time.
#light
let chars = [|'a'..'z'|]
let PrintChars (c:array<char>) =
for index = chars.Length - 1 downto 0 do
print_any c.[index]
PrintChars chars
F# also supports the while construct as well. This of course is the exact same as any imperative construct, but with the caveat of once again, the while loop should not return a value because it is of the unit type.
#light
let chars = ref ['a'..'z']
while (List.nonempty !chars) do
print_any (List.hd !chars)
chars := List.tl !chars
This time we're just printing out a char and then removing it from the list collection. Note that we're using the ref keyword and reference cells as we talked about before. Lastly, let's cover one last construct, the foreach statement. This is much like we have in most other languages, just the wording is a bit different. As always, the foreach statement has the unit type, so returning values is a warning.
#light
let nums = [0..99]
for n in nums do
print_any n
Wrapping It Up
Just a quick walkthrough of just some of the imperative control statements allowed by F#. As you can see, it's not a huge leap here from one language to the next. I have a couple of upcoming talks on F#, so if you're in the Northern VA area on May 17th, come check it out at the NoVA Code Camp.
-
Side Effecting Functions Are Code Smells Revisited
After talking with Greg Young for a little this morning, I realized I missed a few points that I think need to be covered as well when it comes to side effecting functions are code smells. In the previous post, I talked about side effect free functions and Design by Contract (DbC) features in regards to Domain Driven Design. Of course I had to throw the requisite Spec# plug as well for how it handles DbC features in C#.
Intention Revealing Interfaces
Let's step back a little bit form the discussion we had earlier. Let's talk about good design for a second. How many times have you seen a method and had no idea what it did or that it went ahead and called 15 other things that you didn't expect? At that point, most people would take out .NET Reflector (a Godsend BTW) and dig through the code to see the internals. One of the examples of the violators was the ASP.NET Page lifecycle when I first started learning it. Init versus Load versus PreLoad wasn't really exact about what happened where, and most people have learned to hate it.
In the Domain Driven Design world, we have the Intention Revealing Interface. What this means is that we need to name our classes, methods, properties, events, etc to describe their effect and purpose. And as well, we should use the ubiquitous language of the domain to name them appropriately. This allows other team members to be able to infer what that method is doing without having to dig in with such tools as Reflector to see what it is actually doing. In our public interfaces, abstract classes and so on, we need to specify the rules and the relationships. To me, this comes back again to DbC. This allows us to not only specify the name in the ubiquitous language, but the behaviors as well.
Command-Query Separation (CQS)
Dr. Bertrand Meyer, the man behind Eiffel and the author of Object-oriented Software Construction, introduced a concept called Command-Query Separation. It states that we should break our functionality into two categories:
- Commands - Methods that perform an action or change the state of the system should not return a value.
- Queries - Return a result and do not change the state of the system (aka side effect free)
Of course this isn't a 100% rule, but it's still a good one to follow. Let's look at a simple code example of a good command. This is simplified of course. But what we're doing is side effecting the number of items in the cart.
public class ShoppingCart
{
public void AddItemToCart(Item item)
{
// Add item to cart
}
}
Should we use Spec# to do this, we could also check our invariants as well, but also to ensure that the number of items in our cart has increased by 1.
public class ShoppingCart
{
public void AddItemToCart(Item item)
ensures ItemsInCart == old(ItemsInCart) + 1;
{
// Add item to cart
}
}
So, once again, it's very intention revealing at this point that I'm going to side effect the system and add more items to the cart. Like I said before, it's a simplified example, but it's a very powerful concept. And then we could talk about queries. Let's have a simple method on a cost calculation service that takes in a customer and the item and calculates.
public class CostCalculatorService
{
public double CalculateCost(Customer c, Item i)
{
double cost = 0.0d;
// Calculate cost
return cost;
}
}
What I'm not going to be doing in this example is modifying the customer, nor the item. Therefore, if I'm using Spec#, then I could mark this method as being [Pure]. And that's a good thing.
The one thing that I would hold an exception for is fluent builders. Martin Fowler lays out an excellent case for them here. Not only would we be side effecting the system, but we're also returning a value (the builder itself). So, the rule is not a hard and fast one, but always good to observe. Let's take a look at a builder which violates this rule.
public class CustomerBuilder
{
private string firstName;
public static CustomerBuilder New { get { return new CustomerBuilder(); } }
public CustomerBuilder WithFirstName(string firstName)
{
this.firstName = firstName;
return this;
}
// More code goes here
}
To wrap things up, things are not always fast rules and always come with the "It Depends", but the usual rule is that you can't go wrong with CQS.
Wrapping It Up
These rules are quite simple for revealing the true intent of your application while using the domain's ubiquitous language. As with anything in our field, it always comes with a big fat "It Depends", but applying the rules as much as you can is definitely to your advantage. These are simple, yet often overlooked scenarios when we design our applications, yet are the fundamentals.
-
Side Effecting Functions are Code Smells
I know the title might catch a few people off guard, but let me explain. Side effecting functions, for the most part, are code smells. This is a very important concept in Domain Driven Design (DDD) that's often overlooked. For those who are deep in DDD, this should sound rather familiar. And in the end, I think Spec# and some Design by Contract (DbC) constructs can mitigate this, or you can go the functional route as well.
What Is A Side Effect?
When you think of the word side effect in most languages, you tend to think of any unintended consequence. Instead, what we mean by it is having any effect on the system from an outside force. What do I mean by that? Well, think of these scenarios, reading and writing to a database, reading or writing to the console, or even modifying the state of your current object. Haskell and other functional languages take a pretty dim view of side effects, hence why they are not allowed, unless through monads. F# also takes this stance, as "variables" are immutable unless otherwise specified.
Why Is It A Smell?
Well, let's look at it this way. Most of our operations call other operations which call even more operations. This deep nesting is then created. From this deep nesting, it becomes quite difficult to predict the behaviors and consequences of calling all of those nested operations. You, the developer might not have intended for all of those operations to occur because A modified B modified C modified D. Without any safe form of abstraction, it's pretty hard to test as well. Imagine that any mock objects that you create would have to suddenly know in 5 levels deep that it is modified in some function. Not necessarily the best thing to do.
Also, when it comes to multi-threaded processing, this becomes even more of an issue. If multiple threads have a reference to the same mutable object, and one thread changes something on the reference, then all other threads were just side effected. This may not be something that you'd want to do. Then again, if working on shared memory applications, that might be. But, for the most part, the unpredictability of it can be a bad thing.
Let's take a quick example of a side effecting an object like implementation of a 2 dimensional Point. We're going to go ahead and allow ourselves to add another Point to the system.
public class Point2D
{
public double X { get; set; }
public double Y { get; set; }
public void Add(Size2D other)
{
X += other.Height;
Y += other.Width;
}
}
public class Size2D
{
public double Height { get; set; }
public double Width { get; set; }
}
What's wrong with the above sample is that I just side effected the X, and Y. Why is this bad? Well, like I said, most objects like these are fire and forget. Anyone who had a reference to this Point now has a side effected one, that they might not have wanted. Instead, I should probably focus on retrieving a new one at this point, since this is pretty much a value object.
What Can You Do About It?
Operations that return results without side effects are considered to be pure functions. These pure functions when called any number of times will return the same result given the same parameters time and time again. Pure functions are much easier to unit test and overall a pretty low risk.
There are several approaches to being able to fix the above samples. First, you can keep your modifiers and queries separated. Make sure you keep the methods that make changes to your object separate from those that return your domain data. Perform those queries and associated calculations in methods that don't change your object state in any way. So, think of a method that calculates price and then another method that actually sets the price on the particular object.
Secondly, you could also just not modify the object at all. Instead, you could return a value object that is created as an answer to a calculation or a query. Since value objects are immutable, you can feel free to hand them off and forget about them, unlike entities which are entirely mutable. Let's take the above example of the Coordinate and switch it around. Think of the DateTime structure. When you want to add x number of minutes, do you side effect the DateTime, or do you get a new one? The answer is, you get a new one? Why, well, because it's a structure, and they are immutable, but not only that, it solves a lot of those side effecting problems.
public class Point2D
{
private readonly double x;
private readonly double y;
public Point2D() {}
public Point2D(double x, double y)
{
this.x = x;
this.y = y;
}
public double X { get { return x; } }
public double Y { get { return y; } }
public Point2D Add(Size2D other)
{
double newX = x + other.Height;
double newY = y + other.Width;
return new Point2D(newX, newY);
}
}
Spec# is a tool that can help in this matter. Previously I stated why Spec# matters, well, let's get into more detail why. We can mark our side effect free methods as being pure with the [Pure] attribute. This allows the system to verify that indeed we are not side-effecting the system, and any time I call that with the same parameters, I will get the same result. It's an extra insurance policy that makes it well known to the caller that I'm not going to side effect myself when you call me. So, let's go ahead and add some Spec# goodness to the equation.
[Pure]
public Point2D Add(Size2D other)
{
double newX = x + other.Height;
double newY = y + other.Width;
return new Point2D(newX, newY);
}
But, now Spec# will warn us that our other might be null, and that could be bad.... So, let's fix that to add some real constraints for the preconditions.
[Pure]
public Point2D Add(Size2D other)
requires other != null
{
double newX = x + other.Height;
double newY = y + other.Width;
return new Point2D(newX, newY);
}
Of course I could have put some ensures as well to ensure the result will be the addition, but you get the point.
Turning To Design by Contract
Now of course we have to be a pragmatist about things. At no point did I say that we can't have side effects ever. That would be Haskell and they put themselves into a nasty corner with that and the only way around it was with monads, that can be a bit clumsy. Instead, I want to refocus where we do them and be more aware of what you're modifying.
In our previous examples, we cut down on the number of places where we had our side effects. But, this does not eliminate them, instead gather them in the appropriate places. Now when we deal with entities, they are very much mutable, and so we need to be aware when and how side effects get introduced. To really get to the heart of the matter, we need to verify the preconditions, the postconditions and mostly our invariants. In a traditional application written in C#, we could throw all sorts of assertions into our code to make sure that we are in fact conforming to our contract. Or we can write our unit tests to ensure that they conform to them. This is an important point in Eric Evans' book when talking about assertions in the Supple Design chapter.
Once again, Spec# enters again as a possible savior to our issue. This allows us in our code, to model our preconditions and our postconditions as part of our method signature. Invariants as well can be modeled as well into our code as well. These ideas came from Eiffel but are very powerful when used for good.
Let's make a quick example to show how invariants and preconditions and postconditions work. Let's create an inventory class, and keep in mind it's just a sample and not anything I'd ever use, but it proves a point. So let's lay out the inventory class and we'll set some constraints. First, we'll have the number of items remaining. That number of course can never go below zero. Therefore, we need an invariant that enforces that. Also, when we remove items from the inventory, we need to make sure that we're not going to dip below zero. Very important things to keep in mind.
public class Inventory
{
private int itemsRemaining;
private int reorderPoint;
invariant itemsRemaining >= 0;
public Inventory()
{
itemsRemaining = 200;
reorderPoint = 50;
base();
}
public void RemoveItems(int items)
requires items <= ItemsRemaining;
ensures ItemsRemaining == old(ItemsRemaining) - items;
{
expose(this)
{
itemsRemaining -= items;
}
// Check reorder point
}
public int ItemsRemaining { get { return itemsRemaining; } }
// More stuff here in class
}
What I was able to express is that I set up my invariants in the constructor. You cannot continue in a Spec# program unless you set the member variable that's included in the invariant. Also, look at the RemoveItems method. We set one precondition that states that number of items requested must be less than or equal to the number left. And we set the postcondition which states that the items remaining must be the difference between the old items remaining and the items requested. Pretty simple, yet powerful. We had to expose our invariant while modifying it so that it could be verified, however. But, doesn't it feel good to get rid of unit tests that prove what I already did in my method signature?
Wrapping Things Up
So, I hope after reading this, you've thought more about your design, and where you are modifying state and that you have intention revealing interfaces to tell the coder what exactly you are going to do. The Design by Contract features of Spec# also play a role in this to state in no uncertain terms what exactly the method can do with the preconditions and postconditions and through my class with my invariants. Of course you can use your regular C#, or language of choice to model the same kind of things, yet not as intention revealing.
So, where to go from here? Well, if you've found Spec# interesting, let Microsoft know about it. Join the campaign that Greg and I are harping on and say, "I Want Spec#!"
-
Upcoming Functional Programming/F# Talks
Well, I certainly have an ambitious May schedule ahead of me. Most of course will be revolving around functional programming and F# as it seems to be finally catching on. I've been noticing a bunch from the Java and Ruby communities becoming interested in such things as Scala, Haskell, OCaml, Erlang and F#. I was rather heartened by this as some in the Ruby world like here and here coming back to the static world for ways of representing data and functions in different ways. Of course Lisp and Scheme (IronLisp and IronScheme) still manages to eek in the rebirth, but still remains on the outside.
I will be speaking at the Northern Virginia Code Camp on May 17th for a total of two topics:
- Improve your C# with Functional Programming and F# concepts
Learn how .NET 3.5 takes ideas from Functional Programming and how you can apply lessons learned from it and F# respectively.
- Introduction to Functional Programming and F#
Come learn about functional programming, an older paradigm that Object Oriented Programming, and the ideas around it. This talk will cover the basics including high-order functions, functions as values, immutability, currying, pattern matching and more. Learn how to mesh ideas from functional programming with imperative programming in F# and .NET.
So, if you're in the DC area, go ahead and register here and show your support for the community.
Also, I will be taking some time to spend up in Philadelphia this month at the next Philly ALT.NET meeting to also talk about F#. Still ironing out the details on that one in regards to the DC ALT.NET meeting in May. Either way, should be a good time!
- Improve your C# with Functional Programming and F# concepts
-
Making Spec# a Priority
During ALT.NET Open Spaces, Seattle, I spent a bit of time with Rustan Leino and Mike Barnett from the Spec# team at Microsoft Research. This was to help introduce Design by Contract (DbC) and Spec# to the ALT.NET audience who may not have seen it before through me or Greg Young. I covered it in detail on my old blog here.
Spec# at ALT.NET Open Spaces, Seattle
As I said before I took a bit of time during Saturday to spend some time with the Spec# guys. I spent much of the morning with them in the IronRuby session explaining dynamic languages versus static ones. They had the session at 11:30, the second session of the day, in direct competition with the Functional Programming talk I had planned with Dustin Campbell. Greg was nice enough to record much of the session on a handheld camera and you can find that here. It's not the best quality, but you can understand most of it, so I'm pretty happy.
The things that were covered in this session were:
- Spec# overview
- Non-null Types
- Preconditions
- Postconditions
- Invariants
- Compile-Time checking versus Runtime checking
- Visual Studio Integration
Scott Hanselman also recorded a session with the Spec# guys for Episode 128. This is a much better interview than on DotNetRocks Episode 237 that Rustan did last year. This actually gets into the technical guts of the matter in a much better way, so go ahead and give it a listen. I was fortunate enough to be in the room at the time to listen.
The New Release
Mike and Rustan recently released a new version of Spec# back on April 11th so now Visual Studio 2008 is supported. You must remember though, this is still using the Spec# compiler that's only C# 2.0 compliant. So, anything using lambdas, extension methods, LINQ or anything like that is not supported. As always, you can find the installs here.
As with before, both the Spec# mode (stripped down mode) and C# mode are supported. What's really interesting is the inferred contracts. From an algorithm that Mike and Rustan worked on, they have the ability to scan a method to determine its preconditions and postconditions. It's not perfect, but to have that kind of Intellisense is really powerful.
What you can see is that the GetEnumerator method ensures that the result is new. Keep in mind, result is a keyword which states what the return value is for a method. It also says that the owner of IEnumerator will be the same as before. Object ownership is one of the more difficult things to comprehend with Spec# but equally powerful.
Another concept that's pretty interesting is the ability to make all reference types non-null by default in C# or in Spec# modes. Instead of having to mark your non-null types with an exclamation mark (!), instead you can mark your nullable types with a question mark (?) much as you would with the System.Nullable<T> generic class. All it takes is the flip of a switch in Spec#:
Or in the C# mode:
And then you have all the Spec# goodness.
Why It's Important
So, why have I been harping on this? To be able to express DbC as part of my method signature is extremely important to me. To be able to express my preconditions (what I require), postconditions (what I ensure), my invariants (what state will change) is a pretty powerful concept. Not to mention, to enforce immutability and method purity is also a pretty strong concept, especially in the times of multi-core processing. More on that subject later.
Focus on Behaviors
What Spec# can bring to the table is the ability to knock out a bit of your unit tests. Now, I don't mean all of them, but what about the ones that check for null values? Are they valid if you already put in your method signature to require a non-null value or use the ! symbol to denote a non-null type? Those edge cases aren't really valid anymore. The ability to track your invariants is the same as well as your postconditions. Instead, what that does is frees you up to consider the behaviors of your code, what you should have been testing anyways.
Immutability
Immutability plays a big part in Spec# as well. To some extent, I'll cover more in a Domain Driven Design post, but instead will get some things out of the way here. Eric Lippert, C# team member, has stated that immutable data structures are the way of the future in C# going forward. Spec# can make that move a bit more painless? How you might ask? Well, the ImmutableAttribute lays out that explicitly. Let's do a simple ReadOnlyDictionary in Spec#, taking full advantage of Spec#'s attributes, preconditions and postconditions:
using System;
using System.Collections;
using System.Collections.Generic;
using Microsoft.Contracts;
namespace Microsoft.Samples
{
[Immutable]
public class ReadOnlyDictionary<TKey, TValue> : ICollection<KeyValuePair<TKey!, TValue>> where TKey : class
{
private readonly IDictionary<TKey!, TValue>! dictionary;
public ReadOnlyDictionary(IDictionary<TKey!, TValue>! dictionary)
{
this.dictionary = dictionary;
}
public TValue this[TKey! key]
{
get
requires ContainsKey(key);
{ return dictionary[key]; }
}
[Pure]
public bool ContainsKey(TKey! key)
{
return dictionary.ContainsKey(key);
}
void ICollection<KeyValuePair<TKey!,TValue>>.Add(KeyValuePair<TKey!, TValue> item)
{
throw new NotImplementedException();
}
void ICollection<KeyValuePair<TKey!,TValue>>.Clear()
{
throw new NotImplementedException();
}
[Pure]
public bool Contains(KeyValuePair<TKey!, TValue> item)
{
return dictionary.Contains(item);
}
[Pure]
public void CopyTo(KeyValuePair<TKey!, TValue>[]! array, int arrayIndex)
requires arrayIndex >=0 && arrayIndex < Count;
{
dictionary.CopyTo(array, arrayIndex);
}
[Pure]
public int Count
{
get
ensures result >= 0;
{ return dictionary.Count; }
}
[Pure]
public bool IsReadOnly
{
get
ensures result == true;
{ return true; }
}
[Pure]
bool ICollection<KeyValuePair<TKey!,TValue>>.Remove(KeyValuePair<TKey!, TValue> item)
{
throw new NotImplementedException();
}
[Pure]
public IEnumerator<KeyValuePair<TKey!, TValue>>! GetEnumerator()
{
return dictionary.GetEnumerator();
}
[Pure]
IEnumerator! System.Collections.IEnumerable.GetEnumerator()
{
return dictionary.GetEnumerator();
}
}
}
As you can see, I marked the class itself as immutable. But as well, I removed anything that might change the state of our dictionary, as well as mark things with non-null values. That's a little extra on top, but still very readable. I'll be covering more in the near future as it applies to Domain Driven Design.
Call to Action
So, the call to action is clear, make Spec# a priority to get it in C# going forward. Greg Young has started the campaign, so we need to get it moving!
-
let Matt = CodeBetter + 1
Joining the CodeBetter Community....
#light
type FullName = string * string
let FullNameToString (name : FullName) =
let first, last = name in
first + " " + last
let blogger = FullNameToString("Matthew", "Podwysocki")
I'm pretty excited to be joining the CodeBetter gang after following for so many years. I want to thank Jeremy Miller, Brendan Tompkins, Dave Laribee, Greg Young and others for welcoming me to the fold. No, this blog won't be going away, but instead will also serve as a host for my posts.
So Who Are You and Why Are You Here?
So, just to introduce myself, I work for Microsoft in the Washington DC area. I'm active in the developer community in whether it be in the .NET space, Ruby, or less mainstream languages (F#, Haskell, OCaml, Lisp, etc). I also run the DC ALT.NET group since the November timeframe of last year and helped plan the latest incarnation in Seattle.
The number one reason I'm here is to help better myself. Deep down, I'm a language geek with any of the aforementioned languages. I'm one of those who strives to learn a language every year, but not just learn it, let it sink in. That's really the key. Sure, I can learn a certain dialect, but it's not quite being a native speaker. That's how I can take those practices back to my other languages to try to apply lessons learned such as functional programming paradigms (pattern matching, currying, first order functions, etc).
I also have a pretty deep interest in TDD/BDD, Domain Driven Design and of course one of Greg Young's topics, messaging. Right now in the world of messaging, I think we're in a pretty important time in the development world when messaging, multi-threaded processing and such is going to be more mainstream and hopefully less hard than it is now.
I'm also a tinkerer at heart. I'm looking at testing frameworks to help make my TDD experiences easier. I'm looking at IoC containers to help make my system just a bit more configurable. I'll look at the tests to see how each one does what it is. That's the fun part about it.
I'm also on the fringe with such topics as Spec# and Design by Contract. I'd love nothing more than to see many of the things being done at Microsoft Research become a bit more mainstream and not just seen as a place where we might see something 10 years down the line. Topics such as Spec#, F# and others have real importance now and it's best to play with them, give them our feedback and such.
So What Do You Want From Me?
Here's the thing, since I'm always looking to better myself, I'll need your help along the way. I value your feedback along the way and hopefully we'll learn from each other. Now that this is out of the way, time for more serious topics...
-
xUnit.net Goes 1.0 and Unit Testing F#
As I've said before on my previous blogs, I'm very much into F# and functional programming lately. With that, I'm still in the mode of TDD. Just because you enter a new programming paradigm, doesn't mean you throw away your XP and TDD roots. Instead, I find it just as valuable if not even more so when switching to a new model.
xUnit.net 1.0 Goes Live
As Brad Wilson said earlier this week, xUnit.net released version 1.0. You can read more about the announcement here. Since the RC3 timeframe, it was pretty much feature complete, so there hasn't been much change since that time. Instead, the focus was on polishing the existing functionality and including the integration with ASP.NET MVC, Resharper 3.1 and TestDriven.NET. The GUI runner, such as it is has been pretty limited, but ok for most purposes.
Many questions used to arise, why xUnit.net? Why do we need yet another framework out there? Why not just add onto the existing ones in the market? I think with the 1.0 release, the critics in this release to do things a bit differently than MbUnit and NUnit have approached things. For example, the Assert.Throws<TException>, not having to decorate the classes with [TestFixture] and a few other things come to mind as well as being very extensible. It's a smaller framework, but I really don't have a problem with that. With most of the other frameworks, I don't use half of it anyways.
So, why do I care as much as I do about this one over say others at the moment? Well, it's great that we have such choices in the market now. As Scott Hanselman said at ALT.NET Open Spaces, Seattle, he's a StructureMap, Moq and xUnit.net guy. I'll get into the reason shortly enough.
The Traditional Way
When you think of doing your unit or behavior tests, you often need a class and decorate with attributes, have a initialize and teardown and all that goodness. Since F# is considered a multi-purpose language, this works just fine. That's the beauty of F# and hopefully will drive its adoption into the marketplace. So, consider the following functions with the appropriate tests in a more traditional way such as NUnit within Gallio. I am trying out Gallio so that I can see how well it reacts to F# as well as just kicking the tires. I highly recommend you at least check it out.
Anyhow, back to the code. Let's take a simple example of a naive routing table through pattern matching, to see whether a call is allowed or not. Like I said, naive, but proves a point with pattern matching.
#light
#R @"D:\Program Files\Gallio\bin\NUnit\nunit.core.dll"
#R @"D:\Program Files\Gallio\bin\NUnit\nunit.framework.dll"
let FilterCall protocol port =
match(protocol, port) with
| "tcp", _ when port = 21 || port = 23 || port = 25 -> true
| "http", _ when port = 80 || port = 8080 -> true
| "https", 443 -> true
| _ -> false
open NUnit.Framework
[<TestFixture>]
type PatternMatchingFixture = class
[<Test>]
member x.FilterCall_HttpWithPort8888_ShouldReturnFalse() =
Assert.IsFalse(FilterCall "http" 8888)
[<Test>]
member x.FilterCall_TcpWithPort23_ShouldReturnTruee() =
Assert.IsTrue(FilterCall "tcp" 23)
end
Unfortunately of course for me, the Gallio Icarus Runner doesn't really work well for me at the moment with F# integration. Instead, I get all sorts of issues when doing so. This is where I get the large FAIL.
This seems to repeat itself unfortunately for the xUnit.net and MbUnit integration as well, so it's not quite ready for primetime in the F# space. Also, when I exit the application, there is a Gallio session runner that keeps running in memory and therefore I can't perform any builds. So, I have to manually go into Task Manager and kill the process. Not the best experience I've ever had... So, for now, the limited functionality in the xUnit.net GUI Runner works for me.
The More Functional Way
Instead, we see a lot of pomp and circumstance that we just don't need. In the functional world, a lot of the time, we don't want or need to create these classes just to test our functions. After all, most of what we do has no side effects or at least should be (and are code smells mostly if they are not, but that's another post for another time).
At the request of Harry Pierson, another F# aficionado and IronPython PM, talked to Brad and Jim Newkirk about adding static function unit test capabilities to xUnit.net. And sure enough, we now have them, so let's compress the above code into something that looks more like F#.
#light
#R @"D:\Tools\xunit-1.0\xunit.dll"
open Xunit
let FilterCall protocol port =
match(protocol, port) with
| "tcp", _ when port = 21 || port = 23 || port = 25 -> true
| "http", _ when port = 80 || port = 8080 -> true
| "https", 443 -> true
| _ -> false
[<Fact>]
let FilterCall_TcpWithPort23_ShouldReturnTrue () =
Assert.True(FilterCall "tcp" 23)
[<Fact>]
let FilterCall_HttpWithPort8888_ShouldReturnFalse () =
Assert.False(FilterCall "http" 8888)
So, as you can see, I compressed the code quite a bit from here. Since I'm doing functions and nothing more with just some basic pattern matching, this approach works perfectly. That's why I am a fan of this. Open up the GUI runner or just the ever popular console runner, and run it through and sure enough, we get some positive results.
The interesting thing to see upcoming is how well the TDD space will play in the functional programming space. I don't think it should be any different of an experience, but time will tell.
Where to Go?
From here, where do we go? Well, I'm sure the GUI Runner of xUnit.net will get better over time, but the Gallio folks are pushing for the Icarus Runner. Right now, only the xUnit.net runner works for me, so that's what I'm going to stick with at the moment.
An interesting thought occurred to me though. Are the unit tests we're doing mostly nowadays purely functional anyways? Would it make sense to test some C# code in F# to produce cleaner code? Not sure, but I like the idea of having that choice. Or even for that matter, writing my unit tests in Ruby for my staticly typed C# code. Within the .NET framework space, the possibilities are vast. And that's the really cool thing about it. But will we see an IronPython or IronRuby testing framework within the .NET space?
-
ALT.NET Open Spaces Closing Day Recap
In my previous post, I talked about some of the happenings from the day two experience. Day three was only a half day with only two sessions. So, it was best to make the best of times anyhow. Once again, it snowed again, rather heavily at times, so nature's cruel joke on ALT.NET.
Impromptu Sessions
One of the best sessions was an impromptu session with Jeremy Miller on the StoryTeller tool and his future plans for it. If you're not familiar with it, it is a tool used to manage and create automated testing over the FitNesse Dot Net libraries and helps in an acceptance test driven development environment. Anyhow, a number of us managed to corner him at one point during the day and sure enough he had his laptop available. From there, we were able to encourage him to work on it some more as well as learn about where to go from where it is right now. Jeremy covers more about it here. Sometimes these impromtu sessions are some of the more valuable interactions to be had at events such as these.
More Video To Be Had
It seems that almost everyone had a camera at the event. Greg Young and Dave Laribee managed to capture a bit of the sessions on video. That's a great thing because I honestly wish I could have cloned myself and gone to more sessions. Hopefully more of this will be forthcoming. Dave posted Greg Young's fishbowl conversation on Architecture Futures which you can see here.
Other videos that are on this list are from John Lam's IronRuby session, Udi Dahan with ScottGu and Chad Myers talking about Microsoft and Open Source Software and so on. You can find them at the end of Greg's video.
Software Design Has Failed, What Can We Do About It?
Scott Koon, aka LazyCoder, convened with JP Boodhoo a session on how software design has failed us. This turned into a fishbowl conversation as well since there was a lot to be said. The basic points revolved around the large amount of software failures. What causes them? Are they technological issues? People issues? Politics? Many people brought their opinions to bear, and it was interesting that the point that I brought is that at the end of the day, customer satisfaction is the metric that matters. Are we listening to them? In the Agile methodology world, customer satisfaction is the only metric. Yes, we can talk about TDD/BDD, DDD and so on, but are we actually putting software into the hands of the user that they actually want?
I'm not forgetting of course the ideals around mentoring and helping make the team stronger. Those issues are important as well. Do we do pair programming? Do we hold brown bag sessions? All of those suggestions are key to helping grow a stronger team. But, also it helps grow the team as a more cohesive unit that's not afraid to ask questions, pair up and avoid flailing.
F# and Concurrency
Roy Osherove convened a session on concurrency and functional programming as the last topic I was going to attend. When we start to deal with multi-core environments, threading issues come to bear more frequently. Are we utilizing the CPUs to the maximum or are we still just sitting on that one thread, and barely using the machine to its capacity? Those are many of the issues we face. In Software Engineering Radio Episode 14, Ted Neward talks to this very point quite frankly that multi-threaded programming is hard. There are no two ways about it. But, when we talk about functional programming, some of that is solved. Why? Immutability by default is one of the key strong points of FP. Instead, you have to go out of your way to make a value to be mutable. Is this something we'll see in C# 4.0? Spec# has something to say about it. And once again, another topic for discussion. I keep putting these things on my plate...
Anyhow, Harry Pierson and I helped run this session. Harry had some of his parsing code that he has posted on his blog to show off. I think that did the trick well to show some advanced things such as high order functions, pattern matching, anonymous functions and so on. Instead, if you wish to learn more, I'll probably cover it here in some detail, but you can check chapter 13 of Don Syme's "Expert F#" book to learn more in the mean time.
Action Items
Some action items came up from this event that I think are rather important. Because ALT.NET is a community looking to improve itself, there are naturally some things that help. Here are a few that I can think of:
- Keep the conversation going
Just because the conference ended doesn't mean the conversations that started there have to.
- Start a local group
After the session was done, the altdotnet mailing list came alive with people wanting to create that ALT.NET groups like I did in DC, Brian Donahue did in Philly and Jeremy Jarrell did in Pittsburgh.
- Support the community
Ray Houston laid out a challenge for those who use Open Source products to donate to them. This doesn't mean only money, but time as well. Many projects are in need of some assistance, and all it takes is for someone to ask.
- Challenge Assumptions and Bring Change
It was said best during the conference "If you can't change your job, change your job". Don't let these discussions that happened here just stay there. Bring them to your work place, bring change for the better. Question why things are done the way they are.
Wrapping it Up
I'm glad to have been a part of this event in Seattle. It couldn't have been with a better bunch of people who are willing to better themselves, challenge themselves and their assumptions and bring change to the developer community. There was a lot to learn this past weekend and each conversation brought up a new angle. Until next time...
- Keep the conversation going
-
ALT.NET Open Spaces, Seattle Day 2 Recap
In my previous installment of recapping the events from ALT.NET Open Spaces, Seattle, I covered pretty much the opening ceremonies as it were. The weather was definitely interesting the entire weekend. Who would believe that we had snow, hail and rain for most of the time we were there in the latter half of April? Mind you it didn't stick, but if you believe in God, there is something to be said of ALT.NET coming to town.
Coverage Galore
Jeffrey Palermo was gracious enough to capture the opening ceremonies on video for all to see. Here are some of the videos and they are well worth watching. Really gives you an idea of how to run a good Open Spaces. Doc did a wonderful job as a facilitator for the event. And yes, that's me in the black coat in the background setting up for the event.
- ALT.NET Open Spaces, Seattle - Part 1
An introduction by Doc on the meaning of Open Spaces
- ALT.NET Open Spaces, Seattle - Part 2
More introduction and the suggestion of topics. Everyone who submitted topics had to get in the middle of the room and declare their topic of interest.
- ALT.NET Attendees - Why Did You Come to ALT.NET?
Jeffrey interviews various attendees such as the some Microsofties (Scott Guthrie, Harry Pierson, Glenn Block, Don Smith), CodeBetter guys (Greg, Jeremy, JP Boodhoo, Ian Cooper), Scott Bellware, the Israelis (Udi, Roy, Justin and Ayende), Martin Fowler, John Osborn, Jim Shore, etc on what ALT.NET means to them and why they came.
So, as you can see from the videos it was a pretty diverse crowd. And, hey, we managed to get all of 5 women there too! Peter Laudati posted the schedule here which was initialed by all who wanted to see that particular discussion.
IronRuby Session
Since John Lam wasn't around on Friday for the topic submittal, I so graciously put his name in for him. Luckily he agreed so we were good to go for the first session. We didn't have any canned presentations which is nice. Instead, John focused more on how far IronRuby has yet to go. It was interesting that he is using the Rubinius specs in order to validate IronRuby. Also of note, it was pretty cool to see that Spec# has been used for the IronRuby compiler.
Covering Spec#
Unfortunately, the functional programming talk that I planned with Dustin Campbell was put right along side the Spec# talk, so I had to make a choice. I picked Spec# as it was the first Open Spaces they had done. As I said before, one of the major things I wanted to talk about was Spec# at ALT.NET. Both Greg Young and I were pretty interested in getting Rustan Leino and Mike Barnett to show off the technology to the masses. And what better way than to show a bunch of geeks like us this technology. Anyhow, Mike and Rustan did a really good presentation to show off Spec# to a mass audience. For those not familiar with Spec#, I did a whole series on this on my old blog here. Basically, the intent of Spec# is to provide Design by Contract specifications in your classes and have that exposed to the outside world. So, no more guessing about the preconditions, postconditions and invariants of your system, instead, we can be pretty explicit about it.
The problem that they are facing is that Spec# is not just an additive to the C# compiler, instead it's a separate compiler that is compliant with the C# 2.0 specification. The problem is that C# 3.0 introduces a few more items, albeit mostly syntactic sugar for the most part, and yet Mike is really one of the only guys doing the Spec# compiler. So, making it C# 3.0 compliant is a pretty daunting task. Instead, a future focus is on making language neutral pieces available to all .NET languages just as we saw briefly in the System.Core.dll assembly under the Microsoft.Contracts namespace. The point of inviting them was to help bring their cause to a wider audience. Anders Hejlsberg and Mads Torgersen need to put this on their mind as to how to incorporate, and I'll make sure it's widely known.
It was great to see Scott Hanselman quite excited about the technology and hopefully you'll see more of it from him soon. Also, stay tuned to InfoQ for more Spec# related items as well. I intend to cover things again shortly to talk about some other new things in Spec# as well as the new release. Stay tuned for that...
ASP.NET MVC
Phil Haack and Brad Abrams hosted a discussion on ASP.NET MVC which was pretty positive overall. There has been a number, around 5% that Microsoft has been throwing out there as a number of people that would be adopting ASP.NET MVC over traditional web forms. The audience was rightly skeptical of such a number and wish that they would cut it out. Instead, it could have the effect of scaring away people from adopting this framework as their choice for ASP.NET web applications. I can totally understand that the numbers could be there due to the ISV market which make controls for ASP.NET web forms which is something that the MVC framework doesn't support. Another request was to support open source javascript frameworks better. But overall, Phil and Brad were pretty receptive and it was an overall positive experience.
Are We Innovating?
Scott Hanselman convened a talk asking "Are We Innovating or Are We Just Porting?" in which that very question was asked. If you look at the open source frameworks that exist within the .NET space, it's not hard to see what he's talking about:
- JUnit => NUnit, MbUnit, xUnit.net
- Hibernate => NHibernate
- Spring => Spring.NET
- Ruby on Rails => MonoRail
- jMock => NMock, Rhino Mocks, Moq
- Ant => NAnt, MSBuild
- And the list goes on...
To Be Continued...
- ALT.NET Open Spaces, Seattle - Part 1
-
DC ALT.NET Meeting 4/23/2008 - Jay Flowers and CI Factory
Now that we've somewhat recovered from ALT.NET Open Spaces, Seattle, it's time for another DC ALT.NET meeting. I'm currently finishing up my wrapups for Seattle still and I'm sure I have months worth of material from there. Anyhow, this time Jay Flowers will be talking to us about Continuous Integration and CI Factory which was postponed from last month due to schedule conflicts. As always we have the first hour or whenever the conversation ends for our main topic and the rest is Open Spaces. Food will be served as well.
Below are the details for the meeting:
Time:
4/23/2008 - 7PM-9PM
Location:
2201 Wilson Blvd
Arlington, VA 22201
Parking/Metro:
Best parking on N. Veitch St
Courthouse Metro the best bet
As always you can find out more by joining the mailing list here. Hope to see a great crowd there and to continue some of the great discussions that were held in Seattle. Until next time...
-
ALT.NET Open Spaces, Seattle Day 1 Recap
ALT.NET Open Spaces, Seattle has come to a close. What a great time it was and it met every expectation if not exceeded them. Currently I'm in the Seattle airport waiting for my flight home which just got re-arranged. Anyhow, I'd like to wrap up my thoughts for the first day of the event.
Setting It Up
I arrived one day early for the event to make sure we were set up appropriately. I was able to meet up with Dave Laribee, Glenn Block, Scott Bellware, Jeremy Miller, Greg Young, Scott C Reynolds, Ray Lewallen, Patrick Smacchia and others. Everyone was already burned out from the MVP Summit, so I wasn't sure how well people would be for the event. But it was great to talk to Sam Gentile and I'm glad he's back in the fold with ALT.NET as he announced earlier last week here.
Even though a lot of people were tired, we had plenty of help to set up for the event. Of course the joke is that "How many ALT.NETers does it take to go to Costco?"...
Kicking It Off
One couldn't ask for a more prepared and outstanding facilitator in Steven "Doc" List. What an amazing job he did to bring the Open Spaces together. The event started with a description of Open Spaces Technology. if you're not familiar with the Open Spaces, Technology Format, here are the four basic principles:
- Whoever comes are the right people
- Whatever happens is the only thing that could have
- Whenever it starts is the right time
- When it's over, it's over
The Sessions
I met with Mike Barnett from the Spec# team who was one of the many people I had invited to this event. Spec# as you may have figured from my blog is a passion of mine. It is one of my goals to publicize it enough and to make sure that people are aware of this wonderful technology that the product teams such as Mads Torgersen and Anders Hejlsberg notice. Anyhow, Mike went up and announced a session on Spec# and static verification. I'll cover more of that in subsequent posts again. Start your letter writing campaigns now!
Dustin Campbell also was in attendance and he and I chatted about F# and doing a session on functional programming and F#. It was going to be a great session, but unfortunately when the schedule was finalized, I couldn't possibly attend the Spec# and functional programming and F# talk. I was a little disappointed by that, but luckily Roy Osherove suggested a talk about "Concurrency and Functional Programming" which I was more than willing and able to help out on. I also pulled Harry Pierson, the new Program Manager for IronPython to help in such a session.
Since John Lam wasn't in attendance that night, I volunteered him for a session on IronRuby and the DLR which he was more than happy to oblige. We scheduled that for the first session on Saturday. I'll cover each of these in detail in subsequent posts.
The Fishbowl
From there, we went to a fishbowl style conversation in which there are a number of chairs in the middle of the room. There must be all but one of the chairs filled at any given time. Any person may in turn come and take a seat and another person must leave to keep the balance. The discussion started with Scott Hanselman, Ted Neward, Charlie Calvert and Martin Fowler talking about the Polyglot Programmer. Ted Neward couldn't be there for the whole event, unfortunately as he was also doing No Fluff Just Stuff this weekend as well with Venkat Subramaniam, Neal Ford and others. Luckily I got some time to talk to Ted about some F# related items as well as his upcoming trip to Reston, VA for No Fluff Just Stuff next weekend. So, if you're in the area and interested in seeing Ted and Venkat, that's the place to go! But anyways, the event was great and a lot of people pitched in. There are so many to name, I'd just run out of space.
To Be Continued....
-
Off to Seattle and ALT.NET Open Spaces, Seattle
Well, the day has finally come where I'm heading to ALT.NET Open Spaces, Seattle. It's been a long time of planning for this day with all the other guys mentioned on the site. The weather's not looking so great with a possibility of snow on Saturday. Not looking forward to that part as I'm leaving sunny, beautiful Washington DC where it is around 75F or so right now.
I hope to be live blogging much of the event, well as much as I can. I you're on Twitter, you can follow me at mattpodwysocki. Looking forward to seeing everyone there!
-
NOVARUG with Dave Thomas (PragDave) Recap
Last night I attended the Northern Virginia Ruby Users Group (NovaRUG) meeting in Reston last night with Dave Thomas (PragDave) and Chad Fowler. It was a completely packed house and the temperatures were a bit hight in the room, but it was well worth the sweating to attend.
Paul Barry presented first on Merb and gave a really good demonstration of some of the capabilities in comparison to Ruby on Rails. If you're not familiar with Merb, it is a lightweight Model View Controller framework written in Ruby. It was written by Ezra Zygmuntowicz in response to trying and giving up on making Ruby on Rails thread safe. You can find his presentation materials here.
It was mentioned that there will be a Ruby conference in the Northern Virginia area upcoming I'd like to see if we can get some IronRuby in there instead of all those Java guys with JRuby. We'll see what happens, but for right now, everything seems to be in flux. Stay tuned!
Next up, Dave Thomas talked about the Ruby object model with a very good presentation. Below you can find some of my pictures I took from the event. Forgive the quality of the images, but you can tell that it was a crowded place! Anyhow, it was a really good talk about the object model, how the scoping of self and the resolution of classes and methods are done deep down in Ruby. It was an excellent presentation and I was definitely excited by his passion for the community and the technology.
First we have Dave talking about the inheritance chain of Ruby objects.
Then here's Dave talking about the method resolution.
I had a chance to chat with Dave afterwards on F# as he has been looking into OCaml lately, where F# got most of its functionality from. It's his hope that F# succeeds and I ultimately think it will. So, I told him to give it a try. Anyhow, it was a great night and good to reach out to the community. The DC area has a pretty rich community of .NET, Ruby and Java programmers that's really refreshing to see. Until next time...
-
Metaprogramming in F#
Tonight I will be heading to the Northern Virginia Ruby Users Group (NoVARUG) meeting tonight with Dave Thomas (PragDave) talking about metaprogramming in Ruby. Should be a great time and I'm sure it will be full tonight. For those interested in some introduction to metaprogramming in Ruby, here's a good link to help get you started.
Metaprogramming in F#?
One of the many things that has interested me in F# is that it was originally written as a language to write other languages. This of course leads me to a discussion of F# and metaprogramming. Is it a fit? There are a couple of links well worth visiting and then at a future date, we'll come back to the subject.
Before the links, most of the language oriented stuff comes from quotations. Quotations are a little block of code which turns a particular piece of code into an expression tree. This language tree can then be transformed, optimized and even compiled into different languages. There are two types of these quotations, raw and typed. Typed Quotations contain static typing information whereas the raw do not. For a good introduction to these, check out Tomas Petricek's post here.
- Leveraging Meta-Programming Components with F# - Don Syme
Talks about F# with Quotations and LINQ expressions for expressing metaprogramming in F#
- F# metaprogramming and classes - Tomas Petricek
Talks about Class Quotations and basic metaprogramming capabilities in F# and its limitations
- Leveraging Meta-Programming Components with F# - Don Syme
-
Adventures in F# - F# 101 Part 8 (Mutables and Reference Cells)
class Program
-
ALT.NET on DotNetRocks and the Community
Dave Laribee and Jeremy Miller recently recorded an episode on DotNetRocks and was just posted today. Episode 333 "It's the ALT.NET Show" can be found here. It's a great show that explains ALT.NET for those who may not really know what it is outside of some of the arguments on the altdotnet mailing list. This includes discussions on open source frameworks, agile practices, refactoring and so on.
It's great to see the reaction from this show at least from my perspective. To see the job we're doing from Josh Holmes, Glenn Block, me and others from within to reach out and also present ideas and bridge the gaps. It's been very rewarding to be a part of that.
We're only just a few days away from ALT.NET Open Spaces, Seattle. All of those who are attending should have received a notice of such this morning. I'll be arriving in Seattle on Thursday afternoon to help set up for the event so if anyone wants to hang out beforehand let me know.
Bringing It To The Community
Anyhow, this weekend I did my best to bring some of those ALT.NET practices to the CMAP Code Camp and we had a pretty good turnout. This time I talked about refactoring to patterns, dependency injection and inversion of control containers. I'm hoping to do the same for the Northern Virginia Code Camp coming up on May 17th. Brian Donahue has been rather successful doing so with the Philly Code Camps as well. That reminds me that I'm coming up there in mid-May to do an F# session. Should be a fun time.
-
CMAP Code Camp Wrap Up - Dependency Injection and IoC Containers
I really enjoyed speaking at this past weekend's CMAP Code Camp. I hope you all enjoyed my presentation on "Loosen Your Dependencies with Dependency Injection and Inversion of Control Containers". It was a great discussion to have with everyone and I like to learn there as much as I teach.
I also enjoyed teaming up with Scott Allen on his "A Gentle Introduction to Mocking" where we talked about mocks versus stubs, test pattens and mock frameworks such as Rhino Mocks and Moq. Hopefully we'll be doing some more ping-pong sessions in the future.
Once again, I'd like to plug my DC ALT.NET group that I run. Our next meeting is scheduled for April 23rd and the topic will be Continuous Integration with Jay Flowers. We'll announce the location shortly for our group. You can go ahead and sign up for our mailing list here.
Anyhow, here are some resources that can help point you in the right direction. This includes articles, blogs and such that I find will be useful in your journey to better understand these things:
- Articles
- Blogs
- Books
If you note, I my code uses the following products in order to get it to run:
- ASP.NET MVC Preview 2
- xUnit.net
- Castle Windsor
- StructureMap
- Unity Application Block
- Unity Community Contributions
-
Unity Community Contributions and Interception
public delegate IMethodReturn InovkeHandlerDelegate(IMethodInvocation call,
GetNextHandlerDelegate getNext);
public delegate InovkeHandlerDelegate GetNextHandlerDelegate();
public interface IInterceptionHandler
{
IMethodReturn Invoke(IMethodInvocation call,
GetNextHandlerDelegate getNext);
}
}
-
xUnit.net RC3 Just Released
Well, Brad Wilson and Jim Newkirk must really be busy lately. After I talked about the release of xUnit.net RC2, just today, Brad announced the release of RC3. As always, you can find the latest bits here. This fixes a number of bugs and adds CruiseControl.NET and ASP.NET MVC Preview 2 support as well in addition to the Resharper 3.1 and TestDriven.NET support. For more information about it, check out Brad's post here. More or less, they are feature complete for version 1.0 and the only that I think really is needed at this point is a decent GUI runner and that's well acknowledged as something they are working on. Visual Studio integration would be nice as well...
If you were in attendance at last night's RockNUG appearance, all tests for my demos were using xUnit.net, so I am actively using it right now and will be for my CMAP Code Camp appearance this weekend. However, I did not show the GUI runner because, well, it's not there yet, and instead, the console runner works just fine, thank you. So, go ahead and pick up the latest bits and give the team feedback!
For my other posts in this series, check them out here:
One last note regarding Brad, he was recently interviewed by Scott Swigart and Sean Campbell over at How Software Is Built and gives some interesting insights in the open source world inside and outside Microsoft and his contributions to it. Very good interview and well worth the time to read.
-
RockNUG IoC Container Presentation Wrapup
I want to thank the fine folks at the Rockville .NET Users Group (RockNUG) and Dean Fiala for giving me the opportunity to speak last night. It was a record crowd last night, so I'm glad that people were interested in Loose Coupling, Design Patterns, Test Driven Development, Behavior Driven Development and Inversion of Control containers. I hope everyone got some good information, and if not interested in using containers, design patterns and such, at least know they exist and have their use. Based on the feedback I've already received, it was warming and why I like presenting at user groups, so that both of us can learn.
Once again, I'd like to plug my DC ALT.NET group that I run. Our next meeting is scheduled for April 23rd and the topic will be Continuous Integration with Jay Flowers. We'll announce the location shortly for our group. You can go ahead and sign up for our mailing list here.
Anyhow, here are some resources that can help point you in the right direction. This includes articles, blogs and such that I find will be useful in your journey to better understand these things:
- Articles
- Blogs
- Books
-
NoVARUG Meeting April 16th - Dave Thomas (PragDave)
The Northern Virginia Ruby Users Group (NoVARUG) will be holding their next meeting next week with a special speaker in Dave Thomas (PragDave). Dave is in town teaching Advanced Rails Studio in Reston and will be kind enough to come talk about the Ruby Object model and how it facilitates metaprogramming.
The details are as follows:
Subject:
Dave Thomas - The Ruby Object Model and Metaprogramming
Date:
April 16th, 2008 - 7-9PM
Location:
FGM Inc
12021 Sunset Hills Road
Suite 400
Reston, VA 20190
Hope to see a good crowd there! I know I'm very interested in this subject and hope to dive deeper soon. That reminds me I need to do some of metaprogramming in F# as well.
-
Unity 1.0 Released into the Wild
As Chris Tavares mentioned in his blog, Unity 1.0 has been released a couple of days earlier than the April 7th release date mentioned by Grigori Melnik earlier. Scott Densmore also announced this as well as working on porting the inteception from ObjectBuilder2 which I talked about earlier in some of my Unity and IoC containers posts. Looking forward to that post as we've shared some emails on the subject.
Would You Like To Know More?
For those looking for my posts on the matter, I've covered it quite extensively with the comparison to other IoC containers as well as IoC containers in general:
- IoC and Unity - Configuration Changes for the Better
Covers the latest configuration changes to allow for better constructor injection
- IoC and Unity - The Basics and Inteception
Covers the basics of an IoC container and inteception techniques
- IoC Container, Unity and Breaking Changes Galore
Covers the breaking changes made from the old Unity drop to the new one
- IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
Managing instances and parameter mapping resolution
- IoC and the Unity Application Block Once Again
Setter Injection versus Constructor Injection and PostSharp4Unity
- IoC and the Unity Application Block - Going Deeper
Constructor Injection and comparing Unity with Castle Windsor
- IoC and the Unity Application Block
Covering ObjectBuilder and Unity Application Block
Anyhow, if interesting in more Unity content, check out David Hayden's Unity IoC and MVC screencast as well as others on the subject here.
Speaking of which, I'm going to be a busy man indeed with my upcoming speaking schedule on IoC containers, not necessarily Unity in particular, but all of them, the background and decoupling your applications. Here is the complete schedule for this month:
- RockNUG - April 9th
- CMAP Code Camp - April 12th
- CMAP Architecture SIG - April 15th
- IoC and Unity - Configuration Changes for the Better
-
Relooking at xUnit.net RC2
using MVC_APPLICATION_NAMESPACE.Controllers; // This using directive needs to point to the namespace of your MVC project
-
Adventures in F# - F# 101 Part 7 (Creating Types)
#light
let coin = "heads", "tails"
let c1, _ = coin
let _, c2 = coin
print_string c1
print_string c2 -
Covering NUnit 2.4.7
#light
#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.core.dll"
#R @"D:\Program Files\NUnit 2.4.7\bin\nunit.framework.dll"
open NUnit.Framework
let rec fib n =
match n with
| 0 | 1 -> 0
| n -> fib(n-2) + fib(n-1)
| n when n < 0 -> failwith "Cannot be less than zero"
[<TestFixture>]
let FibOfOneShouldReturnZero() =
let fibResult = fib(1)
Assert.AreEqual(fibResult, 0)
-
xUnit.net RC2 Released
public class DatabaseFixture : IDisposable
-
Understanding AOP in .NET
In my previous posts I have talked a bit about Inversion of Control (IoC) containers with respect to Interception and Aspect Oriented Programming (AOP). It's not only important to understand the uses and strategies for implementing your solutions using it, but also how interception and AOP works deep down in .NET. Instead of a long, drawn out post, I think I'll just include some articles and posts that do a very good job of explaining some of the ideas behind it.
Articles and Posts
I think it'd be good if we just start out with some basic MSDN articles and such regarding AOP and interception. Some of them may be older but the concepts will still apply to this day:
- 7 Approaches for AOP in .NET
Ayende covers a few ways of doing AOP in .NET using existing frameworks
- Decouple Components by Injecting Custom Services into Your Object's Interception Chain
Juval Lowy, in the March 2003 MSDN magazine, writes about using contexts for an object's execution scope and intercepting calls to and from that object.
- Aspect Oriented Programming (September 2005 Technical article)
Matthew Deiters describes aspect oriented programming and covers joinpoints, pointcuts, advice and mixins with regards to a simple example using VB.NET.
- AOP: Apsect Oriented Programming Enables Better Code Encapsulation and Reuse
Dharma Shukla, Simon Fell and Chris Sells write in the March 2002 MSDN Magazine with regards to the history to COM and AOP and then relate how it works in .NET. Rather dated article but the foundations still apply.
- AOP using System.Reflection.Emit
Roberto Loreto writes on CodeProject how to intercept method calls of an external type and generating method proxies by using Intermediate Language (IL) injection.
Just Read the Code
There are many AOP frameworks out there in the wild right now for .NET. To understand them pretty well, it's best if you just crack open the code and follow the unit tests. Most of these are no longer active. Let's cover some of the AOP frameworks out there:
- PostSharp
- NKalore (No longer active)
- Gripper LOOM.NET
- Rapier LOOM.NET
- AOP.NET (No longer active)
- Aspect# (No longer active)
- AspectDNG
Conclusion
For those willing and able to go ahead and learn about AOP, it's actually quite interesting. it's also quite a challenge especially when dealing with IL emitting. Go ahead and look at the source code and samples and give some of it a try. Next time we pick up, I'll be talking about AOP in the Enterprise and Spring.NET. Until next time...
- 7 Approaches for AOP in .NET
-
IoC and Unity - Configuration Changes for the Better
namespace UnitySamples
-
FringeDC March 2008 Video Now Online - Haskell and XMonad Extensibility
As I've discussed before with my dive into functional programming and F#, there is a user group of language geeks that specialize in Haskell, Lisp, Scheme, OCaml, Erlang and so on, within the Washington DC area called FringeDC. Brent Yorgey, well known in the Haskell community and contributor to XMonad, presented an introduction to Haskell and explained a bit about extending XMonad. Fortunately for those who couldn't attend like myself due to scheduling conflicts, Conrad Barski recorded this session and posted it to Google Video. The slides have also been made available as well here. For those not aware of XMonad, it's a tiling window manager for X that is extensible in Haskell. Unfortunately, the opening talk by Philip Fominykh on The Zipper, a purely functional data structure in Haskell for manipulating the location of structure instead of the data, was not recorded.
If you want to get your language geek on, come check it out for their next informal meeting on May 10th over a beer or two. More details on the site here. Until next time...
-
IoC and Unity - The Basics and Interception
namespace UnitySamples
-
ALT.NET Thinking From The Outside
As I've noted before, Dave Laribee was recently interviewed by Scott Hanselman on Episode 104 of Hanselminutes. The reaction that I've seen has been pretty positive from what I've seen. It's great to see the ALT.NET message being spread outside the core believers group. Many people can be turned off after a few discussions on the altdotnet mailing list and not get the real gist of what the group is about.
Dave did a great job explaining the core principles of ALT.NET which are:
- Use the right tool for the right job
- Look outside the .NET community for new and different ways of solving problems
- Get involved with the community through teaching and teaching
- A good emphasis on agile methodologies
- Design patterns and principles
But, how do we convey that message to the development community as a whole. That was a part of the conversation that was interesting. And to me, I think we should have that "street kit" which includes such bare essentials as a manifesto (that we'll probably get to in Seattle), frameworks, design patterns, ways of spreading the message, etc.
Christopher Bennage had a good wrapup of the show as well here. I'd tend to agree that ALT.NET isn't about convincing, it's about conversing, having that conversation about what pains them and working through on a solution. It's about spreading the community. But, a direct command to learn Ruby, meh... I think Scala has a few more things to offer right now which is why I'm chomping at the bit to get to more of it.
A post by Leon on community though caught my eye recently. What he says is pretty accurate. I tend to think that what ALT.NET is preaching is what many communities such as the Ruby on Rails and Java communities have been doing for years with regards to design patterns, TDD and so on. A lot of the innovation such as TDD frameworks, design patterns and such just hasn't come from the .NET community. Many people wait on Microsoft to provide these things such as TDD frameworks (MSTest), Logging (Enterprise Library), O/RM (Entity Framework) and won't pay attention to the OSS world which I find an utter shame. Instead, what I'd like people to do is take those frameworks and look what's available from the community as a whole and compare them, much as I have with Unity and some other IoC containers. Yes, many people worry about licensing issues and that's something for your legal team to work out.
But, to his point, I'm glad he's learned Ruby on Rails and is happy. In fact, I think it's great that he is expanding his horizons outside of C# which I think most developers ought to know a few languages and not just C#, VB.NET or Java. For example, this past year I spent time learning Ruby and F#. I plan on taking up Scala soon as well and maybe a couple of other languages. In the past I was a Java, PHP and C++ programmer, so I've run the gamut. You can take some of these practices back to your other languages and learn from the successes and the failures of each community. It only makes you a better developer over time. I think many of the innovations that happen in the .NET space should come from the outside, and not just from Microsoft.
Do I think it's having an effect? Absolutely! If you look at such frameworks as Unity, there is a lot of feedback being provided, the ASP.NET MVC framework, same way. This willingness on both sides to engage is a wonderful thing and maybe to the point where "ALT" isn't the alternative anymore and instead the de facto standard.
-
Adventures in F# - F# 101 Part 6 (Lazy Evaluation)
#light
-
ASP.NET MVC Source Code Now Available
As of yesterday, the ASP.NET MVC Release 2 source code has been made available on CodePlex. ScottGu made the source drop announcement earlier this morning. Congrats to Phil Haack and the ASP.NET MVC Team for shipping the source code. It's worth noting, it's not Open Source in the way that it's just a zip file and no outside patches are to be accepted, unlike IronRuby. The plan going forward is to make incremental drops of the source code going forward.
As always, check out Jeffrey Palermo's MVCContrib project for contributions to the code base, which is open source.
-
DC ALT.NET March Meeting Wrapup
Another month and another highly successful DC ALT.NET meeting. I want to thank Kevin Hegg for hosting the event as he was a very gracious host. We had a better than expected turnout which was very cool. It's good to associate names to faces after chatting, emailing and whatnot. I also want to thank Phil McMillan for stepping up to the plate at the last moment to backfill for the lack of the scheduled speaker. It's even more refreshing to not have any Death By PowerPoint (DBPPT) (TM). I appreciate Phil's talk even more due to the fact that he had a laptop meltdown the night before, so we talked about concepts and implementations without showing any real code.
What Did We Talk About?
Our format that we follow is that we have one hour for our scheduled topic and the rest is Open Spaces. Bring a topic and talk about it. So, for the first hour, Phil led the discussion around interception facilities in Castle Windsor in regards to handling a Unit of Work pattern for a custom written WPF application. There is a lot of headache that comes with undo logic in WPF controls, so using interception and the unit of work pattern can get around this, although not the cleanest code written to man. Also, we talked about the headaches of registration inside IoC containers whether it be in code or in XML. We talked about Binsor and whether that was an answer to the registration headaches caused by massive XML config files. Craig Andera just loves bringing up Lisp and Lisp macros as they solve all programming problems ever invented by man.
The second hour was an open spaces discussion where we had pretty lively debate about:
- Dynamic Language Runtime (DLR) and its uses and extensibility model
- Design by Contract
- Functional Programming with Lisp/Scheme, Functional Javascript, Erlang, and F# and the value proposition it has
- Finding the right developer for your organization
- TDD/Test First Development
- ALT.NET Open Spaces, Seattle topics
Like I said before, we tend to be different than most user groups in the Washington DC area due to the fact that we're an Open Spaces event, for at least half of it. We don't really do PowerPoint presentations, instead a more intimate environment where everyone participates. I don't think anyone stayed silent during the meeting. Instead of being lectured to, you're part of the conversation. We want passionate developers to attend, those who are looking for a better way. It's even effective when not looking at code, nor slides for any given product. I feel we can augment any discussion from any user group in the DC area, and not here to compete, instead compliment them with a more intimate and passionate discussion.
Where We Go From Here
After the March meeting, we're looking to hold the next meeting the week after ALT.NET Open Spaces, Seattle. That should bring some lively discussion and wrapup from the event. We also look forward to having Jay Flowers make it to the event to discuss Continuous Integration and CI Factory. Stay tuned for details on our next meeting. April is going to be a busy month for at least me with the CMAP Code Camp on April 12th, speaking at RockNUG and ALT.NET Open Spaces, Seattle as well as our own DC ALT.NET Meeting.
Wrapping It Up
If you're interested in a better way, to discuss .NET or related topics and you're in the ALT.NET mindset, then come and join the conversation. We're always looking for passionate individuals to come and join and be a part. Join our mailing list and find out more here.
-
Adventures in F# - FringeDC User Group
During my Adventures in F# series that I've been posting, I've always wondered where the interest in these languages come from. Sure, we have a lot of user groups in the Washington DC area, just to name a few that I've been to or belong to:
- DC ALT.NET User Group
- Capital Area .NET User Group (CapArea.NET)
- Rockville .NET User Group (RockNUG)
- Central Maryland .NET Professionals (CMAP)
- Microsoft Integration and Connected Systems User Group (MICSUG)
- Northern VA SQL Server User Group (NoVASQL)
- Northern Virginia Ruby User Group (NoVARUG)
- Northern Virginia Java Users Group (NoVAJUG)
- Washington DC XP Users Group (XPWDC)
-
Looking at DSLs in .NET
As I've mentioned in recent posts such as here, here and here, I've been very interested in Domain Specific Languages (DSLs), especially with regards to F# and the DLR as well. I recently re-listened to Software Engineering Radio Episode 52 with Obie Fernandez discussing DSLs in Ruby. One of the things that attracted me to Ruby for this was the flexibility of the syntax for closures, mixins, etc. Anyhow, it's a good listen and if you're new to the subject, you should give it a go. Also, there is a slide deck of DSLs in Ruby which accompanies this episode which can be found here.
So, of course this gets me excited about the possibilities of seeing such things in IronRuby. After seeing John Lam's presentations at MIX08 and listening to him on various podcasts, I'm excited that they are making such progress and hopefully get it into our hands soon.
But, before we get too deep into things, I just want to take a step back and look quickly at what DSLs are.
Internal and External DSLs?
So, what are DSLs? Well, to put it succinctly, it's a small language that's used for a very narrow task. You can think of these as languages specific to a domain such as medical claims processing, stock trading and so on that only have meaning there. These languages mean very little outside their problem domain and probably wouldn't make sense to anyone outside. I'm very well aware of such things as I've worked in the medical claims processing industry and their terms, calculations and so on are very specific and to solve the problem well, it's best to suit the language best for expressing solutions.
Martin Fowler wrote an article entitled "Language Workbenches: The Killer-App For Domain Specific Languages?" in which he talks about the history of DSLs especially in the Lisp world, but until now really haven't caught on. Martin argues that XML structures such as configuration files, and so on qualify for that status, due to the fact that it is readable by a human and probably a domain expert as well. But Lisp is well know for the Lex/Yacc parsing and expression trees and so on.
Now the real interesting part comes in when we talk about internal versus external DSLs...
External DSLs, quite simply, are those languages that are not in the same language as the main application itself. This means that I could be free to write any free-form code I wish in order to suit my domain specific need. This means that you need to write parsers and then ultimately would need to have a translation boundary between your DSL and your application. This is where I think something like the Dynamic Language Runtime (DLR) could come into play. What I mean by that is that if you write your language parser for the DLR, and I'll get into that shortly. There is a bit of overhead with this of course, plus a good debugger and IDE, but with time and patience things like this can be overcome. Extending such things as #Develop to encompass those pieces is feasible.
Internal DSLs, on the other hand, are the little languages you can create inside your current language of choice. Now languages such as Lisp, Ruby, Scala, Boo, and F# seem a bit more suited for these than the mainstream languages of C++, C# and Java. Of course one of the bigger obstacles is the pesky curly brace which Ruby allows you to discard. F# doesn't have a concept of this either, and instead the indentation scopes the values and functions and so on. Martin has an interesting DSL written in Java that's interesting and could be better applied in different languages.
Thinking About The DLR
As I said before, I'm pretty excited about the DLR and the flexibility it can give me as a software engineer looking for new and better ways to solve my customer's problems. Not only that, but I'm a language geek at heart, what can I say? I've posted several items on building on the DLR in the context of external DSLs as well as writing custom compilers for .NET. Projects such as Irony also appeal to me in that way.
If you want to play around with the DLR, you can get it in one of two places, the IronPython download on CodePlex or on RubyForge with the IronRuby project.
Martin Maly, a member of the DLR team has continued his posts about Building on the DLR. He took some time off to work on some DLR related issues and now is back with some more posts. Let's continue where we left off last time:
- Answering Some Questions
Martin talks about Static and Dynamic Nodes on DLR Trees
- Variations on Trees
Martin talks about DLR trees and LINQ Expression trees
- More questions
Martin talks about implementing a Print method that acts differently per incoming data type
- Extension Methods
Martin talks about adding extension methods to the ToyScript sample
DSLs In Boo?
Oren Eini, aka Ayende, has been working on a book about DSLs called "Building Domain Specific Languages in Boo". Recently, he posted about some sample chapters now available online with the source code. I highly recommend that you at least give it a look. You now have access to the Early Access Edition, and of course you can buy it online. It'll be interesting to see Ayende at ALT.NET Open Spaces, Seattle to see if he wants to cover more of this stuff.
If you're not familiar with Boo, it's one of Ayende's preferred languages. Such tools as Binsor (The DSL for Windsor) were written in Boo. If you're not familiar with the language, it has very similar syntax to Python and formats very nicely. This easily fits Martin Fowler's category as an external DSL. #Develop has some support for Boo to make it a first class language in the .NET family. It also ships as part of the Castle Project. Anyways, a quick sample of Binsor makes it look like a nice DSL for type registration in Castle Windsor in Boo Script:
import Rhino.Commons
logger = Component("console_logger", ILogger, ConsoleLogger)
Check out the first chapter of Ayende's book which is available free online and explore it yourself for DSLs.
DSLs in F#?
Another part that had me intrigued was the possibilities of not only Boo to do this, but F# as well. Robert Pickering covers this in his book, Foundations of F#. If you pay attention to Chapter 11, he covers DSLs in F# and gives a few examples of how you can do so. To me, it's pretty powerful because you have a lot of the built-in features of a functional programming language such as lists, pattern matching and so on. Such examples as given are such things as the arguments parser in F# that is described in the Arg class in Microsoft.FSharp.Compatibility.OCaml namespace. This allows you to parse well known data structures as first class citizens. Martin Fowler also gave such an example from the article I quoted from above. F# lends itself quite well to DSLs in regard to support for lambda expressions.
Don Syme also covers these topics in his book Expert F# in Chapter 9. This covers more language oriented programming techniques, but you can scan some information about building DSLs in F#. Some interesting parts of this come down to Active Patterns which I covered partially yesterday. In the coming weeks, I hope to post some of my forays into this, taking some samples from the Ruby community and applying some of the same functionality in F#.
Conclusion
There is still much yet to be covered in this topic of DSLs in .NET languages. We can go on and on with regards to internal and external DSLs and argue about which language is suited for each. But in the coming weeks, I hope to take some samples and show how they can apply cleanly in F#, and probably run into some language problems where it might not be the best fit. But, that's the fun part about it.
- Answering Some Questions
-
Reminder - DC ALT.NET Meeting March 19th
Just a reminder, we will be holding it tomorrow, March 19th from 7-9PM. The meeting this month will bring ALT.NET to Arlington, Virginia. I want to thank Kevin Hegg for hosting this event. Unfortunately, Jay Flowers will not be able to attend, so instead we will have myself and Phil McMillan presenting IoC containers and Interception with Castle Windsor.
At our last meeting, Stelligent hosted our event in which we discussed a lot of great topics. You can read a wrapup of our last meeting here. Our format is as follows, the first hour or so is the topic at hand and then the second hour or whenever the talk is done is for Open Spaces.
Looking for Sponsors
As always, we're looking for sponsors for our events. We bring a lot of passionate developers to your site and we feel we can bring a lot. Sponsorship opportunities are always appreciated!
Who We Are
Are you a developer who always keeps an eye out for a better way? Do you look outside the mainstream to adopt the best practices of any development community, including Open Source, Agile, Java, and Ruby communities? Are you always looking for more elegant, more simple, more maintainable solutions? If so, then you might be an ALT.NET practitioner!
This group follows the Open Space Technology model. In Open Space, a facilitator explains the process and then participants are invited to co-create the agenda and host their own discussion groups. So, we'll take a vote and present the topics. We're in the pub-club mind occasionally, so it's not surprising to find us geeking out a bar...
This model follows the four basic principles:
- Whoever comes are the right people
- Whatever happens is the only thing that could have
- Whenever it starts is the right time
- When it's over, it's over
Tuesday, Marh 19th 7:00 PM
Arlington, VA. See thread for details.
Come, participate, and make your voice heard! Come meet passionate developers like yourself in the active discussion. Hoping for a great turnout... If you haven't signed up for our list, go ahead and do that here.
-
Adventures in F# - F# 101 Part 5 (Pattern Matching)
#light
-
CMAP Code Camp April 2008 Registration Open
As mentioned in my previous post about my speaking schedule, I am helping organize the ALT.NET track at the CMAP Code Camp. I plan to be speaking on a few topics and will get that posted when the schedule is finalized. Either way, it should be a great time and bringing ALT.NET ideas to a new audience is always a good thing. I feel there is a lot of momentum around the movement right now with the help of the "What is ALT.NET?" MSDN Magazine article by Jeremy Miller and Dave Laribee on Hanselminutes.
Anyhow, back to the topic at hand. Registration is now open for the CMAP April 2008 Code Camp. Space is limited for this FREE event, so register soon. Click here to register.
Central Maryland Association of .NET Professionals (CMAP) will holding its Code Camp 2008 Spring Edition on April 12, 2008. The Code Camp will be held at the Loyola College Graduate Center in Columbia, MD from 9am - 5pm.
Great source of information for FREE, with a FREE lunch, and chances to win great giveaway items, what a great way to spend a Saturday...
http://www.cmap-online.org
http://www.cmapcodecamp.org
-
Upcoming Speaking Schedule for April 2008
While I'm finishing up my F# post on pattern matching, I thought I'd throw out my speaking schedule for April. It's going to be a busy one with code camps, user groups and conferences. Some time I'm sure I'll find some time to sleep and get my own work done. Below is my current schedule as of right now:
- RockNUG - April 9th
Decouple Your Applications with Dependency Injection and IoC Containers
- CMAP Code Camp - April 12th
Heading up the ALT.NET track at the CMAP Code Camp to talk about ALT.NET topics such as IoC containers, TDD/BDD, O/RM frameworks, etc
- DC ALT.NET - April 16th
Inversion of Control Containers for Cross-Cutting Concerns
- ALT.NET Open Spaces, Seattle - April 18th-20th
Design by Contract panel discussion (Proposed). No guarantees since it is Open Spaces
- RockNUG - April 9th
-
Why I'm Excited About ALT.NET Open Spaces, Seattle
Update: Catch Dave Laribee on Hanselminutes discussing ALT.NET here.
It's almost a month away until ALT.NET Open Spaces, Seattle and things are coming along nicely. As you may have noted, we filled up rather fast while keeping some spots open for some pre-invites. We have a great crowd of people not only from inside Microsoft, but outside as well. We've put a bit of effort into getting this off the ground, and I can admit I've spent a bit of time doing so. But to see names like Ward Cunningham, Jim Shore, Martin Fowler from the Agile spaces, folks from Microsoft such as Scott Guthrie, Scott Hanselman, Phil Haack, John Lam, Jim Hugunin, Brad Abrams, Charlie Calvert, Brad Wilson, P&P, Microsoft Research folks such as Rustan Leino and Peli, the CodeBetter guys, the Israeli crowd (Ayende, Osherove, Dahan) just warms my heart. To give you an idea, I'll put the list at the end.
In case you missed it, Jeremy Miller had a great article in the latest MSDN magazine called "What Is ALT.NET?" which sums up my thoughts exactly on the topic. Very nice stuff! And I think Ayende might be onto something with these ALT.NET logos here. Something tells me t-shirts need to be made.
But where will we go from here? Dave Laribee and others, myself included, have been kicking around the idea of a RailsConf, QCon, Spring Experience, No Fluff Just Stuff kind of conference. I really do like that idea and I want an active learning conference where we in the ALT.NET community can learn from each other, but also spread the message outside. Dave set four basic criteria that I think were well worth noting for parameters for such an event:
- It would be longer: four or five days.
- It would start 2-3 days of workshops or classes upfront on advanced topics: DDD, T/BDD, Agile, Patterns, SOA/Messaging, etc.
- The final days would lead into a kind of "dream conference" with talks given by well-known speakers.
- It would cost money, not a lot, but some...
It's hard not to when you see names like these:
Jonathan de Halleux, Trevor Redfern, Russell Ball, Jonathan Wanagel, Ayende Rahien, Brad Abrams, Shawn Wildermuth, Anil Verma, James Franco, Wendy Friedlander, David Pehrson, Scott Hanselman, James Shore, Donald Belcham, Eric Holton, Michael Bradley, Joey Beninghove, Greg Young, Jesse Johnston, Tom Opgenorth, Harry Pierson, Anand Raju Narayan, Justin-Josef Angel, Chris Sells, Matt Pisut, Jeff Olson, Martin Fowler, Rustan Leino, Oliver, Roy Osherove, Rob Reynolds, Brian Donahue, Alan Buck, Jeff Certain, Sean Solbak, Dave Laribee, Dennis Olano, Owen Rogers, Bertrand Le Roy, Jarod Ferguson, Douglas Schroeder, Terry Hughes, Simon Guest, Rod Paddock, Jean-Paul S. Boodhoo, Dustin Campbell, Eric Ness, David Airth, Aaron Jensen, Wade Hatler, Adam Dymitruk, Chris Salahub, Charlie Poole, John Lam, Ben Scheirman, Brandon Lang, Miguel Angel Saez, Dave Woods, Ashwin Parthasarathy, Matt Hinze, James Kovacs, Alex Hung, Joe Ocampo, Alvin Lee, Steven "Doc" List, Kevin Hegg, D'Arcy Lussier, jakob Homan, Pete Coupland, Rob Zelt, Tom Dean, Joseph Hill, Arvind Palaniswamy, Chris Sutton, khalil El haitami, Kelly Leahy, John Nuechterlein, Troy Gould, Kyle Baley, Rhys Campbell, Joe Pruitt, Ronald S Woan, Michael Nelson, Matthew Podwysocki, Piriya Thongtanunam, Howard Dierking, Pete McKinstry, Dan Miser, Eli Lopian, Raymond Lewallen, Neil Blake, Jacob Lewallen, Mike Stockdale, Kirk Jackson, Brad Wilson, Eric Farr, Jeff Brown, Ian Cooper, John Quach, Cameron Frederick, David Pokluda, Charlie Calvert, Shane Bauer, Rajiv Das, Jeff Tucker, Phil MCmillan, Udi Dahan, Bil Simser, Martin Salias, Bill Zack, Chris Patterson, Greg Banister, Osidosi, Gabriel Schenker, James Thigpen, Phil Haack, Ray Houston, Colin Jack, Robert Smith, Sergio Pereira, Brian Henderson, Michael Henderson, Chantal Laplante, Dave Foley, Ward Cunningham, Bryce Budd, Chris Bilson, Scott Guthrie, Robin Clowers, Craig Beck, Phil Dennis, Jeffrey Palermo, Robert Ream, Carlin Pohl, Glenn Block, Tim Barcz, Dru Sellers, Scott Allen, Jeremy D. Miller, Grant Carpenter, Chris Ortman, Drew Miller, Weston Binford, Buchanan Dunn, Rajbeer Dhatt, Justin Bozonier, Jason Grundy, Greg Sangha , david p buchanan , Don Demsak , Jay Flowers , Adam Tybor , Scott C Reynolds , Chad Myers , Nick Parker , John Teague , Daniel , Jim Hugunin , Scott Koon , Justice Gray , Julie Poole , Neil Bourgeois , Luke Foust
Still working on my F# posts and IoC container posts, so stay tuned. Until next time..
-
DC ALT.NET Meeting - March 19th
I've held off recently announcing the DC ALT.NET meeting due to scheduling issues. Anyhow, that has been resolved and we are good to go. We will be holding it on March 19th from 7-9PM. The meeting this month will bring ALT.NET to Arlington, Virginia. I want to thank Kevin Hegg for offering his office as our get together.
At our last meeting, Stelligent hosted our event in which we discussed a lot of great topics. You can read a wrapup of our last meeting here. This time, we're going to have Jay Flowers to discuss Continuous Integration and CI Factory. It should be a great discussion as it's been weighing on my mind lately. Our format is as follows, the first hour or so is the topic at hand and then the second hour or whenever the talk is done is for Open Spaces.
Looking for Sponsors
As always, we're looking for sponsors for our events. We bring a lot of passionate developers to your site and we feel we can bring a lot. Sponsorship opportunities are always appreciated!
Who We Are
Are you a developer who always keeps an eye out for a better way? Do you look outside the mainstream to adopt the best practices of any development community, including Open Source, Agile, Java, and Ruby communities? Are you always looking for more elegant, more simple, more maintainable solutions? If so, then you might be an ALT.NET practitioner!
This group follows the Open Space Technology model. In Open Space, a facilitator explains the process and then participants are invited to co-create the agenda and host their own discussion groups. So, we'll take a vote and present the topics. We're in the pub-club mind occasionally, so it's not surprising to find us geeking out a bar...
This model follows the four basic principles:
- Whoever comes are the right people
- Whatever happens is the only thing that could have
- Whenever it starts is the right time
- When it's over, it's over
Tuesday, Marh 19th 7:00 PM
Arlington, VA. See thread for details.
Come, participate, and make your voice heard! Come meet passionate developers like yourself in the active discussion. Hoping for a great turnout... If you haven't signed up for our list, go ahead and do that here.
-
Singularity - C# OS Released on CodePlex
Update: If you want the .iso I used for the VPC, check it out here on my SkyDrive.
During my research and posts about Design by Contract and Spec# and my interactions with folks from Microsoft Research, I came across Singularity OS, an operating system written in an offshoot language based upon C#. In that time, I realized that the Singularity team extended Spec# and the Design by Contract and static verification pieces of it into a new language called Sing#.
Fast forward to last Tuesday. Almost five years after the start of development, it has finally been released onto CodePlex as an open source non-commercial academic license and can be found here. After reading about it and talking with some Microsoft Research folks about it, I had to give it a shot. That's one of the things I love about working at Microsoft is the fact that I can interact with people like these on a periodic basis.
History of Singularity
During my long commute to and from work, I have the pleasure of listening to many podcasts. Although I like the ones in the .NET space with Hanselminutes and DotNetRocks, I also like to venture into the Ruby and outside community where I'm pretty comfortable as well. So, one of my absolute favorites is Software Engineering Radio for the serious talk and geeking about languages and architecture. Lo and behold, the latest episode, Episode 88, covers Singularity with Galen Hunt where he talks with Markus, the host about the history and features of the OS. I suggest you listen to that before we go any further. Also, a good overview can be found here in PDF format.
If you think about most operating systems we run today, the essence of what they are is dated back in the 1970s and C and Assembly based. Back in 2003, Galen and team started this effort to write an operating system in managed code. Over 90% of the system is written in a language called Sing# which is an extension of Spec# which I will get into shortly. But, Singularity consists of three major parts, Software Isolated Processes (SIPs), contract-based channels, and manifest-based programs.
SIPs are interesting parts of Singularity. They provide a sandbox as it were for program execution free from meddling from outside processes. This includes its own memory space, threads and so on. In fact, memory and threads cannot be shared from one SIP to the other, so the vectors for malicious code are cut way down.
Contract-Based Channels are another interesting aspect of Singularity. It's a built-in feature of the Sing# language which I will get to in the next section. In short, what it provides is a quick and verifiable way of communicating between processes with messages. To support this, the Spec# language had to be extended to support this.
Lastly, manifest based programs are interesting because it defines the code that runs within the SIP and its behaviors. In Singularity, there really is no such thing as Just In Time Compiling (JIT) as all code needs to be loaded into memory and statically verified before it can be executed, which is something a JIT cannot do. But on the other side of this, it makes dynamic languages and late binding impossible as well. So, to work around this, they devised a plan called Compile Time Reflection, so you know your dependencies beforehand and uses Dependency Injection in a way to inject the appropriate dependencies. Really slick stuff!
Sing#
Rustan Leino and others in Microsoft Research had already begun an effort called Spec# to provide Design by Contract features to the C# language and a static verifier to prove that code is in fact working as the contracts were written. Just a quick aside, we're going to be lucky enough to have Rustan at ALT.NET Open Spaces, Seattle to talk about it and Design by Contract (Shameless Plug). Anyhow, back to the topic at hand. Spec# didn't have enough for the static verification that needs to happen. So, instead, Sing# brings us Contract Based Channels for creating message declarations and a set of named protocol sets. Any communication that crosses processes must use contract based channels. These messages that it passes have declarations that state the number and types of arguments for each message and an optional message direction. Each state specifies the possible message sequences leading to other states in the state machine.
I just want to dig through some code to see exactly what that looks like:
class DirectoryServiceWorker
{
private TRef<DirectoryServiceContract.Exp:Start> epRef;
private DirNode! dirNode;
private DirectoryServiceWorker(DirNode! dirNode,
[Claims] DirectoryServiceContract.Exp:Start! i_ep)
requires i_ep.InState(DirectoryServiceContract.Start.Value);
{
epRef = new TRef<DirectoryServiceContract.Exp:Start>(i_ep);
this.dirNode = dirNode;
base();
}
If you notice from above, you can see some Spec# goodness in there including NonNull types using the ! keyword and also requires preconditions. It's pretty well written and a lot of fun to dig through. If you want to learn more about compilers and operating systems, now is the time to sift through the source code and get your geek hat on.
Building the Image
If you want to actually run Singularity, the team has provided as part of the zip file, a way to build the operating system. You'll simply need the following:
- Windows Debugging Tools
- .NET Framework 1.1
- Virtual PC 2007
- MSBuild
I was able to get the results in about 10 minutes or so for the build process. Then again, if you're running Vista, you need to be sure to launch the configure.cmd as an elevated process in order to kick things off properly. That was the first hurdle. But once I got that going, the rest was easy. And I got a pretty cool result as well when I ran the VPC image. Look at the goodness:
I have played with it just yet all that much. I'm figuring what I can do with it next. But, that's part of my copious spare time which doesn't seem to exist much anymore.
Conclusion
I've done well with my learning plan this year to keeping to what is on my plan and not deviating from it. Luckily languages such as Spec# and Sing# still fall into that category. It's pretty fascinating stuff and great to get my hands on an operating system using managed code. It's pretty impressive from the things I've read and the code I've read. I'm only hoping that research projects such as this make a significant impact on future versions of Windows, let alone future versions of most operating systems. Until next time...
-
Videos and Interviews from MIX08
Well, I've had the urge to find all the videos I could and watch them to find out all the goodies I missed while not at MIX08. If you missed any of the main sessions, you can find out more about them here. Note that there are 88 sessions recorded here, so it's a lot of good viewing material.
Best of all are Scott Hanselman's MVC Videos can be seen here. He also covers the MVC Mock Helpers which better allow for unit tests using various Mock frameworks including Rhino Mocks, TypeMock.NET and Moq.
Dave Laribee was great on Twitter to make sure we were all kept up to date with all the good things that were happening. Brendan Tompkins supplied Dave with a video phone so that he could capture impromptu videos and such. But, best of all they were broadcasted live. He was able to talk to guys like Rob Conery, Phil Haack, Steve Harman, Miguel, John Lam, Scott Hanselman and Josh Holmes. Very cool stuff! They were pretty good and entertaining, although the video wasn't always superb and sometimes you needed motion sickness pills. But, the sessions of note are:
- Phil Haack interview
- Capturing Hanselminutes
- Rob Conery and Steve Harman interview
- Miguel de Icaza interview
- Pablo Castro interview
- John Lam interview
- Microsoft Surface demo
- Josh Holmes interview
- Phil Haack interview
-
RockNUG Meeting 3/12/2008 - Refactoring in C#
The Rockville .NET User Group (RockNUG) will be holding their next meeting on Wednesday, March 12th, 2008 from 6:30PM-9:00PM. This month, they'll be having a pretty interesting topic on refactoring in C# with Jonathan Cogley. I've had my refactoring and agile boots on lately, so I can definitely relate. I don't know what I would do though without my Resharper 4.0 Nightly Builds... I've had a few issues here and there, but nothing to discourage me from continuing usage.
Anyhow, here are the details:
Location:
Montgomery College, Rockville
Humanities Building - Room 103
Refactoring in C# - Bad code to better code
presented by Jonathan Cogley
What could be more fun on a Wednesday evening than critiquing some bad
code and making it better? :) Come along to learn how to clean code like
the Thycotic team. What do we look for? How do we take small steps to
keep it working? What tips and tricks make it easier? This session
will be code, code and more code (and a few unit tests of course!).
Jonathan Cogley is the founder and CEO of thycotic - a software
development company operating in the Washington DC Metro Area with
offices in Vienna, Virginia. Jonathan has worked for many interesting
companies over the last decade as a software consultant in both the UK
and the USA. His company has released various .NET projects and APIs
including an implementation of Remote Scripting for .NET, a database
platform independent data access layer for ISVs and various tools for
the Test Driven Developer. Test Driven Development (TDD) is the
cornerstone of the thycotic approach to software development and the
company is committed to innovate TDD on the Microsoft .NET platform with
new techniques and tools. Jonathan is also a columnist and editor for
the popular ASP.NET Web site, ASPAlliance. He is an active member in the
developer community and speaks regularly at various .NET User Groups,
conferences and code camps across the US. Jonathan is recognized by
Microsoft as an MVP for C# and has also been invited to join the select
group of the ASPInsiders who have interactions with the product teams at
Microsoft.
The schedule for the event is as follows:
n00b Session 6:30 - 7:00 ASP.NET GridView Part III Pizza/Announcements 7:00 - 7:30 Featured Presentation 7:30 - 9:00 Refactoring in C#
Hope to see a great crowd there! I'm looking forward to it.
-
IoC Container, Unity and Breaking Changes Galore
IUnityContainer container = new UnityContainer();
-
ASP.NET Team Releases for Mix 2008
For all those interested in the information and the latest bits from the ASP.NET Team, here are the latest links.
Downloads:
- ASP.NET MVC Preview 2
- Silverlight tools including ASP.NET Server Controls
- ASP.NET 3.5 Extensions Preview from December
ASP.NET Updates:
- ASP.NET Home Page Announcement
- ASP.NET 3.5 Extensions Download Page
- ASP.NET 3.5 Extensions Quickstarts
- ASP.NET Preview 2 (MIX) readme
- ASP.NET Updated Forums
- ASP.NET Server Controls for Silverlight Forum
- ASP.NET 3.5 Extensions Videos
I've been playing with the bits for a little bit lately and I must admit it's a lot better now. But, I'm noticing that it seems that the ASP.NET team wants us to use more of the Supervising Controller/Presenter Pattern and less of the Passive View Pattern. Brad Wilson also notes that here. It hasn't dampened my usage of it yet as I have adapted my designs since then. After all, you have to be a little flexible when using a CTP.
- ASP.NET MVC Preview 2
-
Adventures in F# - F# 101 Part 4
#light
-
Live From Mix08
No, I'm not at Mix08 right now, but I'm busy paying attention to every detail. I'm missing a lot of really cool things such as:
- Silverlight downloads at 1.5 million a day
- IE 8 preview with Firebug?
- SQL Server Data Services
You can too by paying attention to the following places:
- Live streaming video from Mix from Microsoft and some short videos on:
- IE 8
- Scott Guthrie
- Ray Ozzie
- Dean Hachamovitch
- CodeBetter's live stream by Dave Laribee which features short snippets from the event.
- Josh Holmes is covering the event and has noted about Ray Ozzie's keynote as well as other things.
- John Lam will be at Mix as well and will be tweeting throughout the conference with his Twitter name john_lam. I know I'm following it now...
-
IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
namespace UnitySamples
-
Coming to Terms with Behavior Driven Development
A while ago, I posted about Behavior Driven Development (BDD) while using the NBehave, and I think I went too far into the tool without going into the whole thought process instead. I've had a series of these blog posts in my head but have been fighting writers block in order to get them out the door.
BDD Introduction
Anyhow, there has been a lot of discussion around BDD lately on the altdotnet mailing list around the definition and applicability of BDD in regards to Test Driven Development (TDD). Subsequently, this led to forming a new group on Google Groups about Behavior Driven Development. It's great to see the community start to gain momentum and talk about it more. I've been following Dan North, Joe Ocampo, Scott Bellware, JP Boodhoo and Dave Laribee on this for a while, but now to come to a centralized place for that knowledge sharing has been invaluable. I've seen too many times that there is a high noise to information ratio out there and we need to clarify a few things before it can really take hold.
Getting back to the subject at hand, if you're unfamiliar with BDD, you should check out Dan North's explanation here. There are a good number of links inside to whet your appetite. To put things succinctly, BDD aims to bridge the gap between Domain Driven Design and Test Driven Development.
Dave Astels, also has a great video on Google Video on BDD you can find here. It's a great video which talks about how TDD differs and evolved from BDD. It also delves into the subject of rSpec, the BDD framework in Ruby. Very worth your time to check it out.
Dave's summation of BDD comes down to the following bullet points:
- Don't talk about Units in regards to Unit Testing, instead talk about Behaviors
- All software we write has behaviors
- There should be no correlation between public methods on a class and test classes
- Structure your tests around the behavior of your application
- Put emphasis on behaviors (How do I get it to do what I want it to)
- Get rid of state based testing and look at interactions instead
- Get rid of tests and instead use specifications of behavior (specs)
- Get rid of assertions and instead set up expectations
I agree with Jimmy Bogard, that going to TDD to BDD in one fell swoop by just renaming your tests. Instead, we should focus on those interactions between the systems and less on the physical implementations of the code. We should also focus on the expectations inside our code as well. Mocking and the use of Rhino Mocks or your other mocking framework will do nicely in here. Brian Donahue also has some nice stabs at BDD as well here, here and here. If you're up in the Philly area soon, Brian will be making the rounds doing BDD presentations...
Dave Laribee has also put some thought into BDD as well with a particular set of classes he has written to help with BDD that you can check out here. Also if you've paid attention to the BDD mailing list on Google Groups, you will note that Scott Bellware also has a framework up on Google Code called SpecUnit which is an extension to NUnit to support naming conventions of BDD inside of the xUnit type frameworks. Very cool ideas coming out!
Wrapping It Up
I encourage you to join the BDD list, read the links, and learn more. I find it's a more intuitive way of proving the behavior of your application (Note that I didn't say test). I find that it bridges the gap between Domain Driven Design and Test Driven Development quite handily especially in regard to using the ubiquitous language. It's important that naming and ubiquitous language comes into play when using BDD, because you can share your specs and they should be able to read them as well. It's a great gap between user stories and the code you write. If you need help with user stories, check out Mike Cohn's User Stories Applied book. Anyhow, I hope you found this useful as an introduction to some of my many upcoming BDD posts.
-
Adventures in F# - F# 101 Part 3
#light
-
IoC and the Unity Application Block Once Again
namespace UnitySamples
-
Thinking Inside the Box and Premature Optimization
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...
-
IoC and the Unity Application Block - Going Deeper
namespace UnitySamples
-
Adventures in F# - F# 101 Part 2
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...
-
DC ALT.NET Wrapup and CI Factory
Well, due to the weather beyond our control, the crowd was a bit smaller than expected at the February meeting of DC ALT.NET. It seems people panic in the Washington DC area if there is even a hint of moisture in the air or a snow flake hits the ground. It was a smaller crowd, yet passionate and I'd rather have that then a big crowd that wasn't involved at all. We had such people as Craig Andera, Jay Flowers, Kevin Hegg among others who attended. But the topics were great talking about functional programming, with Craig and Lisp and me with F#, continuous integration, the complexity of .NET and what's coming down the line, Domain Driven Design and managing complexity in projects. Not once did a laptop nor PowerPoint show its head, instead just passionate people talking about technology and ways of thinking.
I want to thank the people at Stelligent and Jay Flowers for making this happen. It couldn't have been better timing as he just released version 1.0.1 of CI Factory yesterday. If you aren't aware of this product, I've blogged about it in the past here. What it does is it creates an out of the box CI environment which is really important to have in an agile environment. Even teams as small as one person can benefit greatly from continuous integration.
Tools supported by CI Factory include:
- NAnt
- MbUnit
- FinalBuilder
- InstallShield
- MSBuild
- MSTest
- NCover
- NDepend
- Simian
- Subversion
- VSS
- VSTS
- Windows Installer XML
- Xenocode Postbuild
-
Lang.NET Videos Now Available
As you may have seen from previous posts, I have been covering Lang.NET and some of the interesting things that came from it. I've always been interested in compilers, DSLs and such, and I hope you found them interesting as well. I covered it these posts here:
- Adventures in Compilers - Building on the DLR
- DSLs, Compilers and the Irony of it All
- Ruby.NET is dead, long live Ruby.NET
- Lang.NET and Rolling Your Own
-
Final Reminder - DC ALT.NET Meeting 2/20 - 7PM
As posted previously here, the DC ALT.NET February meeting will be held tomorrow, Wednesday, February 20th, 2008 from 7-9PM. Stelligent has been really kind to provide the facility and the food/drinks.
Since we're following the Open Spaces Technology route, we don't have set speakers right now, but that may change over time. We've been discussing some of the topics for the meeting:
- Design By Contract (DBC) and Spec#
- Aspect Oriented Programming and Castle Windsor
- NHibernate Design Patterns and Implementation
Time and Location:
Tuesday, February 20, 2008 7:00 PM
Stelligent Incorporated
Global Headquarters
11495 Commerce Park Drive
Reston, VA 20191
So, bring your topic for discussion and bring your passion!
-
IoC and the Unity Application Block
Update: Fixed code changed from CTP and More in the series:
- IoC and Unity - The Basics and Interception
- IoC and the Unity Application Block - Going Deeper
- IoC and the Unity Application Block Once Again
- IoC Containers, Unity and ObjectBuilder2 - The Saga Continues
- IoC Container, Unity and Breaking Changes Galore
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...
-
ALT.NET Seattle Registration and Mispronouncing My Last Name
Just a reminder that ALT.NET Open Spaces, Seattle registration is still open, although we are sold out at the moment, we are taking stand-by's just in case some drop out. So, if you hadn't registered with us, go ahead and do so, and don't let the sold out scare you. Just keep in mind that you may not be selected, so I wouldn't make concrete plans if you are traveling to get there.
I'm hoping to finish up about 5-6 posts that have been sitting around since last week on F#, the Unity Application Block, Mocking versus Stubbing and so on. Hopefully today I'll get some of that done, so stay tuned. That and there is a DC ALT.NET meeting this Wednesday as well.
So, I know this is a random post, but if you caught over the weekend, the "This Week on Channel 9: Feb 15 with Scott Hanselman!" episode on Channel9, you may have noticed I was mentioned around minute 11, and it was a struggle to Brian Keller on how to pronounce my last name. Don't worry about it, people, it happens all the time, and I usually let people struggle with the first part for a while before I have to hop in. It's a definite way of telling who knows me and who doesn't... It's like "Podwa Podwe Probably not gonna work here anymore, that's for sure!" from Office Space.
-
Resharper 4.0 Nightly Builds Now Released
A recent announcement was made on the altdotnet mailing list that made me jump for joy today. Ilya Ryzhenkov and the great folks at JetBrains have published the nightly builds for Resharper 4.0. The download for this can be found here and you might want to read the release notes here. It's important to note that the LINQ syntax is still not supported yet. As with any product in nightly builds, please use with caution, but download it and play with it today!
-
RockNUG Meeting - ASP.NET MVC + Updates
Tonight, put on the DVR and come out to the Rockville .NET Users Group (RockNUG) for a presentation by Jeff Schoolcraft on ASP.NET MVC.
The timing of course couldn't be more appropriate as ScottGu has recently posted about the ASP.NET MVC Framework Update in which he talks about a few pain points I know I've been having as well as others such as:
- Can be deployed in partial trust in the \bin directory
- Improved routing features and infrastructure
- Test wizard now supports and probably one of my favorite features
- MSTest
- NUnit
- MbUnit
- XUnit.NET
- Removing ControllerAction Attribute requirement from controllers, instead all public members will be controller actions. Another nice thing to remove a pain point
- Filter Support for Controllers and Action methods
- HTML Helpers now built in
- And so on...
Phil Haack has also covered this with his comments on ASP.NET MVC Update and Blocking Direct Access to Views in ASP.NET MVC.
Anyhow, back to the original intent of the post, the details are as follows:
An Introduction to ASP.NET MVC
presented by Jeff Schoolcraft
Come walk with me as I lead you on a gentle, relaxed tour of the ASP.NET MVC Framework. I'll demystify the forest of three letter acronyms. Then we'll take a journey through the hall of ancestors--and cousins--to discuss some influences and other players in the MVC space. We'll end up at the Grove of Hello World and, like habitat for softwarity, we'll build a demo application. Along the way we might run into some tangential trolls, but we'll cross that bridge when we come to it.
Jeff Schoolcraft is the founder of The Queue, Incorporated; a consulting shop that writes software and helps write software better. He has been in the .NET space from nearly the beginning and is still, mostly, writing web applications in C#. He tries to organize a couple Code Camps a year and is hoping to find a developer community that isn't over an hour away. When he's not immersed in code he enjoys spending time with his wife and two daughters.
Time:
Wednesday, February 13, 2007 6:30-9:00 PM
Location:
Montgomery College, Rockville
Humanities Building - Room 103
Rockville, MD
Click here for details....
Come and support the organization if you're in the area! Should be a great session!
-
ALT.NET Open Spaces, Seattle Sold Out!
Within a mere set of hours, ALT.NET Open Spaces, Seattle is officially sold out! Don't worry if you have a registration code, you still have plenty of time to register. We have a wait list if you still wish to attend, so don't let that discourage you at this point. We had a great reaction and I'm really excited to see such a great turnout. As you can notice from our participants page, and it will be growing of the people with registration codes, but we have such people as Jim Shore, Open Source folks, community folks (too many to mention, and if I missed your name I apologize) and Microsoft folks such as Scott Guthrie, Scott Hanselman, Brad Abrams, Phil Haack, and Chris Sells. Stay tuned for future updates to all those who registered. Going to be a great time!
-
ALT.NET Open Spaces, Seattle Registration Open
Darn it, Dave beat me to it here.
Anyhow, yes, as noted, the registration for ALT.NET Open Spaces, Seattle is now open and you can find it here. This site requires OpenID in order to register with just your name and email address. Feel free to use any of these OpenID servers on the OpenID Servers Page. MyOpenID or Versign's PIP both worked for me, so you should have no problem.
We have already 50 pre-invites, so that makes about 100 for general registration right now. It's going to be a great crowd and a lot of big names. We've been working very hard on this effort and it's going to be a great time with lots of events and great topics to discuss.
The hotel logistics have been worked out and information can be found on the site. So, check it out, and register today, and be there!
-
Adventures in F# - F# 101 Part 1
Update: Added more topics
- Part 2 - Currying, Tuples and Returning Values from Functions
- Part 3 - Scope, Recursion and Anonymous Functions
- Part 4 - History of F#, Operators and Lists
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
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
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...
-
Adventures in Compilers - Building on the DLR
So, I can admit, I've been on a bit of a kick with compilers and such after my posts on DSLs, Compilers and the Irony of it All and Lang.NET and Rolling Your Own. Today is no different, but this time, I'm just intrigued by targeting the DLR instead of the CLR. Thankfully there are a few great references that people are doing right now for these little adventures. One day once I'm more finished with the deep dive into F#, I'll dig a little deeper.
So, to get started, head on over to the IronPython download at CodePlex and let's get started. The DLR doesn't compile down to MSIL, instead expression trees. The DLR contains a set of expression trees that allow you to define variable assignments, functions, loops, if/then/else, and much more. After making the DLR expression tree from the aforementioned pieces, the DLR handles the code. This will be covered by Martin Maly in some of his posts.
Building Your Own DLR Language Series
Martin Maly from the Microsoft DLR team has started a series on building languages on top of the DLR. The posts in the series are so far:
- Building a DLR Language - ToyScript
This post covers the basics of the ToyScript sample from the IronPython download. This covers the tokenizer, parser and the Abstract Syntax Tree (AST). This is the starter for the series.
- Building a DLR Language - Trees
This post covers that the ToyScript language generates not MSIL, but instead trees which the DLR then take care of the code generation. This also covers the expressions that the DLR trees support
- Building a DLR Language - Trees 2
This is a follow-up to the previous post and covers the constructs for creating functions and lambdas.
- Building a DLR Language - Dynamic Behaviors
This post covers dynamic behaviors, instead of the previous samples which covered static linked and strongly typed. This sample covers arbitrarily adding two objects.
- Building a DLR Language - Dynamic Behaviors 2
This is a follow-up to the previous post on dynamic behaviors, and this time covers using the ActionExpression. This time he digs into Reflector to show samples of the output. Very cool stuff...
- Building a DLR Language - Dynamic Behaviors 3
In the final post so far in the series, it covers what happens when the DLR encounters a new runtime condition it hasn't seen and doesn't know yet how to handle. These conditions are handled by Rules in the DLR sense.
Tomas Restrepo recently blogged about just that kind of adventure as well with some good posts recently. Here are the ones so far:
- Building On The DLR
This is the first post in the series which gives an introduction to the basics and where to get started.
- DLR Notes 1
This post covers simple things such as declaring global and local functions and variables and the trials and tribulations.
- DLR Notes 2
This post is a rather long post about implementing function calls through Call Actions. This includes such things as call expressions, IDynamicObject and ActionBinders
- DLR Notes 3
This is a follow-up which covers InvokeMember actions which are used to invoke instance members on .NET objects.
This is pretty exciting stuff as it has whetted my appetite for building dynamic languages. My mind is still swimming with the possibilities of this, but to make one of these languages is simpler than ever. Once again, I'll start taking that deep dive after I finish my F# kick, but I still thought I'd start gathering my resources now.
Until next time...
- Building a DLR Language - ToyScript
-
Software Transactional Memory and F#
Since I have a rather long commute to and from work, I have the opportunity to get caught up on all sorts of podcasts and such. Very recently, I listened to the DotNetRocks Episode 310 with Simon Peyton Jones on Haskell and Functional Programming. It seems that Carl and Richard are definitely on a functional programming trip, and I think Scott Hanselman has joined the group as well with his shows on Hanselminutes. Since I've been learning F# and such I thought this show was well worth a listen, and I was right.
Simon Peyton Jones is currently working on a few things including the a Haskell compiler, Glasgow Haskell Compiler (GHC) and C--.
Haskell
If you're not familiar with Haskell, it is a purely functional programming language, unlike F# which allows for imperative and functional programming in the same language. The GHC is one of the more popular Haskell compilers out there today. Much like every other language out there today, there are a couple, although inactive, Haskell .NET compilers out there including Hugs98 for .NET using the Hugs98 compiler, and Modrian using the GHC.
Let's walk through a simple example of computing a factorial in one line:
fac n = if n > 0 then n * fac (n-1) else 1
As you can see from the above line, we create a function that keeps recursing itself until it hits 1.
Now, let's look at a simple version in the Hugs98 for .NET for a simple console application:
main = do
obj <- new "System.Object"
x <- obj # invoke "GetHashCode" ()
print ("The hash code is: " ++ show (x::Int))
Pretty slick actually... Too bad they aren't being maintained anymore, especially with .NET 2.0 and beyond goodness. But, if you're looking for more tutorials and such, go here for a brief demo from Simon himself.
Software Transactional Memory (STM)
One of the more interesting aspects of Simon's visit to DNR was talking about Software Transactional Memory (STM). This has been one of Simon's projects at Microsoft Research and an interesting one at that. STM originally came about back in the '80s, but only more practical now as many times it has failed in the past. Think of STM being analogous to database transactions, but in shared memory for concurrent running programs. The GHC has actually implemented this functionality and is pretty interesting.
So, what does this offer us? Well, with this scheme proposed in their paper, you can take two operations and combine them to be atomic. In the past, it was unclear when and how they should attempt to re-execute the transaction should it fail. So, in turn, Simon's group put in a retry keyword which uses a transaction log that determines the memory that was read and then automatically retries it and changes that piece of memory. They also implemented the orElse keyword which brings an alternative in should the transaction fail the first time, then the alternative is run.
You can read more about Simon's group's research paper here.
STM in F#?
So, this is really cool stuff, but can we have this in .NET? Greg Neverov has indeed written a library called Software Transactional Memory for F# which is available on hubFS. What's interesting is that the low level goo for the STM is actually written in C# using the Monitor class with method calls to Enter, Wait, Exit and PulseAll. So, I guess you could call this library from C# as well to do concurrent programming, but that's more of F#'s gig.
Here's a simple example using this:
let enqueue queue item =
stm { let! used = readTVar queue.used
return! if used < queue.len
then stm { let! head = readTVar queue.head
do! writeTVar queue.a.[(head+used) % queue.len] item
return! writeTVar queue.used (used+1) }
else retry () }
So, download it today and check it out. There may be performance implications of using this code instead of just the standard Monitor.Enter and so on, but I've yet to check that out.
Conclusion
I barely scratched the surface once again on this and the possibilities. You could easily imagine using this in heavy concurrent applications touching static data and shared memory. A lot of these things give me the idea about the strength and power of F# and .NET languages as a whole. .NET is rapidly evolving before our eyes and the possibilities of so many years ago with many languages using the same platform is really solidifying and each language has its purpose...
Until next time...
-
DC ALT.NET Site Now Up
Well, after much trial and tribulation, we finally have our DC ALT.NET site up. Thanks to Phil McMillan and Entropy Zero Consulting for hosting the site! Right now it's a work in progress and I hope to have it more complete tomorrow. As per usual with these kinds of groups, it's a wiki style and will be constantly changing with resources from our previous meeting, voting on the next topics at the next Open Spaces and places for sponsorship among other things.
Meeting Announcement Redux
Just a reminder about our third meeting of DC ALT.NET on February 20th at 7PM.
The meeting this month will bring ALT.NET to Reston, Virginia and the Stelligent headquarters. I want to thank Jay Flowers for offering his office as our get together. The food and booze will be provided by Stelligent, so a big thanks to them! Oh, and they are hiring if anyone is interesting (schilling off).
At our last meeting, CMAP hosted our event in which we discussed a lot of great topics. You can read a wrapup of our last meeting here. We're going to formalize things a little bit this time around and vote on topics for next time at this meeting so we can come prepared. As a group, we're growing fast and learning a lot along the way.
Looking for Sponsors
As always, we're looking for sponsors for our events. We bring a lot of passionate developers to your site and we feel we can bring a lot. Sponsorship opportunities are always appreciated!
Who We Are
Are you a developer who always keeps an eye out for a better way? Do you look outside the mainstream to adopt the best practices of any development community, including Open Source, Agile, Java, and Ruby communities? Are you always looking for more elegant, more simple, more maintainable solutions? If so, then you might be an ALT.NET practitioner!
This group follows the Open Space Technology model. In Open Space, a facilitator explains the process and then participants are invited to co-create the agenda and host their own discussion groups. So, we'll take a vote and present the topics. We're in the pub-club mind occasionally, so it's not surprising to find us geeking out a bar...
This model follows the four basic principles:
- Whoever comes are the right people
- Whatever happens is the only thing that could have
- Whenever it starts is the right time
- When it's over, it's over
Topics for discussion can include the following as well as others:
- Model View Controller Pattern (ASP.NET MVC/MonoRail)
- Inversion of Control (IoC) containers and Dependency Injection (Spring.NET/Castle Windsor/StructureMap)
- Domain Driven Design
- Design by Contract and Spec#
- Continuous Integration
- Agile
Tuesday, February 20, 2008 7:00 PM
Stelligent Incorporated
Global Headquarters
11495 Commerce Park Drive
Reston, VA 20191
Come, participate, and make your voice heard! Come meet passionate developers like yourself in the active discussion. Hoping for a great turnout... If you haven't signed up for our list, go ahead and do that here.
-
DSLs, Compilers and the Irony of it All
In a previous post, I posted about the Lang.NET symposium and rolling your own compiler. I cited an MSDN article that was a good starter for someone interested in writing that new language in .NET we've all been waiting for. It's not by any means to get you towards finishing IronRuby by yourself, but some of the fundamentals are covered.
The reason I've stated that I'm pretty interested is that of course I'm a geek, but I'm also interested in Domain Specific Languages (DSLs) lately as you may notice from my blog and what you can do with compilers to help that along.
DSLs in General
So, why DSLs and why am I interested? I think Oren Eini, aka Ayende laid the reasons out well here and here. In short he covers quite a few scenarios in which you might be interested in them, such as:
- Mapping layers for DTO/Domain objects from incoming objects
- Configuration scripting for IoC containers and so on
- Business situations and Business Rule Engines
Ayende has been quite busy with the DSL posts that I encourage you to check out. If you're looking for basic samples, check out these posts on Building an External DSL, and Implementing a DSL. As you may note, most samples are written in Boo, but you could imagine them written in any language for that matter in the .NET space.
Compiler Basics
Now that we're through that section, let's take a step back to compilers in general. If you're interested in these things, I would suggest the Compilers: Principles, Techniques, and Tools aka the Dragon Books. Even though the first one was published back in 1977, there has been the Purple Edition released back in 2006. There are several sample chapters available online if you wish. This will give you a good foundation on how compilers work and give you more of a headstart than just the simple MSDN sample.
The Irony Of It All
Greg Young pointed me towards Irony by Roman Ivantsov which is available off CodePlex. If you paid attention to the Lang.NET 2008 symposium, Irony and language challenges in ERP systems were covered as noted here.
Off the site, it explains:
Irony is a new-generation .NET compiler construction kit. It utilizes the full potential of c# 2.0 and .NET Framework to implement a completely new and streamlined technology of compiler construction.
Unlike most existing yacc/lex-style solutions Irony does not employ any scanner or parser code generation from grammar specifications written in proprietary meta-language. In Irony the target language grammar is coded directly in c# using operator overloading to express grammar constructs. Irony's scanner and parser modules use the grammar encoded as c# class to control the parsing process.
So, basically it takes the idea from that MSDN article and raises it to a whole new level. And best of all, it's written in C#, so it opens compilers to a different audience instead. For a full walkthrough of the possibilities, check out the article posted on CodeProject. What's really cool is that he's opened it up for anyone to contribute to should you find something missing or not quite right.
Greg brings out an idea of using Abstract Syntax Trees (ASTs) inside custom attributes to bring more of Spec# to the .NET framework. He posted this simple sample of some of the possibilities:
private void MyMethod( [Requires("value>5 and value<10")] int i) { ... }
I think it's an interesting approach and I'm going to have to try it out. I can't turn down a challenge like this.
Conclusion
So, as I continue on the journey of F#, DSLs and compilers, these things come to light and I find even after all these years, I'm still learning something new every day. I hope you found this shallow dive into the deep end interesting into this geekdom. Well, that and after going through some of these samples that my old lex/yacc skills aren't quite what they used to be. With some time and perseverance, maybe it will...
And yes, I'll be getting back to some code samples soon enough. Until next time...
-
Ruby.NET Is Dead; Long Live Ruby.NET
As I noted yesterday, Dr. Wayne Kelly, the leader of Ruby.NET project, attended the 2008 Lang.NET Symposium last week led a discussion of how he wrapped Ruby, a dynamic language, on top of the static CLI. Of note of course in that speech was how hard certain things are with Ruby due to the lack of a formal specification.
Anyhow, fast forward to yesterday. Wayne announced in a post yesterday about the future of Ruby.NET. I encourage you to read the whole thing here.
He writes:
Ruby.NET started life in 2005 as an academic research project with the goals of learning more about the challenges of mapping a dynamic language such as Ruby onto the relatively static CLI platform. When we released our first beta in 2006, many people got excited and started blogging about the project, at which time the project took on a life of its own heading towards a production quality release that people could one day actually use. The release of IronRuby last year obviously caused us to question this unstated goal. At the time we didn't know if the IronRuby project and the DLR would succeed, so we decided to continue with Ruby.NET at that stage. Last week at the Lang.NET Symposium, I presented our work on the Ruby.NET project and also had the opportunity to learn more about the progress of the IronRuby project and the inner workings of the DLR (and also the JRuby project presented by Charles Nutter).
I've come to the conclusion that the DLR is clearly here to stay - it's becoming an even more important part of the Microsoft platform. I also believe that to obtain production quality performance, Ruby.NET would need to reinvent (or adopt) something equivalent to the DLR. If we were starting the project today, there is no way we wouldn't use the DLR. Whilst Ruby.NET initially had a good head start on the IronRuby project; by incorporating the Ruby.NET parser and scanner and by leveraging the DLR, I now believe that IronRuby is more likely to succeed as a production quality implementation of Ruby on the .NET platform. I believe that ultimately there is no need for two different implementations of Ruby on .NET. So, if Ruby.NET is ultimately not going to be that implementation, then we should not waste further developer effort fruitlessly chasing that goal. There is still a massive amount `of work required to achieve full semantic compatibility, to achieve production quality performance and to get Rails to run robustly.
There have already been a number of practical and research outcomes from the Ruby.NET project, however, at this stage, I believe we (the Ruby.NET community) can make the biggest impact by levering our experiences with Ruby.NET to contribute to the IronRuby and DLR projects. Personally, I still feel we have unfinished business - we set our selves the goal of running Rails on .NET and we haven't achieved that yet. If we can leverage our experience to help IronRuby get to that point, then I'd at least have the personal satisfaction of helping see the job completed.
These are just my views. As a researcher, my prime interest is not in developing products, but in developing innovative new ideas and having an impact by having those ideas used in the real world. I'm aware that others in the community will have different goals and so will presumably have a different take on this - I'm keen to hear what you think. If anyone wants to press ahead, then the code base is still owned and controlled by you the community, so you are free to do with it as you please with our full blessing.
I'd also like to make it very clear that this decision is entirely my own - based on research and technical considerations. Microsoft did not in any way suggest or encourage us to kill the project and we thank them again for their support of the project.
I'd like to thank all of our contributors and supporters and apologize if this decision comes as a disappointment. I hope many of you will join me in contributing to the IronRuby project and see it through to a successful completion.
Cheers, Wayne.
So, what he's saying in other words is that it's best that he takes the lessons learned from the Ruby.NET implementation on the static typed CLI and contribute more towards IronRuby on top of the DLR instead. I don't think that's going to dissuade anyone, and may preclude him, but I think others are willing and able to pick up the torch. So far, my experience with the project had been good, although not as complete as I'd like. But many of those problems come from the lack of a spec instead of anything squirrely done inside the code itself.
John Lam has posted his reaction here on his blog. The invitation is out to anyone to join and contribute to the IronRuby implementation. So, all eyes turn towards the IronRuby team and anyone willing to step up to the plate...
-
Lang.NET and Rolling Your Own
Last week, the 2008 Lang.NET symposium was held last week. If you're not familiar with what that is, it's a discussion about languages, compilers and libraries within the .NET space. It's been one of those things I'd love to attend just to understand where Miguel de Icaza, Anders Hejlsberg, Luke Hoban, Jim Hugunin and others are going with their related languages.
So, there was a pretty wide array of speakers there including Tomas Petricek and his project Phalanger. If you're unfamiliar with him, I've referenced him on several occasions when talking about F# as he's pretty deep into that as well. Anyhow, he has assumed control of Phalanger which compiles PHP to IL and has recently added on Silverlight functionality as well. What's really cool is that he's now working on Phalanger on the DLR. His recap of the even can be found here.
Lang.NET Stuff
I followed Ted Neward's recaps as they were going on as to understand what all we were missing. He was good enough to provide great writeups on the symposium and can be found here:
Ted Neward gave a presentation on Scala. I don't think he sounded too pleased as to the way it went with ribbing from Don Box among others. It'll be interesting to see how Scala progresses since it has been noted that Ruby is dead and Scala is in... Scala on .NET is something that I have yet to fully explore but it's on the latter half of this year I think. Right now it's a push on F# to get myself deep in that before anything else.
Anders gave a talk as well as others. It's going to be interesting to see the collision of functional programming into C#, taking ideas from F# and so on. It's already happening with lambdas and the System.Func delegate type.
F# was very well represented this year as Luke Hoban (F# Program Manager), Harry Pierson (Microsoft IT), and Tomas Petricek. Harry has a good recap of what he saw here. It's going to be interesting this year as F# becomes more of a first class player in the .NET space. I'm loving F# in what I'm doing right now and all interested should put it on their learning list.
John Lam has a pretty good writeup as well with regards to Lang.Net as a whole here. This time Ruby was well represented with Charlie Nutter, Wayne Kelly and John Lam. John has a pretty good recap and slides of his talk and that can be found here.
Roll Your Own?
So, why am I interested? Well, compilers and languages is something I definitely geek about. I've been looking at F# for creating my DSLs as well as looking at it to create compilers, both of which it can specialize quite nicely. Robert Pickering's book "Foundations of F#" can start you on your way to that.
With all this discussion about compilers, Joel Pobar published an article in the latest MSDN magazine called "Create a Language Compiler for the .NET Framework". This is a pretty good starting point for those unfamiliar with creating compilers and unfamiliar with the lovely thing that is System.Reflection.Emit and how much of a friend it is. I done a little bit of this years ago when I was creating a compiler for some DSLs that I created. I realized that it was more trouble than it was worth, but still a worthwhile exercise. But the point of the article is stating how easy it is to create or port a language to the .NET platform. A very good read and the source code is pretty solid too.
Until next time...
-
Resharper 4.0 Early Access Program in Two Weeks?
The good folks at JetBrains have recently announced that Resharper 4.0 Early Access Program will be available in two weeks. It's like one of those long awaited things like Duke Nukem Forever, but it looks like R# will beat it to the punch, fortunately for me. For those like me, I can honestly say I haven't been as productive in Visual Studio 2008 as I can say I have been without it. Many people will use the workaround as stated many times around the blogs, but I've just stayed away until they can get it working just right. Instead, I've been happy using it with Visual Studio 2005 in the mean time.
The only thing now that keeps me with the Visual Studio 2005 sitting around continues to be BizTalk. I imagine the next Service Pack of BizTalk 2006 R2 will contain the right templates, but it's frustrating that they haven't come out yet. Either way, I can't wait until R# 4.0! Until next time...
-
Fluency in Fluent Interfaces
Scott Hanselman's recent post about the Daily Source Code 14 - Fluent Interface Edition got me to think more on fluent interfaces and a previous post of mine on ObjectMother versus Test Data Builders. Also, it comes to mind in regards to DSLs, both internal and external that has me intrigued. Partially due to my latest involvement with Ruby and F#.
Test Data Builder Example
So, let's revisit that simple example:
public class ClaimBuilder
{
private DateTime claimDate;
private Provider provider = ProviderBuilder.StartRecording().Build();
private Recipient recipient = RecipientBuilder.StartRecording().Build();
private ClaimLineCollection claimLines = ClaimLinesBuilder.StartRecording.Build();
public static ClaimBuilder StartRecording()
{
return new ClaimBuilder();
}
public ClaimBuilder WithClaimDate(DateTime claimDate)
{
this.claimDate = claimDate;
return this;
}
public ClaimBuilder WithProvider(Provider provider)
{
this.provider = provider;
return this;
}
public ClaimBuilder WithRecipient(Recipient recipient)
{
this.recipient = recipient;
return this;
}
public ClaimBuilder WithClaimLines(ClaimLineCollection claimLines)
{
this.claimLines = claimLines;
return this;
}
public static implicit operator Claim(ClaimBuilder builder)
{
return new Claim(builder.claimDate, builder.provider, builder.recipient, builder.claimLines);
}
}
As you may note I changed the Build method from the previous post to an implicit operator to save me some coding time when it comes to my builders. This is one of the very very few places where I'd recommend using this operator. Anyhow, then we'd have the calling code to look similar to this for my unit tests.
Claim claim = ClaimBuilder.StartRecording()
.WithClaimDate(new DateTime(2008, 1, 1))
.WithProvider(ProviderBuilder.StartRecording()
.WithName("Robert", "Jones")
.WithAddress(AddressBuilder.StartRecording()
.WithStreetAddress("1800 28th St, NW")
.WithCity("Washington")
.WithState("DC"))))
.WithRecipient(RecipientBuilder.StartRecording()
.WithName(James", "Smith")
.WithAddress(AddressBuilder.StartRecording()
.WithStreetAddress("1210 14th St, SE",)
.WithCity("Washington")
.WithState("DC"))))
.WithClaimLines(ClaimLinesBuilder.StartRecording()
.WithClaim("00308-1")));
This is truly powerful here to make it make sense to the reader instead of the usual black box ObjectMother approach. When building my entity objects for test, this is the main approach I use.
Other Examples
Scott Bellware has introduced the Behavior Driven Development NUnit Extensions which makes heavy use of fluent interfaces. With my deeper dive into BDD, this has been very helpful. Dave Laribee also has me on the kick as well, so lots of thanks to them for pointing me in the right direction, although some may disagree with their directions. But that's for another time and another post.
Jeremy Miller also has fluent interfaces on his StructureMap IOC container project. Some new parts with registration will be coming up with his new release of version 2.5 as noted here.
Of course I can keep rattling on with others like NHibernate and the ICriteria, Castle Windsor's fluent registration interfaces and so on. The list goes on! Very cool stuff coming out lately... Until next time!
-
RockNUG Meeting 2/13 - ASP.NET MVC
The Rockville .NET Users Group (RockNUG) will be holding their Februrary meeting on the 13th at 6:30PM-9PM. This month, Jeff Schoolcraft will give an introduction to ASP.NET MVC that we have all come to know and love, to a point of course...
The details are as follows:
An Introduction to ASP.NET MVC
presented by Jeff Schoolcraft
Come walk with me as I lead you on a gentle, relaxed tour of the ASP.NET MVC Framework. I'll demystify the forest of three letter acronyms. Then we'll take a journey through the hall of ancestors--and cousins--to discuss some influences and other players in the MVC space. We'll end up at the Grove of Hello World and, like habitat for softwarity, we'll build a demo application. Along the way we might run into some tangential trolls, but we'll cross that bridge when we come to it.
Jeff Schoolcraft is the founder of The Queue, Incorporated; a consulting shop that writes software and helps write software better. He has been in the .NET space from nearly the beginning and is still, mostly, writing web applications in C#. He tries to organize a couple Code Camps a year and is hoping to find a developer community that isn't over an hour away. When he's not immersed in code he enjoys spending time with his wife and two daughters.
Time:
Wednesday, February 13, 2007 6:30-9:00 PM
Location:
Montgomery College, Rockville
Humanities Building - Room 103
Rockville, MD
Click here for details....
Come and support the organization if you're in the area! Should be a great session!
-
Design by Contract Revisited with C# and .NET
In a previous post, I talked about various attempts at frameworks that are trying to do Design By Contract (DBC) in .NET. Many simply just come across as simple validation frameworks without the heart of DBC which is the contract. Where is the contract? Well, dig through my code and find out! It's something that I've been harping on time and time again is that without transparency to the caller and callee of the contract, it's just another validation framework. You'll hear either myself or Greg Young on that, I'm sure.
The only approach that has worked so far has been Spec# in the .NET world. Unfortunately, still a research product, isn't available for us to use commercially. So, until that time in which it is thoroughly weaved into the .NET framework as a whole outside of the internals of System.Core.dll, we have to look at alternatives.
Eiffel
Before we look at another framework, I just want to walk you through a sample of the original DBC language, Eiffel. This gives you an idea what I'm talking about.
my_list.do_all (agent (s: STRING)
require
not_void: s /= Void
do
s.append_character (',')
ensure
appended: s.count = old s.count + 1
end)
As you can see, it's clearly stated as part of the language what the requirements are, and what its return will be. That's the really slick part about it that we don't have unless we go to Eiffel.NET, but it's not using the latest and greatest .NET APIs, so it's pretty much a nonstarter. So, let's look at yet another framework.
LinFu DesignByContract
Philip Laureano, who has done a lot with LinFu including Aspect Oriented Programming (AOP) among other things has taken a stab at DBC for all .NET languages and not just C# which Spec# has done. He posted the LinFu.DesignByContract2 article on CodeProject that is well worth checking out.
Earlier, he posted one about the LinFu framework on CodeProject as well which includes the following:
- A simple IoC container
- Design by Contract framework
- Dynamic Proxy
- Reflection (Mixins, Duck Typing and Multiple Dispatch)
- Delegates with lambdas for universal event handling
- What do we expect?
- What do we return?
- What do we maintain?
- The precondition may only be weakened by inheritance
- The postcondition can only be strengthened by inheritance
public class StringCollection
{
private int count;
string[] strings = new string[5];
[EnsureCountIncremented]
public virtual void Add([NotNull] string value)
{
// NotNull doing
// Debug.Assert(!string.IsNullOrEmpty(value));
// Add value and redefine
// EnsureCountIncremened
// Debug.Assert(count == count + 1);
}
}
So, what you see here is that I put a postcondition making sure that the count is incremented by one as I'm adding a string to my array. Also, I have the precondition that my string value is not null. But, how does that work?
In order to do that we need to implement a few interfaces. Let's look at the one for preconditions.
public interface IMethodContract
{
IList<IPrecondition> Preconditions { get; }
IList<IPostcondition> Postconditions { get; }
}
public interface IPrecondition : IMethodContractCheck
{
bool Check(object target, InvocationInfo info);
void ShowError(TextWriter output, object target, InvocationInfo info);
}
Ok, so now, I need to implement that somehow for my custom attribute. That would look similar to this:
public sealed class NotNullAttribute : Attribute, IPrecondition
{
public bool Check(object target, InvocationInfo info)
{
string value = target as string;
if(!string.IsNullOrEmpty(value))
return true;
}
public void ShowError(TextWriter output, object target, InvocationInfo info)
{
output.WriteLine("string value cannot be null or blank");
}
public bool AppliesTo(object target, InvocationInfo info)
{
return target is string;
}
public void Catch(Exception ex)
{
}
}
So, it's pretty interesting and clever how this is being done. But still without the static checking of Boogie and so on, it still falls well short of real DBC.
For those interested in postconditions and invariants, those are also supported through the interfaces as shown below:
public interface IPostcondition : IMethodContractCheck
{
void BeforeMethodCall(object target, InvocationInfo info);
bool Check(object target, InvocationInfo info, object returnValue);
void ShowError(TextWriter output, object target, InvocationInfo info,
object returnValue);
}
public interface IInvariant : IContractCheck
{
bool Check(object target, InvocationInfo info, InvariantState callState);
void ShowError(TextWriter output, object target, InvocationInfo info,
InvariantState callState);
}
So, as I said, quite interesting and clever the way of handling the DBC concepts through interfaces. The libraries were also written to support the Eiffel constructs of inheritance. So, very well written I must admit.
Conclusion
I just began to scratch the surface with what you can do with this framework and it's very well written. But, still at the end of the day, it's not statically checked through a Boogie and a theorem prover to ensure the contracts hold. That's the crucial part missing in this equation. I'm sure more will come to mind on the subject. Until next time... -
C# vNext Revisited
I often rethink or have additions to my posts. This topic of what's coming in C# vNext is definitely one of them. I'm always looking for ways to push the envelope to see what I can get from the language. I have to credit such people as Scott Bellware and others to look more outside of the C# bounds and look to such things as Ruby and even F# to really open my eyes to the possibilities of this language. I'd love to see more F# features in the language as they have slowly seeped in and now pretty ubiquitous.
What I like
I enjoyed Jeremy Miller's post about what he likes about C# 3.0. I'd definitely have to concur with a lot of those things such as his and some of my own:
- Object Initializers
- Lambda Expressions
- Extension Methods
- Anonymous types
So, what am I eh about? Well, automatic properties is one of them. Not doing much for me just yet, especially for my domain models. Also partial methods have a particular use, but once again, it looks like a large potential for abuse. Bart De Smet has a pretty good writeup on them though worth checking out here. If you check out Wes Dyer's blog, he also has a good example and why you would use them. To me, it looks like Aspect Oriented Programming in a way, but I much prefer using Windsor interception, and hopefully soon the StructureMap interception.
Do We Know Any More?
Charlie Calvert, C# Community Liason, and Mads Torgersen, C# Program Manager, wrote a post recently about the future focus of C#. The first topic in this series is about dynamic lookup. What dynamic lookup is, is the ability to distinguish a type at runtime instead of static compile time.
But why is this useful? Well, in order to interact with dynamic runtimes, this is the best way to do it. The idea of using this for COM interop is also pretty interesting. I've done more than my fair share in this lifetime. Many of the things you see on PInovke.NET are ones that I either put up there or refined quite a bit, especially while using unsafe C#.
With this upcoming, could Duck Typing be far behind? After all, it has been proposed at least for VB9, although dropped. Of course in .NET, it's already supported on the foreach keyword as noted by Krzysztof Cwalina due to the fact you don't need to implement IEnumerable, and only need GetEnumerator(). But, will it go any further than that like Ruby?
-
Why am I here?
Sorry I never posted a welcome notice to this blog. Anyhow, welcome to my new home on the net. If you don't know me already, my former blog is at geekswithblogs.net. If you're here for the first time, great!
So, who am I? Well, I live and work in the Washington, DC area and actively involved in the .NET and Agile side of things in the area. I run DC ALT.NET with the help of Phil McMillan, who ought to blog more BTW.. I'm also active in planning the ALT.NET Open Spaces, Seattle event coming in April. We're going to have a great crowd there, but space is limited.
Anyhow, my interests are many including:
- Agile/XP
- Functional Programming (FP)/Object Oriented Programming
- Compilers
- ASP.NET
- BizTalk (pays the bills)
- SharePoint
-
CMAP Meeting 2/5 - User Experience (UX)
Central Maryland Area .NET Professionals (CMAP) is holding their next meeting on Tuesday, February 5th, 2008. This month looks to be a great one by Michael Wolf on the User Experience (UX). In the agile methodology, it is quite an essential piece that often gets overlooked. It's obvious too many times after looking at The Daily WTF to see plenty of evidence of that.
Alon Salant posted a good set of Agile User Experience Resources that's pretty extensive on how UX fits into the Agile/XP practice. This includes the Yahoo UX group, articles, practices and so on. I've used this as a resource a couple of times when thinking about UX.
Anyhow, here are the details:
UX is the new UI: It's not the framework, it's how you use it.
By: Michael Wolf
As developers we love our frameworks and the elegance of code. Yet we often spend so much time staring at code we forget the essential user centered problem were trying to solve. In addition, due to the amazing and ever evolving frameworks/ tools / controls we have at our disposal, we often forgo what's most usable for what's most available. In this talk we will delve into these problems using examples written in Microsoft Silverlight, including the winning solution from the Microsoft Phizzpop Design Challenge LA.
About Michael Wolf - Michael Wolf has spent over a dozen years building web applications and is currently a Senior Rich Internet Application Developer for global leader Cynergy (www.cynergysystems.com). He recently was a member of the winning team for Microsoft's PhizzPop Development Challenge in LA, successfully developing an interactive media platform for a mock media conglomerate in 3 days using Microsoft Silverlight technology. Starting with his first web application in vi using Mosaic in 1994, Michael has been heavily involved in application development holding numerous senior development positions at Washington, DC and Baltimore, Md base companies including Real Magnet, Blue Atlas Interactive and Bally's Total Fitness.
Date/Time:
2/5/2008 - 6:30PM
Location:
HCC Business Training Center
6751 Columbia Gateway Drive
Columbia, MD 21046
In addition to all of that, Mike is part of DC ALT.NET, and it's great to have him as part of our group. Hope to see a great turnout! -
Continuing Adventures in F#
Update: Added more F# samples and the foundations of functional programming
This is an ongoing adventure into F# as I think it has quite a future as a first-class citizen in the .NET space. Now, if we can say the same for Spec#. I don't mean to be a link blog by any means, but it helps me to gather these things up as I go along:
In a previous post, I've begun a pretty fun adventure into F#. I'm still working on quite a few samples to post here shortly, but in the mean time, I've collected a bunch of samples that I think are pretty cool and well worth a look. I'm currently digging through Robert Pickering's book "Foundations of F#". I'm especially interested in his DSLs which I hope to cover here shortly.
For those interested in the foundations of functional programming, check out Bart De Smet's blog for his series on the subject:
- F# Latest release
Don Syme discusses the latest release of F# and the differences - Fibonacci Sequence in F#
Scott Hanselman gives Fibonacci sequence code for many languages including F# - Sorting odds and evens in F#
Claudio Cherubino takes a sample from LINQ in C# and translates to F# - Practical F# Parsing by Harry Pierson
Semantic Productions (1)
Semantic Productions (2)
The Abstract Syntax Tree
Syntactical Productions (1)
Syntactical Productions (2)
Active Patterns
Unit Testing
The Parse Buffer - Improve your C# with F#
Compare line for line samples of C# versus F# - Really Digging F#
Samples such as factorials and high-order functions - Project Euler problems in F#
Problem #1 in F#
Problem #1 (alternate)
Problem #6
Problem #9 - Infinite Cheese Fractal with WPF and F#
- SQLCLR Integration with F# Part 1
Lewis Bruck covers a simple SQLCLR integration using F#
Wrapup - F# Latest release
