Differences
This shows you the differences between two versions of the page.
| Both sides previous revisionPrevious revisionNext revision | Previous revision |
| 2014:immutabilty_ftw [2014/01/08 22:05] – jonjagger | 2014:immutabilty_ftw [2016/06/11 14:05] (current) – external edit 127.0.0.1 |
|---|
| Back to [[conference:committee:2014-proposals]]\\ | Back to [[conference:committee:2014-proposals]]\\ |
| \\ | \\ |
| **Title**: Immutabilty FTW!\\ | **Title**: Immutability FTW!\\ |
| **Proposer**: [[2014:Kevlin Henney]]\\ | **Proposer**: [[2014:Kevlin Henney]]\\ |
| **Type**: Tutorial\\ | **Type**: Tutorial\\ |
| **Duration**: 90 mins\\ | **Duration**: 90 mins\\ |
| **Description**: \\ | **Description**: \\ |
| '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? Is this assumption always valid? Is state change as necessary as its widespread use might suggest?\\ | "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? 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.\\ | 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.\\ |
