State Change

A couple of weeks ago I started ‘preparatory drawings’ for a great work of the blogging art about application portability. That was hard. This is a quick caricature of the resultant pile of half-sorted words.

I decided to learn to code in Python, having dismissed several other options; including Java, Ruby, HTML5 and JavaScript. I’d even considered having another go at Lisp but dismissed that as impractical. Surprisingly, I didn’t consider Perl, for my laziness http://c2.com/cgi/wiki?LazinessImpatienceHubris.

Since I went to that Clojure talk I’ve referred to before, I can’t shake the feeling that there was something about immutability that I shouldn’t ignore. Conventionally, I’d replace the assignment of ‘Python’ to the variable LanguageToLearnNext with the new value ‘Clojure’. There would be no trace of the fact that the language I WAS going to learn next was Python – but I’ve written about it several times and now I’ve broken the links. If this was code, that would be a problem.

Variables have no time dimension. Neither does the relational model. Michael ‘JSP/JSD’ Jackson told me that. At around the same time, there was a buzz around parallel architectures and programming. There is again now, if you talk to people who are ahead of the game. They call it concurrency now. Physics has caught up, overtaken the hardware engineer’s RISC wizardry and erected its road-blocks again. We don’t know how to make our processes go faster; so there need to be more of them spinning. We live in a word of multi-core processors.

Clojure is immutable by default, which prevents concurrency scrambling coders’ brains. In Clojure, there is still yesterday’s LanguageToLearnNext and now there is a LanguageToLearnNext for today. Variables are so last century.

See: http://clojure.org/state if you want this explained properly.

 

Advertisement

Applying the Science Process to Process Change (see Recursion)

Now that we’ve established that very few people who work in “IT” have anything to do with technology, except as a tool, and that “computer science” isn’t about computers, we’re back at the original reason I began to write a book. I was once an ‘Information Systems Engineer’ and wasn’t very sure what any of those words meant, particularly “information”.

Software development teams often see their role as solving their customer’s problems. Software package providers say they are “solution providers”. What does the ‘unspeakable profession’ actually do? We got some clues from Hal Abelson in the video I linked to in my last post, that new areas of intellectual endeavour often confuse the ‘essence’ of their subject with their tools; so do we really engineer software?

Hal said that writing software is the process (or function) of formalising our intuitions about process (function.) Our software is a speculative formal abstraction of our intuitive understanding of a process we may not entirely understand. No wonder software projects so often fail. Like the rest of science, software is built on ideas that haven’t been proved wrong yet.

Software developers are presented with, or attempt to discover, experts’ (declarative) knowledge of the business process in the ‘domain’ we are about to change. This is ‘the abstract requirements’. Some of this may have to be implied from imperative knowledge embedded in existing software. It may be presented as imperative solutions. It may be incomplete.

We then follow our own process (function) for: ‘the way we do software’, in order to design a new process, some of which is also likely to be have to be embedded in software. Applying functions to change functions? That’s what functional programming does, isn’t it?

I believe that the ‘stuff’ of ‘computer science’, is state-change of systems of process and data. Who remembers ‘Data Processing’? Functional programming points out that the processes themselves are data and dynamic state-change is unpredictable and therefore dangerous.

Engineering would apply ‘project thinking’ to this unstable, poorly defined change. I may once have tried to be an information systems engineer but I saw that it didn’t work and took a 20 year break from software development.

Agile frameworks recognise such changes as risky experiments and carefully apply the scientific method, incrementally with feedback loops, to check assumptions.

We may need to return another time to see what functional programming has to say about 2 projects making concurrent changes from the same initial state. Until then, good luck with those.