Procedural, functional, object-oriented. What do we mean?

(Andy Wootton) #1

I started re-learning how to code and decided to learn OO for the first time. After reviewing several languages, I chose Python then almost immediately was introduced by @paulspencerwilliams to Clojure and immutability. I’ve now done just enough OO and functional to be equally confused by both, so I wrote this:

I wanted to know more so asked a question on the birminghamfpmeetup Slack channel: “I see an OO system as a network of objects, each representing real-world objects as data structures and methods, plus some other objects, invented to make things work. What does a functional system look like? Is there any reason objects can’t be built out of function calls rather than method calls and with local or shared data structures?”

Paul answered, saying “objects are possible in FP languages. There’s
a good example in Joy Of Clojure. Also, look at Stuart Sierra’s
component library. Other FP systems may have a single state store
(clojure atom, db etc) that side effecting functions update explicitly,
but generally, all renditions of this central state is immutable.”

I asked, “Do you see state/mutability as an essential part of OO?”

Paul said “state yes, not necessarily mutable, but OO by definition is the complecting of state and behaviour.”

I haven’t ever thought about OO in terms of state so this was new to me. I looked for an alternative definition and found this

‘(OOP) is a programming language model organized around objects rather than “actions” and data rather than logic. Historically, a program has been viewed as a logical procedure that takes input data, processes it, and produces output data. The programming challenge was seen as how to write the logic, not how to define the data. Object-oriented programming takes the view that what we really care about are the objects we want to manipulate rather than
the logic required to manipulate them.’ That could be a definition of functional as well as procedural.

It goes on to say ‘The first step in OOP is to identify all the objects the programmer wants to manipulate and how they relate to each other, an exercise often known as data modeling.’ This was a surprise too because I remember doing data modelling for a FORTRAN project before I’d ever heard of OO. If you worked in COBOL, it was called it “Data Processing”.

This discussion seemed to have broken free of the functional paradigm, so I said I’d move it here. I’d like to know what OO people think differentiates Objects from procedural. I think it’s that procedures and data are clustered around objects instead of being in a big lump. I think this is what makes using relational databases for object persistence such a problem for OO languages.

(Andy Wootton) #2

Rich Hickey talks about identity, state & values and distinguishes between immutable value-oriented and mutable place-oriented thinking.

Wirth said "Algorithms + data structures = programs"

OO recognised that the algorithms (behaviour) were often modelling the state of real-world objects and Hickey points out that we traditionally used place as a proxy for value because storage was expensive and it’s probably time to stop doing that. Modelling state-change like a hand-written ledger or a log-structured file system gives us a time-dimension. This was always sadly lacking from the relational model. I think Ted Codd recognised that.

This monologue has helped me a lot. I hope I haven’t annoyed anyone else too much.

We also usually model business change projects as a state change from an AS-IS to a TO-BE state and run projects in parallel without any locking. That’s another bad idea and explains why an agile approach should do better with process re-engineering, as well as software development (software development IS business process engineering.)

(Andy Wootton) #4

Darn, I thought I’d managed to provoke someone. Instead, a timely input from the Twitters on how intertwingularity broke OOP

First time I’ve tried to subscribe to a Medium blog. You can’t, without joining their club. Blog monopolists?

(Daniel Hollands) #5


(Steve Pitchford) #6

I like the sound of Clojure, but I’m not ready to give up on OO yet. I’m also not 100% confident in the statement. There is bad OO, a lot of bad OO, and there is better OO - and by “better OO” I mean OO produced by the sort of people who have read Eric Evans Classic Domain Driven Design ( ), understand how High Cohesion, Low Coupling impacts a system, and get that Aggregates are as important as objects when it comes to modeling systems…

(Andy Wootton) #7

I tried to subscribe from my blog in the usual manner and it it invited me to become a member. I didn’t look any further but thanks, maybe I should have.

(Andy Wootton) #8

I Really can’t buy any more books😁 yet. I buy them 10 times faster than I read.

The link I just added suggests The Problem with OOP is trees again. I don’t like the way it is written but it contains some interesting observations.

(Steve Pitchford) #9

The medium post, to my ears, sounds a little biased. Consider the reuse of a money class. Or a datetime class - perfectly transferable between projects. And the forest-monkey-banana problem is just down to bad oo and a universal object graph rather than a composition of aggregates.

OO has it’s problems, and it never really delivered all that was promised on the reusability front. Functional looks very interesting. I’m not sure total adoption of one or other is a helpful model though - I suspect the future lies in greater adoption of DSL’s .

(Andy Wootton) #10

@paulspencerwilliams pointed me at this. It’s Java-based and free

He’s more about swapping best practice than fighting religious wars. He seems to accept that inheritance is unsafe because reality isn’t always tree-structured. I’m fascinated by whether it is possible to mix metaphors. I like how he translates algorithms+data to ‘behaviour of objects’ and ‘classes’.

