Object Oriented Programming vs Functional Programming

0 is better than functional or is it the other way around maybe the next big thing will be better than both of them this is one of those arguments that exercises developers and they tend to fall into one camp or the other either you think that functional programming is the only sane answer or ooh is the defining approach for complex systems so what are the differences and do they matter what advantages does language paradigm have to offer and have we found all of the paradigms that there are to find [Music] hi i'm dave farley of continuous delivery welcome to my channel if you haven't already please do hit subscribe and if you enjoyed the video hit like as well i'd like to begin by thanking my sponsors harness equal experts octopus and spec flow they're all helping us to grow this channel so please do check out their links in the description below whatever programming paradigm or technology you pick a deployment pipeline will improve your workflow check out my new continuous delivery pipelines book on leanpub which will help you to get started building and to build better deployment pipelines links in the description again in this episode i want to explore programming paradigms there's an argument made by bob martin that we've identified all of the paradigms that there are to find i think that he might be wrong but we'll cover that later on i do though like his analysis of language the language paradigms that we currently have he argues that a programming paradigm works by removing a freedom of some kind it constrains us in some way limiting our options in ways that tend to help us to reduce or even avoid some kinds of mistakes i quite like that description a good place to start is how these paradigms arose in the first place the first languages were unstructured kind of paradigm free they were general purpose languages but this first generation were pretty unconstrained they were really like high level assembler languages in some sense you could do anything the usual way to describe the history of programming languages is as some kind of linear progression we started with unstructured languages invented structure and then oo came along and finally functional is the new kid on the block this is rubbish and completely wrong in reality it was quite a lot messier than that grace hopper wrote the first compiler of any kind in the early 1950s fortran was the first high-level language written in 1957 which is quickly followed by lisp in 1958 so languages began with an unstructured language fortran but then the second language invented was functional kind of fortran was intentionally mathematical fortran was named for formula translator it was unstructured but was built on some core concepts that are common in programming today concepts like variable assignment conditionals and loops cobol was the next big language written in 1959 it was trying to make programming language more like natural language and so easier to learn which i think that most people these days would consider a mistake for a general purpose language lisp was written for researching artificial intelligence at the time we'll come back to the functional paradigm that lisp gave birth to shortly so people built most systems in fortran or cobol for a while lisp was a bit of an outlier even then but systems were getting bigger and more complex so the lack of constraints meant that there were lots of balls of mud being produced dykstra came along in 1968. he wanted systems to be mathematically provable so he said go-to statements are considered harmful and gave birth to structured programming in 68. structured programming works by constraining the flow of transfer of control you can't just jump to any point in a program as you could in cobol or fortran or assembler you are forced to jump to fixed points that are defined jump to points in the language if you like that we these days call functions or methods this allows us to be a bit more cautious at these points we're forced to assemble arguments and we can check them for validity if we want to when a call is received as i said earlier it's a mistake to see this as some kind of linear progression of language goodness while all of this was going on elsewhere in parallel ooh was being invented the term oo was invented by alan kaye in 1966 but the ideas that led to it were around for a few years before that even as early as 1961. the first real oo language was simula which was created in 1965 but there were earlier attempts the radical oo step though was small talk in 1972. the oo paradigm is not really what most people think though it's not really about inheritance and why it is about putting data and behavior together i think that most oo programmers would say it is much more about polymorphism later alan kaye said this 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 i think that what k means here is that the real value is that we can send a message to something and it figures out how to process that message we can send the same message to two different things and each of them deals with that same message but in different ways ways that make sense to them this is polymorphism really this is the real power of o not inheritance in fact the 1972 version of small talk didn't support inheritance at all in bob martin's model this uh this is called dependency management through polymorphism that's how he characterizes the oo paradigm the real value of oo is our ability to modularize our systems and deal from the outside with different modules in consistent ways this is polymorphism structured oo and functional aren't the only paradigms logic programming constrains programs to follow the rules of formal logic for example you could argue that machine learning in its current incarnation is a different paradigm that constrains programmers by allowing them to pick good examples and the only defined fitness functions but let's get back to our topic for today though remember on the timeline kind of weirdly structured programming is historically the last of these paradigms to turn up but let's loop back to the current on point fashion leader the functional paradigm the defining characteristic of functional programming is really that it constrains assignment we write code with no side effects each function translates its inputs into a new output and that's all it does without changing these inputs in any way and without relying on anything but its inputs to achieve its goals sometimes functional programmers talk about this as separating data and function but if i'm honest i think that this is probably so that they can argue with oo programmers who talk about combining data and behavior in reality i like the idea of the constraints i think that we talk a lot of rubbish about languages and paradigms i am probably primarily an oo programmer that's where i spent most of my career but a lot of my thinking was informed by my early programming in assembler languages of different kinds an unstructured approach programming approach if ever there was one by shooting myself in the foot many times when writing assembler programs i adopted some defensive habits that i later learned were part functional part part structured so that when i learned more about these ideas they kind of fit together and that is what i like about this model of constraints because that's exactly how and why i learned these things i wanted to constrain the freedom with which i made designs so that i screwed up less often i adopt programming habits that limit the degree to which i screw up when i write code i don't really think of myself as a language or even a paradigm-focused developer but i like to pick the tools that make sense to me at the time modern languages are mostly a combination of these constraints really pure in concept although there are some i laugh when functional programmers rubbish oo for example and then go on to use collections to implement folds and the degree to which the collections like these make sense is really applying polymorphism to me and oh idea the degree to which the data is external in a list is an implementation detail in this case as long as we don't change that data if i write immutable code in java or c sharp or any other oo programming language then i can justifiably be seen to be writing in a functional style i used to write c i used to use ideas that i now i'd call oo and functional in the design of my code my language didn't help me much in those days in the same way that java doesn't enforce no assignment when i'm using it but it doesn't take a lot of self-discipline to achieve the same results if i want to so at the technical level i think that your choice of paradigm is just that it's a choice and it can be fluid and contextual let's be clear though you can write crap code in any paradigm and you can write great code in any paradigm too there's no functional good oh bad here there's a fashion for each side to rubbish the other and if i'm honest i think that that is a little naive there are advantages to different para paradigms different advantages for each as i've said i am more of an ooh than a functional programmer so probably somewhat biased the problem with this kind of religious war is that people get over-emotional so if i do trample on any of your sacred cows during the course of this please do forgive me there is a social dimension to all of this though and we need we tend to be too tribal in software development broadly i think that we could over simplify the tribes like this functional programmers tend to think of programming as maths oo programmers tend to think of coding as a problem of modeling neither of these are completely true but may be a reasonable approximation so the benefits of a functional approach are that we can abstract ideas into functions that are always correct in every circumstance and so write less code by excluding or at least constraining assignment we can create more stable systems and maybe even prove more provable systems the benefits of a model-based approach are that we can be guided in our analysis by the problem i think that this is one of the advantages that ooh has over functional programming it's that when done well the code is more navigable because it's closer to the problem it allows us to explore the relationships more clearly and understand the problem in small pieces in a way that is closely related to how we think about the problem human beings are naturally classifiers this gets us to what seems to me like an important point i think oo is more closely aligned with how humans brains work i can certainly buy the claim that the more mathematical functional approach is a more rigorous way to capture an idea but much as i love maths it's famously difficult and in essence an unnatural way of thinking for human brains we value mathematical thinkers highly because their skills are so rare this is so obvious if i throw a ball to you is it easier to catch it or to work out the physics of its flight and predict where it will land so that you can move to the right place we don't do the maths when we catch a ball if we did we'd certainly miss the ball so there's something to be said for ease of comprehension clarity of expression which is clearer this or this even if you are a functional programmer i think that you would agree that the second version was easier to read sure we can argue about the flexibility of folds versus loops and because of the immutability of functional style our potential to parallelize the computation of our programs an argument which i confess as a developer of high performance systems i'm a bit skeptical about but the readability the comprehensibility of our code matters a lot here is a function written in imperative style in this case in java we're just going to look at a collection of numbers and form some kind of total here is the same function written in haskell in this case we're going to define the function as a recursive function the first seems to be a lot easier to explain to somebody that has never written any code because of this alignment with the way in which people think about things you have to ask to access some reasonably complex ideas like recursion to even start to understand the second example yes the code is shorter but that compromises its readability somewhat too the first is a bit more like catching the ball than doing the maths in reality in haskell this sum function is a library function which i'm told is apparently implemented like this i rest my case i think that the functional paradigm has a lot to offer in particular the idea of limiting side effects is an excellent one however you choose to write your programs i've adopted that style of thinking in my oo code for a long time now not eliminating assignment but certainly limiting it and reducing the side effects i confess that i've never tried to write a whole functional sys system as a pure functional system and i'm sure that i would learn a lot if i did but i think that one of the reasons that everyone doesn't do functional programming is that it's more difficult to transpose these isds into the kinds of functions in a way that keeps the code readable and navigable i said at the beginning that i disagreed somewhat with bob martin about whether we have found all of the programming paradigms there is another aspect of programs and programming that we can usefully constrain that has some very interesting properties that is synchronicity what if we constrained our programs to disallow synchronous calls between modules of code each component of the system only communicated with any other by sending a message response is sent in a different message some time later i'm not talking about async awaits here which i dislike more like this a sends an add item message to b sometime later b sends an item added message back saying confirming the receipt concurrency only allowed at these module boundaries no creating threads inside a module each module is internally single threaded and so naturally concurrent each module is allowed to be stateful or stateless as need arises this approach is significantly higher performance than any other approach that i am familiar with certainly higher performance than a functional design functional systems copy a lot of stuff to achieve immutability the best that they can do is clever tricks to pretend that they're copying things but but actually not moving the bytes around in memory however clever these tricks are though it's still going to add cpu cycles this is less tightly coupled than oo systems this this approach of limiting synchronicity that i've described but it has some properties of both functional and oo design it also sounds to me quite a lot closer to the vision that alan k had back in the 1960s i wrote about some of these ideas in a thing called the reactive manifesto there's a link in the description if you'd like to hear more about these kinds of ideas in a future video do let me know in the comments thank you very much for watching [Music]

Channel: Continuous Delivery

Views: 596,946

Keywords: object oriented programming, object oriented coding, object oriented programming vs functional programming, oo programming, object oriented programming is bad, functional programming, functional programming example, functional programming tutorial, what is functional programming, functional programming explained, devops, Continuous Delivery, software engineering, software development, Dave Farley, programming, what is object oriented programming

Id: wyABTfR9UTU

Length: 18min 54sec (1134 seconds)

Published: Wed Apr 21 2021