Even if you don’t care a lick about Ruby, you should read Why’s (Poignant) Guide to Ruby. It is by far the most facinating (and freaky) technical book I’ve ever read.

I spent a couple of hours chatting with Neal Ford from ThoughtWorks yesterday. Ted Neward had virtually introduced us a few months ago and he was in town for MTS, so he arranged a meeting. I had asked Ted to introduce me to some dynamic language folks for some research and public debate purposes, and Neal was one of the people he hooked me up with. Unfortunately, this was right before I changed roles and got real busy. Of course, dynamic languages in general and Ruby in particular plays a large role in Edge Architecture, so I’m thankful Neal took the time to drop me a line and meet with me.

Above all else, talking to Neal made me realize that I just don’t know enough about dynamic languages, which limits my ability to discuss them. To date, I’ve flirted with them, but haven’t made a real commitment. For example, I’ve played around with Instant Rails, but hadn’t actually installed Ruby yet. It was time to re-image my dev partition anyway, so I’m going to try using Ruby exclusively for a while.

Here’s a brain dump of some of what we talked about. Not sure what it all means yet, so I’ll try and refrain from making commentary.

• Hungarian notation for interfaces (i.e. ISomething) is a big code smell. This has nothing really to do with Ruby or dynamic languages, but it’s an important point that I wanted to include here. Neal’s point is that the interface defines the semantics of the type and the concrete class is an “implementation detail”. In other words, contract-first isn’t just for web services. Apparently, ThoughtWorks doesn’t use ADO.NET directly primarily because the interfaces “aren’t pervasive enough” and are difficult to mock out. Also, they’re using Rhino Mocks which I wasn’t previously aware of.
• For all the debate about static vs. dynamic languages, it seems like the value Ruby brings is in meta-programming rather than dynamic typing. Certainly, that’s one of the big differentiators for Ruby vs. other dynamic languages like Python. While Rails has pushed the popularity of Ruby thru the roof recently, Neal seems much more enamored with Ruby than Rails.
• There is an even bigger gulf between dynamic and static typing proponents than I had thought. I brought up Singularity, which uses static typing exclusively to deliver a provably dependable system. Neal disagreed with that approach, pointing out that “tests are the best way of encoding the specification of the system” rather than compile time checking. Given my lack of expertise in this space, I’m withholding comment (for now) but I’m guessing the truth is somewhere in the middle.
• However, while the dynamic vs. static typing gulf is big, meta-programming is potentially the bridge. I don’t believe meta-programming is exclusive to dynamic languages. Certainly, some of the new features in the “Orcas” versions of C# and VB bring more expressiveness to the languages while still remaining type safe.
• All this meta-programming leads to domain specific languages. Ruby has strong support what Martin Fowler called “internal DSLs”, but Neal thought over time the focus would shift to external DSLs as they are more expressive and not constrained by the semantics of an existing language. Obviously, we’re pretty heavily focused on DSLs. However, Neal did think our focus on graphical DSLs is misplaced. He called them a “hangover” from CASE/UML tools. He rightfully pointed out that “business analysis speak English”.

All in all, it was time well spent. Neal, I hope we can pick up the conversation again sometime.

I never really missed Web Application Project support in VS05 until I realized what I could do with it. I’ve been experimenting with LINQ and wanted to be able to use it in a web application I’m prototyping. Under the file system model, there’s no easy way to change the compiler used for dynamic compilation of web pages. With WAP, it’s no problem.

If you’ve got both WAP and LINQ installed, you can enable LINQ support in your web apps by doing the folllowing.

1. Open your WebApp.csproj file in notepad.
2. Add references to System.Query, System.Data.DLinq and System.Xml.XLinq.
3. Change the Target Import element to import $(ProgramFiles)LINQ PreviewMiscLinq.targets instead of $(MSBuildBinPath)Microsoft.CSharp.targets

That’s it! Seems simple, but it let me bind a GridView to the following function:

public static IEnumerable GetTitles()
{
  var con = new SqlConnection(Properties.Settings.Default.PubsConString);
  var db = new Pubs(con);
  var q = from t in db.Titles select t;

  return q;
}

It would be even cooler if I could simply write that query in the conext of the ObjectDataSource, but of course ObjectDataSource doesn’t know about LINQ. I imagine a LinqDataSource would be a logical next step.

Having written about Ruby in the scope of the Compiler Dev Lab and the Dual Schema Problem, I was interested to come across the Ruby.NET project from Queensland University of Technology. From the Ruby.NET home page:

Our goal is to create a compiler for the Ruby language that targets the .NET CLR. We aim to support 100% of Ruby language semantics, including all dynamic constructs such as closures and continuations. We plan to generate 100% managed and verifiable CIL code.

Sweet!