In addition to my business, I work for a county-level government agency in Florida. Our legacy system is a 1.2-million-line steaming pile of VB6. While it works (for limited definitions of “works”), there’s no way we’re going to be able to maintain it forever, and we’re certainly not going to write new projects in VB6.

Since we’re a Microsoft shop, we’re going to the .NET platform. The choice, however, is whether to use the familiar syntax and stick with VB.NET, or to harness the additional power of C#. I favor the latter approach, and I’m pleased that the Powers That Be agree.

The world of .NET development is dramatically different from VB6. Techniques that work in VB6 no longer work in .NET; techniques that work in .NET fail miserably in VB6, and even some things that work in both environments are sufficiently different to be difficult to understand.

Using similar syntax to express dissimilar ideas is a recipe for confusion.

I find it difficult to get started on a huge project if I know the project is going to be huge up front. It’s even harder at the tail end of a project, when all of the fun stuff is done and all that’s left is the annoying little tweaks and bug fixes needed to make a program ‘production ready’. Project Waldo¹ is in that very phase right now. When the fun stuff is done, my velocity drops to near zero.

The biggest problem seems to be a lack of internal feedback on time use. If I spend seven hours coding and one hour conferring with colleagues, that’s a productive day. If I spend one hour coding and seven hours conferring with colleagues, that’s an unproductive day. If I spend eight hours reading programming books, that’s a supremely unproductive day (except for the professional development idea). But I tend to gravitate toward lack of productivity, because, frankly, it’s more fun than keeping my nose to the grindstone, and I tend not to notice that I’m not being productive.

That’s where the Pomodoro Technique comes in.

For those of you who haven’t heard of it: the Pomodoro Technique is a time management system, based around indivisible units of time (“pomodoro”²). A standard pomodoro is 25 minutes, followed by a 5 minute break.

The advantages are many. First, and foremost, there is immediate feedback if my work begins to slow down again. If the end of the day arrives and I’ve only completed three pomodoro, I know that either I’m spending too much time goofing off or I’m being far too often interrupted. Second, the system reminds me to take frequent breaks. When I do get in the zone, I tend to not leave my chair for hours at a stretch (no pun intended). The bell gets me out of the zone and onto my feet. Finally, the recording system doubles as a to-do list; as I think of things I need to do, I write them down, and I can go back and prioritize later. Without a system, everything tends to either be ‘priority 1′ or completely forgotten.

It also works because it appeals to my sense of completionism. If I see a goal on my list, I want to complete it. The Pomodoro Technique literature suggests tasks be broken down into approximately 3-hour increments (5 to 7 pomodoro). I can see my progress toward those goals; I can’t really see the progress toward the end. At any given time, I know what I’ve done and what is left to do.

I know that the Pomodoro Technique seems to have been further refined and polished among the developer community. I’m not really using those refinements yet; I’m “playing by the book”. The system as written works for me, and while I may be able to adjust it later to better fit my needs, I’ll try it as it is for a while.

FOOTNOTES
1. It’s a mapping application. I’m a GIS developer, even though it’s not really my passion. But I can still make corny puns. ↑
2. The plural of “pomodoro” is an open question. Proper Italian is either “pomidoro” (from “pomo d’oro”) or “pomodori”. “Pomodoroes” would probably fit in English, but doesn’t ring well. According to a colleague, the plural of “pomodoro” is “pomodoro” (or maybe it’s “sharpei”, I’m not sure). ↑

So far, I’ve solved problems 1-10, 14, 47, and 243. Problem 9 doesn’t really count as I basically borrowed the code verbatim from another site, and problem 5 almost doesn’t as I solved it with pencil and paper.

I may cover a few of the others later, but for now I’ll focus on 14.

Problem 14 was a bit trickier than it looked. I knew from the start that I’d have to resort to some sort of memoization to get runtime down to a reasonable level. As noted on the Project Euler site:

Each problem has been designed according to a “one-minute rule”, which means that although it may take several hours to design a successful algorithm with more difficult problems, an efficient implementation will allow a solution to be obtained on a modestly powered computer in less than one minute.

A brute-force solution without memoization took way too long on the virtual machine I use to run Visual Studio 2010. (I don’t know how long, because I killed it after about ten minutes.) So, I borrowed some code from Programming F# (page 199):

open System.Collections.Generic

