Last week I read an article from the MIT Technology Review that looked into what causes people to make mistakes. The approach was one I hadn’t seen before: it used data mining on a set of chess games. Their rationale was that:
As spoiled by the title, complexity was the main factor whenever a player made a mistake.
*The bottom line is that the difficulty of the decision is the most important factor in determining whether a player makes a mistake. *
So what’s the big deal?
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.
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.
OK, this is going to be a tough one. Strap down, even if it pisses you off at first - I wouldn’t be writing it if I didn’t think it was helpful.
A programmer has something he wants to build.
He finds a framework.
It looks easy enough to get into. There’s a few tutorials available, which show step by step how to build a basic application of just the right type.
He’s happy. He feels really productive. CRUD just “drops out” of the framework’s design. It’s like it was created with his problem in mind.
Then he’s done with the tutorials. He starts plugging in his own, specific requirements. Every so often he hits a snag, but that’s OK, he can just twist the framework’s arm a bit, right?
It all goes well for a while. Then he hits a big one. The framework doesn’t do quite work the way he wants it to.
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.
I love Clojure.
Once you have tried it and enjoyed its advantages, you just don’t want to go back. But those same qualities that make you love it can make it easy to forget that, for someone who’s first encountering it, Clojure can be a threatening, scary area far outside their comfort zone.
A few weeks ago I gave a talk at the Bucharest Functional Programming Meet Up. The title was Clojure All The Way Down, since my initial plan was to focus on how to program web applications completely in Clojure (both the browser client and back end), and what it brings to the table.
Two things happened as I prepared the talk.