You aren't going to see entirely functional applications "in the wild" because it's convenient to keep the top layer procedural. But, it's generally useful to u

You aren't going to see entirely functional applications "in the wild" because it's convenient to keep the top layer procedural. But, it's generally useful to use OO and functional design for components. Then you combine the components in a procedural manner. Here's a decent example of creating functional components and gluing them together imperatively: https://www.destroyallsoftware.com/screencasts/catalog/functional-core-imperative-shell https://www.destroyallsoftware.com/screencasts/catalog/funct... OO and Functional are just good design goals for making an easy to use API for your components. Even if those components are written in C, I think you'll find that many components are designed to be: Object Oriented: - has an interface - hides implementation details Functional: - the same input always gives the same output. I.e. there's no hidden state changes which you need to keep track of You can think of it like concrete vs cement. The OO and functional components are the rocks and rebar in concrete, and imperative code is the cement. The rocks make the concrete stronger, but it's easier to shape with cement in between the rocks and rebar.