A programming language that I have been very excited about is F#. So when I won a door prize at the Columbia Code Camp earlier this year, I jumped at the chance to get the copy of Programming F# by Chris Smith (published by O'Reilly). Although it wasn't a bad read, I was fairly disappointed because I don't think the book is very useful for most people who want to learn F#.
What I liked
Of the programming language books I've read (or tried to read) over the years, this was one of the easiest to read. Unlike my experience with The Ruby Programming Language, I was not bogged down for the better part of a year trying to force myself to slog through it. I got through Programming F# in well under a month. The chapter and section divisions are reasonable as well. Another nicety to this book is that it did not dwell on the usual "todo list" or "recipe database" applications. I also appreciated that the book was not dependent on jargon or "language geek" terminology to get the points across, despite the fact the F# very much appeals to that segment of the marketplace.
Why I was disappointed
I don't think the author did a good job of teaching F#, which made it difficult for me to stay engaged in the book. The author's biggest mistake was never once showing the power of F#. I am intrigued by the language because I have heard of dramatic reductions in the size of code for algorithm processing, but the author never shows this side of F#. I can understand that he perhaps wanted to evangelize F# as a language for day-to-day work, but after reading this book, I feel that nearly every example to show this was actually counterproductive. It looked positively miserable to use F# in a "general computing" capacity in the examples. After reading this book, there is no way that I would tell someone to replace C# or VB.NET with F#. So when the author spends so many pages with information processing style examples, I felt that my time was wasted. The reader would be better served if the author stuck to algorithmic programming, and then showed that F# is perfectly capable of interfacing with other .NET code in case it needs to talk to the .NET Framework or code written in another language.
And if you were looking for ways to improve your algorithmic code by switching to F# (which is why I was reading the book in the first place), the only thing the book really made clear is that F# is great if you need to write complex switch/case statements because of its pattern matching capabilities. While a substantial part of the book is devoted to the functional programming style, this section is not about "how to leverage functional programming" or "where to leverage function programming" or even "when to leverage functional programming," it was about "the feature of F# that fit the functional programming paradigm" like continuations. Since the author didn't show how to really make good use of F#'s capabilities, I was left thinking that I could just use lambdas in C# or VB.NET and save myself the agony of this syntax.
Syntax is another issue. It is not the author's fault that F# is a very symbol-heavy language (actually, it partially is, the author was on the F# team), but he makes the mistake of explaining a symbol once, and then using it without reinforcing the meaning or the purpose; as a result, it is very easy to get lost in the examples. I admit that about halfway through the book, the examples stopped making sense to me, and I stopped looking at them; I simply could not understand the examples once the number of symbols in any given example got too high. If I was sitting down with a compiler and a debugger and walking through the examples, they would have been good, but without that tool it was hopeless.
I really wanted to like F#, and I really want to find a place for F# in my toolbox, but my zeal for F# has been severely diminished after reading this book. I am going to give Real World Functional Programming a shot next, but I am at the point where I feel that, if no one can properly explain F# or functional programming with regards to F#, then maybe it isn't worth my time.
Have you read any books about F# that you recommend? If so, please list them in the discussion.
J.JaDisclosure of Justin's industry affiliations: Justin James has a contract with Spiceworks to write product buying guides; he has a contract with OpenAmplify, which is owned by Hapax, to write a series of blogs, tutorials, and articles; and he has a contract with OutSystems to write articles, sample code, etc.
---------------------------------------------------------------------------------------Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!
Justin James is the Lead Architect for Conigent.