... and Christian moves to his own blog as well!

Been fun running this blog, but now it's time for me too to move back to my old blog:

http://christiangenne.blogspot.com

Hope to see you there!

And Gustaf, thank you :)

/ Christian

Gustaf moves to his own blog.

From now on, I (Gustaf) will post all my posts on my original blog, http://gustafnilssonkotte.blogspot.com/. I would be very (!) happy if you added that feed to your readers.

Sorry for the inconvenience.

Christian: Thank you for a very nice time buddy! :)

/Gustaf

Objective-C... yet another programming language?

Just recently installed XCode on my mac in order to develop applications for my iPhone. The first thing I realized was that I needed to learn yet another programming language. Just another syntax, or does Objective-C actually bring something new?

It turns out Objective-C (which is a language derived from C, similar to C++, but still very different) has one feature I haven't seen before. First of, instead of calling a method on an object, your send a message to it. It's almost the same, but also requires you to pass along named parameters (which means more code to write, but easier to read). The new and cool feature appears when you want to send a message to an object, which should return a value, when the object turns out to be nil.

MyClass* myObject = nil;
if ([myObject getValue] == 0.0) {
  // myObject getValue retuned 0, OR myObject is nil
}

So when executing this code, as opposed to how normal programming languages handles it, it doesn't crash. It simply returns 0.0 if the expected return type is a number, or nil if the expected return type is a pointer to an object. This also works for functions returning nothing (i.e. void), sending a void returning message to a nil object will simpy do nothing.

In for example C# you always have to do null checks all over the code, in order to verify your object isn't nil.

I'm not sure I like it or not, but if you learn to think "pure Objective-C" then perhaps this can be used as an advantage! I'm looking forward to learning Objective-C further, and to adapt these new concepts!

I'll let you know when I've published my first iPhone app :)

From for loop to anamorphism

Introduction

Sometimes you want to generate a sequence of objects. This is often done using a for loop:

[Test]
public void CreateListOfFoos()
    {
        var xs = new List<Foo>();
        for (int i = 0; i < 10; i++)
        {
            xs.Add(new Foo());
        }

        Assert.AreEqual(10, xs.Count());
    }

In this post, I will show you how this code can be made more general, ultimately turning it into an anamorphism over lists.

Generalizing constructed type

First, what we want to do is to be able to create something other than a Foo. We apply ExtractVariable once and we also extract the constructor call to a lambda:

[Test]
public void ExtractMethod()
{
    var times = 10;
    Func<Foo>newFoo = () => new Foo();

    var xs = CreateFooNumberOfTimes(times, newFoo);

    Assert.AreEqual(10, xs.Count());
}

private IEnumerable<Foo> CreateFooNumberOfTimes(int times, Func<Foo> newFoo)
{
    var xs = new List<Foo>();
    for (int i = 0; i < times; i++)
    {
        xs.Add(newFoo.Invoke());
    }
    return xs;
}

From the above code, it’s easy to generalize on the type created. Note that we could have skipped the “constructor lambda” and instead used the “where T : new()” constraint.

[Test]
public void GeneralizeTypeForFunc()
{

    var times = 10;
    Func<Foo> newFoo = () => new Foo();

    var xs = CreateTNumberOfTimes(times, newFoo);

    Assert.AreEqual(10, xs.Count());
}

private IEnumerable<T> CreateTNumberOfTimes<T>(int times, Func<T> newFoo)
{
    var xs = new List<T>();
    for (int i = 0; i < times; i++)
    {
        xs.Add(newFoo.Invoke());
    }
    return xs;
}

Generalizing type for accumulator

We have now parametrized Foo to T, but wouldn’t it be possible to parametrize from “int” to A, as well? Let’s begin with breaking out the int-specific code from the for loop:

[Test]
public void ExtractForLoopLogic()
{
    Func<Foo> newFoo = () => new Foo();

    int i = 0; // Will be modified lots of times
    Func<bool> expr = () => i < 10;
    Action inc = () => i++;

    var xs = CreateTUntil(newFoo, expr, inc);

    Assert.AreEqual(10, xs.Count());
}

private IEnumerable<T>CreateTUntil<T>(Func<T> newT, Func<bool> expr, Action inc)
{
    var xs = new List<T>();
    for (; expr.Invoke(); inc.Invoke())
    {
        xs.Add(newT.Invoke());
    }
    return xs;
}

As indicated in the code, the variable “i” will be modified the closure called in CreateTUntil. Bart de Smet calls this a cruel lambda. Except that it’s quite hard to understand a lambda that mutate its outer scope, refactoring code that’s using cruel lambdas can make your code go totally bananas!

Let’s rewrite the code to use a pure lambdas instead. To do this, we need to refactor the for loop to a while loop, since the first and third “parameters” to a for loop are statements (not pure). We also parametrize from “int” to type parameter “A” instead.

