The re-factored code using the Repeat.Times methods.

You can see how the second code sample is much cleaner than the first. A lot of the messiness of the first code sample comes from talking to the compiler instead of talking to objects. What do I mean by that? Well, in the first example we have to tell the compiler what the delegate should return

You'll also notice some ugliness inside of the delegate body.

Here, I was incrementing a class member and checking to see if it was odd or even. If it was even, I'd return true, otherwise I'd return false. This allowed me to control the number of times the IDataReader.Read() method would return true. In this case, it would return true once, then the variable would be incremented to an odd number and the Read method would return false.

That's all part of me telling the compiler what to expect, when what I really want to do is just tell my objects what to do. This episode of the Alt.net podcast also talks a little bit about class-based programming versus object-oriented programming.

The code base, while touted as a "a real-world sample written using ASP.NET MVC.", is not without some problems. The commentary on Twitter soon after it's release was pretty negative.

This is why Oxite is not good. http://pastie.org/339644

Rob Conery has a great post where he outlines some of the issues with the Oxite code base and how they can be fixed. He has already offered some patches to the team.

That's what I mean when I say this is a great thing. Since the team is doing all their work out in the open, we get to see how it evolves. I fear that a lot of the ASP.NET MVC code that we see written the first few years after it is released will look very similar to the Oxite code. Hopefully, the refactoring of the code base into something that embraces the strengths of MVC will be done in public as well so that first time MVC developers who find themselves writing the same code that the Oxite team has will have a lot of resources available.

I'd encourage everyone interested in the ASP.NET MVC product to watch the evolution of Oxite closely and contribute to the development.(1)

(1) That doesn't include me for quite some time as we're getting ready to have a baby soon. You don't want to see code I've written on only 4 hours sleep over two days.

Mike Moore was kind enough to invite me on the alt.net podcast to talk about the recent jQuery announcement by Microsoft. Chris Brandsma, Rick Strahl, Dave Ward, Bertrand Le Roy, and Steven Harman were also on the podcast.

This was a great discussion. It was especially nice to have Bertrand during the discussion. If we had any questions about how or why Microsoft did something, we could ask him. I was happy to hear that one of the reasons they chose jQuery was because they didn't want to write their own CSS selector functions for MS AJAX. It's nice to see that Microsoft sees the benefit in not always reinventing the wheel. Now, any new features or improvements that Microsoft would have made to their own selector engine can be contributed towards jQuery, making it a better product for all of us.

Some topics we cover in the podcast:

• What is functional programming, and why should we care?
• Types of applications that would and wouldn’t benefit from F#
• How F# differs from C# 3.x and Javascript
• How F# is being used (games, scripting, data analysis and scrubbing, etc.)
• F# pattern matching
• Using F# in your C# or VB based applications today
• Getting started: F# Interactive, reading the F# source, books and resources
• Interaction with DLR
• Functional features we’d like to see in C# and VB
• Spec# and Sing#

The post containing the podcast is turning into a great resource if you are interested in Functional Programming and F#. Matt provided us with a lot of links and we've been adding new links as we find them. If you know of any Functional Programming or F# links, feel free to leave them in the comments here or at the Herding Code post.

I found a great answer over in this forum.

In both Java and .NET, classes can only inherit from one class but a class can implement multiple interfaces. So consider the following code.

Essentially the answer is: The compiler tries to run the code specified by the static method in a class. Since an interface doesn't provide an implementation details, there is nothing to run. You could, if the compiler would let you, cast the interface to the concrete type that's actually being represented. But that defeats the purpose of declaring an using an interface.

I do wonder if type inference could be used to route around this problem?

New Languages Considered Harmful

I can't disagree more with this post.(1) There's no research or study that shows that learning impedes further learning. Once you learn how to program, moving between languages becomes easier. Every language has some kind of flow control syntax, some way to declare a variable, and some way to encapsulate code. You do have to think a little differently if you switch between OOP, functional, and procedural languages. But even Scheme has an if-else statement. It doesn't take much effort to learn a new language, but it does take a lot of effort to master a programming language.

1. I think I could disagree more with this post if I really tried, but I know I disagree enough to make a post.

There are three different values, or types, that a variable can have in JavaScript, null, undefined, and the value you set.

A variable is null if you explicitly set it to the null value or if it receives a value from an expression that results in null; A variable is undefined if you declare it and haven't assigned a value to it yet. The tricky part about null and undefined is that they are equal, but are two separate types. Consider the following code.

