Wednesday, November 30, 2005
World's dumbest spammer

You make the call on this one... cut & pasted directly out of the email (after the horizonal rule):

Subject: Better degree-better pay!

You have 2 options here,

Option 1 - You can put ANY text you want in here.

Option 2 - We will fill it in with the text only portion of the

html message if you put the macro UNIVERSITY DIPLOMAS




If you qualify, no required tests, classes, books or examinations.


Bachelors', Masters', MBA's, Doctorate & Ph.D. degrees available in your field.






in here.

NOTE: Some email clients don't disply html data. In that case what you

put here will be seen by the recipient. If the email client does

display html data then this will NOT be seen by the recipient.

Based on this you may wish to put a text version of your add here;

however, you can also put some macros here to make the message

more random.

Wednesday, November 30, 2005 3:02:26 AM (Pacific Standard Time, UTC-08:00)
Comments [3]  | 
 Monday, November 21, 2005
The immutable string

Mark Michaelis posted a challenge: modify a string such that the following would print "Smile":

class Program
  static void Main()
      string text;
      // ...
      // Place code here
      // ...
      text = "S5280ft";

His solution?

class Program
  static void Main()
      string text;
      unsafe {
          fixed (char* pText = text) {
              pText[1] = 'm';
              pText[2] = 'i';
              pText[3] = 'l';
              pText[4] = 'e';
      text = "S5280ft";

My answer; note that I believe mine to be cleaner, more elegant, and far far more dangerous, since it never uses any sort of unsafe code:

class Program
  static void Main()
      string text;

      string internedText = "S5280ft";
      MethodInfo mi = typeof(string).GetMethod("InsertInPlace", 
        BindingFlags.NonPublic | BindingFlags.Instance, null,
        new Type[] { typeof(Int32), typeof(string), typeof(Int32), typeof(Int32), typeof(Int32) }, null);
      mi.Invoke(internedText, new object[] {0, "Smile", 1, 7, 5});      

      text = "S5280ft";

The point? Playing with Reflection can be dangerous... oh, and it helps to know that strings are only as immutable as the platform forces them to be. In this case, my little hack would only be possible because under the covers, .NET doesn't really have immutable strings--it just doesn't let YOU modify them. :-)

(By the way, same trick is available in Java, using the same approach. Or you could write JNI code to sort of duplicate Mark's trick, but who'd want to do that? Brrr.)

.NET | Java/J2EE

Monday, November 21, 2005 3:01:11 AM (Pacific Standard Time, UTC-08:00)
Comments [9]  | 
 Friday, November 18, 2005
Academic .NET radio show debuts

Matt Cassell is putting on an Academic .NET radio show (something in the vein of .NET Rocks! but aimed at students), and asked me to be the opening episode. It's up online now, so have a listen and see if I managed to steer the kids straight....

.NET | Conferences | Java/J2EE | XML Services

Friday, November 18, 2005 2:13:33 PM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
 Tuesday, November 8, 2005
Anonymous generic methods making things "just work"

A good friend of mine and I are looking at taking on a new project together, and as part of the discussion we were exploring some of the differences of taking a relational perspective against an object perspective, and one of the comments she made was that in a relational model, you can always "filter" the data you want based on some predicate. "Ha!", I said, "If that's what you want, I can give you that over objects, too!" What's more, thanks to generics, I can do this for any collection type in the system without having to introduce it on some kind of base class:

    static class SetUtils
        public static List<T> Project<T>(List<T> list, Predicate<T> pred)
            List<T> results = new List<T>();

            foreach (T p in list)
                if (pred(p))

            return results;

        // Not too hard to imagine the other relational operators here, too

    // Usage:
    class Person
        private string firstName;
        private string lastName;

        public Person(string fn, string ln, int age) {
            this.firstName = fn;
            this.lastName = ln;

        public string FirstName {
            get { return firstName; }
            set { firstName = value; }
        public string LastName {
            get { return lastName; }
            set { lastName = value; }
        public override string ToString() {
            return "[Person [" + firstName + "]" + " " + "[" + lastName + "]" + "]";

    class Program {
        static void Main(string[] args) {
            Person cg = new Person("Cathi", "Gero", 35);
            Person tn = new Person("Ted", "Neward", 35);
            Person sg = new Person("Stephanie", "Gero", 12);
            Person mn = new Person("Michael", "Neward", 12);

            List<Person> list = new List<Person>();

            List<Person> newards = 
                    delegate (Person p) { if (p.LastName == "Neward") return true; else return false; } );
            foreach (Person p in newards)
Any more questions? (This is why having (1) a system that supports managed function pointers directly and (2) a generics system that doesn't rely on type erasure is so powerful. Hint, Hint, Sun guys....)

Now if I could just figure out how C# 3.0 manages to differentiate/overload between delegate instances and Expression objects in LINQ/DLinq, I might be able to backport that to C# 2.0, too, and be able to pass these Predicate instances across the wire for execution on other machines.

In a lot of ways, the Predicate delegate type is an example of using C#'s anonymous methods as a form of closure or lambda expression. (It's been argued that anonymous methods-as-delegates aren't "true" closures, since the local variables referenced in a closure will only be references to the objects, not complete copies, but to my mind that's exactly as it should be, as any time you pass a reference to an object, you're passing just that--a reference to an object, not a complete copy of the object. To do otherwise in anonymous methods would violate the Principle of Least Surprise, IMHO.) The Ruby syntax arguably isn't any more elegant or terse, and I suspect similar things could be done in C++ using templates; probably something along these lines already exists in Boost. But alas, I see no way to do this in Java given the current state of the JVM, namely the aforementioned lack of "managed functors" and type-preserving generics. If any out there in Java-land know otherwise, please holler, because I would really love to know how to do this as elegantly.

.NET | C++ | Java/J2EE | Ruby

Tuesday, November 8, 2005 7:02:22 PM (Pacific Standard Time, UTC-08:00)
Comments [17]  | 
Nullable Type correction/bugfix

This is a bit of old news, but the discussion came up during the Seattle Code Camp, so I thought I'd go through the problem, and use it as an example of the issues that can come up when trying to map language concepts on top of a platform that doesn't support the idea natively. Hopefully, this will cause developers looking to build DSLs or other languages on top of the .NET (or JVM) platform to see some of the edge cases a bit more clearly and a bit sooner. :-)

To lay down the background first: dealing with NULLs has always been somewhat problematic; the most obvious example of this is the mapping between relational databases, where even an INTEGER column can either have a value, or be empty, or be NULL, each of those being separate and distinct states. Trying to map NULL integer column values to integer values in the language has always been difficult in Java. C++, and C#, since primitive types / value types generally don't support null values, and Anders (among others) decided that it was time to try and integrate nullability more deeply into the language. The .NET team saw an opportunity to support nullability by creating a generic/templatized type to represent the possibility of nullability, and the C# language team took it further to try and make nullability feel "more at home" within the language. It was a bold, if at first seemingly-trivial, step.

Initially, the Nullable<T> type was pretty simple: it captured an instance of T internally, and if T was null it tripped an internal flag such that the IsNull property would return true. So, using a nullable int would work something like this:

Nullable<int> ni = new Nullable<int>(null);
if (ni.IsNull)
  Console.WriteLine("It's null!");
By doing this, it seemed fairly straightforward, and then the C# team took it one step further and decided to integrate this more deeply into the language itself, by creating a native syntax for nullability:
int? ni = null;
if (ni == null)
  Console.WriteLine("It's null!");
In other words, any type? designation was an alias for Nullable<type>, and appropriate properties would be consulted when looking to evaluate the nullable type instance. Conversion rules (from the nullable type into the type) had to be written, because it's not necessarily a silent and unambigious conversion to it's original type; for example, in the case where you wrote:
int? ni = null;
int i = (int)ni;
what should the expected behavior of the conversion of ni to i be? Some would argue that it should silently seek to "best" convert the null value of ni to an acceptable integer value of i, but that gets us back to the original problem, figuring out what that mapping is. (Ask any C++ programmer versed in the lore, and they'll be the first to tell you that "0 is NOT the same thing as NULL".) So here, asking to make that conversion will trigger a NullReferenceException.

OK, so far, so good. The problem is, however, that people were going to ask these nullable types to do things that subtly were different from what they'd ask of Nullable<T> instances. For example, the following snippet of code wouldn't behave as expected:

int? ni = null;
object o = ni; // What should this conversion be?
if (o == null) {
  // Should we be in this block?
What the conversion from int? to object should be was the subject of some debate, but what the C# team ended up with was the idea that the conversion followed basic CLR rules: that because int? was, internally, an instance of the type Nullable<int>, the conversion was to obtain an object reference to the Nullable<int> instance. In other words, a boxing operation took place, and since the Nullable<int> instance was always present (it's never null, even though it's value might be null), the "if" block above would never evaluate as "true".

Somasegar's weblog describes what happened next in some detail:

Clearly this had to change. We had a solution in Visual Studio 2005 Beta2 that gave users static methods that could determine the correct null-ness for nullable types in these more or less untyped scenarios. However, these methods were costly to call and difficult to remember to use. The feedback you gave us was that you expected it to simply work right by default.

So we went back to the drawing board. After looking at several different workarounds and options, it became clear to all that no amount of tweaking of the languages or framework code was ever going to get this type to work as expected.

The only viable solution was one that needed the runtime to change.
In other words, the runtime had to take a special interest in the Nullable type, treating it with special-cased logic to handle those conversions between Nullable instances and their non-Nullable equivalents. As Soma points out, "A Nullable int now boxes to become not a boxed Nullable int but a boxed int (or a null reference as the null state may indicate)." More importantly, this permeates throughout the entire runtime, so that
int? x = 10;
object y = x;
int? z = (int?)y; // unbox into a Nullable<int>
works as intended, where under the old rules it would have failed conversion because the boxed Nullable reference wouldn't be the same type as the Nullable type it was being converted into. (In other words, boxed(Nullable(T)) != T.)

The lessons here? When building languages to run on top of another platform or runtime, the decisions that runtime makes often put some serious constraints around what you can do within your language. For example, looking to support first-class functors on a JVM or CLR will run into the fact that functions aren't first-class in the runtime, but instead have to be handled with object wrappers around the functions. Hiding those differences in language semantics can only get you so far, and that sometimes you need to involve the runtime team a bit more deeply if you want to close all those edge cases. (Hint to Sun: you really need to start thinking about revising and extending the JVM, instead of this current policy that essentially describes the JVM as perfect as-is. The changes made to support annotations were minor, but a good first step; it's time to open that Pandora's box wider if you want to keep up with the CLR, to be blunt about it.)

.NET | C++ | Java/J2EE | Ruby

Tuesday, November 8, 2005 2:28:25 AM (Pacific Standard Time, UTC-08:00)
Comments [1]  | 
HTML is not statically typed... but so what?

Dion Almaer made an interesting point recently:

A friend ... talked about how it is interesting that HTML is not statically typed, yet it has scaled pretty well. The internet architecture has made this happen. We are loosely coupled and modules (pages/site) are seperated out.
Except that HTML itself really had nothing to do with the architecture of the Web, Dion--it is just a presentation format. We could have been "just" as successful in growing the Web (from a scalability perspective) had the presentation format been PDF, Flash, or you name it. It was the Architecture of the World Wide Web that led to the organic and anarchic scability of the Web, not HTML itself. The fact that HTML is dynamically typed (and I take issue with that, as well: HTML isn't typed in the traditional sense of the term, nor is XML for that matter) is a red herring.

Ruby has its merits, Dion--you don't need to make spurious comparisons to try and justify it. Let programmers discover the beauty that is dynamically-typed programming on their own.

Tuesday, November 8, 2005 2:25:16 AM (Pacific Standard Time, UTC-08:00)
Comments [1]  |