Decision Mechanics

Insight. Applied.

Is functional programming more effective than object-orientated programming?

By

Imperative vs functional programming. It’s a debate that goes back to the birth of high level languages—Fortran vs Lisp.

In later years, it was retreaded as object-oriented vs function programming (OOP vs FP)—OOP having become the (massively) dominant software development paradigm.

And, I’m a fully paid up member. I embraced Object Pascal via Delphi 1 on 1995 and have been on the train ever since. I now do a lot of development in C# and teach best-practices.

Problems with OOP

But, just between you and me, I’ve never been truly happy with OOP. I understand the technology fully, but it’s never felt elegant to me. My adoption of Object Pascal had nothing to do with object-orientation. I was seduced by Borland’s state-of-the-art tooling—an IDE that was years ahead of its time. Object Pascal just came along for the ride.

On balance, I’ve found OOP to provide more pain than benefits. Take the three pillars of OOP

  • Encapsulation
  • Inheritance
  • Polymorphism

Encapsulation is great. I’m fully on board with it. But, a module system that allows me to group/isolate my code under namespaces, and hide private code, achieves that. Most modern languages—OOP or FP—deliver on encapsulation.

The benefits of inheritance are massively oversold. I have the scars. I’ve battled the fragile base class problem too many times—grappling with someone’s ill-conceived OO hierarchy that looked compelling in UML.

As for polymorphism, well, again, I’ve no problem with this, but it doesn’t need OOP. Polymorphism can be achieved with lightweight interfaces.

I’ve also failed to see many design benefits of using OOP. Mapping objects to the real-world is an incredibly leaky abstraction. Once you get beyond the high-level design it’s positively unhelpful. It also doesn’t fit very well with TDD. Designing objects to map to the real-world isn’t the same as creating testable classes.

The close coupling of data and behavior also feels unnatural. Maybe it’s my background as a data scientist, but I see code and data as separate things. My code is a pipeline through which data flows and is transformed.

OOP has, however, been wildly successful. It just seems that this success is a consequence of the significant education effort, impressive tooling and modelling techniques that have long been part of the OOP ecosystem. There’s a massive industry that supports, and it supported by, OOP.

Growth of interest in FP

FP isn’t new—Lisp dates from 1958. However, there’s been renewed interest in it in recent years. Much of this is down to growth in "parallel" environments, such as

  • big data frameworks
  • cloud computing
  • GPUs

Functional languages tend to be more naturally parallelizable. They encourage the use of immutable data structures which reduce the side-effects that make code hard to run on multiple processors.

Apache Spark, the current darling of the big data world, is written in the functional language Scala. There’s even a (Haskell-based) functional language for programming FPGAs (CλaSH).

Many of the major OOP languages are also adopting functional features. .NET has LINQ—and most of my C# code is now LINQ with object-oriented plumbing. Java 8 introduced Lambdas. Idiomatic JavaScript is increasingly functional…notwithstanding the introduction of classes in ES6. Swift is often talked about as a functional language. Two prominent modern languages, Rust and Go, avoid classes altogether.

FP is also a natural fit for data science work. R, a popular language amongst data scientists, is functional (as is Excel). Functional languages translate well to interactive, REPL (or playground) environments, making it easy to experiment with code/analysis.

We need more op-ed like a hole in the head

A blog article expressing one guy’s opinion. Well, there’s a novelty. And, the flurry of interest in FP might be no more than fashion. Has anyone done any research?

When looking into this, I found a presentation given at Utah Valley University that pointed to some interesting experiments.

In one study a team at Yale asked teams to code solutions to a problem using a range of programming languages, including

  • Haskell
  • Ada
  • C++
  • Awk

Criteria used to evaluate the solutions were

  • Extensibility
  • Understandability
  • Appropriateness
  • Accuracy
  • Compactness

Haskell, a functional language, was the clear winner. Given the possible variation in the skills of the teams, the study authors then had a graduate student learn Haskell for a week before attempting to code the solution. While not as effective as the experienced Haskell developers’ solution, the student’s submission came in second.

Now, this study was conducted in 1994, and development has moved on a long way since then. So…

Fast forward to 2014 and researchers at the University of California, Davis studied the following question

What is the effect of programming languages on software quality?

To do this, they took a dataset from GitHub. This dataset covered

  • 729 projects
  • 80m lines of code
  • 29000 contributors
  • 1.5m commits
  • 17 programming languages

The projects were real-world products—such as Linux, MySQL, bitcoin, etc.

They concluded that

  • functional languages are better than procedural languages
  • strong typing is better than weak typing
  • static typing is better than dynamic
  • managed memory usage is better than unmanaged

The emphasis on the first point is mine.

Conclusion

Obviously, at the end of the day, use whatever makes you most productive. All experienced developers come with a history (baggage?) that makes then more efficient with certain paradigms, languages, environments, frameworks and technologies—regardless of the objective merits of those technologies.

