FP vs OOP: Choose Two by Brian Goetz

all right thank you so this talk is about how we approach the way we learn to be better programmers and so it's about the fictitious two divisions that we invent and how I think they harm the progress of our industry so in this talk I'm going to talk about one particular fictitious division the tension between object orientation and functional programming and I'm going to make an argument for why and how we can do better so functional programming is cool and powerful and after a long time in the shadows is starting to peek into the mainstream as venkata us yesterday you know functional programming has been around for a lot longer than most of us but I still believe that mainstream wide spectrum languages like you know Java or C sharp have even more to offer us in using functional techniques to confront real-world problems than do purely functional languages and there's more leverage I think in in mainstream languages as well because as the famous bank robber Willie Sutton said when they asked him well why do you rob banks he said well that's where the money is and mainstream languages are where the programmers are so if we want people to be more effective programmers that's the place to start now some people might say that I am not qualified to give this talk because Java is a object-oriented language now I'm a Java guy and well that may be true but developers often have strong opinions on things that they don't know anything about so I asked maybe you'll give me a little bit of indulgence to do the same tonight so the first topic I'll start right in with something I know nothing about and that is sports so in particular let's talk about sports rivalries so in America the biggest sports rivalry is that between the New York Yankees and the Boston Red Sox and sports rivalries are an important part of sports every team needs a rival team and the fans they love their team but but they love to hate the other team even more and so you know if you think about like a typical New York Yankees fan and a typical Boston Red Sox fan they actually have quite a lot in common so let's put this in in modeling terms that we understand you know they're both people so they share the behaviors that people share they know they drink the air and such and they're both sports fans so they share all the behaviors that sports fans do like doing the wave and spouting statistical gibberish and all of that and they they certainly both hate the other guy but here's the funny part from the outside they're really the same guy aren't they and you know the the geek Canon has a lot to say about this common pattern as well where we get so focused on our differences that we miss the overwhelming commonality that we have so for example one of the original Star Trek episodes the crew encounters a species of humanoids that are half black and half white and some are black on one side and white on the other and some are white on one side and black on the other and of course they hate each other and they're locked in a bitter Civil War and there's only two of these guys left and of course all they can think about is killing each other and like the sports fans from the outside these guys are the same guy but all they could see is how they were complete opposites now this was not a very so subtle social message in this in this TV show but it's a very common pattern that we play out every day so imagine what we look like to our wives or girlfriends or husbands or boyfriends when we're arguing over spaces and tabs or text editors and from the outside the the spaces advocate and the tabs advocate you know they're indistinguishable they're just you know opinionated geeks with strong opinions and yet they're ready to kill each other not only over code but over a completely non-functional aspect of coding and meanwhile the normal person who's observing this interaction thinks you know if they could just get over their stupid argument and work together then maybe my car would be able to talk to my phone so another topic that I don't know anything about that I'm going to talk about is cultural anthropology so going back to the sports fan analogy when the team wins what do the fans say they say we won well they didn't have very much to do with the winning did they but this comes from our natural wiring to form tribes and tribal identity has a sensible evolutionary basis it was a natural defense against starvation or being eaten by Tigers and that's a good thing there aren't very many Tigers roaming the streets these days but you know our brains take a while to catch up to the the new reality and you know tribalism isn't a bad thing tribe members they learn from each other they help each other they collaborate and that's all good but it's a short hop from helping the members of my tribe to demonizing the members of the other tribe rather than asking like what could we learn from them and I'm sad to say that we as programmers we're pretty bad at this okay now we're really bad at this we constantly define ourselves and our identities in terms of I'm a Python programmer I'm a c-sharp programmer I'm a functional programmer and then we have unconstructive arguments about why the others are wrong or foolish for preferring their primitive tools and then their tabs and the reality is as programmers we all have so much to learn about building correct robust maintainable secure easy-to-use cost-effective software that we should be ashamed I mean we should certainly not be criticizing each other they're tabs or VI or static types or objects or actors the user doesn't really care whether the code was written in Haskell or in visual COBOL they just want their phone to talk to their car and that's kind of a reasonable thing for them to want so the tribal division you know I'm focusing on today is functional programming versus object-oriented programming but it could just as easily be static versus dynamic typing or managed versus native or any of the other fictitious divisions that we invent so these days functional programming is popular there are quite a few talks on functional programming here at devoxx which is great and it's you know not surprisingly it's also very popular to criticize object-oriented programming and it's easy to find you know blogs or conference talks about how object orientation has failed to live up to its promises and okay well it's totally true it has failed to live up to his promises but let's be realistic has there ever been a programming technology that has lived up to its promises you know so when writing this talk I watched a whole pile of these videos and they all pretty much sang the same song and that song was you know taking examples of object-oriented programming done badly or applied to the wrong situation and then they jumped from you know it didn't work here - this must somehow be fundamentally flawed and they certainly had plenty of material to work from I mean there are plenty of examples of object-oriented programming done badly but that doesn't mean we don't have anything to learn from it so you know while some of these guys may have a point they're assuming a false dichotomy their arguments rest on if one tribe is right the other tribe must be wrong but object orientation doesn't have to be wrong for functional programming to be right we all have things to learn from both of them and this brings me to the main theme of my talk tonight which is rather than being Python programmers or or C++ programmers or functional programmers we should care more about being better programmers we all have so much to learn we should seek to learn as much as we can from as many programming paradigms as we can and so you know to be better programmers my advice we should all learn classical functional programming we should all learn classical object-oriented programming and then strive to rise above them both and so what does that mean well languages and programming paradigms they're tools and there's no tool that's right for every situation the French writer Emile Chartier once said nothing is more dangerous than an idea when it's the only idea you have if we only have one paradigm we're gonna use it where it doesn't fit we're gonna try to distort the program so it fits our idea a programmer that skilled in multiple paradigms is far more likely to find the right solution to any given problem than one who's only skilled at one paradigm regardless of what language they're using and the right solution might not be pure or pure F P or pure anything and in some sense it almost has to be right that if you look at the you know the the classical definitions of object-oriented programming and functional programming neither is even really complete right I mean pure functional programming has no notion of computational resources like memory or threads or file handles and and pure oo really has no idea of a computation that isn't localized within some entity or component but to solve real problems we're gonna have to use both of these so it's easy to criticize oh oh and some of it is deserved and some of it isn't so object-oriented programming arrived on the scene under tremendously inflated claims and expectations so in the late 80s and may be around by 1990 which is how many people here were not programming in 1990 how many were not born in 1990 okay so this is a story that has has a long set up so by 1990 the hype surrounding object-oriented programming hadn't reached ridiculous proportions it was gonna cure cancer it was gonna bring world peace I mean it was it was really obscene and you know of course nothing can live up to that right but much of the object-oriented code out there today is what I would call Sorcerer's Apprentice objects and in which they take sensible object-oriented principles and then they apply them to their ridiculous extreme so for example encapsulation the capsulation is a powerful tool but you don't need encapsulation at every boundary you might put a heavy lock on your front door but surely you don't need one on the bedroom closet but a lot of OO code treats family members and and unwelcome criminals with the same degree of distrust and you know to make matters worse we often draw the boundaries in our in our systems before we have a clear design leading to the equivalent of maybe having a bank vault or in every closet and maybe one in the middle of the hallway just for a good for a good measure so it's not surprising that that some people feel object orientation is a little cumbersome and that's not really what oo is about but you know it's what comes to mind for a lot of people and I think largely we did this to ourselves right the worst offender here probably is the javabeans coding conventions now what was this designed for this was designed for dynamically discoverable visual components in an interactive editor perfect application for object-oriented programming but you know the cost and benefits of any technique is contextual and the lessons learned in one sphere or at one scale don't necessarily apply everywhere but you know what did they learn Java and 21 days books tell you it told us this is how you should write Java code and so we did write and you know the result kind of ends up being the worst of both worlds right all the ceremonial overhead and all the friction and no actual abstract of value good job but you know when people think they're criticizing oh oh they're really criticizing a sort of cartoon exaggeration of oo the conventions that are right for a graphical component framework might be downright silly for most domain objects but that doesn't mean the technique itself facili but you know it's so it's it's fun to criticize things that are popular and it certainly gets you the synthesis and attention and it can even be therapeutic but my concern is I think this makes us worse programmers because it closes our minds off to what we have to learn from the other tribes so if that's not what classical oo is well what is so let's step back a little bit from the details of c-sharp or Java or more C++ and Alan Kay once said you know I made up the term object-oriented programming and I can tell you I did not have C++ in mind most of the object-oriented languages that we use today they all they all emphasize inheritance but class-based inheritance isn't essential to oh oh it's just one way to get polymorphism similarly static typing is not essential to oo a small talk was dynamically typed the essence of oo is very simple that computation proceeds by objects sending messages to each other and these messages don't have to be statically tie after synchronous or even local you send a message to an object and it does something maybe it performs a side-effect maybe it sends you a message back maybe it sends a message to somebody else and we can get we can get polymorphism from this without class inheritance because the target is free to respond in any way that meets the meets the requirements for that message and whether that polymorphism comes from classes are from prototypes or from you know arrays of function pointers or from nasty stateful logic that's just bookkeeping but object orientation and object oriented languages give us something that's really important that's something that almost all complex systems needs which is dynamic dispatch and oo languages tend to make this easy ok what about state in in an object model state is owned by objects to access an object state you send it a message say you know tell me something about yourself and this brings us to the other major contribution of glass glow which is encapsulation low languages give developers a straightforward way to say only this code can access this state and in the procedural world one of the big impediment Stu program scale you know in the in the you know 70s and 80s was reasoning about program state if all the code in your program could access all the state that in order to reason about the possible states of your system you had to look at all of the code and encapsulation let us turn what was a global analysis into a local analysis and that in turn freed us to build bigger programs without getting mired in complexity and that was a huge contribution so okay what about classical FP if you were to ask people what's the essence of FP the typical answer is gonna be something like you know immutability and pure functions or maybe of pure functions as first-class values or maybe function application by substitution now in reality most functional languages don't actually behave this way all the time and with good reason because stimulating state and IO with monads is very cool but it's not actually how most people want a program and it's nearly impossible to reason about important things like memory utilization in non-strict languages so most functional languages make some practical concession towards the messy real world and they do that by having some kind of direct support for IO or a mutation and they accept the strictness this entails and then we rely on programmer discipline to not use it where you can avoid it so okay quick comparison in oo computation proceeds by objects sending messages to other objects in FP it proceeds by applying functions to values an FP program is really just a big function and functions have a simple role they transform their inputs into outputs a program in OO is actually a little bit more ambitious to sum an executable model of some entity and for any given situation one or both of these models might be useful to us now with respect to state there's actually you know a fair amount of variety and how functional languages look at this you could sort of look at the division you could divide functional languages into the dynamically types and the statically type ones but in general ownership of data is more distributed and you know the degree of mutability is lower so that reduces the risk but in most FP languages especially like the Lisp derived languages data is frequently transparent for anyone to inspect so they don't you don't have the opacity that Oh gives you where data can be you know encapsulated on its own little island where each object is king of its own little island and there are times when this encapsulation is a lifesaver for managing complexity and for security and there times when it gets in the way so as professional programmers we're going to encounter both of these situations and we should know how to tell them apart and and how to deal with each of them so you'll often hear people say you know well in object-oriented languages everything is an object whereas in functional programming everything is it is a function and in fact like every programming style has an obligatory one sentence everything is a summary where everything is an object or an actor or function or a peanut butter sandwich or whatever and such characterizations are pretty useful for like the first five minutes of learning language and after that they tend to be pretty destructive because not only isn't everything an object in reality nothing is an object nothing is a function you know objects and functions and actors they're just mental models for helping us understand our code and you know and understanding our strategy for solving the problem and there's a big risk that we're going to confuse them for actually representing reality so we can choose to model things with objects or actors or functions with varying degrees of fit and fidelity in the hopes of managing the messy complexity of the problem but there's this big leap from use X to model Y to everything as an X and and and that leaf is the unhealthy one everything an object everything is an object is wrong for two reasons the object part and the everything part but you know FP purism today isn't any more attractive than oil purism was back in 1989 now of course we're gonna have to abstract things away from the real world in order to have any chance of solving them with software because the world is so full of messy accidental detail that we have to filter some of the details out in order to be able to think about it but we have to keep our eyes on the goal and the goal is solving a problem in the world not solving the problem in software and to do that well we may need objects and functions and actors and maybe also peanut butter sandwiches it's only a model so it's way too easy for us to make mistake our tools and our paradigms for reality in the real world let's say we have a problem to solve like I don't know I want to make a phone call from my car and for some reason good or bad reasons we decide the easiest way to solve that problem in the world is to turn it into a software problem so now we have to transform our problem into a set of inputs seen by a program and a set of desired outputs that correspond to our goal and then we write a program to turn the inputs into the outputs and hopefully we are done right now there's some process by which we turn this messy real-world problem into a set of abstracted requirements and then we can solve our problem in the more tractable domain of software so let's call this mapping F and we'll call them a traverse mapping F inverse and here's our big mistake our big mistake is we assume that this mapping F is a homomorphism that is it preserves all the interesting structural properties of the the problem space so when we transform it into program space and solve the problem there and transform it back then we're actually solving the problem but the danger of course is structural information can get lost in this transformation and the more of a mismatch there is between our preferred everything is an X and the real problem we're solving the more likely it is we'll end up with something that takes all the requirements on the you know the requirement sheet but doesn't actually solve the problem in the real world and as engineers were much more comfortable working in the well-behaved domain of software rather than the messy real world it's very easy to confuse writing the program with solving the problem in our more arrogant moments we might describe what we do as building abstractions for a living but abstraction is a double-edged sword if you look up abstract in the dictionary you'll find a lot of definitions it could mean reduced to an idealized form which is to say separating away all the confounding details to reveal the essence of something and you know that's like often what we we think about you know when we say well yes we do abstraction for a living this is the kind of abstraction we want to be associated with but there's another meeting difficult to understand that's the kind of abstraction we think about when we look at other people's code but you know even the first one is is kind of suspect different details matter at different times you know when you try to solve real problems and so by necessity the abstractions we use in programming have to sometimes be leaky so what do we use abstractions for we use them to manage complexity we use them to support reuse but just like it's easy to fall in love with our tools it's easy to convince ourselves that abstraction is the goal it's it's the end unto itself but it's not it's just one of the tools that we use to solve problems so we have to continually be willing to revisit whether our abstractions are really serving the user or whether they're merely serving us and remember the user doesn't care about our abstractions what do they want they want their car to talk to their phone so okay I like object-oriented programming and I like functional programming now a lot of people these days say well I've moved on from object-oriented programming to functional programming and for awhile I started to wonder huh okay so all these people are moving on and I still like object-oriented programming so what does that say about me and I didn't like that explanation so I made up another one so my experience of programming is is probably a little bit different than most people's the code that I write is platform libraries core libraries and when you're writing platform libraries you're on the other side of a boundary for most of your users and in fact you're on the other side of a lot of boundaries maintenance boundaries versioning boundaries encapsulation boundaries compilation boundaries compatibility boundaries security boundaries you can't count on your library class as being co-evolved or even Co compiled with their clients or their subclasses because they're in different maintenance domains their compiled by different people at different times in different places you want to hide your internals because you want the freedom to evolve your implementation separately from your API and sometimes you have to do so because you have security constraints that you need to enforce and you know in a dynamically linked platform like like Java we're so used to this we don't even notice right assuming that you've evolved your library in a responsible way you can just drop a new jar on the class path and everything works without recompilation object-oriented languages give us really good tools for defining navigating and defending these boundaries and so oh is that its best when a code base spans boundaries like this the boundary between platform and users is a pretty natural one but even artificial boundaries can help us manage complexity by limiting the required scope of analysis down to a smaller region of code if my clients can bind directly to my data representation then an order reason about a program I have to audit or change the whole whole code base including my clients if my representation is encapsulated then we only have to audit a smaller region of code and so this is obviously a big deal for for security it's but also it's a big deal for correctness mass algorithms get more complicated take an algorithm like concurrent hash map in Java or the the fork/join pool scheduler this is some really tricky code and the representational invariants are really subtle so it's kind of a good thing that clients not only don't have to but can't poke their fingers into the representation now you might be thinking well ok you know you write platformer libraries that's your thing but I'm just writing an application how does all this help me and the benefit here is it's more indirect but it's no less real you know as we evolve evolve Java one of the important considerations that we apply is will this change enable expressive new library idioms because if you make it easy to develop and distribute robust libraries people will have a richer ecosystem of libraries to use which means application developers will have a greater variety of high quality libraries that they can leverage in their code and and this is true not just for applications you know this is true for language implementers as well you know there's lots of languages that run on the JVM and the richness of the Java library ecosystem is in part why languages like Scala or Clojure chose to target the JVM and so think about like where akka would be without the fork/join pool scheduler it would have been a lot harder to build that I build that library and and so you know we all benefit from the you know the the benefits of being able to build and distribute robust libraries even if we're just writing applications so let me talk a little bit more about boundaries and I want to recommend a talk that you can find easily on the web by Gary Baron Hart called well boundaries and in it he talks about the benefits of using object orientation and functional programming in the same system and the argument he makes is within a closed domain functional ATMs are very effective that they give you tests easy testability and composability it's very easy to reason about state you know so all the things that we get from value based data and pure functions within a closed domain are a pretty big win and within that domain while we don't have any boundaries we don't need them but as we approach the part of the system that deal with messy things like IO or state or failure or communication with other entities the strengths of objects start to dominate so in this diagram you can sort of think of the function of the little circles in the middle those are little functional entities and the outer shell is the part of your program that deals with all the nastiness of state IO and failure and communication and really this is like two different programs right the considerations at the boundary are completely different from the considerations on the inside inside you control all your code it's all recompiled together it's all maintained together it's all version together and when you're dealing across boundaries like communicating to other systems you have to think about validation and defensive copying and failure management and separate compilation and versioning and security checks and migration compatibility so it makes sense to think about the sort of part of our application that for which the functional techniques are ideal and the part of our application for which object techniques are ideal and sometimes the shell is something we write sometimes this shell is party at runtime so this could be an actor an airline and within the actor code everything is clean and functional and beautiful now between actors there's a lot of messy stateful stuff going on like Message Queuing and retrying and failure management and it's easy to convince ourselves that err lying is purely functional because all the messy stuff is hidden from us but it's there and it's imperative and it's messy so airlines actors are actually a lot like classical objects in fact they're even they're more like Ches objects than what we find in Java or C++ and you can make a similar argument about micro-services right within the service you know you you have you know you have no need for boundaries but the service itself represents a boundary and at the boundary it has to deal with i/o and state and failure and all of that is anything but functional so it's kind of amusing that in our desire to move past objects we keep reinventing them just with different names so a small program could be like one of these little shell patterns but it might be more sensible to represent it as a network of cooperating shells rather than some single monolithic shell and you know this kind of looks like every relying program ever written right there's you have this network of actors that send messages to each other and in designing systems the you know the important architectural questions that we should be asking are where are our boundaries where do we put these boundaries or to put it another way what are the objects in my system and I'm not talking about the little fine-grained domain objects I'm talking about the entities that communicate with each other by sending messages so this is really a you know I think the right way to rise above both object orientation and FP which is using them at different granularities use object-oriented modeling techniques to find the right places in your application where the boundaries belong use functional techniques within those boundaries so you know one of the big complaints about object orientation is that that we have so many boundaries especially where we're not needed and and that makes for a lot of extra work but one of the things that objects have to teach the functional world is that sometimes putting boundaries between yourself and yourself is one of the best tools you have for managing complexity so functional programmers like to tell themselves that functional programming is an evolutionary advance over object orientation in a funny way the trend towards FP is actually I think a step backwards in this progression as well so if you think about the conditions under which object orientation became popular the whole world is procedural right I mean si si was the dominant language you know in the 70s and 80s and we had no language support for encapsulation or dynamic dispatch so but we knew how to stimulate those with programmer discipline and function pointers but inevitably what would happen is clients would bind too tightly to the data representation and ultimately that put a limit on how our programs could scale FP offers us more in the way of behavioral abstraction then procedural programming did more in the way of reuse but when it comes to data representation a lot of FP languages like I said especially the dynamically typed ones the ones that derive you know that from the Lisp tradition they take a step backwards into that procedural world where they temp their clients to sort of peek into the data and ultimately become dependent on the data representation and that often puts a limit on how our programs can scale so it's not accidental that the biggest FP programs are a lot smaller than the biggest hello programs but we should be able to get the best of both worlds once we let go of the tribal belief that one has to be better than the other FP is great when you're dealing purely with data and inside that that core of the you know the the shell diagram it's all just data and all that data lives on the same side of all the boundaries and similarly because oo focuses on modeling of active entities it's great for system components that have to mediate between the program and the messy real world and the reason it's possible to rise above them both is that each offers us complimentary tools for managing complexity and so we can apply a combination which is more effective than either applied by itself you can sort of see this this division in the way each of these traditions write about you know their strengths so if you if you look at writing about oo and writing about FP Brion Merrick observed that in general writings about FP languages tend to sort of omit the messy real world problems from their documentation or examples whereas documents about object orientation tend to meet these things head-on and they tend to highlight how well mechanisms can be used to contain complexity so it's easy to pick up an oo tutorial and come away with an understanding of how this is going to implement this like crazy set of payroll rules that you have to implement it's been distorted by however many generations of tax codes and union negotiations most FP tutorials but largely on a cultural basis would just leave those things as an exercise for the reader and I think this is because FP makes us all want to believe we can make the real world as neat and tidy as mathematics but we can't we need to rise above our desire for things to be cleaner and simpler than they actually are and engage the complexity head-on with all the tools we have and you know complexity is definitely the name of the game we are awash in a sea of complexity both inherent and accidental the central goal of programming language design should be to provide us with tools for managing complexity and the fact that there are so many languages out there illustrates that complexity comes in a lot of shapes and sizes and no one tool is going to be perfect for it now it's almost inevitable that we'll always be operating at the limits of our ability to manage the complexity because when a supposedly better technology comes along which allows us to build bigger systems without being overwhelmed by complexity what do we do we rebuild our world in this new image hoping it's going to take us back to a lower complexity level and then what do we do we immediately turn around and build even bigger systems until again we hit the threshold at which we're barely able to contain the complexity once one limiting factor is removed a new one is going to emerge and the cycle of hype and disappointment spins again and it really can't be any other way can it right the economic factors always push us towards building bigger and more powerful systems so we basically have one trick for managing complexity you could call it divide and conquer you could call it composition it's the same thing either way and in that big list of everything the big list of things that everything isn't they all claim composition as their secret weapon functions compose objects compose actors compose no one paradigm owns composition any more than one language owns garbage collection so both the old tradition and the FP tradition guide us towards this divide and conquer just from opposite directions and maybe at different granularities so oo sort of guides us towards it top-down it encourages us to draw encapsulation boundaries which reduce the scope of analysis FP encourages us to build upwards by composing smaller building blocks into bigger ones so big surprise oo fares better with composition the large but can really get in the way when you try to apply it in the small FP really shines with composition in the small but it's minimalism with respect to encapsulation and often representational abstraction can really contain its ability to scale so this false dichotomy of functional versus imperative or functional versus object is is often compared to another false dichotomy which is should programming be more like math or more like physics now as a mathematician by training you know I I have my own preferences and it's one of my favorite comics because well it feeds my sense of confirmation bias and I suspect a lot of functional programmers feel the same way as this comic suggests as well but it's really really easy to be seduced by the math and lose sight of the fact that we're actually running on a physical machine and you know wewe should ignore that at our own peril functional languages explicitly disavow any notion of resources like memory or threads or file channels resource management is entirely the responsibility the runtime and this can be a good thing right because then we get to focus on the business problem without being distracted by the bookkeeping but sometimes it's not enough it doesn't give us the resource efficiency we need to solve our problems in an economically feasible way now imperative languages come at it from the other direction they start with the physics and they work towards the math this gives us finer brain control but like a lot more temptation to get mired in low-level details that aren't so important to the business problem so you know for example the cecum you know one of the secret weapons of functional programming is immutability right it's great for reasoning about the state of state of your system it's considerably less great down to the data structure level right I mean most data structures are almost exclusively concerned with resource management and this is something that functional languages give us absolutely zero help with almost all the classical data structures involve mutability and there's a good reason for that mutability gives us far cheaper resource reuse then destroy and create us and you know without mutability for example we give up on cheap updatable hash tables which is like our only trick for reducing Levin problems to O of one problems and of course the hardware itself is always mutable right immutability is just an illusion that we voiced on ourselves and you know don't get me wrong purely functional data structures are really cool but they're kind of a bit of a dancing bear right it's it's impressive not because the dance the bear dance as well but that the bear dances at all so to think that programming is basically math risks ignoring the resource management reality to think that it is basically physics risks ignoring computational abstraction so okay what's the good news the good news is that as programmers we get to play in this whole spectrum between physics and math and we should be happy about that right you know we need both we should be comfortable in this whole space and not hide off to one side because the light is better over there so okay we get it narrow viewpoints are bad right how do we get past our tribal perspectives we can start by not letting our tools narrow our thinking and avoid having our models become our reality so we can shift between OO and FP influences as the needs arrived arise so in this way you know I think pure FP languages are gonna have a pretty hard time competing with broad spectrum languages that offer reasonable support for multiple paradigms and that doesn't mean we have to stop doing FP it just means the language isn't gonna force us to so we have to make it a more deliberate choice the single paradigm languages the everything is in acts languages they force us to wedge everything into their paradigm whether it fits or not now most languages are built on top of something else right I mean this and so sometimes we have to drop down into the the underlying language especially to implement a lot of the core libraries for example you can't implement Erlang's message dispatch in Erlang or the i/o monad at Haskell or even socket inputstream in Java now language implementers are often willing to do that right like our our JVM guys like to say we code in C++ so you don't have to but when users have to drop down into the substrate that's usually not a great thing and narrow-spectrum languages give users this bad choice either split your program across two different programming models with a big barrier in between them or do without the things you can't do in the hosted language so in a successful broad-spectrum language you can write more of your platform in your application without having to cross that big barrier and it's pretty powerful that we can write data structures in Java like concurrent hash map using ordinary java code because that means among other things that were likely to get more to those libraries than if they had to be written in written in C and that users that have specialized needs can just like take this code and customize it as they see fit and abstraction z' like akka can just use them at the same time object-oriented languages like Java and c-sharp are adept at learning tricks that had previously been the domain of functional programming 20 years ago was garbage collection now it's lambdas co-routines and pattern matching and despite their historical associations these features have nothing to intrinsically to do with functional programming at all except that they were popular in those languages first but it turns out they can fit very nicely into object-oriented languages as well in his keynote last year Julia condi Steele remarked that good ideas survived by hopping from one language to another and you know the language that develops an idea is very often not the one that survives it may well be some other language that comes along maybe a less pure language that comes along later to popularize it and sometimes you know it's new combinations of multiple old ideas that are the best new idea so you know III think you know these broad spectrum languages are offered offer developers an awful lot of flexibility to pick the programming paradigm that works for the problem that that's in front of them without having to switch languages and I think that's a really good thing so if you want to hear more about where we're taking Java and what we're learning from functional languages you can come to my talk tomorrow tomorrow morning but it doesn't really matter what language you're working in no one can stop you from doing functional programming in your head so summing up we all have so much to learn the problems we're trying to solve or so messy we can't afford to ignore what we can learn from any programming paradigm or lock ourselves into one paradigm just because we like it better so we need to learn from functional programming from object-oriented programming and from others too and rise above them all so don't be a functional programmer don't be an object programmer be a better programmer thank you [Music] [Applause]

