1. Wikipedia Tourism #10

    May 25, 2008 by Craig

    Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo.” is a grammatically correct sentence used as an example of how homonyms and homophones can be used to construct complicated constructs.

    The sentence is unpunctuated and uses three different readings of the word “buffalo”. In order of their first use, these are:

    • c. The city of Buffalo, New York (or any other place named “Buffalo”), which is used as an adjective in the sentence and is followed by the animal;
    • a. The animal buffalo, in the plural (equivalent to “buffaloes”), in order to avoid articles (a noun);
    • v. The verb “buffalo” meaning to bully, confuse, deceive, or intimidate.

    Thus, the sentence when parsed reads as a description of the pecking order in the social hierarchy of buffaloes living in Buffalo:

    Bison from Buffalo, New York who are intimidated by other bison in their community also happen to intimidate other bison in their community.

    From Buffalo buffalo Buffalo buffalo buffalo buffalo Buffalo buffalo. More good ones at List of linguistic example sentences.


  2. .NET Generics and Type Inference Landmine

    May 21, 2008 by Craig

    Let’s say that you have a class that takes a generic type parameter:

    public class Foo<T> {
      public void accept(T someObject) { }
      public void doSomething() { }
    }
    

    It’s difficult to doSomething() to a collection of Foo<T>s when you don’t know what T is and/or there’s multiple types used for T. To work around this, you can create a typeless interface:

    public interface FooTypeless {
      void doSomething();
    }
    

    The declaration of Foo<T> now becomes:

    public class Foo<T> : FooTypeless
    

    Now you can have this method:

    public void doSomethingOnAllFoos(
      IEnumerable<FooTypeless> foos) {
    
      foreach( FooTypeless foo in foos ) { 
        foo.doSomething();
      }
    }
    

    Also, say that you have the following extension method:

    public static IEnumerable<T> toEnumerable<T>(this <T> obj ) {
      // Any IEnumerable implementation should work here; 
      // but we'll get to that in a bit
      return new T[] { obj };
    }
    

    Type inference would let you write this:

    Foo aFoo = new Foo();
    doSomethingOnAllFoos( aFoo.toEnumerable() );
    

    However, this code does not work; you get a compile error:

    cannot convert from ‘System.Collections.Generic.IEnumerable<Foo<string>>’ to ‘System.Collections.Generic.IEnumerable<FooTypeless>’

    This occurs even though Foo<string> inherits from FooTypeless. Even though the generic type parameters are compatible, the generic-enabled reference isn’t, at least according to the compiler. (We humans could probably see that IEnumerable is an interface that could safely be converted, but the existing compiler cannot).

    Now, you can do this:

    IEnumerable<FooTypeless> someFoos 
      = new Foo<String>[] { foo };
    

    …but not this:

    IEnumerable<Foo<String>> someStringFoos 
      = new Foo<String>[] { foo };
    IEnumerable<FooTypeless> someFoos 
      = someStringFoos;
    

    You may be tempted to try casting to work around this. For example, this works:

    IEnumerable<Foo<String>> someStringFoos 
      = new Foo<String>[] { foo };
    IEnumerable<FooTypeless> someFoos 
      = (IEnumerable<FooTypeless>) someStringFoos;
    

    However, this only works if someStringFoos is assigned an array. The following does not work:

    IEnumerable<Foo<String>> someStringFoos 
      = new List<Foo<String>> { foo };
    IEnumerable<FooTypeless> someFoos 
      = (IEnumerable<FooTypeless>) someStringFoos;
    

    If you try this, you’ll get an InvalidCastException. Furthermore, this generates the compiler error:

    IEnumerable<FooTypeless> someFoos 
      = new List<Foo<String>> { foo };
    

    Currently I have no idea why the array works but the List doesn’t; it doesn’t make a lot of sense to me.

    I originally discovered this by using type inference with my toEnumerable() extension method. An easy way around these problems is to avoid the type inference completely and explicitly specify the type of IEnumerable you want:

    Foo<String> aFoo = new Foo<String>();
    doSomethingOnAllFoos( aFoo.toEnumerable<FooTypeless>() );
    

    This works fine, even if toEnumerable() uses a non-array type (such as List) as its IEnumerable implementation. Execution-wise, nothing has changed, but the generic type used in the call can make or break the code.

    Stuff like this starts to make Java’s type erasure look not so ugly in comparison. 😛


  3. Stupid .NET Tricks #13

    by Craig

    In Java, making a field “final” means that you can only assign a value to it once. It’s an important part of making a class immutable. It helps to prevent bugs too: make a field final and you’ll get a compiler error if you leave it unassigned or try to reassign it anywhere.

    .NET has a similar concept with the “readonly” keyword for fields. However, there’s one important difference compared to Java: a “readonly” field can only be assigned in the class’s constructor, but it can be assigned multiple times within that constructor. The only restriction it places is that the field can’t be reassigned outside of the constructor. You don’t even get a compiler error for not assigning it at all; you only get a compiler warning (which can be turned off).

    This has encouraged bugs at least twice in my code: I assigned a value to a field twice within the constructor and then got unexpected results due to the incorrect object being used. One of these was caused by a conflict resolution from a Subversion Merge (and thus it was less-than-obvious that it had been introduced).


  4. New Perspective

    by Craig

    Alternate headline: “New Spirit of Chinese-American Cooperation comes to Cuba”


  5. Wikipedia Tourism #9

    May 19, 2008 by Craig

    From the Same Wikipedia article on Jeanne Calment:

    In 1965, aged 90, with no living heirs, Jeanne Calment signed a deal, common in France, to sell her condominium apartment en viager to lawyer François Raffray. Raffray, then aged 47, agreed to pay a monthly sum until she died, an agreement sometimes called a “reverse mortgage”. At the time of the deal, the value of the apartment was equal to ten years of payments. Calment lived more than thirty additional years. Raffray died of cancer in December 1995, at the age of 77, leaving his widow to continue the payments for twenty more months.


  6. Wikipedia Tourism #8

    by Craig

    I’ve only got one wrinkle, and I’m sitting on it.

    From Quotations by Jeanne Calment, the human with the longest confirmed lifespan.


  7. Stupid .NET Tricks #12

    May 15, 2008 by Craig

    Disclaimer: There may, in fact, be a good reason for the following .NET behavior. However, if there is, it’s certainly not clear to me. I pose a question at the bottom; dear lazyweb, please explain.

    .NET’s type inference lets you avoid specifying the type of a generic parameter on a method call some, but not all, of the time. Consider the following infrastructure:

    public String getSomeString() {
      return "Some String";
    }
    
    public T returnTheValue<T>(T value) {
      return value;
    }
    
    public delegate T Factory<T>();
    
    public T createSomeValue<T>(Factory<T> factory) {
      return factory();
    }
    

    The following code works fine:

    Console.WriteLine(returnTheValue("A String"));
    

    .NET is smart enough to know that, since you’re passing in a String for T, it can assume that String is used for T elsewhere in the method (including the return type), and so it doesn’t require you to explicitly state that returnTheValue is using String for T, like so:

    Console.WriteLine(returnTheValue<String>("A String"));
    

    The above code does work, and if you specify a non-compatible type (ex: int), then you get an error. However, it’s not necessary due to type inference.

    The following code also works:

    Console.WriteLine( returnTheValue( getSomeString() ) );
    

    There’s no difference between using a literal and calling a method (they’re both dealing with values).

    The following does not work:

    Console.WriteLine( createSomeValue( getSomeString ) );
    

    Here we’re not passing a value, but passing a method that will create/return a value. In this case, the .NET compiler returns the following error message:

    The type arguments for method ‘createSomeValue<T>( Factory<T> )’ cannot be inferred from the usage. Try specifying the type arguments explicitly.

    “Specifying the type arguments explicitly” means doing this, which works:

    Console.WriteLine( createSomeValue<String>( getSomeString ) );
    

    What I don’t understand is why the type inference works in one case and not the other. We know that getSomeString() satisfies Factory<String>, and thus we know that the return value is a String. If returnSomeValue() can infer its generic type parameter is String based on the String argument, why can’t createSomeValue() infer that it’s generic type parameter is String based on its Factory<String> argument? It already knows for sure that it’s getting a Factory; it just needs to know what type of Factory.

    Is there some inherent limitation to the .NET type inference system that makes it impossible to know this? Or is this simply that the .NET implementors didn’t carry the concept one step further?


  8. Lies We Tell Kids (and Ourselves)

    May 14, 2008 by Craig

    Paul Graham has posted a great essay on the lies and misdirections we tell to children, the reasons we do it, and the consequences of doing so. There’s one passage I particularly liked:

    Telling a child they have a particular ethnic or religious identity is one of the stickiest things you can tell them. Almost anything else you tell a kid, they can change their mind about later when they start to think for themselves. But if you tell a kid they’re a member of a certain group, that seems nearly impossible to shake.

    This despite the fact that it can be one of the most premeditated lies parents tell. When parents are of different religions, they’ll often agree between themselves that their children will be “raised as Xes.” And it works. The kids obligingly grow up considering themselves as Xes, despite the fact that if their parents had chosen the other way, they’d have grown up considering themselves as Ys.

    One reason this works so well is the second kind of lie involved. The truth is common property. You can’t distinguish your group by doing things that are rational, and believing things that are true. If you want to set yourself apart from other people, you have to do things that are arbitrary, and believe things that are false. And after having spent their whole lives doing things that are arbitrary and believing things that are false, and being regarded as odd by “outsiders” on that account, the cognitive dissonance pushing children to regard themselves as Xes must be enormous. If they aren’t an X, why are they attached to all these arbitrary beliefs and customs? If they aren’t an X, why do all the non-Xes call them one?

    Now, to segue a bit:

    This form of lie is not without its uses. You can use it to carry a payload of beneficial beliefs, and they will also become part of the child’s identity. You can tell the child that in addition to never wearing the color yellow, believing the world was created by a giant rabbit, and always snapping their fingers before eating fish, Xes are also particularly honest and industrious. Then X children will grow up feeling it’s part of their identity to be honest and industrious.

    My grandmother has, on a couple of occasions, (jokingly) said to Laura that “she must have some Irish in her” due to her cheerful and outgoing personality. Laura happens to be Latin American and of course has pretty much zero actual Irish ancestry. There are cheerful and outgoing people in all cultures, but we like to assign people to groups and then infer properties about the person based on the properties we’ve observed or assigned to the group. That’s called prejudice, and it’s misleading even when it’s done with positive intentions.

    Lastly:

    We arrive at adulthood with a kind of truth debt. We were told a lot of lies to get us (and our parents) through our childhood. Some may have been necessary. Some probably weren’t. But we all arrive at adulthood with heads full of lies.

    There’s never a point where the adults sit you down and explain all the lies they told you. They’ve forgotten most of them. So if you’re going to clear these lies out of your head, you’re going to have to do it yourself.

    Few do. Most people go through life with bits of packing material adhering to their minds and never know it. You probably never can completely undo the effects of lies you were told as a kid, but it’s worth trying. I’ve found that whenever I’ve been able to undo a lie I was told, a lot of other things fell into place.


  9. Perfectionists

    May 12, 2008 by Craig

    Stephen Dubner on Freakonomics Blog writes:

    Have You Ever Noticed that people who go around saying “I’m a perfectionist” never are, while people who actually are perfectionists never go around saying it?

    I have.


  10. Spelling

    May 11, 2008 by Craig

    From the Political Compass FAQ:

    When are you guys gonna learn to spell ?

    This grievance comes from pernikety people who have leapt into attack without checking the FAQs ..and without even the remotest realisation that British and American words are sometimes spelt differently. They should have travelled more! We’ve been at the centre of some rancour, but we’re not going to take offence or harbour any grievances. The catalogue of their ill-informed certainties won’t colour this organisation’s programme. It’s a grey area anyway. And we don’t want to labour the point. Except to add that most of these cavillous correspondents seem to feel that they have a licence or a blank cheque for a level of rudeness that more civilised souls wouldn’t have dreamt of. In response, we nevertheless practise polite dialogue, enabling them to recognise that the error is entirely their own. (We manoeuvre them towards the Oxford English Reference Dictionary, which is also an encyclopaedia.) This leaves them quite defenceless, which may account for the fact that these less than honourable individuals virtually never apologise.

    (Firefox’s spell checker flagged 24 words as I posted this)