Matthew Podwysocki's Blog

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...

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.

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:

• Day One
• Day Two
• Day Three

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...

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!

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!

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

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
  

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