F# for Fun and Profit
Correctness
As a programmer, you are constantly judging the code that you and others write. In an ideal world, you should be able to look at a piece of code and easily understand exactly what it does; and of course, being concise, clear and readable is a major factor in this.
But more importantly, you have to be able to convince yourself that the code does what it is supposed to do. As you program, you are constantly reasoning about code correctness, and the little compiler in your brain is checking the code for errors and possible mistakes.
So how can a programming language help you with this?
A modern imperative language like C# provides many ways that you are already familiar with: type checking, scoping and naming rules, access modifiers and so on. And, in recent versions, static code analysis and code contracts.
All these techniques mean that the compiler can take on a lot of the burden of checking for correctness. If you make a mistake, the compiler will warn you.
But F# has some additional features that can have a huge impact on ensuring correctness. The next few posts will be devoted to four of them:
- Immutability, which enables code to behave much more predictably.
- Exhaustive pattern matching, which traps many common errors at compile time.
- A strict type system, which is your friend, not your enemy. You can use the static type checking almost as an instant “compile time unit test”.
- An expressive type system that can help you “make illegal states unrepresentable”* . We’ll see how to design a real-world example that demonstrates this.
The "Why use F#?" series
-
Introduction to the 'Why use F#' series
An overview of the benefits of F# -
F# syntax in 60 seconds
A very quick overview on how to read F# code -
Comparing F# with C#: A simple sum
In which we attempt to sum the squares from 1 to N without using a loop -
Comparing F# with C#: Sorting
In which we see that F# is more declarative than C#, and we are introduced to pattern matching. -
Comparing F# with C#: Downloading a web page
In which we see that F# excels at callbacks, and we are introduced to the 'use' keyword -
Four Key Concepts
The concepts that differentiate F# from a standard imperative language -
Conciseness
Why is conciseness important? -
Type inference
How to avoid getting distracted by complex type syntax -
Low overhead type definitions
No penalty for making new types -
Using functions to extract boilerplate code
The functional approach to the DRY principle -
Using functions as building blocks
Function composition and mini-languages make code more readable -
Pattern matching for conciseness
Pattern matching can match and bind in a single step -
Convenience
Features that reduce programming drudgery and boilerplate code -
Out-of-the-box behavior for types
Immutability and built-in equality with no coding -
Functions as interfaces
OO design patterns can be trivial when functions are used -
Partial Application
How to fix some of a function's parameters -
Active patterns
Dynamic patterns for powerful matching -
Correctness
How to write 'compile time unit tests' -
Immutability
Making your code predictable -
Exhaustive pattern matching
A powerful technique to ensure correctness -
Using the type system to ensure correct code
In F# the type system is your friend, not your enemy -
Worked example: Designing for correctness
How to make illegal states unrepresentable -
Concurrency
The next major revolution in how we write software? -
Asynchronous programming
Encapsulating a background task with the Async class -
Messages and Agents
Making it easier to think about concurrency -
Functional Reactive Programming
Turning events into streams -
Completeness
F# is part of the whole .NET ecosystem -
Seamless interoperation with .NET libraries
Some convenient features for working with .NET libraries -
Anything C# can do...
A whirlwind tour of object-oriented code in F# -
Why use F#: Conclusion
Twitter