On June 3, I presented Break Free with Managed Functional Programming: an Introduction to F# at the Indianapolis Mobile .NET Developers group. Brad Pillow was kind enough to record the entire presentation and post it to YouTube. The slides are a bit hard read in the video but I’ve posted them to SlideShare (and embedded them below the video) so you can follow along.
Bob Martin’s 2008 book, Clean Code, is considered by many to be one of the “must read” books for software developers, and for good reason: The guidelines discussed in the book aim to decrease long-term software maintenance costs by improving code readability. One of the most beautiful aspects of Clean Code is that although it was written with an emphasis on Java development, the guidelines are applicable to software development in general.
Clean Code was written to combat the plague of unmaintainable code that creeps into software projects. You know the kind: intertwined dependencies, useless comments, poor names, long functions, functions with side-effects, and so on. Each of these things make code difficult to read but some are more nefarious because they make code fragile and difficult to reason about. The end result is code that is difficult and expensive to maintain or extend.
In March I had the good fortune to speak at Nebraska Code Camp. I was really excited about the way the schedule worked out because I was able to sit in on Cory House’s talk about Clean Code. As Cory walked through the points I remembered reading the book and pondered its impact on how I write code. Eventually, my thoughts drifted to the climate that necessitated such a book and its continued relevance today. In the days following Cory’s talk, I reread Clean Code and further developed my thoughts on these subjects. (Confession: I skipped the chapters on successive refinement, JUnit internals, and refactoring SerialDate this time around.) What I came to realize is that while the Clean Code guidelines are an important step toward improving code quality, many of them simply identify deficiencies in our tools and describe ways to avoid them. Several of the guidelines gently nudge us toward functional programming but they stop short of fixing the problems, instead relying on programmer discipline to write cleaner code.
There is no doubt that understanding and embracing the Clean Code guidelines leads to higher code quality but relying on developer discipline to enforce them isn’t enough. We need to evolve Clean Code. (more…)
This past weekend I had the good fortune of speaking about F# at GR DevDay in Grand Rapids, Michigan. As part of this particular talk, I highlight how the F# compiler deals with calls to methods with out parameters. Naturally, this prompted a question about how it handles ref parameters. I don’t use ref parameters very often (ok, ever – I seem to have an aversion to side-effects!) so I had to admit that I’d never given it much thought and couldn’t immediately recall how to do it. I’m here today with the answer to the question.
Consider a C# function with the following signature:
public void DoSomethingWithRefParam(ref int refParam)
Just as with out parameters, F# doesn’t have any direct way to pass arguments by reference. Instead, we need to use a reference cell. Coming from C#, you might think the following F# code would be adequate.
// Bad, does not work
let v = 10
x.DoSomethingWithRefParam (ref v)
This code compiles but it’s not quite right. When it executes, any changes that DoSomethingWithRefParam makes to the reference cell will not be reflected in v. Why? Remember, the ref operator creates an instance of FSharpRef<_> which is a type that carries a mutable value. It is the mutable value which is passed by reference to the method. By including the ref operator in the call to DoSomethingWithRefParam as we would in C#, we’re not passing v by reference but instead wrapping the value of v in a reference cell to which we have no reference outside of the method call. To make this code work, we need to change the definition of v as follows:
let v = ref 10
Now, v is a reference cell and any changes made to its wrapped value in DoSomethingWithRefParam will be reflected whenever we access it later in the code.
To get back in the habit of blogging I thought I’d start by trying to breathe some new life into one of the oldest pieces of the .NET Framework – the StringBuilder. A few years ago I wrote about an aspect of the StringBuilder class that’s often overlooked – it’s fluent interface. Back then I speculated that one reason the fluent interface is so rarely used is that virtually every StringBuilder example, including those on MSDN, fail to highlight it by using a more imperative style. (more…)
To celebrate the release of my new book, The Book of F#, I’ll be back in Fort Wayne, IN to talk to NUFW on March 19. Instead of the usual technical talk, this will be an open-ended discussion of my experiences writing a technical book but I’m sure that F# will find its way into the conversation at least a few times.
If you’re in the Fort Wayne area and would like to join us, we’ll be meeting at the Cole Foundation Conference and Training Center (3213 Stellhorn Rd) at 6:00 PM. I’ll be giving out a few copies of the book as door prizes so you won’t want to miss this!
As The Book of F# is nearing completion I’ve suddenly found myself with a bit of something people like to call spare time. This concept has been pretty foreign to me over the past nine months so as a way to fill that time I started looking at the Project Euler problems. I’m not far along yet (my math skills have gotten rusty over the years) but so far it has been a fun exercise.
Problem 2, involves calculating the sum of the even Fibonacci numbers less than 4,000,000. In the spirit of the project, I won’t divulge my entire solution (though it won’t be hard to fill in the gaps), but I thought the algorithm for generating Fibonacci numbers was interesting so I wanted to explore it a bit along with some interesting ways we can use it to create sequences in F#. (more…)
Earlier this year (late February to be exact) my life took an interesting turn: a publisher approached me about writing an F# book. Writing a book had been something that I’d thought of doing for some time but it was never something I gave any serious consideration. After some discussion with my wife, mostly about the time commitment, I decided to go ahead with the project. Since then, a mix of writing, reviewing, revising, and the variety of other activities that go along with getting a book on the shelves have consumed most of my nights and weekends.
If you’re an experienced .NET developer that would like to break free from the chains of C# and Visual Basic or someone that’s just curious about the language, this book is for you. The Book of F# will introduce you to the basics of the language and walk you through features such as currying, partial application, pattern matching, discriminated unions, record types, units of measure, type providers, and a plethora of other concepts. Throughout the book you’ll see examples of how F#’s terse syntax and functional-first nature will help you be more productive and produce code that’s more predictable than that of many modern languages.
F# has been getting a lot of attention lately. If you’re even remotely curious as to why, I hope you’ll consider adding this book to your collection.
On August 21st I’ll once again venture out of my cave for a trip to Fort Wayne, Indiana where I’ll spread more F# love with my friends at NUFW.
If you’re in the Fort Wayne area and want to learn about how F# and functional programming principles can improve your software, please join us. The doors open at 6:00 for networking and the main event begins at 6:30. Be sure to check NUFW ‘s events page for the latest logistics information.
If you’ve spoken with me or have been following this blog for any time you know that over the past year I’ve developed a bit of an obsession with the F# language. You’ve probably also noticed that fresh content here has been a bit, well, lacking over the past few months as I’ve focused on some speaking engagements and writing an as yet untitled F# book. I was very surprised, ok, shocked, when earlier this week I received word that I’ve been selected as a 2013 Microsoft MVP for Visual F#! I’m extremely honored to have received this recognition and will do everything I can to continue promote and advance this fantastic language.
I owe a debt of gratitude to the Indiana development community that I’ve been part of for so many years, particularly the user groups in Indianapolis, Fort Wayne, and Bloomington. Thank you for your all of your support and encouragement.