Channel: Devoxx

Views: 26,149

Rating: 4.6943822 out of 5

Keywords: Devoxx, Devoxx2018

Id: HSk5fdKbd3o

Length: 42min 59sec (2579 seconds)

Published: Thu Nov 15 2018

Reddit Comments

[u/aphexairlines]

An interesting perspective on OOP+FP (a common theme in Scala) from someone who works on another language at Oracle.

[u/alexelcu]

This is a pretty good presentation. Overall some of his points are pretty good.

I think Brian is wrong towards the end where he's saying that FP is bad at resource management. It really depends on what kind of resources you're talking of. If we're talking about RAM memory, then yes, FP is pretty bad at working with memory. But if we are talking about managing file / socket handles, then the abstractions I've seen in the FP world are far better.

Speaking of the big picture, a language like Rust can go further and protect against resources being prematurely closed, which is pretty cool. People are trying to solve this in Haskell by introducing "linear types", but it's unclear to me if that helps.

This has more to do with the type system however, than with OOP vs FP.

[u/oleksandrb]

I totally agree. It's useful to use objects for make big boundaries, and use FP inside the boundaries.

[u/Milyardo]

That neo-nazi reference at 8 minutes is hilariously out of place. I'm 100% certain Brian doesn't know that Rise Above is a classic neo-nazi slogan, and that exact tattoo is common with the Aryan brotherhood, which makes the juxtaposition with the topic of the talk about getting along with multiple paradigms even more funny.