Inside F#

Brian's thoughts on F# and .NET

Archive for July, 2008

I’ve been tagged in the software development meme…

Posted by Brian on July 29, 2008

Kirill tagged me in this game, and I’m willing to play along.  :)

How old were you when you started programming?

Something like 8-10 years old.  In my elementary school we had a computer lab with TRS-80 Model III computers and I remember learning the commands to get it to load tiny game programs off external media (which at the time were cassette tapes, like the ones you used to use for music, back before CDs).

How did you get started in programming?

The TRS-80 machines had BASIC, and in the computer lab there was a book with some BASIC programs you could type in.  One fun one was a game that I think was called ‘road race’, a very very simple scroller where there is a car on a road, and you press left and right to steer the car to keep it from going off the winding road that scrolls down the screen.  So I would type in some of these programs, just rote transcription out of the book, and that was my first exposure to programming.  Of course this led to experimentation, and like everyone at the time, I think my first self-authored program was probably something like


20 GOTO 10

Fun stuff.

What was your first language?

It was BASIC.  I recall understanding conditionals and GOTO, but I never quite understood GOSUB.  So all the code I wrote back then must have been spaghetti.

What was the first real program you wrote?

My first home computer was a TRS-80 Model IV-P (the ‘P’ was for portable, which basically meant there was a large handle on the back of the machine), and I remember using it to write a program (probably for some school project) that did long division on the screen, something like


and at the time it was a lot of effort to get working!

What languages have you used since you started programming?

After BASIC, in middle school I learned C, and then in high school C++.  I learned these from books, and used Turbo C++ on my 386 box at home.  I also did a little stuff with MS-DOS .BAT files.  Along the way I also learned some dBASE/Clipper (see below). 

When I went to college and grad school, I was exposed to tons of programming languages, and wrote a bit of code in Pascal, Smalltalk, perl, LISP, Haskell, and Java, as well as a smattering of Ada, Prolog, ksh, tcl, Eiffel, Scheme, and probably a few others I’ve forgotten.  C++ remained my favorite language throughout most of that period.

Then I got a job at MS and learned C# (fortunately already C# 2.0, with support for generics).  Recently I joined the F# team, so of course now F# is my favorite language.  F# rocks!

What was your first professional programming gig?

The summer after high school I got a job working for an engineering firm where I did some dBASE III programming.  A couple summers later I got a different summer job using Clipper.  Those were my first ‘real world’ jobs where I got paid to write code.

If you knew then what you know now, would you have started programming?


If there is one thing you learned along the way that you would tell new developers, what would it be?

There is no "one thing" I can call out.  I think that being a good developer requires a mix of both on-the-job experience and schooling.  Before college, I had written tons of C++ code, but had no training in algorithms or using procedural/data abstractions to break up large problems, so all the code I wrote was awful spaghetti.  Then I got to college and learned lots about good ways to structure code, as well as important algorithms, and finally felt like I knew what I was doing.  Then I came to work for MS and had to learn about other issues we almost never dealt with in school, like software perf and scale, and working on large teams.  There are always new technologies and new processes/methods in this field, so you need to always keep learning to stay current and add experience and tools to your personal toolbox.

What’s the most fun you’ve ever had… programming?

No single instance stands out, but a few memorable experiences have a common theme.  I really enjoy it when you discover or come to understand some cool language mechanism.  Back in high school I was writing some expression evaluator in C, and the expressions had parentheses, and the problem seemed so hard until I found out that, yes, "a function can call itself".  And once I found that out, I was so happy because I knew an easy way to write the evaluator.  So that was my experience discovering recursion.  Much more recently, the blog I wrote about why pattern matching is cool was the same kind of thing… I had been thinking about the cleanest way to write a Dictionary API for forever, and then I learned about pattern matching, and it’s a perfect solution to the problem, and I just love that moment of revelation/understanding.  To draw a stretch of an analogy, it’s like the end of the movie The Usual Suspects, when you finally realize who Keyser Söze is… except that in programming, each time you have a great revelation and come to understand a new abstraction, you get to name it and add it to your toolbox and carry it along with you forever more.

Over to you

I’ll keep things linear and tag only Jomo.

Posted in Uncategorized | 1 Comment »

Sneak peeks into the F# project system, part two

Posted by Brian on July 26, 2008

One commonly requested feature that’s missing from the research releases of F# is the "Add Reference" dialog. 

The upcoming CTP release will support the ‘Add Reference’ dialog:


which makes it easy to select the assemblies you’re looking for:


The other main feature here is project-to-project references.  This makes it easy to create a Visual Studio solution containing code from multiple languages.  So, for example, if you have a C# library as another project:


