×
Eventil - Find Tech Events
Official mobile app
FREE - In Google Play
View
×
Eventil
Official mobile app
FREE - In App Store
View

Programming Across Paradigms

1 0

[Music] [Music] hi I'm an Jenna hopefully you can hear me and this is my name in really big letters you can find me on Twitter and there's links there to my various other online presences and yeah I'd like to talk to you about programming paradigms today or more specifically about programming across different paradigms and kind of I thought this was a fitting topics for for poly cons because we've been learning about all these cool different languages and different technologies different ways of looking at problems and so what I'd like to do what I'd like to do with you is kind of zoom out a little bit and get a little bit so accessable because my background is not in computer science my bachelor's actually in philosophy so I like to geek out on the philosophy stuff so buckle up that's what we're going to be doing just a little bit about me I am an engineer at a company called uber research no affiliation with uber and we do data about scientific research funding and so I work mostly in Python on building a custom query language for interacting with our data on science research funding and we're actually hiring so if anybody is into Python and pyramid and web development with that come talk to me after I am an alum of a couple really fabulous programming communities or text communities that I've been so lucky to be involved with one is called the recurse Center it's a three month self-directed programming retreat in New York City and a really warm and wonderful programming community and while I was at the recurse Center in 2015 is where I was kind of mulling over all these different programming paradigms I'm started to learn about what were new to me paradigms like functional programming and start thinking about how all these pieces interact so a lot of what were going to talk about right now I was thinking about when I was at the recurse Center and another program I was lucky to be a part of was outreach E which is an amazing initiative to get more women and underrepresented folks involved in open source by offering paid remote internships at organizations like Mozilla so outreach org is a fabulous place to go or to send people if you know of anyone looking for a way to break in to tech or to break into the open-source world send them that way outreach org and I'm still involved with Mozilla although my internship ended I'm still a volunteer with the tech speakers program so you can find me around at conferences quite frequently and I have Mozilla stickers so if you want one of those and you couldn't grab one downstairs also come grab me so yeah more than happy to chat about any of this after the talk but you're not here to talk about me we're here to talk about programming and when I was learning to program and when I first encountered the notion of a programming paradigm I started wondering you know what it really meant and where it kind of came from so I found out eventually that one of the first times that the idea of a programming paradigm kind of came to the public attention in the programming community was in 1978 when this guy whose face is really big named Robert Floyd won the Turing award low price and he decided to dedicate his tiering or lecture and the subsequent paper which you see to start up here to the paradigms of programming and I guess when you win a Turing award you're allowed to start your paper with a quote from the Oxford Dictionary because that's what he does but I always got yelled at for doing that but anyway he starts off by defining a paradigm as a pattern or an exemplar an example I think pattern is kind of the most salient of those definitions and he talks about paradigms as being these kind of what we might think of now as more patterns of doing programming things like structural structured programming or dynamic programming he talks about these different ideas different ways of approaching a problem it's a little bit different from how we're going to look at programming paradigms in the rest of the talk and I think how people generally frame the idea of a programming paradigm today but I think that this paper despite being from 1979 the year after you won the award in 78 is actually like really current and really relevant and I love this quote from it he says that I believe the best chance we have to improve the general practice of programming is to attend to our paradigms so he really frames paradigms of being central to the entire discipline of programming not the language not the algorithm but the paradigm as being something that we should really focus on and that's why we're talking about it right now so my hope in this talk is that we we just pay some attention to the paradigms that we use the paradigms that we know the paradigms that maybe we don't know so well and we're going to go through some of the ones that we're probably familiar with and take a look at how they affect the code we write in the way we think about our code and hopefully when we leave we will all have a little bit more motivation to keep attending to our paradigms so this of course brings up the question what are we talking about I've used the word paradigm like 80,000 times already and it's only a minute five of the talk what is it what is the paradigm so as I said I studied philosophy and when I first ran into the word paradigm really big word it was in a philosophy of science class where we read a book called the structure of scientific revolutions by Thomas Kuhn anybody read it couple hands a couple hands okay cool so Thomas Kuhn is basically like a historian of science and at least in this book he is kind of trying to give an account of how we make scientific progress as kind of a collective as a civilization and he centers the whole dialogue on his whole way of thinking about scientific progress around the notion of a paradigm and the way he kind of puts forward a paradigm one way of understanding it is that it's sort of like a worldview a way of looking at the universe the world around us and if we're talking about it from a scientific perspective it's a view of the world of the disciplines that were in a scientist so if you're an astrophysicist the universe is probably like the literal universe and if you're a maybe I don't know in the medical field perhaps the world that you care about is the world of the human body or perhaps populations of humans as computer scientists of course the world that we'd be interested in would be computers and the programs that we weren't on them so it's a way of understanding that whole domain and another way of thinking about it is as kind of a model of that universe a representation a kind of symbolic a shorthand for understanding how that universe ticks what makes it work and if it's a model then of course that brings up a classic quote from a statistician George box who said that all models are wrong so it's important to keep in mind that a paradigm this view of the world view of the universe is just an approximation it is not how things actually work it's just a model of how things work that helps us understand and helps us do science to better understand the world around us and so Kuhn says that this model this paradigm isn't just telling us what's in the universe it also tells us not just the theory but also the methods and standards of a science together in an inextricable mixture so these three things theory methods and standards all come out of a paradigm what do we mean by that well in theory we mean what to the universe is what entities it's made up of and how those entities behave and interact with each other so what kind of system we're dealing with and that's kind of what we would more typically think of when we look at a model we see kind of what it tells us about the entities in the domain that it's trying to describe but the other important thing that who noted that kind of follows along or sort of falls out from that model is what it means to make scientific progress what methods we should use to try and understand things better another way to understand that is like which questions we should ask which questions that even make sense to ask which questions are important to ask which again we could understand is asking which problems are worth solving which problems we should be focusing our attention on and the standards by which we judge the quality of our work are also wrapped up in that so this is kind of saying okay if we're figuring out in the method what questions we should ask in the standards we have an idea of what answers are good answers and in this case what solutions to the problems that we framed would qualify as good solutions so all of this the entire like act of doing science he says is wrapped up in a paradigm and in that sense a paradigm according to Kuhn is necessary for scientific progress it basically enables us to make progress so the way he describes it is he talks about kind of a pre paradigm Dark Age like nothing is getting done there's maybe someone over here who's got their own little mental model of the universe and is doing their own experiments but they have completely no interaction with this other person over here who's got a different model is asking different questions getting different answers we're all just kind of fumbling around in the dark and as a collective at the community we're not really getting anywhere until a paradigm comes along that everyone in the community tends for whatever reason or decides to rally behind and get on board with and that theory those methods those standards allow us as a whole to collectively make work and advance our understanding of the universe in this model in this paradigm so for example the paradigm of the Ptolemaic geocentric view of the cosmos where the earth is like this warm bright shining center of the entire universe and all of the celestial bodies that we can see in the sky revolve around us quite literally in these celestial spheres this is an example of a paradigm where it's a model we know now that the model is wrong but having this model enabled astronomers to reach some kind of consensus and collaborate together to make advances in their observations and give a structure to their work that allowed us to make some kind of progress on understanding the universe around us but of course as we just mentioned this model is wrong so they're going to be anomalies they're going to be observing that scientists make while carrying out that progress that don't fit in the model and what ends up happening is that first we try to shoehorn them in you say like okay yeah I noticed that Mars is going backwards but uh that totally makes sense if we have like crazy epicycles like orbits around orbits and yeah we can just keep adding circles until everything works out and so this is what ends up happening these anomalies at first day they kind of get crammed into the model that they don't quite fit well in but as enough of them accumulate eventually they can no longer be ignored and the community is sort of thrown into a state of crisis where maybe you know the the old guard is like no this paradigm is corrected is the final answer to everything that we know about the universe and we will keep adding at the cycles we will keep adding complicated mechanisms to explain the anomalies as long as we need to until everything is solved and other people are saying no we can't keep holding to our old ideas we need this new paradigm and somebody else says no not that new paradigm this other new paradigm and blah blah blah and it's just argument and chaos and progress has kind of stopped at this point we've all just arguing with each other and this kind of continues until the notion that the kun is most famous for paradigm shift happened so a new paradigm comes along that everybody can again more or less agree upon so for example the the Copernican heliocentric model where the idea is okay well if we want to explain things like retrograde motion wouldn't that be a lot easier if we just stopped clinging to our idea that the earth is at the center of the universe and instead imagine that the Sun is at the center and we are just on one of the spheres orbiting it then everything kind of falls into place and the things that were anomalies in the old paradigm are no longer anomalous they make sense they fit nicely in our new model and so this is the new paradigm a new model that allows progress to continue but of course it's still a model it's not perfect it becomes a new paradigm it has new anomalies a new period of crisis comes about another shift happens and so on and so forth forever basically it just continues in this cycle he says and so this is yeah this is the idea of paradigms and how they enable progress and what they what they do for science according to the kuhnian view of things but okay this has been a lot of me like yapping about science and outdated astronomical models that we know don't work so we're not here to talk about that we're here to talk about programming so let's get deep what is it what is programming what are we doing what our programs what are computers why are we even here what are we talking about and this is kind of the answer that different programming paradigms sorry the question that different programming paradigms give us sort of different answers to they give us different models of the world of programming so if we think about the dark ages before computers before when when like computers were like humans like actual humans sitting down and doing computations and like looking up logarithms and like books and stuff like this is a really dark age right none of us want to think about it it was terrible and then the miracle happened and humans collectively as a civilization somehow figured out how to like electrocute a pile of rocks and make it do whatever we say which is pretty awesome and gave us all jobs ultimately and this led to kind of this new paradigm imperative programming where we give the computer commands so the idea here is that programming is like telling the computer to do stuff imperatives do this do that follow my commands and follow them in the order I give them do this and then do that and then do the other thing so in the imperative programming we have this notion of like time being important state values changing and we tell the computer okay like remember these values like put these values in your little boxes in your brain and remember them and change them in ways that I asked you to and then tell me what they are later and so these this command giving is kind of what the active programming becomes in this paradigm and I think it's helpful to have like visual mental models of things I'm a very visual learner and as I said also X philosophy student so I like to have like meta like models of models of models and I think a useful metaphor or kind of visual metaphor for imperative programming is a complex machine like a like a clock or a watch because imperative programming sort of Phocis forces us to focus on the nitty gritty unlike the intricate details of putting together a complex system a complex machine that that gives us the intended action whether that's like turning hands on a clock I think clocks are good metaphor also because of the time notion and imperative programming state but of course like a clock these intricate machines that means we have to pay very very close attention and we have to be very precise about each individual component each little tooth on each little cog in the machine and if we mess up somewhere or if we don't maintain this machine very well and it starts to corrode it freezes up it stops doing what we want things stopped working we don't get we don't get the computer to do what we say so this could be considered a type of anomaly or situation that this paradigm doesn't handle very well and so other paradigms came along that aimed to fix that or or or give a better solution to that type of problem which is hard under a part of programming so for example object-oriented programming says ok this is too complicated once we try to create a really big machine like for little watches it works ok but if we're trying to make something really complex there's too much going on there's too many moving paces keeping all of that state all of those changing values all the time in in our heads and in our programs keeping all that straight is too hard so let's divide it up into little chunks which we'll call objects and each little chunk will say ok you object you keep a little part of the state of the program to yourself that'll just be your responsibility to hide it from the rest of us hide it from the rest of the object keep it to yourself and then what we'll do is the rest of the program will send messages to you so receive those messages listen for them watch keep your eyes out for them and when you get those messages like depending on what state you have and what you know how to do respond to them as you will now I don't know about you but this was a little bit different of an idea of a way of thinking about object-oriented programming than what I was taught when I first learned object-oriented programming I was taught it was all about and inheriting and like different types of mammals and these complicated taxonomy xand UML diagrams and like Wow but we're going to come back to this a little bit later but I think that the actually the a better way of conceiving of this is as the way that people like Alan Kay one of the founding fathers of the program paradigm talked about it when he talks about the early days of small talk and things like that and this is this is based on this idea of hiding stayed in little chunks and sending messages back and forth and so the visual metaphor or the model of a model that I think works for this paradigm comes from alan kay who was a biology major and he gives us a really nice a biological metaphor of cells in a body as being kind of like an object-oriented program the idea being that each object is kind of like a little cell which has its own little state like its little organelles and it's a little mitochondria and like whatever else is in a cell and our member biology but and they send messages back and forth chemical messages bypassing molecules across their membranes so so will receive a molecule at a particular receptor it will ignore other molecules that doesn't have receptors and it will send out other molecules and from that these concepts of like little cells having their own responsibilities and sending messages we get a nice complex system that's no longer as rigid as our mechanical imperative watch it's flexible it's more more resilient we don't have to worry about losing an individual cell things like that so this is on one hand a way we could consider abject Oriya programming as a new model that solves some of the anomalies of imperative programming but of course it's not the only way of explaining some of those anomalies or getting rid of them another program like another paradigm like functional programming might also have a good solution to some of those problems so functional programming then takes the view right that like okay this complex watch with all of these moving pieces that's like a lot of mutable state that's super dangerous because if we do one little thing wrong and one cog moves a little lever in a way that another cog wasn't expecting then like everything goes kaput so mutable states that idea but pure functions functions that just take inputs in and just return outputs out and do nothing else those are faced because they don't mess with any other parts of the program so if we just looked at our programs as being pure function that just take data in and return data out and we look at those functions as being made up of other functions that just take data in and put data out and those are made up of other functions editing idiot and data then we have a much safer program that is sort of composed of smaller parts and is much easier to manage when we get to large levels of complexity and so since this then has this very strong focus on data coming in and data going out you started in functional programming you start thinking of your program as being kind of like a pipeline of like transforming data from inputs to outputs and I think a good visual metaphor for that is an assembly line where you have kind of individual functions are sort of like individual stations on your assembly line they take in you know the first one takes in some raw material some sheet metal and assembles it into pieces of cars and then the next one takes pieces of cars and assembles them into like the body of a car and the next one takes some wheels and adds them on so on and so forth until you get the desired output and this is a very different way of thinking about a program then as a complex machine where you have to engineer every single little piece all to be working exactly at the same time together or as a biological entity where cells are cooperating by sending messages back and forth very different model but explains or solve some of the anomalies of imperative programming in another way it's own way which we'll return to in a moment there's another programming paradigm that want to talk about real quick and that's the broader or paradigm of declarative programming so if imperative programming is like giving commands right like telling the computer do this and then do that telling the computer exactly how to do declarative programming takes the view that maybe for some situations for some problems that's a bit of an anomaly like the fact that we have to be so focused on how we do everything so declarative programming we could think of as saying like maybe that's not the best way of modeling the universe in some cases maybe it's better to just model the universe in terms of what I want and not how you go about getting it for me so in that case programming becomes less about issuing commands in a certain order and more about stating making declarative statements about the world so saying like these are the facts that I know these are things that are true this is what I want from you computer lovely computer who does what I want but I don't care how you do it I just care that you give it to me and I think especially because one of the sub paradigms of declarative programming is logic programming I think a good visual metaphor for declarative programming is like a Sudoku puzzle any Sudoku pants Wow not a single pseudo ku fan and okay - great so for those of you who don't play or don't know pseudo ku it's like you have this nine by nine grid made up of three by three squares and you have to have all of the digits one through nine and each row in each column in each Square and in this metaphor you are the computer right and the the newspaper or whatever the puzzle book of the Sudoku puzzle says okay here the here the fact your the constraints of the world you got to put all the digits in all the rows there's like a 1 in the top right top left corner etc go and you just have to fill out the puzzle it doesn't care how you do it it doesn't matter if you use pen or use pencil it doesn't matter how you make guesses or what order you enter the numbers and it just matters that you do it and that at the end of the day you've got a filled out grid that meets all of the criteria so anyway this has not been meant to be like a next you know exhaustive tour of all of the paradigms obviously just trying to think a little bit about how we can understand how we can how we can kind of crystallize these models for ourselves but these are just some examples they're by no means all of the paradigms out there and they're not even the principle paradigms so this guy named peter van roy made a chart that I think was intended for this screen and it goes through and tatical categorizes all of the various principle programming paradigms as made up of different concepts and shows how the paradigm relate in terms of adding or subtracting a concept here and there and give some examples of languages that support those paradigms and he writes he's got a lot of writings about about these things but this is a this is just to give you a sense of like how much we could spend time thinking and talking about programming paradigms it's almost limitless and one thing that I think that's interesting that that you can see in this chart is that sometimes paradigms that we generally think of as being really diametrically opposed might actually not be that far apart they might differ just by one or two concepts and this brings me to another question like when we're looking at any given paradigms how different are they really I when I started as I said I wasn't always in tech and when I started getting into the programming community and I was exposed for the first time to these like epic battles between you know like different language proponents and different paradigm users and you know you got like the functional programming people being like ah Oh P is so gross like Java is for losers and you've got the the Oh P people being like whatever Haskell's gross like you who wants all those weird symbols like and then just have a year worse no you're the worst laughs like is this really necessary what are we talking about here what is the argument so it's in particular with the paradigms of object-oriented programming and functional programming I started wondering like how different are they and I think in a certain light we can actually see them as being really really close so if imperative programming if one of the potential anomalies of imperative programming is this idea of shared mutable state which we could represent as like having to manage all the complexity of this intricate machine all at once and know exactly where every wheel has to be at every moment if that's an anomaly then it's recognized by both the object-oriented and the functional paradigms they both say this is a problem we need solve it's just that they do it in different ways so functional programming is like well if we just make everything immutable and you can't change state anymore as there just isn't states like values don't change over time then you can share whatever you want it doesn't matter because you won't be able to mess up like somebody else as part of the code over there and object argued programming just takes the other approach it says well you know there's nothing inherently wrong with mutation as long as we protect it by keeping it safe in little units called objects and we don't share it between them and so I think this is kind of interesting because again the the there's two different ways of looking at it but the basic thing they're trying to do is the same and I mentioned earlier that this is kind of different than what I had learned about object-oriented programming so this is a quote from alan kay on a guest now famous mailing list message where he says he's sorry that he coined the term object for what became to be known as as object-oriented programming because it gets many people to focus on the lesser idea the big idea he says as we talked about earlier is messaging and so in this view of object-oriented programming or this view of objects an object is just something that's kind of defined by how it responds to messages it takes messages in and it gives responses whether that be changing something in its internal state or returning something or who knows messages go in and responses come out but functions in a way are similar because they're just things that take in inputs and give outputs and one way of understanding a function like a mathematical function is just in terms of what output it gives for a given input so there seems to be a similarity here in that they both seem to focus on the way things behave at least if we zoom out and take a really big picture broad view and so one thing that like really kind of blew my mind with when one of my batch mates at the Ricker Center Darius bacon pointed out a similarity between the lambda calculus which you know it's got a lambda lambda the logo of like every functional language out there like super functional right everything is a pure function untyped now we're talking about untyped lambda calculus and in the lambda calculus since you only have pure functions Lambos you have to represent data as functions as the way they behave so a true is just something that a boolean value like true is just something that takes in an X thing a first thing and takes in a Weifang a second thing and returns the first thing sex and false it just takes the first thing it takes a second thing and returns a second thing but this is actually almost exactly what boolean look like in small talk which is like the canonical like Alan pays like object oriented language like very closely associated with the paradigm in small talk a boolean is also a thing that just takes two values a and B and the true to do the first one and false gives you the second one so like there's clearly a similarity here when we think about the the big picture of what how these two paradigms conceive of or model a program and its components so can't we all just chill out on the like right geez anyway this question which paradigm is the best which people love arguing about yeah I think you can see where I'm going with this George box because all models are wrong no paradigm is the best they are all terrible they're all wonderful depending on your glass half-full glass half-empty outlook on things but this isn't the end of his quote here he doesn't just say all models are wrong he says all models are wrong but some are useful and I would say that all programming paradigms are useful for certain things so just like in in physics you know Einstein came along and with relativity relativity provided an alternative paradigm to Newtonian classical mechanics that solves some of its anomalies I didn't mean that we just threw out classical mechanics it's still really useful for doing things like building bridges or like figuring out what happens when cars crash into each other whatever it's perhaps even more useful than like trying to use Einstein theories to understand like very slow moving small objects so when we think about models or when we think about paradigms going back to George box he says the question to ask isn't is the model true or like is the paradigm good it is the model illuminating and is it useful what can it illuminate for us what can it teach us what can we learn from it and so then this is the question right what can we learn from each paradigm what can a given paradigm highlight for us that could be useful so I think that what imperative programming when you when you learn to code in it it is really good at illuminating and kind of focusing on being explicit saying exactly what you want to happen and that focus on the implementation is something that's very useful when you're trying to think like a computer because our poor little computers they're sort of stuck in this paradigm a little bit at least for now until the next giant revolution so if we want to be machine efficient this is a really useful paradigm and just this morning we had a great talk about if you're working in a lick sir like a functional language you might want to drop down to an imperative language like rust to implement certain algorithms so we saw this talk from from Hans and it's about how we can use these nifty ah native native implemented functions I just really can't resist that joke today anyway how we can use the the nips that the Erlang VM allows us to to deal with to bring imperative code into our functional it looks for code because sometimes you just need to implement an algorithm imperative ly especially if you're doing things like complicated math and you want so performance well anyway if that's what imperative programming illuminates then declarative programming kind of is the complement to that it sort of helps us understand how to be abstract and how to focus on the higher level domain and how to think about efficiency not in terms of how the machine would like to be efficient but in terms of how humans are efficient and what is the clearest way for a human to express or to understand a problem at hand so this is an example kind of taken from a book called domain-specific languages by Martin Fowler and Rebecca Parsons and this is one example of how when you're working in an object oriented language like Java for example it doesn't mean that you have to write object-oriented code this is code that looks a lot more declarative because it's in what what Tyler and Parsons call an embedded DSL like a DSL that uses a subset of the of the host languages syntax and so although this is this is Java it's technically object-oriented it really sort of seems more declarative so what we're doing we're making a calendar and we're saying like we're declaring certain facts about an event that we want to put on that calendar we're not instructing the computer like how to remember the date and like how to store everything and what order to do things and we don't care for our human use of this calendar it doesn't matter we just want to declare information about it so bringing some of these declarative principles into the code that you write in a different paradigm like object-oriented Java here can be useful if you're trying to focus on that big-picture domain so then returning to our friend object-oriented programming I think this is great at illuminating and teaching us the principles of you know encapsulation classic - the paradigm and and remembering things about the world so state that we need to for a given purpose this is an example of bringing some object-oriented code into functional code so it's from a blog post by Eric palace called Yop matters in F sharp so he's an F sharp programmer F sharp being a language that's sort of multi-paradigm but functional first allows you to do oo P but in general you tend to do functional programming in it and but he points out in this article some great moments where it's a good idea to switch to object-oriented thinking for example if you're building an API that has to be aware of various dependencies if you're doing this all as pure functions you're gonna have to pass around those dependencies all the time and that can get cumbersome if you start to get into a large number of dependencies or a large number of functions so sometimes it would just be easier and just easier to think of that easier to write shorter cleaner to just wrap that all up in an object-oriented style into something that you can instantiate once with all of its dependencies and then you can call the functions are the methods on it that just they remember those dependencies for themselves you as the programmer don't have to remember them all the time now of course as we said before there's similarities between functional programming and object-oriented we could do this kind of thing with like closures and stuff but that's in a sense even though that's a functional technique it's sort of taking an object-oriented a mentality of how we would go about constructing our code here now of course functional programming can also be really useful to bring into code your writing and other paradigms because it really puts the focus or illuminates these principles of isolation and of transforming data from inputs to outputs I think a really good example of this is from a blog post and there's kind of a related conference talk by Jessica care where she's talking about trying to diagram a new program on the whiteboard I think she was writing it in Java or an object-oriented language like that and she says that so this this diagram she starts writing on the on your left here which is her thinking in an object-oriented style she starts trying to plan out how the program is going to flow and she goes okay you have to make certain checks and then you have to loop back over here if something is the case then you have to come back down over here she gets this really convoluted ugly kind of diagram that she also isn't sure okay if this is how the program works how am I going to divvy that work up to the rest of my team because all of these components are kind of interconnected like what am I supposed to do with that and she says that when she switched to a functional way of thinking about things as transforming data is flowing data through kind of pipelines or functions that just make small modifications to to it in isolated ways a much cleaner structure of the program just sort of fell into place where she started thinking about the program is just having sources of inputs that gets the data gets filtered and combined together in some way and then comes out into whatever the output is that you want and so this comes up with a much cleaner diagram as you see on the right-hand side here and that that nature of functional programming that sort of focuses on isolating transformations to one small chunk of work at a time that also means that it's easy to this up as you can see in the yellow boxes on the right hand side diagram to break this up into kind of isolated chunks which you can just hand out to different people on the team and then put their work together all the end and you have a nice clean structure that was easy to implement for your team so the point here is that no matter what paradigm you're working in there is probably something that you could learn or something that could be helpful from some other paradigm and I think peter van roy kind of sums things up nicely in an article so graciously titled programming paradigms for dummies he says that each paradigm supports a set of concepts that makes it the best for a certain kind of problem and this is really the whole idea all models are wrong but some are useful and each paradigm is useful for a certain kind of problem none of them are best absolutely they're all just best in their own particular the problems that they shine in so one thing that Peter Van Roy stresses and I think that we all at this conference can probably get on board with is that learning lots of different languages and especially working in multi-paradigm languages gives you a wider range of options because then if you want to bring in something useful from a different paradigm that would be a better fit for your problem you don't necessarily have to switch the language you're working in or switch all the tooling and cetera etc so he says that it can be a good idea to work in a language but gives you support for all these different tools so that you can then decide which one to use at any given moment ok so I'm almost out of time here and you're probably wondering like what is my point well it's pretty simple really as we saw with Kunz we're gone on understanding how science works paradigms enable programming we can't really do programming unless we have a model in our heads of what a program is and what it means to do the act of programming the computer writing the code that the computer will run once we decided on one of those models we can go forward but we have to we have to have some kind of model and what that model is defines what programming means what our lives as programmers look like what we have to do so when we're working in a given paradigm I think it would be great if we could just embrace that paradigm for what it's good at for what it does well and not fight it and try to like shoehorn anomalies or things that it does badly into it and instead be open to shift our paradigm try a new language or use a different feature of our language when it would be a better solution so just to close out with a little more floyd he said in that same a turing award lecture that the advancement of the general art of programming requires the continuing invention and elaboration of paradigm so as a community as a as a field as a club of like Superfund program friends we need to come up with more paradigms we need to keep inventing new ones we keep tree to keep trying things out so like playing with things like the like the zeta vm project where you can create new languages and maybe do things differently that's what we need to be working on and at the same time he says that advancement of the art of the individual programmer requires that they expand their repertory of paradigms but you didn't exactly say that because he was a little confused about how pronouns and gender work in english but i fixed it for him he's just a Turing Award winner he's not that smart so the idea here is that as an individual programmer we need to also expand our toolboxes learn new paradigms learn new ways of thinking not just let's say new languages that use the same paradigm and this is obviously a great place to do that kind of thing so yay congratulations this is this is the whole point we should just keep trying to learn new paradigms keep trying to invent new paradigms combine old ideas in different ways and come up with new ideas and basically just attend to our paradigms so thanks a lot I just want to give a big shout out to some of the folks with a recurse Center who helped me put this talk together and think about paradigms this way and thanks to Polycom for having me i'm antonovic ela on twitter and here's a bunch of references thank you [Music] [Music] you