simoneb's blog

Labeling Trees - Exercise 2

2013-04-21T01:07:00+02:00

In the previous post of this series we did a small improvement to the state monad implementation by generalizing it over the type of the state. This is not exactly a requirement for labeling trees as the state can be simply an integer, but it’s a more natural choice now that we tackle the second exercise.

Go from labeling a tree to doing a constrained container computation, as in WPF. Give everything a bounding box, and size subtrees to fit inside their parents, recursively.

As you know the exercises come without any solution, so let’s try to understand what we need to do here. Because we’re talking about binary trees let’s assume that the requirement is to perform the constrained container computation based on containers with two children, where each child can either be another container or a terminal element, like a text block.

By translating it to WPF as suggested in the assignment we can represent a branch as a Grid with two rows and a single column. Each row’s unique cell can contain either another grid with the same characteristics or a TextBlock. The layout features of a grid match exactly the solution to the problem we’re asked to solve, as child elements of grid cells expand to match the size of their parent.

Starting with the same simple tree we used as a sample throughout the series:

A simple tree (a-simple-tree.cs) download

                                //  tree.Show() outputs:
var tree = branch(              //  Branch:
            leaf("a"),          //    Leaf: a
            branch(             //    Branch:
              branch(           //      Branch:
                leaf("b"),      //        Leaf: b
                leaf("c")),     //        Leaf: c
              leaf("d")));      //      Leaf: d

tree.Show();

we can transform it into this simple WPF markup, as described earlier:

<Grid>
    <Grid.RowDefinitions>
        <RowDefinition></RowDefinition>
        <RowDefinition></RowDefinition>
    </Grid.RowDefinitions>
    <TextBlock Grid.Row="0">a</TextBlock>
    <Grid Grid.Row="1">
        <Grid.RowDefinitions>
            <RowDefinition></RowDefinition>
            <RowDefinition></RowDefinition>
        </Grid.RowDefinitions>
        <Grid Grid.Row="0">
            <Grid.RowDefinitions>
                <RowDefinition></RowDefinition>
                <RowDefinition></RowDefinition>
            </Grid.RowDefinitions>
            <TextBlock Grid.Row="0">b</TextBlock>
            <TextBlock Grid.Row="1">c</TextBlock>
        </Grid>
        <TextBlock Grid.Row="1">d</TextBlock>
    </Grid>
</Grid>

The result of this markup, along with some additional styling and a bit of logic to outline the bounds of each cell and display its box size, is shown below. The full code of this example is available as a ready-to-run LINQPad query here.

As you can see the children of grid cells automatically expand to fit their parent’s size. More precisely, each grid row gets 50% of the height of its parent, regardless of the contents. We’ll now try to do the same monadically by adapting our data structures and labeling logic to this new case.

First of all we need to decide what is the type of the state we’ll be carrying around. Intuitively, each time we branch a grid into its two rows we allocate 50% of the available height to each of them, therefore the state will certainly include the available height. Although not strictly needed in this scenario let’s make it a little more realistic by including the width as well, and we’ll call a structure containing two such values a Box. With this little piece of information we can already define the signature of our function which, similarly to the previous MLabel, will represent the entry point for the constrained box computation.

Tree<StateContent<Box, T>> MConstrainedBox<T>(Tree<T> tree, Box box)

The function takes a tree, which in this case we can imagine being a visual tree of graphic elements, and an initial box size (our initial state), representing the size of the root element. The return value is a tree whose generic argument is a tuple of state-content values. The state is the Box representing the size allocated to that tree and the value is the generic parameter T that we’re currently filling with characters to distinguish a leaf from another leaf.

As we did with the labeling problem the entry function will finally delegate to a helper function that will call itself recursively. We can thus define the body of the previous function as follows:

Tree<StateContent<Box, T>> MConstrainedBox<T>(Tree<T> tree, Box box)
{
    return MConstrainedBox1(tree).RunWithState(box).Item2;
}

No big surprises here as the juice is actually in the body of the MConstrainedBox1 function, in the same way as it previously was in MLabel1. Let’s start by defining its signature, which we can infer from above.

S<Box, Tree<StateContent<Box, T>>> MConstrainedBox1<T>(Tree<T> tree)

Not much else to do except reasoning about how to solve the problem of assigning box sizes to tree leaves according to the rules described earlier. The process is overall simple, let’s outline the steps.

If the current tree is a leaf then extract the state value using a proper getState function similar to what we used in the labeling scenario. The main difference here is that when we encounter leaves we do not need to update any state but only extract it from the monad and attach it to the new leaf we create.

If the current tree is a branch then:

update the state by halving the height of the current box
recurse over the left branch
recurse over the right branch
update the state by doubling the height of the current box
return an instance of the state monad whose value is a branch with the results of steps 2 and 3 as the left and right trees, respectively

Let’s go through a simple example to understand better. Assuming to start with a box of size 200 x 400 (W x H) and that the root element of the tree we want to process is a branch, we halve the available height and process the left and right trees using 200 as the available height for each of them. If at some point we come across a leaf we use whatever current value of the state we have at that point during the computation (if both left and right trees are leaves then each of them will get a height of 200). When we’re done with the two trees we restore the original height by multiplying it by two. This leads exactly to the solution we’re looking for.

public S<Box, Tree<StateContent<Box, T>>> MConstrainedBox1<T>(Tree<T> tree)
{
    if(tree is Leaf<T>)
    {
        var lf = tree as Leaf<T>;

        var getState = new S<Box, Box>
        {
            RunWithState = b0 => Tuple.Create(b0, b0)
        };

        return Bind(getState, b0 =>
                    Return<Box, Tree<StateContent<Box, T>>>(leaf(stateContent(b0, lf.Value))));
    }
    else
    {
        var br = tree as Branch<T>;

        var halveHeight = new S<Box, Box>
        {
            RunWithState = b0 => Tuple.Create(new Box(b0.Width, b0.Height/2), b0)
        };

        var doubleHeight = new S<Box, Box>
        {
            RunWithState = b0 => Tuple.Create(new Box(b0.Width, b0.Height*2), b0)
        };

        return Bind(halveHeight, _ => Bind(MConstrainedBox1(br.Left),
                    left => Bind(MConstrainedBox1(br.Right),
                    right => Bind(doubleHeight,  __ =>
                    Return<Box, Tree<StateContent<Box, T>>>(branch(left, right))))));
    }
}

Now if we run the computation against the same old tree:

var tree = branch(
               leaf("a"),
               branch(
                   branch(
                       leaf("b"),
                       leaf("c")),
                   leaf("d")));