Going pure and a more general constructor

[Test]
public void ForLoopToWhileLoop()
{
    Func<Foo> newFoo = () => new Foo();
    Func<int,bool> expr = a => a < 10;
    Func<int,int> inc = i => i + 1;

    var xs = CreateTUntilUsingWhile(newFoo, 0, expr, inc);

    Assert.AreEqual(10, xs.Count());
}

// Now a pure method
private IEnumerable<T> CreateTUntilUsingWhile<T>
    (Func<T> newT, int init, Func<int,bool> expr, Func<int,int> inc)
{
    
    var xs = new List<T>();

    int i = init;
    
    while (expr.Invoke(i))
    {
        xs.Add(newT.Invoke());
        i = inc.Invoke(i);
    }
    return xs;
}

Now we don’t have any concrete types in the method signature, except bool, which I think is ok to have there at this point. But, as the observant reader might have noticed, the constructor can’t be called with a variable argument, i.e. the accumulated value. What we need to do is to “connect” the lambdas that generates values, like this:

[Test]
public void ArgumentForConstructor()
{
    Func<int,Result<Foo,int>> gen = n => new Result<Foo,int>(new Foo(), n + 1);
    Func<int,bool> expr = a => a < 10;
    
    var xs = GeneralizedCreateTWithArgsUntilUsingWhile(gen, 0, expr);

    Assert.AreEqual(10, xs.Count());
}

private IEnumerable<T> GeneralizedCreateTWithArgsUntilUsingWhile<T,A>
    (Func<a,Result><T,A>> gen, A init, Func<A,bool> expr)
{
    var xs = new List<T>();

    var i = init;

    while (expr.Invoke(i))
    {
        var result = gen.Invoke(i);

        xs.Add(result.Value);
        i = result.Accumulator;
    }

    return xs;
}

Going recursive

Now it’s up to the generating lambda to pass an argument to the constructor or not. What’s funny with this is that if we replace the while loop to a recursive call, we come pretty close to the definition of an anamorphism over lists in the introduction of Functional Programming with Bananas, Lenses, Envelopes and Barbed Wire by Erik Meijer et. al (link to postscript version).

[Test]
public void WhileLoopToRec()
{

    Func<int, Result<Foo, int>> gen = n => new Result<Foo, int>(new Foo(), n + 1);
    Func<int, bool> expr = a => a < 10;

    var xs = CreateTUntilUsingRec(gen, 0, expr);

    Assert.AreEqual(10, xs.Count());
}

private IEnumerable<T> CreateTUntilUsingRec<T,A>
    (Func<A, Result<T, A>> gen, A init, Func<A, bool> expr)
{
    
    if (!expr.Invoke(init))
        return new List<T>();

    var result = gen.Invoke(init);

    return (new List<T> {result.Value})
        .Concat(CreateTUntilUsingRec(gen, result.Accumulator, expr));

}

Abstracting away from bool

It seems that the only thing left to do is to abstract away the dependency on “bool” in CreateTUsingRec, but then we bump into a small problem,as you will see. What we do is to join the two lambdas into one and performing a null check inside the recursive function.

[Test]
public void MergeOnceMore()
{
    int? i = 0;
    Func<int, Result<int?, int>> gen = n => new Result<int?, int>(n < 10 ? i : null, n + 1);

    var xs = CreateTUntilUsingRecNullCheck(gen, 0);

    Assert.AreEqual(10, xs.Count());
}

private IEnumerable<T> CreateTUntilUsingRecNullCheck<T, A>
    (Func<A, Result<T, A>> gen, A init)
{
    
    var result = gen.Invoke(init);
    if (result.Value == null)
        return new List<T>();

    return (new List<T> { result.Value })
        .Concat(CreateTUntilUsingRecNullCheck(gen, result.Accumulator));

}

Writing it in F# instead

The problem with this solution is that we have lost the ability to generate ordinary non-nullable structs and that’s bad! We could easily solve the problem with writing our own MyNullable<T> which would  allow both classes and structs as instantiators of the type variable, but instead of doing that, I’ll show you something similar: the option type in F#.

let rec anamorphism n f = 
    match f n with
      | option.None -> [] 
      | option.Some (e,next) -> e::(anamorphism next f)

> anamorphism 0 (fun a -> if a < 5 then option.Some("Bar" + a.ToString(), a + 1) else option.None);;
val it : string list = ["Bar0"; "Bar1"; "Bar2"; "Bar3"; "Bar4"]

Here, we removed the Result class and used a pair instead, together with the Option type, which is essentially the same as Nullable<T>, but without the restriction on type.

Conslusion

