ParallelFX CTP released

The ParallelFX (PLINQ) CTP was also released yesterday. Not so coincidentally I also purchased a quad core yesterday. Microsoft has created a new site dedicated to parallelism. I will be playing with ParallelFX a lot in the weeks to come and also with Haskell. For a neat example of how to do parallelism in Haskell see this link.

Finally some news on PLINQ

It's here (almost)! PLINQ is a technology that allows developers to parallelize their LINQ queries. Check it out at MSDN. Competing platforms are so far behind .NET in this area it's laughable. They're still debating whether to add first-class closures to Java and Ruby still doesn't support native threads. By coaxing developers into writing functional code with LINQ Microsoft has done something truly brilliant. New programs written in .NET 3.5 will be ready to be parallelized just as Moore's law squeezes processing power in its icy grip. Imagine adding a single query operator to your query and seeing speed increases of 30% and more! Also see PTasks, a library for parallelizing procedural code. I can't wait for .NET 3.5!!

The Luddite Developer

Throughout the short history of commercial software development we see the same dynamic repeat itself again and again: 1. New abstractions are introduced which increase developer productivity. 2. Developers resist these abstractions because they a) legitimately need to maintain low-level control to satisfy requirements OR b) they don't want to learn the new abstractions and tools required to use them 3. The developers that resist for reason b either suffer or eventually capitulate because of competitive pressure. When C was created many assembly developers resisted using it even though the benefits were obvious. Many C++ developers still resist writing client applications in Java and C#. Many Java developers still resist using slower, more powerful languages for writing web applications where performance is far less important. In some cases these decisions are justifiable (see reason a) but they are edge cases.

When a developer chooses, all other things being equal, to use a low-level abstraction instead of a high one it’s worth asking them why. If they attempt to justify their decision on the grounds of “simplicity” chances are that they are motivated by reason b). High-level abstractions are simpler than low-level ones by definition. They reduce code size and increase code clarity. Most of the time what the developer is really saying is “I didn’t want to learn anything new.” So why do some software developers resist learning new things? It’s not laziness. A developer who manually writes the same code with slight variations a hundred times and spend countless hours maintaining it can hardly be accused of being lazy. The real reason is that they are afraid of new technology.

So how can a software developer possibly be afraid of technology? Two words: cognitive dissonance. These individuals spend their lives creating technology to improve the productivity of accountants, managers, and housewives but insist on coding GUI’s by hand. They use REST instead of web services because they don’t want to learn how to generate a proxy. They’ll write reams and reams of repetitive code instead of learning a new domain-specific language and every argument they’ll use to justify it can also be used to argue that they should get rid of their compiler and write bytecode by hand.

It’s easy to understand why software developers can be afraid of new technologies. Software development is extremely challenging for many reasons. Once having successfully developed software using one set of abstractions a developer would be wise to consider carefully the decision to learn new ones. This is why it’s so important to familiarize yourself with a variety of different platforms, technologies, and development approaches before you are put on a deadline. Once you understand the strengths and weaknesses of a variety of development paradigms, platforms, libraries, and tools you can stop wasting time fearing the unknown and start fearing the known.

Do you know any luddite software developers?

The last configuration handler I'll ever need...really

Scott Weinstein has a fantastic approach to deserializing configuration sections. I would like to propose an improvement though: make the class generic. Here's a simplified version:

Public Class XmlSerializerSectionHandler(Of T)
Implements IConfigurationSectionHandler

Public Function Create(ByVal parent As Object, ByVal configContext As Object, ByVal section As System.Xml.XmlNode) Implements IConfigurationSectionHandler.Create


Dim nav As XPathNavigator = section.CreateNavigator()

Dim ser As New XmlSerializer(GetType(T))

Return ser.Deserialize(New XmlNodeReader(section))

End Function

End Class

This eliminates the need to embed the type attribute in the data tag and moves it into the type declaration in the section tag. This...

<namessection type="TheMechanicalBride.Web.NamesSection, TheMechanicalBride.Web">
<name>Jafar Husain</name>
<name>Johhny</name>
</namessection>

Becomes...

<namessection>
<name>Jafar Husain</name>
<name>Johhny</name>
</namessection>

snip

<section name="namessection" type="TheMechanicalBride.Web.XmlSerializerSectionHandler `1[[TheMechanicalBride.Web.NamesSection, TheMechanicalBride.Web]]"/>


This is a minor modification but is definitely an improvement as the tag that contains the data no longer needs any awareness of the method by which it is serialized and deserialized.

Slaying CSS bugs with AJAX for ASP.NET

Recently I've been working on an ASP.NET project and am writing a whole host of custom controls. I really can't emphasize enough the power of custom controls. They are code which writes code, allowing you to build DSL's for expressing user-interface elements.