and you want to reference it from your F# code, you can just add a reference:


to the project:


and you’re good to go:


so you can reference the code in the library:


Posted in Uncategorized | 2 Comments »

Sneak peeks into the new F# project system, part one

Posted by Brian on July 20, 2008

We’re getting closer to the next major release of F#: our first CTP release out of Developer Division.  As a result, now is a good time for me to start talking about some of what I’ve been working on for the past few months: the F# project system.  Over the coming weeks I’ll describe some of the new-to-F# project system features we’ll deliver in the CTP, providing a "sneak peek" at what’s coming.

For today, I’ll just give an overview of some of the high points, and in subsequent blog entries, I’ll dive down into the details of these features.  The most noteworthy project system features I can think of are (in no particular order):

  • New F# project & item templates (for ‘New Project’ and ‘Add New Item’)
  • An ‘Add Reference’ dialog similar to C#’s, including project-to-project references
  • Support for linked items (‘Add Existing Item’… ‘Add as Link’)
  • Support for folders and for reordering files within the project
  • Project property pages similar to C#’s
  • F# projects realized as ‘.fsproj’ files that work with MSBuild
  • Some new features regarding scripts (.fsx files)

Here’s a teaser screenshot…


Posted in Uncategorized | 8 Comments »

ICFP 2008 Programming Contest

Posted by Brian on July 14, 2008

This year, for the first time, I participated in the ICFP programming contest.  This year’s contest involved commanding a rover to navigate the Martian terrain: see the contest task description.  It was tons of fun; I teamed up with Chris Smith, Luke Hoban, and Dustin Campbell for an F# team.

In the end we submitted an entry that does pretty well on a variety of maps.  Some features of our entry:

  • It is a heuristics-based approach.  We have some general computations from what we learned about the world physics, but there are lots of hacks where we have arbitrary parameters like "multiply by 2.2" for no other reason than that seems to work well.   And there are tons of if-then-else cases for various edge cases (e.g. if we think we are going too fast, then turn less sharply, unless about to crash, …).
  • It is completely "local" – we use the current state for each movement, and do not plan for the long term.  In general we either ‘aim home’ or else ‘aim tangent to the next closest item blocking our path’.
  • We use a ‘connected components’ model to group together overlapping (or nearly-overlapping) obstacles.  That way, we can steer around an entire group of nearby objects rather than trying to precisely weave between them.  (I lifted code directly from this post, hurray!)  Our components are connected on an ‘absolute’ scale; it may have been better to group on a relative scale (the farther two distant objects are from you, the more likely it’s an advantage to treat them as a single connected component despite any absolute distance between the two distant objects), but I only just thought of that now.  I think we ‘connect’ any two craters that have only a two-rover-diameter-or-less distance between their perimeters.  This avoids slowing down for precise steering through narrow gaps, but might also cause us to drive long distances around objects we could in fact squeeze through.
  • We only rarely slow down – if we are pointed away from home base, or if soon-after-the-next-tangent-we-are-currently-aiming-for we see an object coming soon right behind it.  (Our heuristics for computing ‘stopping distance’ and ‘how fast we can brake to avoid things’ are decent, but not outstanding.)
  • We almost completely ignore Martians (very little logic to account for them).  This is risky, but there is no good alternative.
  • We ignore many contest parameters, such the ‘max lookahead’ of our sensors.  As a result, if we are given a fast rover who cannot see very far ahead, he will drive way too fast directly ahead into the unknown.
  • We are very good at turning quickly and smoothly, despite using a very ad-hoc heuristic approach that’s only loosely based on the (supposed) physics of the task specification.
  • We did not create enough of our own sample maps, so I expect there are important cases we neglected.
  • There are lots of features we considered implementing but did not have time.  For example, if we are trapped inside a connected component of obstacles with no line of sight out (imagine being inside the top-right of an @-shaped maze), I think we will get befuddled.  We have ‘tunnel vision’, and may potentially drift gently into a boulder that is just barely to the side of the direction we are headed.  We never consider using bouncing off boulders to our advantage.  We thought a lot about a completely different approach that would just predict and simulate the future, and then search futures for best possible outcomes with very little heuristic strategy and mostly learning-on-the-fly, but did not have time/resources to try it.
  • We had lots of good, colorful debugging output.

Of course we used our in-house latest-and-greatest F# bits, which are very useful.  I haven’t written any blogs in the past month, partly because I’ve been so busy adding features and fixing bugs for our upcoming CTP release of F#.  I am looking forward to showing off all the hard work we’ve been doing on F#!

Posted in Uncategorized | 2 Comments »