Tag Archives: programming

Objects vs Functions

I learned to ‘programme computers’ long ago, almost before there was no “me” in ‘program’ and certainly before I knew how to ‘team’. I had a very brief and unsuccessful exposure to functional programming in LISP (not Lisp) then stopped. I did other ‘Data Processing’ things.

In recent years I’ve been working as an analyst, alongside people who write code according to the object model. I think I have a feel for objects but never having written code in an object-oriented language, I can’t be sure. I decided to try, in the Python language, then got distracted by the shiny Clojure language which is functional. I feel that right now I’m approximately equally confused by objects and functions, so I thought I’d write this quickly before I know what I’m talking about. I can come back later to laugh at my naivety, along with the rest of you.

Like the person who wrote this https://news.ycombinator.com/item?id=4246018 ,
I’ve been watching some talks online recently by Rich Hickey of Clojure fame”
The post asks “So if I follow Hickey’s advice, how am I supposed to represent a book? As a vector of vectors of vectors of vectors of strings? If so, then how do I prevent a change in the representation of the Book from breaking client code?”

I found the question very interesting because representing ‘books’ in a functional language is exactly what I want to do. I think differently to the author because  I’m not yet trapped inside the object paradigm. I can see that ‘book’ is a real-world class of objects, a very specific and limited implementation of the representation of a small subset of all the information in the world. That’s what my ‘book’ was going to be about and why I’m now playing with functions instead of writing it.

Objects are good at simulation of real life systems. They encapsulate small sub-systems of a process and it’s local data into an object. What I always struggled to understand was what you did with the data that didn’t want to be enclosed – “information wants to be free”. People seem to cope by inventing objects that don’t really exist: to be data shepherds.

Functions are good at abstraction. A book is a single output format from something much richer. That’s what I want to write. Data and processes are complex. Objects and functions are simplifying models; there may be others.

p.s. (not Lisp) Get it?


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.

Programming Paradigm Objectification

I  learned to program according to the principles of

  • structured programming (rather than spaghetti code)
  • modular code (rather than monolithic)
  • top-down design/functional decomposition (rather than JFDI)

The Idea was:

  • you had a big problem that you completely understood and the problem could be decomposed into smaller and smaller pieces of function until you could see how to write them as code (producing a functional hierarchy – a concept similar to dissecting a body, with no significant understanding of anatomy until you had finished)
  • your organisation’s data could be analysed and abstractly modelled without any knowledge of how it would be used (producing a data model)
  • you could trace the route of all information in the system as it was input from a data source, processed within the system into a different form and output to a data sink (producing data flows & data processing)

Sadly, none of those assumptions were completely true and the systems produced were liable to be hugely disrupted by minor changes if they had not been anticipated – or not – it was fairly random.

I worked in that culture for a few years. I could see what was wrong but didn’t know how to fix it, so I got out of programming and ran systems for people who didn’t seem to have  existential issues with their programming paradigm.

I don’t like being beaten by a problem, so I kept a weather-eye on what was going on in software development. I started to hear about Object-Oriented Programming and decided to investigate. It took about three talks for me to begin to understand tiny bits of ‘what the hell They were talking about’, because each time I was told that O-O languages had some of the following features:

  • Encapsulation and information hiding
  • Objects (with attributes and methods)
  • Dynamic dispatch
  • Abstraction
  • Polymorphism
  • Inheritance (or delegation)

Oddly, I didn’t find that knowledge helped me much to understand WHY. I’ve started reading about O-O again this week and I realised in the shower this morning that the object paradigm isn’t just a list of jargon words.

Instead of splattering representations of the things your program is dealing with throughout the functions, with references to many elements of the data structure and data flows,  O-O models any of ‘the business objects’ of your organisation that your program needs to deal with. The objects encapsulate their local functions and  data. Objects don’t change as often as functions so changes are localised.

The connections between the objects are represented by message-passing. If things have to be taken apart later, as relationships between real objects change or are replaced, the connections can be re-made to represent the new reality.

The O-O model represents “small systems, loosely joined”, like Unix. If someone had just pointed that out, it would have helped me to understand. So I’m saying it here, now, in case it helps you.

Without O-O, I don’t think the Agile software development revolution could have happened, because the early uncertainties and ‘sketched solutions’ of Agile would have had too great a cost of change, later.