Matthew Podwysocki's Blog

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

#light

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.

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

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)

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

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

#light