MConstrainedBox(tree, new Box(200, 400)).Show();

the result we obtain is the same we obtained using WPF:

Branch:
  Leaf: { State = { Width = 200, Height = 200 }, Value = a }
  Branch:
    Branch:
      Leaf: { State = { Width = 200, Height = 50 }, Value = b }
      Leaf: { State = { Width = 200, Height = 50 }, Value = c }
    Leaf: { State = { Width = 200, Height = 100 }, Value = d }

The full source code is as usual available as a gist containing a LINQPad query that you can download an run right away. In the next post we’ll do a step forward in defining a self-contained monad type before moving on to more interesting and challenging exercises.

Labeling Trees - Exercise 1

2013-04-07T19:41:00+02:00

In the last post of this series we learned how to label a binary tree monadically, and in doing so we discovered the state monad. I’ve collected the pieces we built incrementally last time into this gist containing the whole monadic label implementation as a LINQPad query that you can simply copy and run. I’ll keep making changes to that gist and create links which point to specific revisions from now on.

As I mentioned in the introduction I decided to write this series as a result of watching some years ago Brian Beckman talking about monads and not being able to grasp the topic at that time. Going through it again and explaining what it took me to understand it will hopefully help someone else follow the same path. Up until now we’ve rediscovered what Brian explained in his interviews, but the accompanying source code (that I’ve copied in this gist for convenience) also gave 10 assignments to the reader - without solutions - which I’m going to tackle in the remainder of this series.

The exercises are of varying difficulties, basically expanding on the topic of the state monad with tasks which require generalizing the pattern and applying it to solve problems other than labeling binary trees. So, without further ado, let’s move on to the first exercise.

Exercise 1

generalize over the type of the state, from int to <TState>, say, so that the S type can handle any kind of state object. Start with Labeled<T> –> StateContent<TState, T>, from “label-content pair” to “state-content pair”.

I rephrased the original text of the exercise a little bit so it matches our own implementation rather than Brian’s. Some type names are different as well as some design choices, but the overall concept is the same. Let’s see what this exercise is about.

So far we used a Labeled<T> class to represent the contents of a labeled tree - leaves, specifically. This class is a simple container of label and value pairs, where only the latter is generically parameterized via the T generic parameter. This exercise requires to parameterize the type of the label/state too, which is currently fixed to be an integer. It doesn’t sound very difficult, does it? We simply come up with a new type StateContent<TState, T> which does just that, and then adapt the usages of Labeled<T> to match the new type.

In addition to that we’ll also have to make some changes to the S<T> class, because it’s hardcoding the type of the state to be an integer. This will in turn require some changes to the MLabel1 function, mainly to cope with limited type inference capabilities of the C# compiler. The end result is shown in the diff below.

@@ -59,10 +59,10 @@ public class Branch<T> : Tree<T>