let memoize (f : 'a -> 'b) =
    let dict = new Dictionary<'a, 'b>()

    let memoizedFunc (input : 'a) =
        match dict.TryGetValue(input) with
        | true, x -> x
        | false, _ ->
            let answer = f input
            dict.Add(input, answer)
            answer

    memoizedFunc

The project statement uses a starting point of 13, and gives a sequence length of 10; I realized that if the sequence ever reached 13, for instance, it would always be at 1 ten iterations later. My first attempt at a solution copied around the actual sequence of numbers for each starting point. Ideally, if I always tacked the new number on as the head, the tail would eventually be a list that had already been generated, and wouldn’t need to be recreated or even copied, as the new list could just point to the old one.

While this wasn’t a horrible idea, it seemed a lot slower than I’d like. So, I switched to a simple tally of sequence length. Still slow.

After I let the program run all the way through, I realized my problem: the debugging output. What started as a ten-minute process shortened itself to about ten seconds when I removed the printfn from the inner function. I probably could have kept the sequence after all.

let rec collatz =
    // The only reason to create an inner function here
    // is to memoize it. You have to call the outer
    // function recursively or the memoize function
    // won't catch it.
    let collatz_ (x : int64) =
        if x = 1L then 0
        elif x % 2L = 0L then
            1 + collatz (x / 2L)
        else
            1 + collatz (3L * x + 1L)

    memoize collatz_

// Candidates
[ 1L..999999L ]
    // Calculate path length for each, decorate
    |> List.map (fun x -> (collatz x, x))
    // Sort by path length...
    |> List.sortBy fst
    // ... long paths first
    |> List.rev
    // Give me just the longest path
    |> List.head
    // Give me just the starting point
    |> snd;;

PS: if you’re asking why it’s called “collatz”?

So, what did I learn?

I learned that console output is slow. I also learned that decorating an input list with tuples (a la the “Schwartzian Transform”) is a useful technique in F#. Function pipelining is incredibly handy. And I’m addicted to Project Euler.

Explicit Interface Implementation

Why are all interfaces implemented explicitly, making it necessary to cast an object reference to an interface type before using any of the members of that interface? I thought requiring that sort of redundant bullcrap was phased out with COM. The compiler knows what interfaces the class implements; shouldn’t it be able to determine, at least in the simple case, whether you’re calling something on an interface?

I mean, the compiler should be able to figure this out:

// Borrowed with modification from "Programming F#"
type IDoStuff =
    abstract DoStuff : unit -> unit

type Foo() =
    interface IDoStuff with
        override this.DoStuff() = printfn "Doing stuff..."

let x = new Foo()

// This fails with a compiler error
x.DoStuff()

// This works.
(x :> IDoStuff).DoStuff()

// This works too.
let y = x :> IDoStuff
y.DoStuff()

Don’t get me wrong; I understand the utility of explicit interface implementation, at least when member names collide. But is it really necessary to require all interface members be explicit?

Note that this only applies to classes implemented in F#. Classes implemented in C# have the option of implementing interfaces implicitly, and F# can use those interfaces without casting. In VB.NET, interfaces are implemented explicitly, but generally with a method with the same name:

Public Interface IDoStuff
    Sub DoStuff()
    Sub DoMoreStuff()
End Interface

Public Class Class1
    Implements IDoStuff

    Public Sub DoStuff() Implements IDoStuff.DoStuff
        Console.WriteLine("Doing Stuff")
    End Sub

    Public Sub AnotherMethod() Implements IDoStuff.DoMoreStuff
        Console.WriteLine("Doing More Stuff")
    End Sub
End Class

Calling it from F# works much the same way:

let x = new ClassLibrary1.Class1()

// This works, since the method has the same name in the interface and class.
x.DoStuff()

// You can't call the interface method...
x.DoMoreStuff() // (fails with a compile error)

// ... but you can call the implementing method directly.
x.AnotherMethod()

// Or you can use the upcast operator.
(x :> ClassLibrary1.IDoStuff).DoMoreStuff()

Mutually Exclusive Exception-Handling Keywords

Why can’t catch and finally be combined? The only other language I’m aware of that doesn’t allow combining of these forms is Python, and that’s only versions prior to 2.5. Hell, even VB.NET can combine catch and finally.

Extension Methods

When you add an extension method in F#, it only works with other F# code. You can’t call an extension method defined in F# from C# or VB.NET code. Granted, given the hassles involved in setting up extension methods in C# or VB.NET, this isn’t surprising, and probably for the best; within F#, extension methods are easy, and forcing compatibility with other languages would make them unwieldy. But still, having the option would be nice.

Overall, I’m pleased with F#. As a standalone language, it’s fairly impressive. While the .NET integration is a bit rough around the edges, it’s tied in well enough to act as an effective Trojan horse, bringing functional programming to .NET-only shops. And that’s worth the hassle.

I thought, “Even as a beginner, I can do better than that.” Here’s my first attempt:

let rec primes_match n =
    match n with
        | nn when nn <= 1 -> []
        | nn when nn > 1 ->
            let so_far = primes_match (n - 1)
            if (so_far |> List.filter (fun d -> nn % d = 0) |> List.isEmpty)
            then nn :: so_far
            else so_far

let primes n = n |> primes_match |> List.rev

Then I realized ‘match’ was a bit heavy for what I’m doing, and shifted to if/then/else:

let rec primes_match n =
    if n <= 1 then []
    else
        let so_far = primes_match (n - 1)
        if (so_far |> List.filter (fun d -> n % d = 0) |> List.isEmpty)
        then n :: so_far
        else so_far

let primes n = n |> primes_match |> List.rev

And finally, I learned about List.exists.

let rec primes_match n =
    if n <= 1 then []
    else
        let so_far = primes_match (n - 1)
        if (so_far |> List.exists (fun d -> n % d = 0))
        then n :: so_far
        else so_far

let primes n = n |> primes_match |> List.rev

I was proud, but not satisfied. There are still two major problems with this code. First, it’s still not the sieve of Eratosthenes. It’s just a more-time-efficient version (I think, maybe) of the original algorithm. Second, it’s not tail-recursive, and stack depth grows with the input parameter, so it can only generate primes up to 32,750 or so.

So, I started from scratch. I managed to create a new sieve function that is, in fact, the sieve of Eratosthenes, and tail-recursive. As it turns out, Chris Smith has a sieve implementation as well, but I didn’t look at it before writing my own. Mine came out shorter, but probably less efficient.

let rec sieve_drain (sifted : int list) (unsifted : int list) =
    if List.isEmpty unsifted then sifted
    elif (sifted |> List.exists (fun d -> (List.head unsifted) % d = 0))
    then sieve_drain sifted (List.tail unsifted)
    else sieve_drain ((List.head unsifted) :: sifted) (List.tail unsifted)

let sieve n =
    sieve_drain [] (2::[3..2..n]) |> List.rev

Any suggestions? Am I being too strict when it comes to functional style? Is there any way I can polish this?

Update:

I managed to find a cleaner way to do this:

let rec sieve_drain (sifted : int list) (unsifted : int list) =
    match unsifted with
    | [] -> sifted
    | x :: xs ->
        if not (sifted |> List.exists (fun d -> x % d = 0))
        then sieve_drain (x::sifted) xs
        else sieve_drain sifted xs

let sieve n =
    if n < 2 then [] else sieve_drain [] (2::[3..2..n]) |> List.rev

But it’s not very efficient. Chris Smith’s implementation (due to the use of shared state) takes about 2.5 seconds to run from 1 to 500,000. Mine takes about 55.

Lisp is worth learning for the profound enlightenment experience you will have when you finally get it; that experience will make you a better programmer for the rest of your days, even if you never actually use Lisp itself a lot. [Eric S. Raymond]

I, for one, know that I’m only partially enlightened.

When I was taking “Programming Languages” (COP 4020), one of the languages covered, intended to represent the entirety of functional programming, was Common Lisp. We studied it for about two weeks. On the exam, a 5-point question asked us to write a function to determine whether a list was palindromic. I set off writing tons of code (on paper, even), checking for the equality of the first and last elements, then stripping them off and recursing on the rest.

As I handed in my exam, I commented on the difficulty of that question compared to the low point value. The professor looked at my test, then at me, and then she wrote on a scrap of paper so that the other students couldn’t see (yet):

(defun is-a-palindrome (lst) (equal lst (reverse lst)))

That’s thinking functionally. I could hammer out the code, but I was writing C with a bunch of parentheses. I wasn’t really writing in Lisp.

When I started working here, I was writing a lot of Python. Python isn’t generally considered a functional language, but it has enough of the features (first class functions, lists, map/filter/reduce, etc) to give me a taste of power. Then I was forced into using VB.NET 2005, which felt like stepping back in time a decade. It had none of the Pythony goodness I was used to: no list comprehensions, no map/filter/reduce (with clunky forms added in VB 2008), and no lambda statements (halfassedly added in 2008 and properly added, supposedly, in 2010).

What skill I picked up from Python quickly began to fade.

My outlook was bleak, as well. I thought the .NET platform was headed for the same old languages and the same old paradigms, for the same old Blub coders. I was afraid that I’d end up a Blub coder… or worse, that I already was one.

Then I saw some of the nice features of C# in .NET 3.5 (and immediately started griping that VB didn’t have them), and what’s more, I found F#.

Let me say this up front: I like Lisp. Most of it makes very little sense to me, but I can feel the power behind it. Though I’ve wanted to learn a functional language for a while now, I know that my chances of ever getting a job writing it are slim, so I’ve focused on the standard OO and procedural languages. F# has the advantage of being backed by Microsoft; Visual Studio 2010 will have F# out of the box, and it’ll be right there on the desks of almost every .NET programmer, overcoming much of the inertia that leads people to use languages like VB.

So that’s why I’ve decided to throw myself into F#; it’s a paradigm I want to embrace, and a language that I may actually get paid to use someday. That’s worth reshaping my mind for.

And at the very least, I’ll end up writing better code in other languages.