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

Computational Science + Informatics = Software Development

1970s At university, I studied Physics and:

• Computer Science

but it had very little to do with computers. It was far more about becoming a

• Computer Programmer

1980s When I started work I heard about the increasing formalisation of the software development process and I wanted to be a

• Software Engineer

1990s I’d moved into server management by the time I qualified as a

• Chartered Information Systems Engineer

which fit in with my thinking that information is the important resource in any organisation but took me no closer to knowing how to make great software efficiently. I became disillusioned by watching people trying to apply the rigorous methods of hard engineering to the uncertainties and unknown complexities of software. I became interested in prototyping, incremental delivery and Agile.

2000s I was increasingly drawn to the idea that constructing software is a design discipline and that a software developer needed to be a

• Software Craftsman

2010s After a few years working with an agile software team, I decided I wanted to try writing software again myself. A few weeks ago, an online MIT course on Python programming introduced me to an idea that I felt very comfortable with: a good developer is a

• Computational Scientist (I’d settle for ‘Computing Scientist’)

and I’d add the option

• Informatician, which overlaps with what librarians do now

Agile development processes are adaptations of the scientific method, to research what customers want and work out how to give it to them in the way that meets their opinion of best value, and I don’t see why software developers can’t be their own customer. Every great new software component starts off as someone’s experiment.

Software Life-cycle. Part 2 – From Craftsmanship to Computational Science

I decided to learn the programming language Python. I was steered towards the MIT OpenCourseware ‘Introduction to Computer Science and Programming’ 6.00 course, taught by Prof. Eric Grimson and Prof. John Guttag (they say it is a course about computational thinking.)

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/6-00-introduction-to-computer-science-and-programming-fall-2008/video-lectures/

As the first lecture felt a bit basic, at great personal risk of uncovering ‘a spoiler’, I skipped on to the course summary in the last lecture to see if it was worth sticking around. I found it inspirational. Prof. John Guttag explains computation in the context of ‘The Scientific Method’. I’ve since realised that his explanation maps with great accurately onto Agile iterative methods. Agilists aren’t engineers, we’re scientists again. Engineering Project Management uses experience of similar previous projects. Why would you ever write similar software twice? Most of the work is already done. Every change to a computational system should be R&D.

Every Scrum Sprint is a suite of computational experiments. The Product Owner is our test subject. This feels right. I never felt like a computer scientist. In James Gleich’s ‘The Information’, he explains that Alan Turing introduced Babbage’s mechanical Difference Engine when talking to non-specialist, to emphasise that computing is an abstract concept, independent from computers and electricity. I’ve always had a computational scientist trying to get out <Woo asplodes>.

Programming The Hard Way

I wrote about my plan to restart computer programming. I’ve postponed the HTML5/CSS/JavaScript route, as I was blindly following instructions, which is not my preferred learning style. I wasn’t learning fast enough so got disillusioned and lost interest.

I found a book called ‘Learning Python the Hard Way’
http://learnpythonthehardway.org/
and I was “trying it for free” but I’m not really its target audience:
“Made for beginners who know nothing about programming.
Not a book claiming to be for beginners but really for programmers.”
If you are one of those, then it looks a good way to learn Python programming.

I skipped to the end to read “Advice from an Old Programmer” and saw that the author  claimed to know 20 languages when he wrote the book.
“How ridiculous!”, I thought, “No-one needs to know that many programming languages.”

Then I made my list. I was a student then professional programmer for less than 10 years.

At university: Algol 68, COBOL, Lisp.

At work on VMS: DEC DCL, BASIC, Pascal, FORTRAN. On IBM mainframes VM/CMS with Rexx.

In recent years: Business process modelling in the graphical language, UML.

Along with dabbling with various bits of:
POP-11, C, Macro-32, SQL, Unix/bash scripting, C#, XML and Java

and now I’m trying Python, HTML5/CSS3/JavaScript.

About 20. As I said, RIDICULOUS!

There is a further gem of advice in that section of the book: don’t see programming as a profession but as a weapon in another field, where the things you can achieve with computers are valuable and respected. I had achieved this until the last couple of years, when I was re-organised into an IT department, without my agreement. They were the least satisfying of my career. I like solving real problems, not artificial ones caused by ill-advised IT changes.

Coding is a tool but there is little chance of finding satisfaction in a job advertised as ideal for someone who likes hammering; particularly if they tell you the manufacturer of the hammer which you must have 2 years previous experience with. Don’t work for a fool. It only makes you look foolish.