-public class Labeled<T>
+public class StateContent<TState, T>
 {
-    public int Label { get; private set; }
+    public TState State { get; private set; }
     public T Value { get; private set; }

-    public Labeled(int label, T value)
+    public StateContent(TState state, T value)
     {
-        Label = label;
+        State = state;
         Value = value;
@@ -72,3 +72,3 @@ public class Labeled<T>
     {
-        return new { Label, Value }.ToString();
+        return new { State, Value }.ToString();
     }
@@ -86,15 +86,15 @@ public Tree<T> branch<T>(Tree<T> left, Tree<T> right)

-public Labeled<T> labeled<T>(int label, T value)
+public StateContent<TState, T> stateContent<TState, T>(TState state, T value)
 {
-    return new Labeled<T>(label, value);
+    return new StateContent<TState, T>(state, value);
 }

-public class S<T>
+public class S<TState, T>
 {
-    public Func<int, Tuple<int, T>> RunWithState;
+    public Func<TState, Tuple<TState, T>> RunWithState;
 }

-public static S<U> Bind<T, U>(S<T> m, Func<T, S<U>> k)
+public static S<TState, U> Bind<TState, T, U>(S<TState, T> m, Func<T, S<TState, U>> k)
 {
-    return new S<U> 
+    return new S<TState, U> 
     {
@@ -102,3 +102,3 @@ public static S<U> Bind<T, U>(S<T> m, Func<T, S<U>> k)
         {
-            Tuple<int, T> mResult = m.RunWithState(s0);
+            Tuple<TState, T> mResult = m.RunWithState(s0);

@@ -109,5 +109,5 @@ public static S<U> Bind<T, U>(S<T> m, Func<T, S<U>> k)

-public static S<T> Return<T>(T value)
+public static S<TState, T> Return<TState, T>(T value)
 {
-    return new S<T> 
+    return new S<TState, T> 
     {
@@ -117,3 +117,3 @@ public static S<T> Return<T>(T value)

-public Tree<Labeled<T>> MLabel<T>(Tree<T> tree)
+public Tree<StateContent<int, T>> MLabel<T>(Tree<T> tree)
 {
@@ -122,3 +122,3 @@ public Tree<Labeled<T>> MLabel<T>(Tree<T> tree)

-public S<Tree<Labeled<T>>> MLabel1<T>(Tree<T> tree)
+public S<int, Tree<StateContent<int, T>>> MLabel1<T>(Tree<T> tree)
 {
@@ -128,3 +128,3 @@ public S<Tree<Labeled<T>>> MLabel1<T>(Tree<T> tree)

-        var updateState = new S<int> 
+        var updateState = new S<int, int> 
         {
@@ -134,3 +134,3 @@ public S<Tree<Labeled<T>>> MLabel1<T>(Tree<T> tree)
         return Bind(updateState,
-                    label => Return(leaf(labeled(label, lf.Value))));
+                    label => Return<int, Tree<StateContent<int, T>>>(leaf(stateContent(label, lf.Value))));
     }
@@ -142,3 +142,3 @@ public S<Tree<Labeled<T>>> MLabel1<T>(Tree<T> tree)
                     left => Bind(MLabel1(br.Right),
-                                 right => Return(branch(left, right))));
+                                 right => Return<int, Tree<StateContent<int, T>>>(branch(left, right))));
     }

It was an easy one this time, which sets the foundation for the next exercise, but we’ll come to it in the next post. The source code after this change is in the same old gist at this revision.

Stay tuned!

Labeling Trees - Invisible state

2013-03-31T01:45:00+01:00

This is the second post of a series about labeling trees. In the previous post we saw how to mark leaves of a binary tree with integer, incrementing labels, first manually and then functionally without relying on mutable state. We achieved it by writing a recursive Label1 function which threaded the value of the label, the state, via function arguments and return value, incrementing it every time it came across a leaf of the tree.

Let’s review the signature of the Label1 function and then move one step forward towards a different, less explicit way to pass the state around.

Tuple<int, Tree<Labeled<T>>> Label1<T>(int label, Tree<T> tree)

As the signature clearly shows the state passing is visible both in the arguments and the return value of the function. There is certainly a good reason for that: if we need to increment the label and use the new value whenever we come across the next leaf would it be possible to do otherwise? Let’s as well review the part of the function which took care of applying labels to the leaves.

Label1 leaf logic (label1-leaves.cs) download

var lf = tree as Leaf<T>;

return Tuple.Create(label + 1, leaf(labeled(label, lf.Value)));

This simple code mixes together two concerns: creating a labeled leaf and incrementing the value of the label, squeezing them into a tuple. Let’s try to abstract and extract these two responsibilities and then apply a series of simple transformations over them, while keeping the behavior unchanged.

First transformation: from integer to tuple

Label1 first transformation (label1-leaves-transformation-1.cs) download

// previous:    int
// current:     Tuple<int, int>
var newAndOldLabel = Tuple.Create(label + 1, label);

return Tuple.Create(newAndOldLabel.Item1, leaf(labeled(newAndOldLabel.Item2, lf.Value)));

Here we extracted the increment concern as a standalone operation. newAndOldLabel is a tuple whose first item contains the new value of the label and the second item contains the previous, unchanged value. The second statement simply uses it to create the final tuple.

Second transformation: from tuple to functions returning tuples

Label1 second transformation (label1-leaves-transformation-2.cs) download

// previous:    Tuple<int, Tree<Labeled<T>>>
// current:     Tuple<int, int> => Tuple<int, Tree<Labeled<T>>>
Func<Tuple<int, int>, Tuple<int, Tree<Labeled<T>>>> labelLeaf =
    arguments => Tuple.Create(arguments.Item1, leaf(labeled(arguments.Item2, lf.Value)));

return labelLeaf(newAndOldLabel);

Here we wrap the last statement from the previous step into a function which accesses newAndOldLabel via its arguments (rather than via local variables) and returns the result of invoking the function itself with newAndOldLabel.

Third transformation: from anything to functions

Label1 third transformation (label1-leaves-transformation-3.cs) download

// previous:    Tuple<int, int>
// current:     int => Tuple<int, int>
Func<int, Tuple<int, int>> bumpLabel = s => Tuple.Create(s + 1, s);

// previous:    Tuple<int, int> => Tuple<int, Tree<Labeled<T>>>
// current:     int => int => Tuple<int, Tree<Labeled<T>>>
Func<int, Func<int, Tuple<int, Tree<Labeled<T>>>>> labelLeafCurried =
    labelValue => s => Tuple.Create(s, leaf(labeled(labelValue, lf.Value)));

Tuple<int, int> bumpResult = bumpLabel(label);

return labelLeafCurried(bumpResult.Item2)(bumpResult.Item1);

Here we apply a transformation to both the label increment and the leaf-labeling logic. In the first case we wrap the creation of the newAndOldLabel tuple into a function which rather than grabbing the value of the label from the integer label argument of the containing function accesses it via its own argument.
In the second case we curry the already existing function so that instead of accepting a tuple argument it accepts a single integer argument and returns a function which accepts another integer argument and finally returns our output tuple. The external function takes care of fixing the current value used to apply a label to the leaf, while the inner function fixes the new, incremented label value as the first item of the resulting tuple.

The rest of the code binds together these two functions in a way which preserves the overall behavior.

Fourth transformation: Bind

As we just mentioned binding, let’s finally abstract this concept into its own Bind generic function. This function basically encapsulates the logic of composing bumpLabel and labelLeafCurried from the previous transformation.

Label1 fourth transformation (label1-leaves-transformation-4.cs) download

return Bind(bumpLabel, labelLeafCurried)(label);

Before looking at its definition let’s observe some of the characteristics of this function. It takes two functions as its arguments and returns a third function, which is then executed passing label as its only argument. Knowing both the signatures of the input functions and the return type of the containing Label1 function implies that we also know the signature of the Bind function. Furthermore, being a replacement for the last few lines of code from the previous step means that the body will encapsulate the same logic in some form.

Bind (bind-tuples.cs) download

public static Func<int, Tuple<int, Tree<Labeled<T>>>> Bind<T>(
    Func<int, Tuple<int, int>> m,
    Func<int, Func<int, Tuple<int, Tree<Labeled<T>>>>> k)
{
    return s0 =>
    {
        var mResult = m(s0);

        var kResult = k(mResult.Item2);

        return kResult(mResult.Item1);
    };
}

The important thing to note is that we’ve come here by applying some simple and logical transformations to the initial code, and if you try to follow what this code is doing you can realize that the behavior is unchanged. One final step to abstract this even more is to make it generic over the second item of the tuples involved, thus leading to a new signature (the body is unchanged).

Generic Bind (bind-tuples-generic.cs) download

public static Func<int, Tuple<int, U>> Bind<T, U>(
    Func<int, Tuple<int, T>> m,
    Func<T, Func<int, Tuple<int, U>>> k)

Fifth transformation: S type

The signature of our Bind function is a mouthful, but we can see that there’s a recurring pattern in there. Specifically, we can see occurrences of Func<int, Tuple<int, X>> again and again. Let’s encapsulate this into a generic type S<T> which will have a single member of that function type, arbitrarily named RunWithState.

Empty S class (s-class-empty.cs) download

public class S<T>
{
    public Func<int, Tuple<int, T>> RunWithState;
}

Let’s as well rewrite Bind in terms of S.

Bind (bind.cs) download

public static S<U> Bind<T, U>(S<T> m, Func<T, S<U>> k)
{
    return new S<U>
    {
        RunWithState = s0 =>
        {
            Tuple<int, T> mResult = m.RunWithState(s0);

            return k(mResult.Item2).RunWithState(mResult.Item1);
        }
    };
}

Now we can apply one additional transformation to our Label1 function by rewriting everything in terms of S.

Label1 fifth transformation (label1-leaves-transformation-5.cs) download

var bumpLabelS = new S<int>
{
    RunWithState = s0 => Tuple.Create(s0 + 1, s0)
};

Func<int, S<Tree<Labeled<T>>>> labelLeafS = labelValue => new S<Tree<Labeled<T>>>
{
    RunWithState = s1 => Tuple.Create(s1, leaf(labeled(labelValue, lf.Value)))
};

return Bind(bumpLabelS, labelLeafS).RunWithState(label);

Sixth transformation: Return

We can finally observe one more pattern in how the labelLeafS function creates an instance of the S type. You can see that the only value this instance depends on is the labeled leaf created inside its RunWithState function, which is of exactly the same type as the generic argument of the instance S<Tree<Labeled<T>>>. Not that we benefit much from it now, but let’s extract this pattern into a Return method, which given a T, returns an instance of S<T>.

Return (return.cs) download

public static S<T> Return<T>(T value)
{
    return new S<T>
    {
        RunWithState = s => Tuple.Create(s, value)
    };
}

Let’s also rewrite the relevant part of the Label1 function in terms of Return, additionally inlining the labelLeafS function.

Label1 sixth transformation (label1-leaves-transformation-6.cs) download

return Bind(bumpLabelS,
            labelValue => Return(leaf(labeled(labelValue, lf.Value))))
       .RunWithState(label);

Hiding the state

Before we move on and formalize the outcome of this long sequence of transformations in a new, named pattern let’s observe one important thing in the final version of our code. The final statement returns a value of type Tuple<int, Tree<Labeled<T>>> simply because we execute the RunWithState function of the S<Tree<Labeled<T>>> instance returned by Bind. Executing this function is also the only occasion in which we use the integer label argument of the containing function Label1.

The observation is therefore: if rather than returning a Tuple<int, Tree<Labeled<T>>> we returned S<Tree<Labeled<T>>> then we wouldn’t need the label argument in Label1 and shift to the caller the responsibility of executing RunWithState with the initial label value. In fact Label, the caller, is already doing that, just more explicitly via function arguments, but we can see that we have an opportunity to change the pattern of providing the initial state by moving from a function with this signature:

pseudo old signature

int, Tree<T> => Tuple<int, Tree<Labeled<T>>>

To a function with this signature:

pseudo new signature

Tree<T> => int => Tuple<int, Tree<Labeled<T>>>

Those familiar with functional programming will find that this is vaguely similar to currying, where a function of n arguments is transformed into n functions of 1 argument each.

We now have all the building blocks for rewriting our whole labeling functions Label and Label1 from a completely new perspective, where the final outcome is the same but the means by which we get there are completely different. This also justifies creating two new functions called MLabel and MLabel1, respectively.

MLabel and MLabel1 (mlabel-and-mlabel1.cs) download

public Tree<Labeled<T>> MLabel<T>(Tree<T> tree)
{
    return MLabel1(tree).RunWithState(0).Item2;
}

public S<Tree<Labeled<T>>> MLabel1<T>(Tree<T> tree)
{
    if(tree is Leaf<T>)
    {
        var lf = tree as Leaf<T>;

        var updateState = new S<int>
        {
            RunWithState = s0 => Tuple.Create(s0 + 1, s0)
        };

        return Bind(updateState,
                    labelValue => Return(leaf(labeled(labelValue, lf.Value))));
    }
    else
    {
        var br = tree as Branch<T>;

        return Bind(MLabel1(br.Left),
                    left => Bind(MLabel1(br.Right),
                                 right => Return(branch(left, right))));
    }
}

Together with Bind, Return and the type S<T> this is the bulk of the code required to label trees in this new way.

Now, although we have gone to great lengths talking about leaves, you might wonder why branches did not deserve their own considerations as I’ve included them in the code above already.
The reason is that as soon as you understand what we did with leaves it should be easy, even easier, to figure out what is happening with branches, as there is no state change involved. Before we try to understand the similarities I suggest you lookup the final version of the code from the previous post.

The analogy should be more visible than it is for leaves, let’s explain in words. We bind a recursive call to MLabel1 fed with the left tree of the branch to a function which takes the left labeled tree and binds another recursive call, this time fed with the right tree, to a function which takes the right labeled tree and returns an instance of the state monad created from a branch whose left tree is accessed via a closure and the right is the argument of the function itself.

Besides the mouthful, did I just say state monad? Ah right, the state monad is the triplet represented by S<T>, Bind and Return, while MLabel and MLabel1 are just our logic to label a tree in a third way besides manually and functionally: monadically.

As for the state monad, we just invented it, but more on this in the next post.

Labeling Trees - Introduction

2013-03-17T00:00:00+01:00

A few years ago I came across a video interview on Channel 9 starring Brian Beckman on a topic which I had never heard of before. The interview is still available online (part 1 and part 2) but you don’t need to watch it to follow me as I’ll start from the beginning and guide you gently through the whole topic.

Although I then considered myself an already proficient C# developer I was quite confused, I just couldn’t wrap my head around the crazy concept of passing state around invisibly, although it was done in my favorite language. The interview comes with full source code and an assignment containing 10 exercises, which I was quite disappointed I could not even tackle. The main topic of the interview is labeling a binary tree, and Brian showed how to do it in several ways, which we’ll see and try to understand before moving on to the exercises.

Time has passed and I can finally go back to that interesting topic and hopefully help someone else out there. The topic, needless to say, is monads, and not even the simplest of the monads, the state monad. This post is the first of a series where I’ll introduce the concept and then go through the exercises, hopefully solving them correctly.

Without further ado, here’s the class which will accompany us throughout the journey, during which it will undergo only minor changes: a binary tree in C#.

A binary tree (binary-tree.cs) download

public abstract class Tree<T>
{
    public abstract void Show(int indent = 0);
}

public class Leaf<T> : Tree<T>
{
    public T Value { get; private set; }

    public Leaf(T value)
    {
        Value = value;
    }

    public override void Show(int indent)
    {
        Console.Write(new string(' ', indent * 2) + "Leaf: ");
        Console.WriteLine(Value.ToString());
    }
}

public class Branch<T> : Tree<T>
{
    public Tree<T> Left { get; private set; }
    public Tree<T> Right { get; private set; }

    public Branch(Tree<T> left, Tree<T> right)
    {
        Left = left;
        Right = right;
    }

    public override void Show(int indent)
    {
        Console.WriteLine(new string(' ', indent * 2) + "Branch:");
        Left.Show(indent + 1);
        Right.Show(indent + 1);
    }
}

As you can see a tree can either be a leaf, containing a Value, or a branch, whose left and right sides will be other trees (and thus either branches or leaves). The entire class hierarchy is generic for no special purpose except that it will allow us to give a meaningful representation to the leaves via their T Value property. I’ve also included a Show(int) method to easily ask the tree to dump itself to the output stream. A couple of helper methods to create branches and leaves will also come useful:

Helper methods to create trees (helper-methods.cs) download

public Tree<T> leaf<T>(T value)
{
    return new Leaf<T>(value);
}

public Tree<T> branch<T>(Tree<T> left, Tree<T> right)
{
    return new Branch<T>(left, right);
}

Now creating and displaying a tree of type string is straightforward:

A simple tree (a-simple-tree.cs) download

                                //  tree.Show() outputs:
var tree = branch(              //  Branch:
            leaf("a"),          //    Leaf: a
            branch(             //    Branch:
              branch(           //      Branch:
                leaf("b"),      //        Leaf: b
                leaf("c")),     //        Leaf: c
              leaf("d")));      //      Leaf: d

tree.Show();

Manual labeling

First of all we need to know what labeling a tree means. In our case it means to navigate the tree and assign a integer label to every leaf. Tree navigation can usually be done in two ways, depth-first (DFS) or breadth-first (BFS), we’ll use the former here. In order to store the label in the leaves we need to enrich its structure. We’ll do that by making the generic parameter of the tree a Labeled<T>, defined as follows.

Label (labeled-class.cs) download

public class Labeled<T>
{
    public int Label { get; private set; }
    public T Value { get; private set; }

    public Labeled(int label, T value)
    {
        Label = label;
        Value = value;
    }

    public override string ToString()
    {
        return new { Label, Value }.ToString();
    }
}

public Labeled<T> labeled<T>(int label, T value)
{
    return new Labeled<T>(label, value);
}

In practice, labeling a structure of type Tree<T> means transforming it into a Tree<Labeled<T>>. With this new knowledge labeling our tree manually is as simple as recreating the same tree structure and replacing the value of the leaves with a Labeled<string> instance, incrementing the value of the label manually every time we visit a leaf.
The value, or state, of the current label at each point in time lives in our brains: we’ll have to remember the previous value and increment it every time we visit a leaf. Not a big deal as long as the tree is small.

Manually labeled tree (manually-labeled-tree.cs) download

                                                 // labeledTree.Show() outputs:
var labeledTree = branch(                        // Branch:
                    leaf(labeled(0, "a")),       //   Leaf: { Label = 0, Value = a }
                    branch(                      //   Branch:
                      branch(                    //     Branch:
                        leaf(labeled(1, "b")),   //       Leaf: { Label = 1, Value = b }
                        leaf(labeled(2, "c"))),  //       Leaf: { Label = 2, Value = c }
                      leaf(labeled(3, "d"))));   //     Leaf: { Label = 3, Value = d }

labeledTree.Show();

Functional labeling

As you can see labeling a tree manually is not very useful, imagine to have a tree with more than a bunch branches and leaves, it becomes quickly inconvenient. What if we could label it programmatically? We indeed can, and we’ll have to come up with a function, which given our initial unlabeled Tree<T>, gives us back a Tree<Labeled<T>>.
Let’s call Tree<Labeled<T>> Label<T>(Tree<T>) such a function.

Label function (label-function-empty.cs) download

public Tree<Labeled<T>> Label<T>(Tree<T> tree)
{
    // what to write here?
    return null;
}

One constraint that we want to have is that we don’t want to store the current label in shared memory and update it whenever we visit a leaf. We would like to do it in a purely functional way. This means that the state needs to be passed around explicitly, with a starting value of 0. This suggests that we’ll need an additional support function that will thread the state via its arguments and return the updated state via its return value.
Given the structure of the data we’re handling this function will also most likely call itself recursively.

Label and Label1 functions (functional-label.cs) download

public Tree<Labeled<T>> Label<T>(Tree<T> tree)
{
    return Label1(0, tree).Item2;
}

public Tuple<int, Tree<Labeled<T>>> Label1<T>(int label, Tree<T> tree)
{
    if(tree is Leaf<T>)
    {
        var lf = tree as Leaf<T>;

        return Tuple.Create(label + 1, leaf(labeled(label, lf.Value)));
    }
    else
    {
        var br = tree as Branch<T>;

        var left = Label1(label, br.Left);
        var right = Label1(left.Item1, br.Right);

        return Tuple.Create(right.Item1, branch(left.Item2, right.Item2));
    }
}

Label1 accepts an integer value representing the current label and a tree to be labeled. Its return value is a tuple containing the new label value and the labeled tree.

Let’s go through the code to see what it does exactly. You can see that it does two different things according to whether the tree to be labeled is a leaf or a branch.
In the first case it labels the leaf with the current value of the label, bumps it and returns a tuple containing the new label value and a leaf labeled with the value of the label before bumping it.
In the second case it first calls itself recursively to label the left branch of the tree, which returns again a tuple with the current label value and the labeled sub-tree. Then it does the same with the right branch by passing the just-returned label value as the current label value. Finally it returns a tuple containing the final state of the label and a newly constructed labeled branch containing the previously labeled left and right branches.
You might notice that it is this way of recursing that enables the depth-first approach.

Finally, Label calls Label1 passing 0 as the initial state and returning only the second item in the tuple, which is the labeled tree.

The interesting thing about this approach is that it does not rely on any shared state to do the labeling. The current value of the label is passed as a function argument and the new value is returned as part of the result, versus storing the label value in a variable accessible from the function and incremented every time.

In the next post we’ll see how to make this state-passing less explicit, while still avoiding shared memory to store it.

Async support in NUnit

2013-01-19T00:00:00+01:00

.NET’s version 5 of the C# compiler introduced support for an interesting feature related to multithreaded programming, available via the new async and await keywords.

This post is not much about the feature itself as plenty of information is available online, but rather the support that was introduced for it in NUnit. Here is a simple NUnit test:

A simple test (nunit-simple-test.cs) download

[Test]
public void OneSimpleTest()
{
    var eightBall = new EightBall();
    var answer = eightBall.ShouldIChangeJob();

    Assert.That(answer, Is.True);
}

So far so good, but let’s assume that invoking that method on the 8 ball is really expensive in terms of execution time and you would like your production code invoking it to not just sit and wait until it completes. That’s where the async feature fits, and you could change the method to be an async, Task-returning one instead. How to make that specific method asynchronous is definitely out of scope here though.

Testing asynchronous code

In order to call the new method asynchronously the test code would need to be adapted as shown here:

A simple async test (nunit-simple-async-test.cs) download

[Test]
public async void OneSimpleTest()
{
    var eightBall = new EightBall();
    var answer = await eightBall.ShouldIChangeJob();

    Assert.That(answer, Is.True);

    // why am I still here?
}

Awaiting the result of the method implies that the test method has to be marked as async, too. Now, assuming that you’re not planning to change job you would really expect the test to fail, which it instead doesn’t if run with a version of NUnit older than 2.6.2.

The reason behind this incorrect behavior is that asynchronous methods are rewritten by the C# compiler in a way that they return control to the caller as soon as they await on an operation which has not completed yet, as is the case with the invocation of the ShouldIChangeJob method. In this case therefore the control is returned to the code which called the OneSimpleTest method, which turns out to be NUnit itself.

Up to version 2.6.2 of NUnit the test runner always assumed that as soon as a test method returned then its execution was complete, and thus if no assertion failures were reported the test was successful. This is no longer the case with asynchronous methods, as we just found out, because the now asynchronous test returns immediately after invoking ShouldIChangeJob on line 5.

Without any support from NUnit there was a simple fix available already, which was to Wait on the Task returned by the asynchronous method rather than await it.

A simple test - workaround for async (nunit-simple-test-workaround.cs) download

[Test]
public void OneSimpleTest()
{
    var eightBall = new EightBall();
    Task<bool> answer = eightBall.ShouldIChangeJob();
    answer.Wait();

    Assert.That(answer.Result, Is.True);
}

This would work perfectly, although it’s not as nice as being able to write the test code in the same way you would write the production code, that is, by using the await keyword. This has the additional disadvantage of exception handling behaving differently between await and Wait. When using await the code looks like everything is happening sequentially, and you can catch exceptions in the same way you do with sequential code. If ShouldIChangeJob threw an exception of the fictitious type TimeoutException you would see exactly that exception bubbling up from your code. When using Wait instead a System.AggregateException would bubble up, which is a sort of container for multiple exceptions which might have happened during an asynchronous operation, and would wrap the real TimeoutException. This of course makes await more intuitive and preferable over Wait.

Just a matter of Waiting

Introducing this support in NUnit doesn’t necessarily mean that NUnit has now become asynchronous or that it allows to run tests in parallel. This is something which is being worked on for the next 3rd major release of NUnit though.

What we did in NUnit 2 was to allow users to write async tests without worrying about tests completing before their assertions were even evaluated, in addition to supporting thorough use of asynchronous methods in some specific framework use cases. In other words, when invoking asynchronous test methods NUnit will “sit and wait” on your behalf, until the test method, along with all the asynchronous operations it invokes, has finally completed.

Behind the scenes

As should be clear by now NUnit’s support for async methods is mainly a matter of detecting async methods, calling Wait on the Task returned by them and handling exceptions accordingly. This is true in most cases, although NUnit’s need to be compatible with .NET 2.0 means that all of this logic needs to be implemented without referencing any .NET > 2.0 assemblies.

Yet this was still not as straightforward, but we really strived to open up as many intuitive usages of await/async as possible so to relieve the users from having to even think about it.

Although you might not have noticed it you’ve already encountered one example of why this is not trivial. In the asynchronous sample above you can see that the test method is void. What does it mean exactly? Well, it means that there is no Task on which to call Wait, and that really waiting for it to complete means setting up a new SynchronizationContext to hook into the .NET implementation of the async/await feature.

Although asynchronous void methods were not designed for this purpose and Microsoft itself discourages using them besides in event handlers, we really wanted to support them for a couple of reasons:

Not supporting them would mean that NUnit would throw an exception at runtime every time a test is written with an async void signature
Most users would probably repeatedly commit the same mistake of writing asynchronous test methods as void async because no one really cares about their return value

We thought that the two reasons above would lead to a frustrating user experience and decided to support async void tests as well as Task-returning ones. This choice came with some drawbacks too:

The ways async void methods interact with the SynchronizationContext in which they run is undocumented and might change in the future, which opens up the possibility of breaking NUnit’s implementation
Switching the SynchronizationContext in which the test method runs (the way NUnit supports async void tests, that is) might affect even up to a great extent the flow of the code wrapped by the new SynchronizationContext

We though that these two issues alone did not justify the poor user experience and we opted to fully support async void tests.

If not void, what?

Now, although it seems quite reasonable to write the above asynchronous test as one returning void it is equally valid to write it so that it returns a Task instead.

A simple async test returning Task (nunit-simple-async-task-test.cs) download

[Test]
public async Task OneSimpleTest()
{
    var eightBall = new EightBall();
    var answer = await eightBall.ShouldIChangeJob();

    Assert.That(answer, Is.True);
}

It is actually more advisable to do so if you are especially interested about forwards compatibility of your code for the reasons explained above. If you do this NUnit will not have to jump through hoops to run it correctly and will simply fall back to waiting on the returned task.

async, where else

As briefly mentioned earlier support for await/async in NUnit 2 goes beyond test methods. The good thing about it is that in most cases you won’t have to think about whether it is supported or not, because it most likely is.

In any case here’s a by-no-means complete overview of places where we had to do some relevant work.

Test cases checking results via Task return values

Methods marked with TestCaseAttribute can return values, which are then checked against the Result property of the test case. They now support returning result asynchronously:

An async test case returning Task<int> (nunit-async-testcase.cs) download

[TestCase(1, 2, Result = 3)]
public async Task<int> TestAddAsync(int a, int b)
{
    return await SumAsync(a, b);
}	

public async Task<int> SumAsync(int a, int b)
{
	return await Task.FromResult(a) + await Task.FromResult(b);
}

Async lambdas

The async support went slightly beyond test methods, and extended to framework features which accept lambda expression as their arguments:

Async lambda support in NUnit framework (async-lambda-support.cs) download

[Test]
public async Task AsyncLambaSupport()
{
    // throwing asynchronously
    Assert.That(async () => await ThrowAsync(), Throws.TypeOf<InvalidOperationException>());

    // returning values asynchronously
    Assert.That(async () => await ReturnOneAsync(), Is.EqualTo(1));

    // "After" works with async methods too
    Assert.That(async () => await ResutnOneAsync(), Is.EqualTo(1).After(100));
}

Framework support is not yet available in NUnit 2.6.2, it will be in the next build.

Test context availability

If you don’t know about TestContext I suggest you check it out as it might come handy in a bunch of scenarios. If you’re already using it, just be aware that it is now accessible anywhere inside the body of asynchronous tests, which is how you would expect it to be.

What else?

This feature has been ported to the upcoming major release 3.0 of NUnit as well as to NUnitLite to make it available consistently throughout the whole testing platform.

If there’s anything we’ve missed feel free to let us know on the NUnit’s mailing list.

NUnit via LINQPad

2012-10-28T00:00:00+02:00

I’ve been a frequent user of LINQPad for several years now for I enjoy the simplicity with which you can fire it up, start writing code and see the results immediately. I appreciate that other programming languages provide REPLs for you to try and even modify the currently running application, and I enjoy them when I have a chance to work with node.js or Ruby, but this is not something that people writing C# code are used to, and in any case outside the scope of this post.

Recently my involvement with NUnit has increased to some extent and on several occasions I found myself needing to try running one-off tests and quickly see their outcome in order to validate bug reports or in general for experimenting.
As you can guess this would usually require launching a full-featured IDE like Visual Studio, create a class library project, reference NUnit, build and run some NUnit runner against the resulting assembly. That’s a lot of work for just getting a few lines of code to run.

The idea was therefore to be able to run NUnit tests on LINQPad, which is definitely possible and quite simple, as it turns out.

Now, a bit of background about NUnit is in order. The current release, which at the time of this writing is 2.6.2 and has been available for a few days, along with the whole 2.x series, has always kept the framework and the core separate.

The framework is contained in the nunit.framework.dll assembly, which client code usually references in order to write tests. Just to mention a few it contains the TestAttribute and the Assert classes, which everyone writing unit tests should be familiar with.
The core, on the other hand, contains the code needed to run the tests, which includes test discovery, filtering, the logic for handling application domains and processes, and finally exposes this functionality by means of test runners. NUnit currently ships with a console and a graphical GUI runner.
This net separation of the core from the framework basically means that running tests in LINQPad via NUnit requires referencing both the core and the framework assemblies, and then invoking a runner pointing it at the current assembly. This is possible but also not the fastest and cleanest way to accomplish it.

Enter NUnitLite. NUnitLite has been around for some time now and the main difference with NUnit v2 that is of some relevance here is that there is no distinction between the core and the framework. Everything is contained within a single assembly that you can reference from your tests, and the very same project containing the tests can be used to run them with a single one-liner.

Although NUnitLite does not provide all of the features of NUnit it has quite enough of them for most needs, and above all simplifies our life a lot here.
On the other side, we’re going to leverage a new feature available in LINQPad, the ability to reference NuGet packages, which right now is provided in the beta version downloadable from here.

Now that the ground is set here are the steps to get started writing unit tests in LINQPad:

Create a new query and set its Language to C# Program, which will create a stub main method
Add the NUnitLite NuGet package, which is easily done by hitting F4, then Add NuGet… and then looking up and selecting NUnitLite. Also add the namespaces NUnit.Framework and NUnitLite.Runner

Fill the main method with the single line which will allow to run the tests in the current assembly and finally start writing unit tests.

NUnitLite in LINQPad (linqpad-nunitlite.cs) download

void Main()
{
  new NUnitLite.Runner.TextUI().Execute(new[]{"-noheader"});
}

// Define other methods and classes here
[Test]
public void SomeTest()
{
  Assert.Pass();
}

Hit F5 and see the results of the test run

The steps outlined above are quick and simple, but still require some time if you have to do it over and over, therefore a better option would be to save the raw template as a LINQPad query somewhere on your file system, or even better, although this chance is limited to the owners of a professional license, using a snippet which is available for download from the NUnit wiki here.

The snippet takes care of the whole plumbing so you just need to download and copy it to the snippets folder, usually in %userprofile%\Documents\LINQPad Snippets, then just type the snippet shortcut, nunit, in any query window and you’re ready to write your tests.

Past, present and future of .NET assembly merging

2011-11-21T00:00:00+01:00

Compiling code written for the .NET framework usually produces assemblies in the form of either standalone executables or libraries. These assemblies contain mainly Microsoft Intermediate Language (MSIL) code which is then jitted upon execution.

It’s not uncommon for libraries which expose public APIs to rely internally on assemblies provided by third parties that should not end up in the final package. I’ll take the mocking library NSubstitute as an example.

There are commonly a couple of reasons why they shouldn’t. First, the client code does not need to reference them directly as they are only used internally. Back to the mocking framework example, it wouldn’t make a lot of sense to build a dynamic proxy from scratch as there exist excellent implementations already, like Castle DynamicProxy, which NSubstitute uses.
The other reason is to avoid cluttering the release package of the library with dependencies that are of no interest to the end user, thus simplifying the distribution of the library which would then consist of a smaller number of files.

The aim is thus to embed somehow the dependent assemblies in a single assembly. There has been mainly a single approach to this so far, and it’s called ILMerge.

ILMerge

Mike Barnett’s ILMerge is a free tool which statically links several assemblies into a single output assembly. It runs as a console application and rewrites the IL of the main assembly by embedding the contents of the other assemblies into it. It takes care of a couple of additional things, like strong naming and target framework version, but accepts additional configuration options which allow further customization. One particularly useful is internalization of types, which allows to change the accessibility levels of the types contained in the dependent assemblies, thus effectively hiding them to everyone except the containing assembly.

One thing to be aware of is that embedding types belonging to one assembly into another assembly makes the first lose its original identity. This can represent either a pro or a con depending on the use case. Serialization and security may not work correctly, as they usually make some use of metadata related to the assembly, which now no longer exists, but also opens up interesting scenarios.

NSubstitute ILMerges the Castle.Core.dll assembly, which contains the DynamicProxy part. If you were to use NSubstitute in a project where you needed to make use of DynamicProxy directly you would be safe, and could use whatever version of the library you liked, as the runtime would consider the types as belonging to different assemblies and thus not conflicting in any way. The only issue you could encounter is of conflicting namespaces if the assembly wasn’t merged with its types internalized. Public types would in fact still be visible and you would need to specify some alias to avoid ambiguous references.

If on the other hand NSubstitute didn’t merge Castle.Core.dll and distributed it alongside NSubstitute.dll, then you would be somewhat tied to use the version distributed with NSubstitute. Loading different versions of the same assembly in one AppDomain is in fact discouraged as it can generate all sort of weird behaviors. Also it wouldn’t be very easy to load two versions of the same assembly because unless the assemblies resided in the GAC you would have to find a way to keep them both on the file system, and assuming you usually load assemblies from the same folder you couldn’t let two files with the same name stay in the same folder. In this case the version of the assembly ending up in the output folder would depend on the build process, according to the order it chose to resolve dependencies during compilation.

Another recent and blocking shortcoming of ILMerge has to do with WPF assemblies. These assemblies contain embedded resources which in turn encode the identities of the original containing assembly. As I said merged assemblies loose their identities, therefore these resources would no longer behave correctly. ILMerge would thereby need to extract the resources, patch the encoded assembly identities replacing them with the target assembly identity and re-encode them, something which it is not capable of doing as of now.

And that’s from embedded resources that comes another solution.

Embedding assemblies as resources

Serializing other files into assemblies as resources has always been possible. Resources can then be deserialized at runtime and manipulated. They can be anything, although commonly used for storing media, icons and inanimate data in general. Nothing prevents you from storing assemblies in there, and load them at runtime. This approach has been described thoroughly by Jeffrey Richter in his excellent CLR via C# book, whose relevant excerpt is available here.

The approach is simple, so simple that ILMerge creator commented:

As the author of ILMerge, I think this is fantastic! If I had known about this, I never would have written ILMerge.

The trick to make it work is to subscribe to the AppDomain’s AssemblyResolve event. This event is fired when the runtime is unable to locate a referenced assembly, and as a last chance gives the application developer a chance to pick it up according to custom logic. The logic here is to load the assembly from the resources and load it into the application domain.
One caveat is that the AssemblyResolve event needs to be subscribed to before any code requiring the embedded assemblies is ever run, which is not always possible. One such case is a .dll, which has not explicit entry point.

To work around that you have to rely on a feature of the .NET framework which is not exposed to the programming languages directly, called module initializers. Think of type initializers (aka static constructors), just for modules. In the same way as type initializers are guaranteed to be called before any members in a type are accessed, modules initializers extend this guarantee to the types with an module (assemblies usually contain a single module).

Placing the AssemblyResolve subscription instructions in a module initializer is thereby either the safest or unique option to inject custom assembly resolution logic, but requires IL manipulation.

Costura

Costura is a neat open source project developed by Simon Cropp which takes care of all the steps described above, and is thereby the suggested way to merge third party assemblies using the embedded resource approach.

It does so by embedding all referenced assemblies marked as copy local (thus excluding assemblies living in the GAC, for instance) into the main assembly, and then injecting the module initializer code which subscribes to the AppDomain’s AssemblyResolve event and looks up unresolved assemblies from the embedded resources.

Costura only requires you to call its custom MSBuild task in the AfterBuild target of the main assembly project.

Costura task (costura.xml) download

<UsingTask
    TaskName="Costura.EmbedTask"
    AssemblyFile="$(SolutionDir)[path to]\Costura.dll" />

<Target Name="AfterBuild">
    <Costura.EmbedTask />
</Target>

This approach however comes with its drawbacks too. Most notably it prevents multiple version of the same assembly to be loaded, as in this case the assemblies maintain their identity. This can be dangerous because it could lead to non-determinism in which version of one assembly is loaded. For example, if you distributed a library using this approach and the library client was referencing directly an assembly with the same identity as one of those embedded in your library, which assembly gets loaded in the application domain would depend on the order in which the client code uses your library. If your library is loaded in memory first, then its version of the third party assembly would be loaded in memory, in the other case the client code version of the library would be loaded instead, leading to a fully working application in the best case and to a runtime exception in the worst.

Both approaches have their pros and cons, but it’s useful to realize that both exist and know when to apply each.

Speaking's overrated

2011-11-19T00:00:00+01:00

Today is the Italian Agile Day, happening in Rome.

I didn’t attend mostly because past editions haven’t been very interesting, with a few exceptions, and I’ve been following some sessions on the live streaming site from home.

It happens quite rarely that I hear anything really interesting being said at these meetings, but I can live with that, there’s usually not enough time to delve into a topic deep enough to provide any valuable understanding. More often, there is barely time to instigate curiosity so that people can further research when they go back home. This is perfectly healthy, and what I try to do when I speak myself.

Sadly what I see happening most of the times are speakers talking for hours without really saying anything except trying to sound convincing. I’ve experienced this so many times now that I’m starting to think that it is probably intentional attitude rather than a side effect due to lack of skill or anything else.
When I was younger I would look at these talks in wonder, asking myself when I would have been able to speak in the same way about complex topics that at the time I just could not understand. Now that I’ve somewhat grown up professionaly I can look at things a bit differently and judge with more awareness what is going on, and it pisses me off.
It does mostly because when you speak to people you have some responsibility towards your listeners, and they don’t expect you to deceive them or may not even be able to realize that it’s what you’re doing. There are other reasons, however.

Out of context - deliberate omission

You have probably heard someone saying that context is king. It indeed is. Many people tend to make absolute statements way too often, and to avoid the effort of figuring out whether there may be any truth in what they’re saying my current strategy is to simply assume that they are wrong.

Frameworks are a smell

QA is useless

These are just some examples of things I’ve heard presenters say in the recent past. Now I consider myself as being on neither side of the spectrum when it comes to these topics, because as usual context is king. How can you say that using an ORM is always wrong and slows you down? There are compromises that you need to be ready to accept, but aren’t always there?

Another variation of taking things out of context is when something is deliberately omitted. It is way too easy to support your thesis when you intentionally omit arguments that go against it. It’s not easy to realize omissions unless you know a topic very well, or you’re directly involved in the omission, like I had to hear right today about proposing (I proposed it) a supposedly terribly bad TDD video course to be watched by development teams in the company.

Knowledge flaunt

As I said it’s usually hard to delve into a topic enough during a time constrained speech. Nonetheless, it should not be an excuse to pretend you know much more about the topic than you actually do.
Once again it’s hard to judge whether someone is really an expert or is pretending to be one, and the most effective way is to know the person yourself. The most annoying attitude is when the speaker is presenting at the most of his knowledge while pretending that he’s talking about the easy things, and there’s much more to it that you’re not entitled to know just yet.

This happened very recently to me, with a person I know presenting the easy things about a topic and laughing annoyed at most people not getting it right. Just a week before me and him talking about the very same topic in a slightly more advanced manner caught him off guard, with me thinking whether he really knew anything about it.

Fluff

Lots of presenters finally just speak of fluff. In Italian it translates nicely to fuffa. This is probably the easier to figure out when attending a presentation, because at the end you are left thinking whether anything of what you’ve heard really made any sense.
Someone built their entire career on this, and you usually see them proposing training and courses. These people are dangerous mostly because they are attractive to companies. I personally believe that these people are not even worth a penny.

Why speaking is overrated

There is much more to this than I’ve been able to explain in my first blog post after several years, but I hope I have given some valid arguments.

I am under the impression that pretty much everything that you can hear talking about is overrated, as people have to make a living out of it.