Drifting away from .Net

Fatigue?

I don’t think there’s .Net fatigue, in the same way as described on Eric Clemmons’ Javascript Fatigue. At the very least, I don’t think it’s the same feelings at play, considering how people breaking up with Javascript talk about it.

I just think .Net may have missed the love boat altogether.

But let me back up a bit here.

Flexibility Through Immutability, part 2: How and When?

The second part of the original text for “Flexibility Through Immutability“.

The first part focused on the why of immutable data. On this part I’ll review what to do about if you’re working on an object-oriented language.

Flexibility Through Immutability, part 1: Why?

Here’s the original text for “Flexibility Through Immutability“, for those of you who prefer reading to watching a video.

It’s a bit of a long read, so I’ve divided it into two parts. The first one focuses on the motivations behind preferring immutable data, and the second one (which will go up on Wednesday) on how to go about it.

Flexibility Through Immutability

While functional programming has a lot of advantages, the more I worked on the paradigm, the more surprised I was at how much thinking in a functional manner made refactoring easier.

As happy as I am to sell people on Clojure, I realized that teams could benefit from adopting some functional programming ideas even on their current language. I decided to try a different approach, and gave a talk at the 2016 ITAKE Unconference in Bucharest, elaborating on the benefits of immutable data. I wanted to focus on how the functional paradigm has a value in-and-of-itself. A secondary goal was to provide some tips that teams who can’t yet pull away from C# or Java can put into effect to help.

You’ll find my screen recording, as well as the slides, below.