Non-shoes

Back in April Tony, knowing how much I don’t like shoes, sent me a link to an article titled “You Walk Wrong” that discussed the problems with shoes and footwear that feels close to barefoot.

Before that my favourite footwear was my Teva sandals, but they had some limitations: most importantly, I could not wear them to work as the dress code is a bit more formal than my usual “shorts ‘n’ sandals”. They also had the problems mentioned in the article.

I was keen to try two of the barefoot-style shoes mentioned: the Vibram Five Fingers and the Vivo Barefoot; so I did.

The Five Fingers were interesting. Some friends had already tried and spoke highly of them. Having now tried them quite a lot myself, I have mixed feelings. When I first put them on I thought they were great, although my toes felt slightly odd being each enclosed in their own little toe-sock. But on that first hot summer day that was fine. Unfortunately by the end of that day I had developed blisters on both feet. I was certain this was caused by a defect in the shoe since I could have managed the same travel completely barefoot without any problems. Schwern said the same thing happened to him: it was caused by lumps in the seam between the sole and the upper; and he fixed it by adding some moleskin. Simple solution, but why should I have to fix my new shoes?! Vibram, please keep the seam smooth, or move it to the side of the shoe where it can’t cause these sort of blisters.

A few months later I discovered another problem with the Five Fingers: they don’t dry well. They are good when permanently wet and great in the sun, but if you get them wet just once in the morning of a non-sunny day, they’ll still be wet the next morning. Compared to my Tevas this was a downgrade. The Tevas, not having any upper, would dry out in a few hours of use, and allow my feet to dry too. The Five Fingers stayed wet and kept my feet wet. Then both feet and shoes started to stink. At least the five fingers were easy to wash.

The Five Fingers are also not acceptable office wear (except at weekends), but they are a conversation starter. I think they’re great for outside the city, but not for urban use.

The Vivo Barefoot, however, are the greatest urban footwear I’ve ever seen. Quoting the article: The Vivos are a totally different experience, since they’re as close to going barefoot in the city as you can get. I bought the “Dharma” version. The sole is thin enough for me to feel the texture of the ground, but tough enough to protect my feet. Although enclosed, my feet feel free. The Vivo Barefeet do take a while to dry out if they get wet, but they don’t get as wet as easily as the Five Fingers. But for me the best feature is that nobody in the office notices that they aren’t normal shoes!

Practical OCaml: larger example

This "Larger Example" I’m going to write about is in chapter 18, starting on page 243. The chapter is (supposed to be) about the object oriented features of OCaml (they would be the "O" part) but this example is more objectionable than objective. It was intended to be an implementation of the Levenshtein distance algorithm: it started with an incomplete description of that algorithm and a figure of a matrix with four mistakes. Then it got worse.

Smith’s plan was to create a base class containing the algorithm and then use subclasses to adapt the algorithm to different data types. But when I looked at the edit_distance base class I noticed that half of the core algorithm was missing! I found it in the string_edit_distance subclass, and also in the list_edit_distance subclass. Martin Fowler in his great "Refactoring" book says: Number one in the stink parade is duplicated code. If you see the same code structure in more than one place, you can be sure that your program will be better if you find a way to unify them. Following Fowler’s good advice, which Smith should have done, I moved the duplicated code to the base class. There was only a small bit of code that was different for each subclass: the part that compares the elements of the particular data structures (strings and lists in this example) to work out if a changing cost is required. I created a cost_to_change method to handle that.

Then I tried to simplify the code and make it more readable.

In the update_matrix method I removed three of the let bindings and passed the calculation results directly the trimin function I mentioned before.

In the gen_matrix method I replaced the pattern matching and nested iteration functions with two separate iteration functions, which hopefully makes it clear that we are only initialising the first row and first column; most of the matrix is left untouched.

In the calc method, which I’d moved from the subclass to the base class, I again replaced the pattern matching and nested iteration functions, this time with nested for loops. Pattern matching and higher-order iteration functions are very powerful, and they could be used instead of loops and conditional statements in all ocaml code; but ocaml includes for loops and if statements because they are easier to use and understand than the more powerful features. Choose the right tool for the job.

As a result of all these changes the size of a subclass has been reduced from 18 lines to 6, only 2 of which need to be changed for each data type (the other 4 are structure). You can have a look at some of Smith’s code and my modified version to see the differences for yourself.

Practical OCaml: not again

I was about to comment on the "Larger Example" in chapter 18, starting on page 243; but first I have to get rid of the trimin method it contains:

    method private trimin x y z = match x,y,z with
        m,n,o when (m > n) -> if (n < o) then n else o
      | m,n,o when (m < n) -> if (m < o) then m else o
      | m,n,o -> if (n < o) then n else o

Let me now repeat exactly what I said in my previous post: Huh?! This method will return the smallest of its three arguments, although its ugliness made me doubt that for a while. But even if it were improved, it shouldn't even be part of this class at all. So I removed that method and replaced it with a simple function:

let trimin x y z = min x (min y z);;

That done, I was then able to continue with the "larger example".

Practical OCaml: minimum review

I have been reading Practical OCaml. I didn’t buy the book; I recommend that you don’t buy it too. I was given a copy and asked if I could say something good about it, so here goes: “it could be worse”.

There are so many other negative reviews of this book I don’t want to just repeat what has already been said. Instead I’m going to criticise some parts of it in more detail in the hope that it may help. I’m going to choose targets on a whim, with not much rhyme or reason; that should mirror the structure of the book quite well.

So, to start small, my first complaint is against page 172. Smith (the book’s author) writes:

let min x y = match x with
    n when x < y -> x
  | _ -> y;;

Huh?!

That can’t possibly be a sane way to define a function that returns the smaller of two arguments. In addition to the needless complexity we have the unused named value n. What was wrong with:

let min x y = if x < y then x else y;;

That should be clear enough. But I now have another question: why even bother? The min function is built-in to OCaml; it is part of the Pervasives module that provides “<” and the other comparison operators.