Tuesday 17th May, 2016
11:30am to 1:00pm
"When it is not necessary to change, it is necessary not to change" observed Lucius Cary, four centuries ago. He could well have been talking about program state (had such a concept existed). We have it by the bucket — by the megabucket, gigabucket and terabucket — and most code, designs and programming languages assume that program state is something that is changeable. But should it be? Is this assumption always valid? Is state change as necessary as its widespread use might suggest? Immutability is a cornerstone of pure functional programming, and is often seen to be exclusively associated with it, but immutability and other restrictions on state mutability are more widely applicable, and certainly not the sole preserve of functional languages. It is a necessary practice in languages with reference-based semantics and in concurrent environments, for example. Without it, code becomes difficult to reason about (oh...) or chock full of locks and deadlocks (ah...). This loss of simplicity may seem familiar.
This session explores the consequences, benefits and implications of programming in an immutable (or less mutable) style, from value objects and pure functions to persistent data structures and concurrency
consultant · father · husband · itinerant · programmer · speaker · trainer · writer
Kevlin is an independent consultant and trainer based in the UK. His development interests are in patterns, programming, practice and process. He is co-author of A Pattern Language for Distributed Computing and On Patterns and Pattern Languages, two volumes in the Pattern-Oriented Software Architecture series. He is also editor of 97 Things Every Programmer Should Know.
Sign in to add slides, notes or videos to this session