Functional programming is perhaps more abstract than imperative programming, but it is also seems to be more general, at least in this case. This post has only showed an anamorphism over lists, which is the simple case. Look here if you want to see a more advanced example.

Why you love and hate Ruby

What strikes me when programming Ruby is how simple everything is! You've got utility functions for almost everything, and writing an application doesn't take more then a few lines of code. No need to setup a project, no need to think about types. You just write code!

The downside of this, of course, is that the code easily becomes bad written, and as there are very few rules in Ruby, it isn't very easy reading others' code. This is why Ruby sometimes is classified as a "hard to lean language". There are simply too many ways of writing the same code.

I don't agree that this makes the language more hard to learn, but perhaps makes it take longer to learn the language fully. For instance, I just recently learned you can write code in the following way:

puts "Hello my friend" if userIsFriendly

I've never seen code like that before, but it really opens up for some nice syntax!

Another feature of Ruby is that Classes are open, and everything is an object, meaning you can extend/modify classes on the fly. Even classes are objects! For example:

class Fixnum
  def minutes
    return Timespan.new(self)
  end
end
class Timespan
  def ago
    return Time.now - self
  end
end

5.minutes.ago

The syntax is almost perfect! How would you otherwise say "5 minutes ago"? That's what people often talk about when they describe Ruby. "The only truly object oriented language".

Why Ruby isn't the perfect language, IMO, is because it's too "open". There are too many ways of writing code. Writing smaller applications, or better scripts, won't take you more than a few minutes, but when you need to work on a larger project, I would definitely go with a strictly typed language, such as C#, where you have better control over your code. Also, not surprisingly, no IDE can help you writing your code, as the code is dynamically typed, and you really can't say what functions are available on an object until you actually run the code.

So, thumb up for this language when working on smaller applications. But for larger projects, I would recommend going for another one.

Fluent language in FsStory

A nice feature for a story runner is to be able to provide arguments in a story sentence, like this:

ATableWithNumberOfLegs 4

This example is not hard to understand, but there's some mental translation going on, since the order of the words is all screwed up. Let's try another one:

TheNumberOfLegsOfATableIs 4

Better, but still not good. First, it's longer than the previous example. Second, even if the grammar is correct, the word order is, well, unusual.. ;)

What about this?

ATableWith 4 Legs

Now we're talking!

Here's a bigger and more complete example:

[<Fact>]
let tableLegsScenario =
    given (ATableWith 4 Legs)
 |> whens (ICutOf 1 Leg)
 |> thens (ItHasOnly 3 LegsLeft)

Note: As far as I know, RSpec/Cucumber is the only story runner(s) that is able to use variables inside a story sentence.

The nice thing about this is that I didn't have to change FsStory itself to make it work. Not a single line. So, what's the trick?

If you split up a story sentence like this, you have to prepare the step definition code (the behind-the-scenes code) in a certain way:

let ATableWith = fun n _ -> ... do something here ...

..or if you prefer, without a lambda:

let ATableWith n _ = ... do something here ...

Then you have to define Legs:

let Legs = id

As you see, in this case, it was just a matter of discovering the usage, rather than implementing it in the language. Honestly, I had no idea of this usage when I started to write on FsStory. This is clearly one of the reasons why I like internal DSLs!

Exercise: How would you implement the step definition for the following story sentence?

given (ATableWith 4 LegsAnd 2 Chairs)

Cheers!

ImpossibleEstimation and Pomodoro Technique

Sometimes when using Pomodoro Technique I find it real difficult to estimate how long a particular activity will take, i.e., when locating a bug or find out why the webserver won't read my files.

In Pomodoro Technique, every activity should have a time estimate - how many Pomodori I think it will take. Though, this is sometimes impossible! "The problem is solved when I find the bug and since I don't know what the bug is related to, it's impossible to say how much time it will take to find it."

The solution: instead of just writing a number besides the activity, I use the less-than sign (<) before the number, indicating that I have a time-box for the activity, but that it might take less time. If I'm not done when the time-box is over, I have to ask a colleague to help me or ask my boss for extra resources - thus, escalating my problem. Then, I'm forced to have collected some data of the problem to help them to help me. The nice thing is that I still can have most of the benefits Pomodoro Technique gives me, i.e., increased focus when in a Pomodoro and possibility to get "the whole picture" during my breaks. The latter have proved to be an extra nice thing to have during hard problem-solving.

And, if a colleague comes to the rescue, we can construct another time-box, to know when to escalate it further, or at least to notify the team or the boss that we have some nasty problems at hand.

Yet, if I'm collecting metrics of my estimation skills, it is not a very good idea to track data for these bug-fixing Pomodori estimates. Put a "N/A" or a "-" in your records sheet and think for yourself: "Today was an exception, tomorrow will be a bug-free day." And don't forget to do your daily mind-map before you leave for home.