I have been writing code a long time and have used most of the paradigms over the years. I have worked in procedural languages like Fortran and C then moved into C++ in the early days of that language. I then had a long detour in Visual Basic before finally finding my home in C#. I started in C# 1.0 and have watched that language transform over the years to the multi paradigm language it has become today.
LINQ was my first introduction into map/reduce type code and that sparked my interest in Functional Programming. Over the past few years I have dabbled in ML style languages and Haskell but have never really built anything more than tiny toy projects. I love Haskell, such a beautiful and concise language but it just spins my head out. Just as I think I have grasped applicative functors it feels like someone has put my mind in a blender.
This exploration has forever change my day to day C# code though for the better.
Recently I decided to start on something with a bit more scale in F#, an ML language closest to OCAML. Far kinder on the mind than Haskell :)
Hence Building a roguelike in F# from scratch, links to all the other parts in the series at the end of the article along with the GitHub repo.
Here are some observations so far:
- Types are really important, they are the glue that everything hangs off so you need to get them right.
- Immutable state feels like hard work initially, but structure you code correctly and that falls away.
- Function purity is easy to let slip but you should resist that temptation, an impure function is a warning sign your code is just wrong.
- Functional code takes a lot more thought so feels slower to write. On the flip side you get far more done in far less code.
- Gang of Four Patterns simply do not exist, you can name any of the GOF patterns and the functional programming replacement is functions, functions and more functions.
- Map/Reduce is not functional programming, it just naturally falls out of immutable state and pure functions.
- Monads are not functional programming, again they just naturally fall out of immutable state and pure functions.
- Functional code is far easier to just read than debug. If you have ever tried to debug LINQ code and watched the current line bounce all over the place that is nothing compared stepping through ML code.
- Because all the functions you write are single minded and tiny they are very hard to screw up. Reading code becomes far easier, in many cases there is just no need to debug.
- Simple functions mean lots of tiny building blocks. It is far easier and more natural to build complex shapes from small building blocks than plug Classes and interfaces together.
- Duplicate code does not really occur, you have reduced everything to small blocks so they are easier to reuse.
- All of your code details what you want done, not how it is done. Less moving parts means less bugs.
Getting comfortable with a functional style of programming can take a long time click, this is really true if you have worked for any length of time in imperative world. So OO or Procedural spaces. It is just so alien but well worth exploring. For me it has already become the next part of my 35 year journey in code, I have even thought about digging deeper into my shallow knowledge of Lambda Calculus and Category Theory, I just wish I had discovered it back when I was starting my journey into C.
Challenge yourself and start to explore FP, it will become far more important now the CPU core count is rapidly climbing. It will teach you so many new ways at looking at problems!
Happy coding
Woz