The joy of functional concurrent programming

by DotNetNerd 25. June 2015 07:40

Pleanty of people have said that concurrency and functional programming are becomming essential to developing modern systems. Some have even gone so far as to say that if you don't adapt you will become a maintenance programmer in a few years. With the increasing need for concurrency to provide speed and handeling of huge amounts of data, I beleive it to be true. I do however beleive there will still be pleanty of smaller applications, so I am not predicting doomesday for anyone quite yet.

What I do find interesting is that this evolution is moving so relatively slowly. We have talked about this for at least a decate now. Still every single project I have ever worked on uses platforms and tools where immutability, functional constructs and even types that handle concurrency well are not the default. Why is that? 

Lots of speakers have talked at length about how simple concurrency actually is, if we simply take away the bad habbits that drown us in complexity. Mutable types need locking when used in concurrent scenarios, imperative programming adds complexity and builds on constructs that use mutable types, and I don't see a lot of reasons why we are defaulting to implementations like List<T> in C# that breaks in certain scenarios.

Oddly this is not at all scary as some seem to feel it is. Once you get over the "WHO MOVED MY CHEESE" stage, it really is simpler than what we are doing now, and building faster systems that are easier to understand is deeply satisfying.

Who am I?

My name is Christian Holm Diget, and I work as an independent consultant, in Denmark, where I write code, give advice on architecture and help with training. On the side I get to do a bit of speaking and help with miscellaneous community events.

Some of my primary focus areas are code quality, programming languages and using new technologies to provide value.

Microsoft Certified Professional Developer

Microsoft Most Valuable Professional

Month List