When building custom controls it's nice to make the elements in the control scale with the size of the control itself. This probably means that you will be using tables for any sufficiently complex control. Unfortunately in IE 5 and 6, if you nest a textbox inside of a table cell and make its width 100% the end of the textbox get's cut off thusly:



Attempts to correct this by specifying a value for margin-right are rudely ignored by IE. You can test this yourself by trying out the following code:


<span ><span id="ctl00_Main_PercentField1" style="display:inline-block;width:50px;"><table border="0" style="width:100%;"></span>
<span style="font-family: courier new;"> <tr></span>
<span > <td><div><input name="ctl00$Main$PercentField1$TextBox1" type="text" value="23" id="txt" style="width:100%"></div></td></span>
<span style="font-family: courier new;"> </tr></span>
<span ></table></span></span>

After confirming that this problem was a known bug I did the first thing most developers do: I bitched and moaned. There is not much web developers can do about browser CSS bugs. Or can they?

I've been doing heavy DHTML programming since the days of IE4 and am aware of a little known property called clientWidth. This property gives you access to the actual width of a UI element in pixels. All I needed to do, I figured was get the textbox using the DOM methods and set the CSS width to the clientWidth and subtract some absolute value. Sure enough it worked like a charm. Ten pixels is the magic number for some reason.



In addition to custom controls I've also been writing control extenders using AJAX for ASP.NET. I've complained about AJAX for ASP.NET in the past but I must admit it's a very elegant way of encapsulating javascript behaviors. It was child's play to create a custom extender that I could point to a textbox that was positioned inside a table. Here is the code:

FixTextBoxWidthBehavior.js
----------------
Type.registerNamespace('TheMechanicalBride')

TheMechanicalBride.FixTextBoxWidthBehavior = function(element)
{
GE.Water.Web.FixTextBoxWidthBehavior.initializeBase(this,[element]);

}

TheMechanicalBride.FixTextBoxWidthBehavior.prototype = {

initialize: function()
{
TheMechanicalBride.FixTextBoxWidthBehavior.callBaseMethod(this,'initialize')

var e = this.get_element();
e.style.width = "" + (e.clientWidth-10) + "px"


},

dispose : function()
{
TheMechanicalBride.FixTextBoxWidthBehavior.callBaseMethod(this,'dispose')


}
}

TheMechanicalBride.FixTextBoxWidthBehavior.registerClass('TheMechanicalBride.FixTextBoxWidthBehavior', AjaxControlToolkit.BehaviorBase);



------------------

FixTextBoxWidthExtender.vb
---------------------




Imports System
Imports System.Web.UI.WebControls
Imports System.Web.UI
Imports System.ComponentModel
Imports AjaxControlToolkit


<Assembly: WebResource("TheMechanicalBride.FixTextBoxWidthBehavior.js", "text/javascript")>

Namespace UI.WebControls

<ClientScriptResource("GE.Water.Web.FixTextBoxWidthBehavior", "GE.Water.Web.FixTextBoxWidthBehavior.js")> _
<TargetControlType(GetType(TextBox))> _
<RequiredScript(GetType(CommonToolkitScripts), 0)> _
Public Class FixTextBoxWidthExtender
Inherits ExtenderControlBase

Public Sub New()

End Sub

End Class

End Namespace



And that's it. The lesson: in the age of modern browsers you don't always have to accept CSS bugs. Get hacking.

LINQ to Validation

I spent the weekend looking at the Enterprise Library 3.0 validation block. It's fantastic and long overdue. Developing this library was a no-brainer. I wrote something similar (though much less ambitious) as soon as I learned to use attributes in C# 1.0. Although it is a great framework as is I can't help but imagine ways in which LINQ could make it even better.

Validation has annoyed me more than any other problem with perhaps the exception of the object-relational mismatch . Validation logic should be applied at every tier: client, server, and database. However writing and maintaining the same validation rules in Javascript, a server-side language, and then again in SQL is so labour-intensive and thankless that I suspect few people actually do it.

Several attempts have been made to solve this problem in the past with limited success. Some code generators allow you to express business rules in a domain-specific language which is then translated into various target languages. There have also been attribute-based solutions that use XSL as the validation language. The problem with all these solutions is that they force the developer to use yet another language. This is necessary because the language has to be able to be expressed as data so that it can be analysed and converted into other languages. Unfortunately this means that the validation language has to be stored in config files or strings putting it out of reach of the type checking and refactoring tools available in most IDEs. Does this problem sound familiar? It should. It's the same problem we have with data access code today.

Now that LINQ is coming we will have two languages that are powerful enough to express any kind of validation rule, will have full IDE support, and can also be converted into data and thus into other languages: VB.NET and C#.

