Every project should ideally start off with considering how to show something to the stakeholders in the first day, and providing a mechanism to allow those stakeholders to provide feedback as simply as possible.
This is part 3 of a series of handling change within immutability. So far we’ve looked at creating complex values based on other complex values and even playing the OO game of creating changeable objects. This time I’m going to focus in on a purely functional technique for creating a complex object that is only different from its predecessor by a value that is deep down inside the object.
Changing the thing inside the thing inside the other thing
This is part 2 of a series of handling change within immutability. Today we are going to “cheat” by going against all of our best functional language intentions and actually create a mutable object.
Why would you intentionally create a mutable object in a language founded on mutability?
Well, let me tell you a story…
My name is Pete, and I’m addicted to F#.
I admit it — I love using functional languages and, given my .Net back-ground, particularly F#. The simplicity and above all readability puts it at the top of the heap. Most of what I’ll be talking about generally applies to most functional languages. I’ll use F# in my examples, but anyone familiar with the ML family should be able to follow along without a problem.
There are two things that can put a dubious look in the eyes of a Software Development manager: “we’re going agile!” and “working from home”, especially if he or she is prone to a bit of micro management.
This is the story of how I came to write a generative type provider for Neo4J, and the trips and traps I came across on the way.
This year I was a repeat offender and I don’t regret it.
Test Driven Development (TDD) is a buzzword that enjoying an upswing in popularity at the moment. I think that a lot of developers know that writing tests is a good thing and that everyone seems to be saying that writing them first is the way to do it. So an initiative is started to do TDD either self-taught or with the help of a training course.
One constant in my career has been the need to measure. While working in a sawmilling technology research team at Scion in the late 90s my catch-cry to a very traditional industry became
You can’t fix it, if you don’t measure it
The sentiment is the same in our software industry too. If a change is made to software without the means to measure the effect then all that can be done is to hope that everything is as intended.
Hello, and welcome to my first blog entry as software development consultant at Clarus. But, before I start, let me introduce myself.