there we go baby boys one of my most successful videos on this channel so far Compares functional and object-oriented programming this is an interesting topic and clearly not just to me but there's more to this debate than we discussed in that episode this is one of those debates that to be honest seems a little weird to me I think I could have agreed with this this take not too long ago real talk I I really do think I would be on the this is a strange debate kind of talk maybe if you were to ask me five years ago seven years ago hey Prime what do you think on the functional versus non-functional debate I would probably take I'd probably have some stupid ass take right this was probably during the height maybe if you went eight years ago my height of loving rxjs I'd been like reactive [ __ ] stupid great right but I really don't even know what functional programming is at that point still don't even really know what it is I you know I'm real I'm just gonna be straight up here procedural programming is greater than everything else my stance is not that I hate functional programming in love or vice versa but rather but I think of each of these approaches as tools rather than things to go to war about so so I'm not even so this whole idea of saying that a language Paradigm is a tool is an interesting take to begin with right uh because is it a tool or is one objectively better than the other because they're both they're both an equalizer if you will they both simply take a problem and give you a way to solve things so it'd be kind of silly to say that it's just it's just a tool when unless if there's like specific problems that lend itself better to one than the other oh hold on one second my wife brought me yerba mate and this shot full of do you see that that's you know what that is olive oil and what else she doesn't want to say what else is in here my guess is anabolic steroids ah stream oh you hand it to me oh my mouth is burning all right now that we got those Anastasia anabolic steroids I'm ready all right here we go let's go I'm checked all right well oh the arguments for and against our own FP okay I like the framing oh oh I think this is too loud I think that's way too loudly continuous delivery welcome to my channel and if you haven't been here before please do hit subscribe and if you enjoy the content today hit like as well there is no always best or FP is best for me there are times when functional programming is the best choice for some things and times when object orientation is best for others by the way I've never liked the term object orientation it's not a real term object oriented but uh and people said to do that was like the most common phrase I hear all the time object orientation there's no there's no orientation okay that's the wrong word um uh you know that's that's speaking about the positioning of items relative to others versus oriented is like the uh that something is leaning towards or going towards it uh anyways uh uh agree with this take so far okay maybe we agree with that my guess is that there are some problems that are just naturally easier for functional programming and there's some problems that are naturally easier for oh though I'm not sure yet most of the systems that I can remember building had some aspects of both approaches despite the fact that they can't still think of myself as primarily you know her programmer this is not because of language support but because oo ideas or functional ideas made most sense in the context of the code that we were writing at that time is rust a functional programming language or is it a object-oriented programming language if you don't have the word inherits but you do have interfaces both I like whatever rust is multi-paradigm because you've got like this functional kind of feel to it but you can also in you know it is adding methods considered functional programming or is that just simply a feature of the language and it's neither functional nor object oriented I can't really tell this is the part of the definitions that I always get confused on really you think that adding okay so adding functions to a struct is object oriented it like at what point does your orientation become objective like what what's where's the line I guess maybe we should make sure we all agree on that what's the line to me is that that's more procedural right um Ampersand self would be the the line message passing oh we can't talk about message passing again okay new new new um my man said objective objective orientation programming I was another programmer in C for a long time and some of my C code was passing rain pointers to functions that I could call polymorphically um and using immutable data structures so my C code was both oo and functional so again is having a function in which you can use polymorphically is that oh oh I think that that's one thing that I think we all really struggle on is the definition a clear definition of oh does anyone have like a link or something that makes a clear objective definition that we could potentially agree on because I feel like this is going to be a very hard thing to watch without that you know what I mean foreign much further in this let me just thank our sponsors we're extremely fortunate to be sponsored by equal experts trisentis transfig and Roost all of these companies offer products and services that are well aligned with the topics that we discuss on this channel every week so if you're looking for excellence in continuous delivery and software engineering then click on the links in the description below to check them out difference between ronfp is one of those debates though that seems to polarize people we can end up trying to score points in an argument rather than just shedding much light if we're not careful the first thing to say may be obvious but general purpose programming languages are general purpose in that you can write any system in any language there is nothing that you can do in an oo language that you can't do in a functional language and vice versa that's really what yeah I guess if we're talking about like in the end if we're talking about if we're talking about like the problem the end state right treating the program as a black box then yes this is correct but I mean I think back to like my Java 1.5 days I you couldn't do curing it's just like it's a concept unavailable in that language right they don't even have closures so it was like you could not do it I mean you could do something maybe like it with some sort of weird decorator pattern and try to like wrap that crap on top and on top and on top and on top maybe uh but you couldn't really the rest of it didn't quite you know there was no transferable concept between the two but I assume right there's a difference between a general purpose language and a domain-specific language domain-specific languages have by design a narrower focus on whatever it is that their domain is for example SQL is a good example of a DSL and it's great at finding a collection of Records in a set but it'd be a rather poor choice for writing Space Invaders this doesn't mean that every general purpose you should never say it's a rather poor choice to write Space Invaders I all of a sudden believe that we will be seeing SQL Space Invaders like for whatever reason when you announce something to the world that it can be done squeal gets done right it just it it just happens it just happens challenge accepted I know people just write these dumb things I mean right now we're writing the Chad stack for this exact reason he's always an equally good choice for any problem but it does mean that any general purpose language could be used to solve any problem in computer science this is the idea of curing completeness which describes the universality of computation it may be a bad idea to write an operating system in Python but we could so while it may be easier to write immutable code and plus functions as arguments in Haskell we can write code that has the same effect in C Java or any other general purpose language too well it may be more difficult to write code with side effects enclosure or half score we can still do that if we try hard enough so the real difference between these different paradigms is not that they what they allow us to do but how easy they make it to do the things that we want to do it's an interesting point in what she's trying to make which is yeah he's he's coming from it from a practical sense I guess the first thing I always think of which is these type of paradigms strongly dictate how you structure your code and also the performance of your code can be very much so dictated by the language you're using oh interesting about syntax more than capability but syntax matters it can change how we think about the problem that we're trying to solve different languages so syntax okay so this isn't fair per se it's not syntax that really changes how we do it it's the semantics of it so the semantic analyzer the back end to a compiler right like what it allows you to do because I mean theoretically is there any difference between declaring a uh trait in Rust and an interface in typescript no I mean syntax wise there's some various lettering differences and you can use say uh semicolons versus commas but semantically they mean very very different things and what you can do with them semantically are very very different and I think that's like the kicker uh that makes something better or worse is what is the semantics of it all in different paradigms like some ideas easy to express that's it really let's look at a really simple example a popular idea from functional program is the idea of mapping as in map and reduce in this context the map is a higher order function that means apply some function to each element in a collection this is which one do you like out of these tail press one in the chat if you like the top one press two in the chat if you like the bottom one one two one two one two three uh real talk I I I I like this one better than that one this one just feels like you're being a tryhard you just try Harding so hard to do this one it's often seen as one of the preferred ways to process one way in which map is deemed to be better is in terms of performance now the real answer to whether Maps process lists faster than Loops is it depends what did I just hear did I just hear something about maps and Loops being faster than one versus the other I mean shouldn't they really be the ex how how would they be any different when compiled like how would this be any different than that is like two Loops no because it's a stream so I assume a stream is going to be a pull bottle so for each is a pull model so this would be an iterator so this would be uh yeah yeah so this isn't I assume this is effectively a pull model iterator and so you're like you're pulling each value so the stream would emit one value you'd map it over then you'd print it out then you'd pull a value map it stream you know for each it uh it's not doing two Loops that's JavaScript see with JavaScript you do two Loops there depends on a lot of things one of the common advantages cited for functional programming is that it makes concurrency easier this is true writing immutable pure functions means that we can automatically parallelize them but why is that a good idea the naive assumption is that parallelizing like this means that we'll get the results faster but this is almost never the case if you measure it the problem here is that concurrency is fine okay so what just he said right then and there that is an extremely difficult statement to qualify saying that parallel you know we think parallelism will make something faster but it I believe he said something in this in the in the along lines of in most cases it doesn't let me just pull that back up just to make sure I'm not putting words on a lot of things one of the common advantages means that we can automatically parallelize them but why is that a good idea the naive assumption is that parallelizing like this means that we'll get the results faster but this is almost never the case if you may so almost never the case that's kind of a bold statement it's a pretty dang bold statement to make that it's almost never the case I think the more appropriate term would be is the parallelization of code and the efforts around it any mutexes any things that you have to add is the overhead of that outweighing the paralyzation of itself most problems you can do is you can like break up an array to process right so you just turn it into a paralleled algorithm and that's like way faster I think it just totally depends like that's like a problem domain thing this is it's a very bold statement to say that it almost never matters I would say that it almost always matters but you may not get the bang for your buck right you may get like a 10 increase everyone uses uh concurrency and parallelism interchangeably and they shouldn't concurrency and parallelism aren't the same thing parallelism means two pieces of code are executing at the same time concurrency is more like the interweaving of many tasks right and people kind of goof that up and so if you make five requests out to uh a server you can make them concurrently it doesn't mean you're processing the incoming responses in parallel you're processing them one at a time they just happen to be all running at the same time that's kind of like the general one that people goof up when they say parallel versus concurrent accurate the problem here is that concurrency is fine but it only improves performance when we don't need to join the results back together again as soon results the costs of locks semaphores cache misses and even the most efficient mechanism of all to manage that kind of concurrent join compare and swap operations dominates performance it's not true at all it's not true at all like you could get so many more things out of it it's just it depends on what you mean by joining and all this stuff again this again these these blanket statements are extremely hard to prove I would just take this section as parallelism is hard and if you're gonna do it learn how to be good at it and learn also how to measure comparing swap is often hundreds of times slower than a single thread for example so you need 100 threads to get the same performance as a single thread and then your concurrency problems would be worse so map can be great for splitting problems into parallel processes but will always be much slower if you need to be join the data again to look at it again careful saying words such as these I don't know whenever someone says it's 100x slower therefore you'll need a hundred more again careful hard you know when it comes to Performance my general rule of thumb is that you should it's the same thing as when people ask me how to like measure a task I say hey this task is going to take me days weeks months years and because I'm not giving anything specific I'm just giving you a range so if someone says this thing is faster hey this thing can be a lot faster this thing can be a lot slower I'll just say yeah it's like it could be faster it's like an order of magnitude faster right like I just it's either like fast as [ __ ] or probably faster or somewhat equal right like I don't give I don't you know don't ever give precise wording because you can be proven wrong in so many different edge cases so if you don't get any performance what are the other benefits is the solution simpler or easier to read I think this is a matter of taste but I confess I don't really care very much I see no real advantage that's my representation here as an old school programmer I'd probably prefer the explicit nature of the loops a little bit but it really doesn't really make that much difference to me the verbose nature of java in this example certainly doesn't show the map in its best light here as a result of that I thought I'd write it in Python instead and I have to show you this little Quirk because it's funny you can't call print from a Lambda in Python so you end up doing this instead which is certainly worse than the loop more technically though can't call print from a Lambda I don't do enough python but that's funny right that's kind of funny functional program is a no progress program is talk about the value of different ideas each picked to show off the advantages of their preferred approach usually hello programmers talk about the value of modeling the problem I value the high modeling the problem holy cow again when someone Casey and I talked about this these white board programmers modeling problems to hell with that it's always [ __ ] it's almost always universally [ __ ] I'd say the only time that it's really useful to model your own like problems ahead of time like this and to try to guess how your shapes and everything should be uh really always comes down to you kind of learning how to like program well and I there there just comes this point where that exercise is futile because one you'll never know all the conditions and two requirements change and so any amount of time spent other than really high level uh high-level whiteboard stuff doesn't make any sense uh proof of concept faster than whiteboard yeah most people you should be able to proof of concept faster than proof of concept learning from it and building the final product will always be faster than whiteboarding building it off the Whiteboard discovering why you're wrong rebuilding it re-going back to the Whiteboard to fix your problems and then building the final product uh uml diagrams are full of [ __ ] 100 100 anyone that tells you otherwise I would be very careful digesting their opinion take a moment and really I mean you can challenge this okay I am not the end-all of of programmers I could be wrong but currently that is [ __ ] okay hard [ __ ] okay level navigability of the problem that I get from oh oh that's true but this model isn't telling you the province of object orientation there's a good presentation from Marco orientation there it is a functional approach a domain-driven design that I particularly enjoyed I liked Marco's idea that the core domain of the system is functional and the i o you know I do like his idea uh but these spaces right here made me completely uh discredit everything he has to say uh because I am a nitpicky son of a [ __ ] uh right there you know when I see you put little spaces in between your arguments I just immediately go you know I just can't uh can't trust anything you gotta say the edges is always not because it has side effects after I've stored something in a file or a database which is shared mutable State I really want the state to have changed this is an interesting insight and certainly based on relationship to how our usually Design Systems even though as I said before I think of my Approach as more object-oriented than functional definitions of oo usually include abstraction which allows us to hide unnecessary details inherit I don't like that word okay I'm a 1D programmer I like one level of abstraction anytime you're working with an abstraction of abstractions it becomes this Insanity to refactor like the moment you need to change something you have to change so many fundamental assumptions wow that's not even assumptions about what you've done and it just like blows things up I find that abstractions though they look nice in their end product like you know you tell me tell me this does not feel good when you come up with an abstraction that when you write it out in like its final line it's like one line of code and you're like dot do that dot done that boom look at how good I am you know you're feeling so smooth and then somebody comes along it's like uh I need to add one and you're just like my life I hate myself and I hate everything here and I'm gonna quit my job right like it's just like you somehow ruin your life over like the simplest request because you think you have something great and then all of a sudden you're completely wrong because your abstraction just slightly changes and now you're refactoring an abstraction that's built on an abstraction that's built on an abstraction in your whole life crumbles hate it since defining one type of thing in terms of another polymorphism being able to access things of different types through the same interface and encapsulation which allows us to hide polymorphism isn't just an oh oh principle right I mean polymorphism in some sense exists in functional right I mean isn't that just a trait at this point you're just treating an object with a with the ability to you know you have X different types but they all have a singular way in which you can access something about it is that really you know polymorphism is kind of like everything yeah okay because people use this term sometimes like as if it's an oo specific technique it's just like well just because some got a function on it don't don't mean it baby an interesting detail I think the most functional problems all of these are good things encapsulation is also not really a specifically oo idea it's just making it so that there's some data that's un like grabbable or some State that's captured in something right even like just a plain old struct that has some private members and some functions I mean is that oo or is that just encapsulation you know again these terms are very vague and they're very hard for me to understand in fact all of these are principles that also underping functional programming it's just that we describe those things in somewhat different terms there we go functional programmers talk about declarative programming which is really a form of abstraction and information hiding and the use of types which is based on the idea of polymorphism inheritance though is tricky because while it is clearly true that it has some strong benefits it's also often been misused and can have some serious I'd say that your argument for inheritance being clearly good really comes down to like what I can think of right now I still have this just one use case that I think it's good and that's it and I know there's other ones like it but it's a very rare problem set uh yeah composition's not even on here um anyways the only time I can think oh oh is really really or The Inheritance specifically is really good is when you have a method that's directly tied to a property that's needed but you don't want to implement or state that property so I can think about right away I think something that's really great here hold on I know where this is Cobalt by look at that Cobalt by the way you know what I'm talking about um I uh me personally do I have any something that ends with TS do I have anything there you go I'll go to this guy uh something that really makes me happy I think in general is uh extends event emitter right it's just one of those things that I find to be a fine abstraction for oo and I'm not particularly sure how you do this in rust without say a a macro right so if you're using a macro it kind of sucks to do you know I'm not like loving the macro approach here for the specific thing and so this is like one of those few items that I'm fine with being here because then you can just do that blah blah blah and now my rectangle has a DOT on and uh I mean no a trait I mean traits only work you can only have default implementations on a trait if the thing again event emitter requires a property to be present it requires something so you'd have to make a trait and then a blanket implementation off like off of a couple traits then you could do it but that would require you to still Implement a trait per type you know what I mean I've never saw the diamond problem in a real code base if you haven't been programming long enough Sun drawbacks if you create a virtual window inheritance on your display baby it's your inheritance that you can resize or click it object orientation was the technical it's not technically true step that really liberated code sharing and it's no surprise that o and the GUI came from the same place Xerox Park it's pronounced GUI okay it's not pronounced GUI okay we all call it GUI everyone knows it I know it you know it the GUI is deeply an object-oriented inspired idea when non-o programmers poke fun at oh though they're often poking fun primarily inheritance that's because you can make horrible misses with inheritance to the extent that people who prefer simple binary answers to things will often say inheritance is bad of course inheritance isn't bad but bad inheritance I'd say inheritance generally is bad I'm so confident in that we're gonna go on Twitter where people are gonna get angry inheritance inherit enhance enhance is generally bad to wait send now suck it I don't even know what Jack Ford said but I'm just gonna like it because that's the person that I am okay that's who I am he certainly bad the big mistake in inheritance and I'd probably say programming in general is not to model the problem that you're trying to solve well enough tactical programming is often at risk that's a no true Scotsman thing right you I mean I guess you could you could use inheritance to model any problem it can totally be done all right I I get it you can solve any problem with inheritance it's not like it's an incapable problem it's just how does it scale is the real question and the fact that you have to just sit down and try to write out on paper your problem regularly to try to understand how to make changes in the system or to be able to model it in general to me just immediately says that there's something fundamentally wrong here because it's not tied directly to programming in the real world which often is messy and way harder and then you have to keep doing this back and forth like I find that when I'm doing a really strong oo inheritance style things I actually am thinking on paper I actually do draw all things because that's the only way for my small P brain to understand the shape and the size whereas when I do it more just like as a series of functions and some strategic objects here and there and maybe some caching for some fast stuff every now and then so some classes here and there then yeah then I I don't need need to model anything else out like I can just blaze through the program and then the spots that suck the spots that are kind of a bit convoluted they usually always start off as a utils folder right it's just like hey here's a bunch of [ __ ] I don't know where to put them start doing that and once I start seeing a pattern or some things that are really needed I'm like you know what like this thing right here I need to move over here and make it a first class citizen because it's just really needed yeah it sucks to refactor but it generally makes it so that I know kind of what I want and how to use it I don't know this whole idea that this whole modeling plan is crazy to me it's a good thing tactical crap for example in Java a set inherits from a vector and properties inherit from hash tables this is tactical crap a set isn't a vector properties are not hash tables this was a lazy choice because it made implementing sets and properties easier but I mean to be completely Fair a set you know you can imagine that it is a vector underneath the hood right that's that's really all a set is it's either an array which you have to double the size of and copy everything over or it's a vector either way it's kind of like the same thing you know you get really are you getting anything out of it I I mean I can understand why they did that I mean I just don't like the whole idea of inheritance just use a vector it is nonsense really I said he's not a vector and results in all sorts of features of sets in Java that make no sense at all what does index of an entry mean for a set yeah why would I ever wish to rehash my properties this isn't the fault of inheritance why do you think you can rehash it properties is there any reason other than it's purely it actually is just purely due to inheritance if that's the case that's just crazy you should just use a vector not inherited from a vector I don't know uh sets are sometimes sets are often I mean sets let's see it I mean a set is typically represented by a some contiguous chunk of memory somewhere and that's usually on the Heap and you put that crap in there by performing a hash set and if there's a collision you may have a linked list or you may have uh quadratic slash linear back off but I think the big thing is now it's all about they can be Beatrice too but I think the big thing is now it's all about doing uh uh linked lists in those spots and we can certainly make poor design choices in any language even functional languages I think that the key decisions in software are outside the technical detail of individual languages largely or programming language paradigms for that matter if you'd like to see what I mean take a look at my training course better software faster it describes what it takes to build high quality software and why that matters there's a link in the description below in Marco's presentation he quotes functional programmers saying functional programming is great because it has immutable data structures a stateless programming model pure functions and no Loops these things make it easier to read I don't really care for immutable data structures I don't I don't think these really offer a huge benefit I think they they do hurt performance if you're having to make a copy to make a change um you know it's not that great for memory just is what it is using about your code they say only most oo languages I can easily make immutable data structures program stateless code create pure functions and avoid Loops if I can you make stateless code in oo can you copy on right going uh yeah I don't know how I feel about some of those things I mean I like I like the idea but I also don't like the idea choose to even before choosing to use the functional features that I've been added to most modern languages these days the real value in a more functional approach to programming as I perceive is really in three areas treating functions as variables immutability and declarative programming functions as variables is a significant step once again you don't need a functional language to do this though I used to do versions of this in assembly C plus plus Java and python but having direct language support certainly makes it nicer to use this allows us to pass one function as an argument to another we can then call that function yeah if you have ever come up to very similar bits the first class like this then this ability to pass a function is an arguments okay so this is something that people say all the time and I think it's just very difficult for people to understand and I think everyone has their own version of this right because people call react a declarative programming language but fundamentally when you start calling like you any of these hooks and things like that you're like you start falling off the declaring nature and you start falling into this procedural business and then you start putting things together I'm going to keep calling it a framework dude it's funny that people say these phrases because you know for calling it a funk for for calling it a declarative programming language I've seen a lot and a lot of um you know ternaries saying which function which type to use and all this feels a little procedural sometimes being smashed into declarative programming variables is a significant step once again you don't need a functional language but having direct language support certainly makes it nicer to use this allows us to pass one function as an argument to another we can then call that function if you have ever come across two very similar bits of code but that are just slightly different like this then this ability to patch a function as an argument is a really nice tool to use to simplify and generalize the code this is also the idea behind things like event handlers oh hang on I know idea immutability is an important tool but it's never the only tool is event handling a idea it is how the hell does a Berkeley socket work then if only there was some sort of event that happened and then you had to do something with that gosh if only there was something out there that was some sort of signal perhaps from somewhere to let you know that something else was ready hmm yeah you're probably right it's probably an o-o concept definitely no concept has nothing to do with anything else you're right sorry things because otherwise Berkeley your socket this is one reason why I liked Marco's points always has side effects because if he didn't your code isn't doing anything I agree thank you how do Hardware interrupts work I don't know kind of sounds like an event you haven't interrupt that exists with this hmm can I hand you a function okay that's not a that's not a that's not an event handler that's an interrupt Handler they're different see that one's imperative programming but when you called an event handler it's only oop shut up but it's also never the whole answer at least in the purest sense of no mutable State at the level of whole systems there are very few Corner cases where genuinely stateless systems make any sense and then yeah context where code is acting as some kind of pipe that changes the data in some way this idea is extremely valuable as part of a system a simplifying step but in whole systems there's always State changing somewhere so the idea the tool I'm writing right now is this it's just it's literally just something that gets data from up to six separate data sources puts them together does some calculations on top of it deep log inspections and shits out answers that's all it does right and it's stateless there is no State uh you can mock the data meaning that I can make it so that when it tries to do these calls out to these different data sources I can pre-provide values for those such that it's none the wiser but nonetheless it is just a stateless data processing tool a lot of Dev tools tend to be more stateless processing tools you know what I mean they just take in stuff and take out stuff nearest stateless systems is never an absolute where you deal with the state changes rather than eliminating them all together minimizing side effects is great in the right place and has been with hindsight an important aspect of my own approach to object-oriented design for a very long time as Michael feathers said to me in our chat a few months ago object-oriented programming looks a lot like functional program when it's done right but whether you are sometimes I feel like I haven't had enough functional programming knowledge to really understand that last statement because when someone says when it's done right it will look like functional programming is that true I don't know I don't know how to qualify that statement I think I'm just stupid sometimes because I don't know how to argue against that statement because I don't know because I've never been able to make it into functional programming therefore my self doesn't see how that's possible I don't know where he's going developing an object-oriented fashion or functional there are times when you want side effects we've already talked about the obvious times when you're doing I O of some kind if you want to write it to a file the state that the file is in matters sure you can clone any mutable snapshots of a picture of that file but immediately you do that it is at least potentially out of date because the real file on the disk is shared maybe someone else changed the file or the operating system deleted it while you're in the process of dealing with your copy now your immutable snapshot copy of the files run the changing the file I've never ran into that problem you know what I mean you know what I mean I've never really had this problem of this of what he's talking about that I mean I think a better example is databases right you try to read something from a database you display it but by the time you display it happens all the time on Twitter someone's deleted the Tweet you're trying to like and it's like sorry that that tweet has been deleted I mean I get that that makes sense um is that a problem I don't know isn't that just the definition of a chaotic system by lowering the database is always a side effect or another reason too it's a side effect of working with computers that forget things when we turn them off if I change the balance in my account the fact that I need to store that change somewhere isn't my goal the change in the balance is my goal so the storage is just a side effect functional programming languages of course support this kind of thing and some supports ideas like monads that allow us to break the pure functions rule of functional programming by adding side effects but I'd argue that this is only a special case of a more general idea one of my favorites architectural approaches is to build message-based reactive systems these things are like state for actors communicating only via asynchronous messages one reason that I like these systems quite so much is that they allow me to separate The Accidental complexity and the essential complexity in my system is this a subtle support for rxjs signals do we have some other hot buzzwords that we can throw in here hooks is this hooks let's imagine I have a bank account of some kind and I want to credit it in my favorite actor-based approach I may send a credit message with the value that I want to add my infrastructure will manage the i o it will save the message on its way to my service and only if the message is safely stored or clustered or whatever else will it forward it then to my service at this point my service will update the value of the account that it holds to it to create a new total balance is this mutable state or not is this oo or not I'd say that this is a very oh way of thinking and working my actors embody Rich stateful domain models of them I would say this is neither a functional or oo this is just modeling a complex system right these are each individual pieces of a larger complex system that all fit together in there whatever right I mean you could imagine this is some sort of SNS system going on here in Amazon and you know or sqs I always forget which ones which at this point I haven't done it so long and it's just like a series of [ __ ] that happens I don't know how this is either or right is this is just a thing it's a state machine yeah it's sqs unfortunately sqs State machine International systems and The Changing State an important one that must be represented somewhere is clearly expressed and easy to understand and can't happen without the side hell yeah you see all those numbers going up okay I want to know that my total is even after a crash or a restart if I want to know what the balance is for my account I can query with this stake for copy but I can also discard this copy and recreate it into exactly the same state as before by replaying the message of the messages that I stored but I can also discard this copy and recreate it in exactly the same state as before by replaying the message that I stored earlier I can also it's into exactly the same state as before by replaying the message of the messages that I stored but I can also discard this copy and recreate it in exactly the same state as before by replaying the message that I stored earlier so once again is this state here mutable or not actually I think it's kind of both my point here is not to sing the Praises of reactive systems well maybe just a bit but to point out that the line between object orientation and functional programming and maybe even actors is all a bit more blurry than the culture wars would sometimes suggest yes it is sensible to me it's very hard for me to follow this example being an overarching like he's talking about systems interacting with other systems here I am unsure if at any point you can say you can dictate functional or object orienting oh dang it now he got me going with this whole orientation business you can't say it's either or because you're only looking at like you know the HTML of it or the HTTP of it a series of transactions that are happening between many systems right there's just a protocol between them whatever the protocol is now this could be all in the same system this could be all one language one system or it could be something else dude I know I'm getting orientationed but is there really a big difference between having a function that takes two arguments one of them supplied by another function that defines its value and an object with a private member variable that is used instead of the function supplied variable sure the oocode here is more verbose but that's a different question really all that's really going on here is how we decide to represent the sequencing of the function calls uh hold on let's go back and look at this code for a quick second I mean I see what he's trying to say here uh this whole idea of just creating something new to calculate this one thing that just seems like crazy talk right like why would you do this versus that it makes no sense you just use a function right why would you create an object just to hand it in a variable and then a second variable to get the result out to do the result right it makes no sense this this is nonsensical code right you're adding just so much complexity for no apparent reason it's just a function just throw that crap on the stack and add some values or whatever you're doing sure the other code here is more verbose but that's a different question really all that's really going on here is how we decide to represent the sequencing of the function calls we could debate which one's easier to read and there are arguments on both sides but I do believe that if you're up I don't think there's an argument on the other side for that one like it had to see a more complete example to understand if there's an argument I'd minimize typing we're already looking in the wrong place there is an awful lot of typing in assembler programs after all optimizing for thinking is much more important my point is not to rubbish functional programming I uh you know as a programmer people always say this take which is like oh I spend most of my time thinking what are you doing in your life I spend most my time trying to get my thoughts out of my head into the editor that is by far the greatest majority of time I spend every every week is getting what's up in here through here my point is that I think that the debate I got to meet somebody that spends more time just thinking like what the hell are you thinking about when I hear that I think of someone who doesn't really know how programming works and I don't mean that in like a pejorative sense right like you're just not familiar with the concept say of some good async programming and so you sit there and like look at your program trying to suss out why it's not working versus once you've gotten past that point and you just understand how programming works you just make fewer those types of bugs and you spend more time just like trying to get what's in here through here and I I really do hope yeah like if you're making a fine tuning to a legacy system then yeah you spend most of your time just trying to understand the system and I would agree that that's like a completely different function but once they're implementing something once you've understood the system you fall back into this I just gotta get what's in here into here but you know Legacy systems that is a large part of a lot of people's lives so maybe yeah that's different I work in mostly Green Field stuff and I so I think that that's like a huge problem for me it's because due to my working in mostly Green Field I don't have like a strong understanding of what working in a really Legacy system is like anymore but I get I guess I guess it's worked in a 12 year old C plus application and I built my own uh sync player to be able to uh effectively take in sound and video and pretend like it's playing so we could do some performance analysis of our playing tools and so I had to build out that and that was all just like me typing in a completely Legacy system and adding stuff and I don't know it just seemed it didn't I wasn't Bound by thinking there was like a small part that was me learning what the system needs what the values were how to get them in place the expected API then the rest of the time was me make it the thing which was almost purely abounded me being too stupid thing going like I gotta tell you okay I'm doing this I'm doing this I'm doing this and I gotta get this thing out get this thing out get this thing out and then there were some times where I was just like you know the person I said earlier the majority the non-projorative thing I don't understand C plus plus that well so I was using some things wrong and I had to re-understand why they were wrong right that's fun well sound and video is fun long you know you know yeah I I am very I would love the day where I could do a lot of uh the day I can do faster input I'm willing to do it it's it's still a reason why I don't think AI is there because I'm massively faster than AI massively faster than AI because the problem about AI is what it produces other than boilerplate is categorically wrong every time so it's like I have to go fast to massively slow down to find out all the problems where everything's at and then I can speed up really quick and then have to stop and like do this thing again trying to figure out what the hell's happened whereas if I just build it myself I can just be like and I just overall am significantly faster that function will probably be good that's why I like logical boilers sometimes when functional programming is more terse and ters can be good but it can also be bad ultimately depending on how easy the code is to read straw man straw man dumb straw man that's just a dumb straw man I can Minify a code and say look at this this is terse this see not all terse is good that's just a straw man argument don't make that argument you can make much better arguments right uh you can make much much better arguments than that right really really well written rust feels very confusing to me uh when I was first starting out because I didn't understand a lot of the concepts it was very very terse and I couldn't quite grasp all the things that were happening that on the other hand totally get that right just because something's terse does not necessarily mean it's good but don't use minified code as an example of of terse the last time you want to do is that functional program is often soft for a computer the real value of functional programming is the advantage of declarative over imperative programming I've spoken about this before there are certainly significant advantages to expressing some ideas declaratively my approach to test driven development is always to always aim to declare in my tests what I want that's a good take right there that's an extremely good take if you're doing a test and you're doing logic 95 of the time I'll say you're wrong if you cannot declaratively State what you are doing ah you're probably doing it wrong honestly you're probably doing it wrong because it once you start putting in heavy amounts of logic you start needing to test your tests and once you get to that point you're done okay yeah the system to do without it why are you guys still talking about her she doesn't have to say how he does it this means that my tests are a lot more durable to change than Tesla attempt to assert the implementation detail in the code this is the same idea as declarative programming if we can clearly Express the outcome that we'd like to achieve without worrying about how the outcome is achieved then great I see lots of an example of this in examples of functional code but to be honest it's less obvious in people's real code as far as I can see to be fair my exposure to reading other people's functional code is somewhat limited I don't read lots of it so this may be down to the limits of my experience but you should state that up front because the problem is you made this whole 20-minute case about why they're the same and then you kind of just let the you kind of said the quiet part out loud which is you don't have a lot of experience on one side like I don't have a lot of experience on one side I'm definitely not like a hugely functional person my most functional language is is rust and that's not like I wouldn't put that as like I wouldn't categorize it as like functional functional but it's it's it has a lot of functional Concepts but still that doesn't mean I know a lot about it that's why I can't tell you a well-written oo project can it end the same as a functional project I don't know I don't even know if this is the case if the levels of abstraction that functional languages give to us are genuinely as advantageous as functional programs tell us that they are then shouldn't functional Pro projects prove to be a lot faster to develop and produce fewer bugs than non-functional again that's you know that's a very hard statement to measure once again so the problem with this statement is that throughout the 90s 2000s 2000 really all the way up to like 2020 it's been largely dominated by a singular thing which is like largely oo styled languages and so we don't have like a huge amount of data on is functional better I I don't know if it's better and you know I like to think personally that rust ultimately is better for developing even long term I think it makes a much better programming language to develop on than say typescript but am I right I don't have like a huge amount of experience yet to really like say that you know better so how I think of better is in six months what is the speed of features in two years what is the speed of features to me if you cannot make features in your programs then that is really what is better or worse you know ultimately that's that's for me that's like the biggest that's like the biggest thing sure like performance is obviously very very important it's a Cornerstone of any good piece of software but if you for a long running project a project that continually has to change like Twitter like anything making a change if that takes exponentially longer then something is wrong right like when you go when you go on Twitter when you go on Twitter over here and you jump in here let me hear Let me just find this screenshot I have dang it here let me just jump in here I have a screenshot right here hey look it's me um look at this this is the source code for a singular for just just this tweet that's right here linked that's the divs and video element for just the Tweet itself not for any comments or anything else just the tweet like that's an insane amount of stuff like try to make a change to that is that a brittle system or is that an easy system it's a brittle ass system right like when you look at this oh gosh I'm in I'm in the Firefox hey bro is that Firefox dude let me just zoom in hey man let me just zoom in here let's go like this let's do it again inspect right so when you look at this you're like oh gosh like it can just keep on going like you can just look at look at all that look at all that that's like that's a lot for a div can we all agree that that's probably a lot for a div or oh my goodness dude I I hate Firefox don't become emotionally angry you're gonna you're gonna make it trust me you're gonna make it I mean look at this thing it still is going like starting right here look at how many divs there are look at that for this thing just this one little thing just this one little thing right here uh here uh what is it here let's go over here and go like this um what is it it's HTML pretty uh protify HTML it's just an effing image it's just an effing image and this is what we got for an image like that's a lot of that's a lot of stuff to generate it's just a lot div slash a div ending div image all right that's a lot of it's a lot of stuff man hey man that's like a lot of stuff hey man that's like your opinion no it's just a lot of stuff man this is the claim that functional programmers sometimes make but I have looked and I don't find much evidence to support this claim functional programming does appear to produce fewer bugs but the research that I've read says that this is at or close to the level of statistical noise we're talking about one percent fewer bug fix commits than imperative languages when measured by comparing the I don't like research papers into these kind of things because there's too many factors right the thing is is okay so at Netflix if you want to get a feature through and you think it can change retention and do you think that you've developed something significantly better it takes Millions upon millions of people to test that that's actually true and the reason being is that the confounding factors even on a singular change is insane now let's take something like development where you have various languages experience with the languages complexity of the problems they're solving complexity of the systems that are required to solve management management plays a huge role into all of that kind of stuff right like just think about how many confounding factors exist in trying to solve this thing this type of research is what I would call as uh academic masturbation it's it's useless ratio of commits that that are for new things versus commits that are intended to fix bugs to put this into context the data for unit testing says that you get somewhere around 58 reduction in production defects overall though measured in a completely different way so it may not be fair for me to make this comparison but it's never fair to make those comparisons okay no I don't know if unit testing gives you anything it could give you a lot it could give you 90 it could give you zero percent again girl the difference if any inequality of the code produced by functional programming versus object-oriented program languages seems to be tiny I think they're both functional programming and object orientation are valuable tools but I also think that there are some extravagant claims made for functional programming in particular that to me at least don't seem to stand up to scrutiny my conclusion is that I don't think you gave us a solid scrutinizing take here you know relying on Research I think is just too fraught with confounding factors saying that you didn't have a ton of experience doing it I would take somebody's opinion like if pick came in here where is Piccadilly at if Piccadilly's in here and he says hey I really think these things about it I'd actually take his word a little bit higher because he's been doing Haskell for years and he's done other languages as well like he at least has enough experience somewhere to kind of give somewhat of awaiting like I need to see someone with a lot of experience building a lot of applications right has glow and it pays to understand both functional programming and object-oriented programming the idea that functional program is a Step Beyond object orientation in the evolution of programming languages seems just a complete misinterpretation of the history and of what's going on in reality our own FP are both valuable to also doing complex systems use them in the right context and each will help you to build better systems but neither is the deciding factor thank you very much for watching and if you enjoy my stuff please do consider supporting our work on this channel by joining our patreon community there's a link in the description below thank you [Music] sound Equalization please um I did not choose this photo I kind of feel like I gotta go yo what is this photo I did like a little I did like a little monocle I need one of those uh Gaucho man mustaches going on here I needed like a top hat this is not me it's not me I could tell you that right now okay I learned nothing in that video yeah okay so take away from the video is that it didn't the title did not promise what it delivered meaning I didn't learn when to use functional versus oop I really didn't learn the difference between the two I didn't I'm coming away more confused than I was in General on that topic because I really do want to understand when I I do want more experience in functional programming because I want to actually have like a really strong opinion about it because right now I'm just like a rust Andy right oh what did you build hey build it in Rust oh what's that over there did you try it with rust right like maybe you know maybe I need a little bit more you know what I mean maybe I need a little bit more but I feel like I don't and I don't know what I'm doing okay hey the name is the primogen