DEV Community

loading...
Cover image for Functional programming is conversational, OOP is abstract art

Functional programming is conversational, OOP is abstract art

John Kazer
Interested in making life easier and smarter. Amazed by the power of the modern web. solarfuture.org.uk
・2 min read

Functional, OOP and procedural styles are all valid, just different - and in fact complementary.

To explore how, here's a fundamental question: What is it really like to program in a functional, procedural or an OOP style? I don't mean the technical nuts-and-bolts, which many folk have and will write about. I mean from a personal perspective - what thinking style are you using and is it suited to the task at hand?

I was reading an article by Arsen recently, on the different interactions implicit in software engineering teams. For example, engineering processes are basically code procedures that are both impersonal and hard to stop once started. But very useful and efficient for well-understood activities.

Consider modern art (such as the article's header pic which is a part of "Little painting of fir-trees" by Paul Klee). It takes a lot of thought and consideration to distill a thought or a scene into an abstract representation on canvas. And once done it is hard to undo - the links between painting and reality are not always obvious or reversible. But the end-point is powerful and imparts meaning quickly. Of course, the meaning you extract might not always be what the painter intended you to see!

Contrast this with the interactive conversation that is pair-programming or an agile sprint. Feedback is rapid, change is easy (desired) and you have more control over the questions and answers.

A common development process therefore might start with some rapid-feedback activity, when the solution space isn't clear. But over time become more structured.

We can apply the same concept to the style of programming. Start functional, move to objects with message passing once the structure is clearer and more organisation is needed (the objects may be functions with closures or some other OOP concept). Then convert some of the fundamental activities into fast and efficient procedures when you can cope with the loss of control this implies.

Functional, OOP and procedural styles are all valid, just different - and in fact complementary.

Discussion (0)