[I’m now wondering if I misremembered that, having just come across a note that Paul said ‘Behaviour & State’. I now see more clearly that he meant “…of objects”, whereas I originally interpreted it as ‘behaviour of process’ and ‘state of object’. The difference is in whether the code is a simulation of a real process or is the process. I think I’m into information metaphysics again.]

Having only modelled business domains with objects, I was interested in the way he talks about objects which model only behaviour. Why are they objects? They have to be, by the rules of the language. It sounds like Java 8 has a healthy dose of pragmatism but that usually comes at with a heavy price in elegance when retrofitted.

I think I’m getting closer to seeing how functional people think. I suspect their data structures only model ‘objects’ in the real-world. All the system state information is distributed into the network configuration of function pipe-lines. I think that’s why it’s safer to dynamically change the ‘pipes’. If you aren’t ‘sucking’, by making function calls, the pipes are empty. Oh, dear: fluid analogies.

I’ve been looking back to procedural programming. Yourdon methods used to talk about “data flow” and “flow of control”, “data sources” and “data sinks”. The model was literally fluid in pipes, being controlled by valves. I was never convinced that the data flowed but I worked with people who were totally convinced. The functional folks talk about transformation of data from one data structure to another because they think in maths instead of water. We put too much faith in the stories we tell ourselves to make the world seem simpler.

(Marc Cooper) #11

Behavioural objects are very important. They’re often called service objects. Sadly, they’re often implemented poorly, if at all. They are also central to the well-known strategy pattern. This pattern is usually unnecessary in modern OO languages (i.e. post Java and PHP).

The importance of behavioural objects lies in decomposing complexity through composition. e.g. avoiding God objects.

Very few developers, ime, get this far in their understanding.

(Marc Cooper) #12

Something like phoenix – the web framework for elixir – centres itself on this principle. It passed the html request/response “object”, which is calls conn, all the way through the request/response cycle. It’s simple and quite logical. There’s no mathematics about it.

I’m familiar with many web frameworks. Phoenix’s conn is the most elegant handling I’ve experienced of the req/resp cycle. The same could be done with an object; even with an object and methods returning self – which amounts to the same immutable principle in FP.

FP and OO achieve the same ends. I’m far more confident of constraining devs to conform to FP than OO. The discipline require for OO is far higher than FP to attain working software. The difference is that you can break all the rules in OO and still achieve working software (it will vary from language to language). The same is not true of FP.

For the avoidance of doubt, I regard working software as the lowest rung on the ladder. Anyone can write working software with a little application. Working maintainable software, however, is a completely different game.

(Andy Wootton) #13

The day Guido said Python wasn’t really designed as a functional language :slight_smile:

(Marc Cooper) #14

I always like reading Guido’s ramblings. I’m pretty sure if I’d liked python’s syntax, then I would have gone with it. Current project is using it, and the absence of end is just wrong. Still don’t get on with it :frowning:

(Steve Jalim) #15

Pffffft :wink:

(Daniel Hollands) #16

I hear you, Brother.

(Andy Wootton) #17

Algol 68 had typed ENDs: If… Elif… Else… Fi, Case… Esac, While Do…Od.

They were really For-If-While-Do loops though. Intertwingled symmetry. Thinking about it, maybe that’s what put him off. Another ‘interesting’ feature was that code was constructed of serial-clauses with “;” as ‘separator’, not terminator. You wouldn’t believe the number of compilation errors introduced by changes to the last serial clause in a block. I think it was the only thing I liked better when I started coding in Pascal, to buy food.

(Dee Vious) #18

Objects can totally be built using functions!
You can write a DSL that employs OO principles if you need to but, you’re not restricted by them. That’s why I became enamoured with Clojure. Immediately, you can take advantage of multiple inheritance - Java cannot and, consequently, cannot directly transform some models.
My current view is that you might use FP to develop an OO system, providing functional objects that use OO for modelling.
As in, Clojure would do a better job of transforming some UML model, than Java.
Course, it depends what your goals are, in programming.

(Andy Wootton) #19

I’ve been spending some time on Quora recently. Someone asked if Smalltalk was influenced by Lisp. Some guy called Alan Kay had a lot to say about it :slight_smile:

There is a link to the LISP 1.5 Programmer’s Manual in there. I find it interesting that MIT had a “Computation Centre” rather than a computer centre.

(Andy Wootton) #20

@ArgyBargy Possibly relevant? Living Clojure, p80 in ‘Practical Polymorphism’, “Clojure protocols and data types are powerful solutions when you need them, but beware! Many people who come from an object-oriented background tend to reach for them just because they are similar to how they are used to modelling and thinking about code.” Then a warning: "Think before you use protocols."
I’m finding it a very good book and I’m using it in a way I’ve never used books before; jumping about and dipping in wherever something interests me. I’m not sure if this is due to the structure of the book or if I’ve changed.

(Dee Vious) #21

The developer of Onyx Platform explained, in a YT video, why he avoided multi-methods. I didn’t understand his reasons!
I think it might be to do with when and where protocols are declared. My misunderstanding is that, unless you re-def a protocol, it might not take changes to other functions into account.