LINQ is the gift that keeps on giving. As I've written in this blog many times before, the applications for turning code into data extend far beyond improving database integration. Let's examine the ASP.NET PropertyProxyValidator control that comes with the validation block in EL3. You associate it with a property on an object and when the user attempts an action it does a server postback, calls the EL3 Validator object, and displays an error if one is encountered. This keeps you from having to create a custom validator control that performs the same validation you are already doing in your business object. However most validation (regular expression validation, string length validation) can be done in client-side code. The postback is unnecessary. Unfortunately performing the validation on the client-side means writing Javascript as well as server-side code (after all, the user's browser may have javascript turned off). Now imagine that, post-LINQ, a new validation attribute called ExpressionValidatorAttribute is added to the EL3 validation block:

public ZipCodeValidatorAttribute : ExpressionValidatorAttribute<string>
{
public override Expression<Func<string,bool>> GetExpression()
{
return x => new Regex(@"[0-9][0-9][0-9][0-9][0-9]").IsMatch(x);
}
}

Notice that we are returning a validation function as an Expression which means that it instead of returning a delegate it will return a data representation of the function. An ASP.NET validator control could retrieve the expression using reflection and convert it to the following Javascript function without breaking a sweat:

function (x){
return /[0-9][0-9][0-9][0-9][0-9]/.exec(x) != null;
}

It could then run this function on the client-side, avoiding a postback. On the server-side the validation object would just compile the expression and run it (which could be done once and cached). This would allow us to use the same code for validation on the client and server-side!

Javascript is actually a very powerful functional language. You can even translate LINQ queries to it without much effort. In fact the only validations that could not be converted to Javascript would be those that require access to some server-side resource. In practice this is rare.

Almost all validation logic is functional because it doesn't modify the state of the objects it inspects. It takes some data as an input and returns a single boolean. Therefore most validation can be expressed using lambda functions and can therefore be converted to lambda expressions. Voila! We've solved the problem of duplicated validations without having to rewrite code in different languages, learn a new language, or leave the comfort of Visual Studio.

Haskell for C# 3 Programmers

I've been occupying myself as best I can, waiting impatiently for .NET 3.5 to come out. In the meantime I've been playing with Lisp and Haskell, two of the languages with the most cache among the smart folks who hang out at Lambda the Ultimate. Well it’s happened: I've fallen head over heels for Haskell. It's just so beautiful. It is a pure functional language and is therefore limited in the kinds of operations that can be performed. As a result a little bit of well-thought out syntax to support these operations goes a long way towards improving readability.

It occurs to me that it is worthwhile to introduce C# users to Haskell because many of the improvements coming in C# 3.0 (and many of those introduced in C# 2.0) are actually inspired by Haskell. Learning Haskell is a great way of training yourself to think functionally so you are ready to take full advantage of C# 3.0 when it comes out. There are a variety of Haskell tutorials available on the internet so I will just focus on some similarities between C# and Haskell with the aim of deepening your understanding of both.

Type Inference

Haskell and C# 3.0 both have type inference. In C# 3.0 you write this:
var number = 3;

In Haskell you write this:

number = 3

Haskell’s type inference is a quite a bit smarter than C#'s, but I’ll give you examples of that later.

Lazy evaluation and Streams

In C# I can create a stream of all natural numbers like this:

IEnumerable<int> NaturalNumbers()
{
var i = 0;
while (true){
yield return i;
i++;
}
}

The reason that this loop does not continue forever is that the algorithm stops as soon as a yield command is reached and resumes where it left off when it is started again. In Haskell you can duplicate this behavior by using the colon operator to construct streams.

nat :: [a]
nat = 0 : map (\x -> x +1) nat

This function specifies that the first item in the stream is 0 and then the next result is a list derived from chasing the function's tail and applying a lambda to each item. The map function is equivalent to select in C# 3.0. The first item will be 0, the next will be 1 because the previous was 0, and the next will be 2 because the previous was 1, and so on. The expression on the left side of the colon is an item and the right side is a list. You can build lists like this in Haskell:

0: 1: 2 : 3: 4 : [] -- [] is an empty list in Haskell

This syntax is useful because it signals that the algorithm can stop as soon as it gets a value that it needs, just like yield. It is also very useful to express lists using this colon separated syntax when you are creating recursive list processing functions but I’ll explain that later. For now just make sure you can recognize this syntax as the construction of a list.

Functions, Functions, Functions

It probably won’t come as a shock to you that functional programming relies heavily on functions. Consequently Haskell provides all sorts of useful syntax for manipulating them. The thing that caught me off guard when I first tried to learn Haskell was the function signatures. Look at this example of a function that adds two integers:
add :: Integer -> Integer -> Integer
add x y = x + y
Does this seem odd to you? You might have expected to see something like this:
add :: (Integer, Integer) -> Integer
add (x,y) = x + y

In fact the definition above will work, but it's not really the preferred way of defining functions in Haskell. If you read the first function signature left to right it would say: “add is a function that accepts an integer, which returns a function that accepts an integer, which returns an integer.” One of Haskell's elegant features is that you can take a function that accepts n arguments and convert it into a function that accepts n-1 arguments just by specifying one argument. This is known as partial application. For example given the first add definition I can do this:
addone = add 1 -- returns function that accepts 1 argument

addone 5 -- this returns 6

In Haskell all functions accept a maximum of one argument and return one value. The value returned with be another function with one less parameter until all the arguments have been specified in which case the output value is returned. As I’ll explain later this behavior is very useful when writing certain types of recursive functions.

Recursion

Pure functional languages have no loops. Instead they rely on recursion to repeat operations. Recursive functions have a terminating case and an inductive case. As a result you often see code like this (C#):

public int Add(int x, int y)
{
if (x == 0) // terminating case
return y;
else
return Add(x-1,y+1); // inductive case
}

Haskell allows you to specify the terminating case in a different definition than the inductive case. This is called pattern matching and results in a much more declarative style of coding:


{-- function signature (takes two Nums, returns a Num) --}

add :: Num a => a -> a -> a
add 0 y = y -- terminating case
add x y = (add (x-1) (y+1)) -- inductive case
Take a look at the add function’s signature. add is a generic function. Pretend that "a" is "T" and “Num a =>” is "where T : Num" and it will be a lot clearer. In fact our add function will work on all numeric data types that implement the Num interface (Integer, Double, etc). This doesn’t work in C# because you can’t include operator definitions in an interface. In Haskell, operators are just like any other function and are not bound to a particular class. They just use a symbol instead of a proper identifier. This allows you to include them in interface definitions and thus use them in generic functions.

Now some of you might be asking “Isn’t all this recursion awfully expensive?” No, because Haskell and many other functional languages are equipped to recognize a particular kind of recursion known as tail recursion. When Haskell recognizes this type of recursion it translates it into a simple loop so that the stack doesn’t grow. For instance our C# version of Add above could be translated to the following by a smart compiler:

public int Add(int x, int y)
{
do {
if (x == 0) // terminating case
return y;
else
{
x = x-1;
y = y+1;
}
} while(true);
}

So how do you tell when a function is tail recursive or not? It’s easy. If a function ends with a call to the same function it is tail recursive. The add function defined above is tail recursive because at the end of function add is called again. Some functions are not tail recursive which means they do grow the stack. Take the following flatten function which takes a list of lists and flattens it into a list:


flatten :: [[a]] -> [a]
flatten [] = [] –- if list is empty, return empty list
flatten (y:ys) = y ++ (flatten ys)


Notice that the last operation to execute is the list concatenation (++) function. This means that the concatenation function must wait for a result from the recursive call to flatten before it can finish its computation. As a result flatten will consume both time and stack space because it will have to keep track of where we are in each previous recursive call.

The good news is that we can take many recursive functions and convert them into tail recursive functions using a straightforward technique. We introduce an accumulator function that adds a new parameter and uses it like a variable to store the computation done so far.

flattenAcc :: [a] -> [[a]] -> [a]
flattenAcc acc [] = acc
flattenAcc acc (y:ys) = flattenAcc (acc ++ y) ys

flatten = flattenAcc [] –-partial application

I want you to notice that we are using the colon list syntax in the inductive case definition of flattenAcc. This is a great example of pattern matching. We are effectively saying that in this version of flattenAcc y represents the first item in the list passed as the second parameter and ys represents the rest of that list. Haskell uses its own syntax in its pattern matching expressions resulting in very readable code.

In our revised version the last procedure called in flattenAcc is flattenAcc. This makes our function tail recursive. In order to accomplish this flattenAcc effectively stores the state of the flattened list so far in the newly introduced "acc" function parameter. Remember that when a tail recursive function get translated into a loop the function parameters act like variables. Note that we don’t need to specify a type signature for flatten because Haskell infers it.

*Note: Derek Elkins and Cale Gibbard point out in the comments that tail recursive functions are not always preferable to recursive ones because of Haskell's lazy evaluation. If you can write a non-recursive function that uses the colon syntax it is probably better than a tail recursive one that doesn't. This is because Haskell's lazy evaluation enabled you to use the non-tail recursive version on an infinite stream without getting a stack overflow.
Now you’re familiar with the basic concepts of functional programming. Next time we’ll look at features that inspired C# query comprehensions and nullable types.