Tag Archives: immutable data

A Functional Mindset

When I started learning Clojure, I thought I knew what functional programming was but I’ve learned that the functional paradigm is now more than I expected.

Everyone agrees that it’s a computational model based on evaluation of mathematical functions, which return values. This is generally contrasted with imperative programming languages such as FORTRAN, C, JavaScript or Python, which are also procedural and some of which are object-oriented but may make functional coding possible, in a hybrid style. I wouldn’t recommend learning functional concepts in a language that gives you short-cuts to stray back  to more familiar territory.

Clojure is a member of the Lisp family, first specified in 1958. The unusual feature of Lisps is their homoiconicity – code and data are the same thing. Learning Clojure has informed my thinking about business process change.

Some modern, functional languages such as Clojure use immutable data whenever possible, to eliminate side-effects. This allows better use of multi-core processors but requires a complete change in thinking, as well as programming style. ‘Variables’ are replaced by fixed ‘values’, so loops have to be replaced by recursive functions. New data can be created but it doesn’t replace old data. Yesterday’s “today’s date” isn’t automatically wiped when we decide today has happened.

Objects with their methods and local data were designed for simulating the current state of real-world objects by changing (mutating) object data state. The object model, like relational databases, has no inbuilt representation of time. Functional programming splits these objects back into separate functions and data structures and because values can’t change, they may be transformed by flowing through networks of functions, some recursive, to keep doing something until a condition is satisfied. Eventually, code must have a side effect, to tell us the answer.

Rather than computation being a conditional to-do list with data being moved between boxes, it becomes a flow of data through a network of ‘computing machines’; and the data and machines can be transformed into each other.

I hear that map, reduce & filter data transformation functions will change my world again.


Becoming Functional

I’ve been playing with the idea of doing some functional programming for a while now. I’ve been trying to learn and paddling around in the shallows but this week I dived right in the emacs/CIDER pool. I was aware of some dangers lurking beneath the surface: recursion, immutable data structures and the functional holy trinity of map, reduce & filter, so I came up with some ideas to face my fears. I’ve also realised my maths has got rusty so: Some of That Too.

  1. I’ve ‘done recursion’ before but I thought I’d read that my chosen weapon Clojure didn’t do tail-end recursion. This isn’t true. What it can’t do is automatic optimisation of tail-end  recursion, to stop it blowing the stack after a few thousand iterations but Clojure has a ‘recur’ expression to manually signal tail recursion and fix that. I knocked off the programme in a couple of hours and went to bed happy. My code was happily printing the first n numbers of the Fibonacci sequence but a day later I still couldn’t get it the return the numbers as a sequence.
  2. I was finding out about immutable data the hard way. You can’t build up an immutable vector, 1 element at a time. You get to keep the empty vector you created first. It’s a big mind-set change to not have variables that can vary. In my next post, I’ll try to say what I’ve learned. On this occasion it was lazy sequences.
  3. I mentioned the Algorave in my last post. I only found out about that because of an idea I had for improving my theoretical understanding of music. I realised that I could write, for example, a function that would return the 1st, 3rd and 5th notes in a major scale, using a map function.While working the theory out, I found out that Lisps are already popular in the live-coding world.
  4. At Algorave, I was inspired by the live-coded graphics to try automatically generating some graphics too, to work out the maths of mapping triangular grids onto Cartesian co-ordinates. I need that for another idea.

Three basic working programmes in about a week. They aren’t ‘finished’ but is software ever? They have delivered value via increased Clue.

Asynchronicity Traps

Don’t you love it when lack of planning comes together?

Last Thursday, I learned about JavaScript callbacks, which reminded me of OpenVMS Asynchronous Traps (ASTs.) I learned to code in a world of single-threaded processing, so this was an advanced topic, along with my interest in occam and Communicating Sequential Processes. Back then, only real-time coders and those looking to the future cared about parallelism. I remember not really seeing the point of Yourdon ‘state-diagrams’. I’d never experienced the complex state network that a GUI with a few option buttons can generate.

Last night I came across debates about the advisability of abandoning JS callbacks for the HTML5 ‘promise’ construct; “callback hell”, they called it. Promises are functions. This is another area where the elegant simplicity of functional programming appears to offer hope. Functions are mathematical constructs, so in functional languages perhaps all possible states that code might enter can be identified.

Alongside this, I’ve been reading about research into the energy requirements of computation. For a long time, computer scientists thought that every logic operation would have a cost in terms of energy and hence entropy, but that appears not to be true. It is information deletion that costs energy, so immutable data is more energy efficient. I’m only up (down?) to quantum bits, so I’ll have to let you know how the cat gets on another day. I worry when physics starts to look like mystical religions.