Sunday, January 17, 2016

The Book of F# - Introduction

In my previous post I said that, as a means of reinforcing my own learning, I would be going through The Book of F# and giving my own thoughts on what’s inside.

Before I dive into the contents, let me answer a few questions.

What do I know already?

I’ve been programming in C#, the object-oriented big brother of F#, for the past two years. Whilst I am not yet expert in the language, I feel able to express what I need to in C# code.

On the other hand, I don’t feel fully comfortable with the object-oriented (OO) paradigm . My view on what software does is (perhaps overly) simple:

Data comes in one end, gets acted upon, and goes out the other.

The astute observer will notice that, whilst not incompatible with OO principles, this view is closer aligned to Functional Programming. The amount of scaffolding required to do a simple computation in C# often surprises me, and feels inefficient.

This combination makes F# attractive: a functional-first language that harnesses the power of the .NET Framework sounds like a great mix of simplicity and familiarity.

To boot, I also did Erik Meijer’s fantastic course on edX, Introduction to Functional Programming. This introduced me to some concepts that seemed to align closer with my logical reasoning about software, things like pattern matching and recursion.

Complicating matters further, my favourite bit about programming C# is having access to the System.Linq Namespace. Note the precise vernacular — I didn’t say that my favourite bit was LINQ (which I have never used, and never intend to), and I also said ‘having access to…’. This is because the bits that I like are actually part of the .NET Framework, and so can be used by any language that runs on the CLR, including F#! (yes, I know that they can’t be used in the same way because they use C#’s extension methods, but we’ll come to that).

So here I am: a C# developer that doesn’t quite feel natural writing fully object-oriented code, loves the functional-style of the extension methods on IEnumerable<T> with their expression trees and lambdas, and has had a taste of ‘pure’ functional programming via some basic examples in Haskell.

Time to go functional, then?

Why am I learning F#?

It’s quite a simple reason, in a way. There are bits of C#, bits of .NET, bits of functional programming, bits of object-oriented programming, all of which I think are great. Wouldn’t it be awesome if there was a language where I could use all of them?

And that is the question I am truly asking: is that language F#? On the face of it, it could be. On the other hand, it could be that it combines the worst bits about all that I mentioned above! It’s worth figuring out, though.

What am I trying to get out of the book?

The answer to my question!

This may be flippant, but it sums it up. I’m looking at the book as a window into the language from the perspective of an experienced C# developer:

  • How does the syntax compare: it is more natural, less natural, or about the same?
  • What about functionality: how does it integrate with the .NET Framework?
  • Does it help with writing complex or long-winded calculation routines?
  • How are the elements of functional programming and object-oriented programming interleaved?
  • Is it possible to build enterprise applications with it?
  • Are there enough tools available to ensure code quality?

These can be combined:

Would I write a new project in F#?

If I can give a good answer to that by the end of the book, I will be happy.

And so to the book.

The Foreword and Preface got me hooked straight away. Both the author Dave Fancher and the technical reviewer Brian Hunter talked about their journey into F# in strikingly similar fashion to my spiel above. Dave was a C# developer who loved LINQ but hated the verbosity of C#; Brian is another functional convert who is furthermore convinced that OO programming is harmful, spreading of the dangers of mixing data with behaviour.

The best sentence was actually a printing of someone else’s quote, so I will cross-reference it here (source Joe Armstrong):

“You wanted a banana, but what you got was a gorilla holding the banana and the entire jungle.”

That chimes with some of my gripes about C# — I find it a constant struggle not to end up passing around references that refer to, essentially, an entire jungle.

Next came a short introduction, where we learnt about F#’s interoperability with other .NET langauges as well as its functional-first approach. Again, these are two points that really make the language appeal to me. I already use lots of the .NET framework (familiarity), and am able to tie in functional concepts with my own way of logical thinking (simplicity).

From here, the book is organised into twelve chapters, each building on the last. To help move around them, here’s a copy of the table of contents, with links updated as I write the posts:

After these are all done, I’ll refer back to this post with an answer as to whether I would use F# for a new project or not.

Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)