So how do we differentiate between null and undefined variables? By using either the typeof function or the identity(===) operator. The identity operator has an evil twin (!==) that returns true if the object is not of the type you passed. The typeof function is defined in the JavaScript global object and returns a string containing the name of the type of object passed to it. The identity operator is a binary operator that compares the types of the two objects being compared and returns a boolean.

n.b. If you pass "null" as an argument to a function, typeof will return "Object", but the object will === null.

So, how does this affect the logical OR operator? Well, both null and undefined are evaluated to "false" by the || operator, but the argument is still declared in the scope of the function and you can assign a default value to it. It's important to know the distinction between null and undefined. A function call may result in a null return value, a failed function call may result in an undefined value.

Editor's Note: I don't know what Visual Basic did to anger the Gods of Computer Science, but think about it for a second: they were a dynamic language that ran on a bytecode-based platform, used dynamic typing and late name-based binding by default, provided a "scripting glue" to existing applications (Office being the big one), focused primarily on productivity, and followed a component model from almost the first release. Then, after languishing for years as the skinny guy on the beach as the C++ developers kicked sand on their blanket, they get the static-typing and early-binding religion, just in time to be the skinny guy on the beach as the Ruby developers kick sand on their blanket.

Oh, and to add insult to injury, the original code name for Visual Basic before it got a marketing name? Ruby.

Whatever you did, VB, your punishment couldn't have fit the crime. Hopefully your highly-publicized personal hell is almost over.

While I agree about the dynamic typing and so forth. The reason VB got kicked around was:

1. The CS majors thought that it promoted bad code written by bad developers. In reality, it promoted bad code written by inexperienced developers which still managed to meet whatever dorky requirements they had for the tiny application they were writing. Which is OK in my book. You weren't writing eBay in VB, you were writing Sally's strudel recipe database.
2. A complete and utter lack of pain-free inheritance. Sure you had editor inheritance, but that's no way to run a language.

I'm not going to debate the merits of TDD right now, did enough of that on Twitter last night ;), but I did notice something interesting that I hope the group conducting the test follows up.

It's in a PDF so I can't quite link to the appropriate charts, but they are regression charts on page 10 and 11. One compares quality to # of tests written and the other compares productivity to # of tests written. (I'm summarizing). The interesting part to me was that there were some of the participants in the TL (test last) group that scored higher than some of the TF(Test First) group members. In fact, if I'm interpreting that chart correctly, the highest quality code was written by members of the TL group.

The second chart appeared to show that the overall productivity for ALL group members was low, with the exception of a couple of members who fell way outside of the C.I.

I also liked that it appeared that the regression lines were hand-drawn on after the fact.

Eh, just don't add them to the URL. The ASP.NET MVC assumes you know what you are doing. I'm sick of frameworks babysitting me.

I replied:

and yet you use a managed language that holds your hand and cleans up your memory for you.

Which came out a little harsher than I meant. But my gist is, isn't a GC system babysitting you already? How much abstraction do you want out of a framework?

Bottom line is: a web application, is basically an abstraction for sending and receiving headers and HTML to/from a browser. You can dress that process up with domain models and other abstractions. But you *can* build a web application strictly using sockets if you really don't want to be babysat.

Now that's absolute crazy talk. No one wants to build an eCommerce site by sending packets over a pipe. That'd be a crazy as writing an operating system today using 32-bit/64-bit x86 assembly. So we accept some levels of abstraction. In fact, we embrace abstraction. Hunting down errors in a memory dump is no fun. Neither is making sure all of your string buffers are properly allocated and sized. We don't want to have to malloc() and free() char buffers when we want to concatenate strings, so we make a StringBuilder class that handles all the nastiness for us.

It's also not fun to get stuck in a framework that is so opinionated that when you stray from it's primrose path you are assaulted by rabid dogs. Opinionated software is good, but a framework should allow you to inject your own opinion.

So what do you really want out of a framework. Ultimately, I think developers really want a framework that will nerf the sharp corners of the underlying hardware for us. We want to be babysat.But we also want the freedom to rip things out and route around the hard parts. And frankly, we want frameworks that work for us, not against us. It's when the framework is working against us that we rail and rant and cry out for change.

Me? I want the full on Star Trek-Computer:write-me-a-program-that-will-let-me-sell-my-"My Little Pony"-collection-on-eBay" framework.

Feel free to leave your own thoughts below. Difficulty: No Linking to Spolskys "Leaky Abstractions"