However, if you are an OOP developer who’s never given FP a serious look (i.e. used it to develop a real-world application), I recommend giving it a try. It’s no longer an academic curiosity. React, the most popular front-end library for web development, encourages FP.

We’ll benefit from continued research into the effectiveness of different programming languages. Having data is so much more useful that a barrage of strong opinions (of which I’m as guilty as the next dev).

The rise of functional programming

By

Yes, I know functional programming has been around since the 1950s. And, yes—Excel users are functional programmers. There’s nothing particularly new to see here.

Or is there?

There’s been sustained hype around functional languages for a few years now. Yet they have failed to break into the mainstream. Languages such as Haskell, Clojure and F# remaining frustratingly niche.

The top ten programming languages rankings in recent surveys by Stack Overflow and GitHub are devoid of functional programming languages.

Except that they aren’t.

Functional programming is on the rise, but through approach, techniques and style—not language choice.

Mainstream languages are hybridizing—adding functional capabilities to their (predominantly object-oriented) features. C# has LINQ. Java has added Lambda Expressions. JavaScript has many features that support a functional approach—which is actively encourage React, for instance. Rust, Kotlin, Swift…and a host of other modern languages…have a distinctly functional flavour to them.

Functional programming languages have a lot going for them. They encourage (or enforce) functional design principles. And they often bring desirable features with them, such as powerful type inference. However, the real revolution in functional programming is happening through traditional enterprise languages—gradually introducing practising software developers to the ideas without forcing them into a "paradigm shift".

Why does functional programming matter?

Functional programming brings with it skills and concepts that are valuable when building modern applications.

One benefit for data scientists is that functions look like…well…functions. Mathematical functions to be more specific. The closer the code is to the equations you are using, it easier it is to make sure you have the correct implementation. There’s a reason that Excel and R draw heavily on functional ideas.

Today’s applications are increasingly asynchronous. Mobile…web…microservices…functions-as-a-service (FaaS). Asynchronous software is hard to write—and even harder to debug. Functional programming encourages practices such as immutability and isolation of side-effects that make it easier to reason about asynchronous code.

There’s a view, admittedly controversial, that the object-oriented programming (OOP) paradigm that’s dominated software development for over 30 years has retarded progress.

Alan Kay, who coined the term "object-oriented", has long criticised mainstream OOP.

I’m sorry that I long ago coined the term “objects” for this topic because it gets many people to focus on the lesser idea. The big idea is messaging.

He has also expressed his dissatisfaction with major OOP languages.

Java is the most distressing thing to hit computing since MS-DOS.

I invented the term "Object-Oriented" and I can tell you I did not have C++ in mind."

It’s been called the "trillion dollar disaster". Its "three pillars" are a combination of the unremarkable (encapsulation) and positively harmful (inheritance).

OOP’s singular focus on "nouns" has given us an industry of convoluted patterns in an attempt to impose some order–leading to CommandExecutor classes with executeCommand methods.

As we build more complex, asynchronous systems, OOP is failing to scale effectively.

The tools used in functional programming—map, filter, reduce, copy-on-write, etc—are simpler and more generic than OOP patterns. And, as functional programming has a mathematical foundation (lambda calculus), it opens the door to more advanced tooling for automatically diagnosing problems in our code.

Unlike OOP, functional programming encourages us to separate our data from our calculations. This makes our code easier to test and aligns perfectly with today’s data-centric workflows. Data pipelines fit snugly into functional designs.

Can I use functional techniques without adopting a functional programming language?

Yes! That’s the point. Absolutely.

Functional programming is a set of concepts and techniques. It’s a way of thinking about and writing code. Sure, functional languages make it easier to apply those ideas, but you can apply them in any programming language.

And, as mentioned previously, modern languages are increasingly becoming hybrid languages—supporting the use of multiple paradigms.

Focusing on the concepts, rather than language features, will allow you to take your functional programming skills with you as you move from language to language during your career.

I’d argue that it’s worth learning at least one functional-first language as it helps consolidate your ideas, but it’s not essential.

Just start writing functional code. Today. Your customers will thank you for it.

Spreadsheet error delays opening of children’s hospital

By

An audit report has blamed a spreadsheet "copy and paste" error for cost overruns and delays at an Edinburgh children’s hospital.

A local politician called it

[…] one of the most expensive typos in history.

How many more high-profile spreadsheet failures is it going to take before we deem the inappropriate use of them to be professional malpractice?

Skin in the game

By

knife-wielding robot

I tend to listen more to opinions when people have placed money on their espoused outcome—having “skin in the game”, as Nicholas Taleb calls it in his latest book.

However, this robotics developer seems to have gone one better. He literally has skin in the game.

Good scientists aren’t supposed to experiment on themselves, but I will feel better if the first people to use autonomous cars are those who built the guidance systems.

At least it’s more impressive than Test-Driven Development.