scale.bythebay.io: Paul Cleary, Scala for the Rest of Us
Recording: scale.bythebay.io: Paul Cleary, Scala for the Rest of Us
you so my name is Paul clear I'm a engineer at Comcast and today my talk is called Scala for the rest of this and this is a talk about transitioning from an oo mindset to more of a functional programming mindset in the way that you build software so how many people here are kind of new to Scala new 200 in general all right cool so ok so as part of this talk - I'm hoping to maybe dispel a little bit about a little bit of the anxiety about coming to functional programming right so it's not this this daunting right it's not this long of a bridge so to speak so we'll start with who are the rest of us and I think you know I've been doing development now for a long time I don't want to show my age a very long time but you know all the rest of us have been building systems using oo and I don't think we have a practical experience or education and functional programming right there there tends to be with an L now because it's been the predominant methodology if you will for the last 20 years these kind of standard building blocks that we use to build systems right it's almost like this ubiquitous language which is actually pretty cool because when you open up an oo system or a project and you're not familiar with it you kind of can get around in the code pretty easily right you know there's if I see an adapter I know what's going on there if I see a decorator I know what's going on there and if I see a controller I know what's happening right but so the issue when you I think that when you come to functional programming is that there's a whole new set of tools that you really don't know how to apply right they challenge our understanding about how to build systems you know functions are things right like they're not methods on classes there's something else carrying and partially applied functions and things like that and in addition to the newness of these things you kind of get thrust immediately into like category theory right there's all these abstract concepts and IDs and terminology I mean how many people here have been like attended a talk or watch the video and at the end of it you're like I I don't know what just happened right like like there were words said I think it was English and unfortunately like this is the trap that we get in right because you kind of feel left out coming from an oo standpoint you feel left out of the conversation so it's very compelling to just jump in and try to learn category theory overnight right so but the problem is is that every time you learn a new term there's 20 more terms that you've never heard about before right and then for each one of those there's 20 more terms and it's a rabbit hole and I kind of experienced this myself because I was trying to learn all these things and you get frustrated it's like all right so how do I actually build systems using this alright the theory is nice but what's the practical application of these concepts in my day to day routine right can anybody here tell me what a mono and a semigroup have in common yeah they both have that the binary operation but the associate but the answer I'm actually looking for is neither one of them are necessary for to do functional programming and scallop right so so the idea is that the hard thing is is that there's a lot of people running around peddling their dank category theory right and it's like really hard to resist the urge to kind of jump into that side of things right so if if you don't need to know all that stuff to get started if you don't need all that stuff to do functional programming in Scala the question is well what do you need to know right and you know the next slide unfortunately I came across this like later in my my learning of Scala but there's a video by roon up yarnís in it was 2010-2011 I think was a scala meet up and he said functional programming is programming with functions right it's simple right a little bit tongue-in-cheek but he doesn't ruin our doesn't say functional programming is programming with applicatives right or isomorphisms right its programming with functions in it as an oo developer and we Road developers here some of us at least right it means I can build systems using nothing more than this ok so like it's very very simple and when you start building systems that if you try to build a system something that's more than a trivial example using this you come into some of those other things like like carrying and things like that but beyond that we'd kind of read like so this is Wikipedia even the Oracle all of knowledge and it has this kind of long definition about what functional programming is right when you hear about things like referential transparency and you hear purity that a function is it is defined in terms of its input right avoiding mutable state and avoiding side-effects but really what this means is being predictable eliminating uncertainty and the way that you build software okay so I have this the this bulletproof guide that I think that you can this path the learning functional programming of scholars avoid being distracted by the category theory things at least at first write learn the basics I mean you have to learn Scala syntax but the Seattle syntax today there's a lot of different ways that you can use it 47° is great when I get started I got Scala cones that everybody else is here dude Scala cones right and then just look there I believe that there are some fundamentals that you have to learn before you get started okay and the last important point here is pretty important is that learn as you go don't try and tackle category theory and tackle all this abstract math up front you know discover it as you go so that these are the basics that I believe that you need to to kind of tackle before you get into programming and and I didn't invent these by the way so if you look at the Coursera classes if you look at the red book in the first chapters or essential Scala from the underscore book like these kind of are the first things they teach you but the neat thing the neat thing about all these things is that we can relate to these things as object-oriented okay so I'll try and relate to some of these and the upcoming slides can you guys see this in the back okay so so the idea is prefer immutability so we use vowels over VARs in Scala and Java right we prefer final okay the other thing is is that we use a mate immutable data structures okay so case classes now these 400 people will Java people these are like Java beans without setters right they're more than that but that's kind of the understanding and once you start using these in your code it kind of subtly influences the way that you rate your code immutable collections this is pre Java 8 and without guava by the way but like we rate code like to do filtering and there's a lot of words in here it's pretty verbose and the first time you start doing working with collections and this was really enticed me about Scala you know four years ago or so is that the bottom code is where I'm doing filtering I'm given a list of people I'm returning only those that are managers but not only is it more concise but it's extremely you know easy to understand right it's very expressive and now I'm using lambda so by the way I'm doing functional programming right I'm using functions in my code so this is pattern matching Java old way this is I have a function that given a pet returns a description of it based off its type all right so this is ugly okay and this is only three cases and I've written code like this and generally you don't want to touch code like this right but once you get used to and you see the power of pattern matching and you're using case class and immutable data structures and it's readable types it's very expressive right like I can connect to this because I've worked with code like this but I can connect to how much better pattern matching is okay handling goals is another thing that you kind of we work with us their standards around handling knows like so the problem with in Java where at least a lot of systems that I've built is that how do we know person is there right so the how you know it is that you either have to inspect all the code paths right to get to that point in the code to determine whether it's no lore not in order to do the check or you have to live with squashing NPEs during your you know the execution of your runtime which is an unsatisfying place to be right but the but with in Scala Wiis option and this is this is kind of where we use wrapper types to kind of like denote for certain characteristics about values here we're making we're bringing to the forefront the fact that this value might not be there so you as a developer are forced to deal with it as opposed to guessing we talk about uncertainty and making your code more predictable okay business Irv's we handle these through text exceptions is everybody loved checked exceptions right the problem with Java has that exceptions are like they're not returning a value right it's it's a an abnormal execution or return exit out of your code hey so it's hard to kind of like so it's an abnormal exit we throw a business owner out and we hope that the caller of this code is going to manage it the right way but they don't right we see that every single method in my system has throws exception on okay and it comes all the way up or else we squash it in uncertain ways or unfortunate ways but in Scala again we have this concept of wrapping our types wrapping our values in some kind of context where we denote that hey by the way this is either it might be on the left side a negative outcome of this this function or in the right side a positive outcome but the nice thing too here is that we're returning a value we're not throwing an exception and then the last kind of exercise here is just like we have two methods here one that loads a person out of a database and one that learners loads a company out of a database they both throw sequel exception right and we see this in this try/catch block here and if the the first for the first method fails we go into this cache block we exit abnormally if the second get in the company fails we exited normally and then we go in as cache block we have to do something with it so how many people have written code like this okay yeah this is a safe place right we're okay it's okay you know where where you might just return null coming out of this right but it's unpredictable what's actually happening in here right but within scala we do the same thing with again these wrapper types are giving context to values and the fact that this could be a failure and forcing the person call on our function in order to deal with it so I have here like I still have the same short-circuiting behavior just in the scala way right if get person fails you're going to return the failure we're not going to we're not going to throw right if get company fails we're going to return that failure and only if both of those succeed by the way will they actually return our employee as a successful result so this is kind of short circuiting behavior that you have we can emulate but just using returns and not using throws and then this is where you get into category theory and then this is like this is like the slippery slope the Gateway if you will a gateway drug of category theory but you see flat map and immediately you know that this is a Mona OK and I mean and these things come from category theory and a naming is unfortunate right short-circuiting might be better than monad and proceed if okay might need be better than flat map but we do have to deal with these terms right but it's just important to know how these meet these things mean what these mean and once you start using monads you get monad superpowers right well you get four comprehensions and then these are a sequence of steps and you know that they can exit they can short-circuit right it's very very powerful and this kind of wraps up the code portion of this but like from a no stand point I can relate to all these things right I can relate to them they're less scary right and these but I believe are by and large the fundamentals that you need to know before you start doing functional programming Escala so what's next so the next thing is start coding you know I mean I I'm a practitioner of theories great but I like to build systems right so there's nothing better than actually building something with tools to in order to learn how they're used right and grow your knowledge organically the the the neat thing today where I can't where I stored it I think playing knew was kind of the only thing out there today you have git er eight templates the precursor was activator templates but I was able to like my first applications are play akka applications but I was able to spin him up I was able to new up a play application with like an actor backend right and I didn't need to know SBT simple build tool right I didn't need to know anything about that I didn't need to know how to define an endpoint and play or how to like connect that endpoint to an actor I was able to get that out of the box and the only one I needed to actually implement something different that I actually have to go out and research it and then hit a problem or implement something different and learn organically so this kind of transitions I want to build an application a little maybe about a year ago I have an application built in spray that I need to migrate and there's this emerging type level stack I don't know if everybody loves that term stack but stack where your HD before a HTTP cersei for JSON do be for database access and cats and so like I want to build an application using a stack but there was no kind of template out there right so I started assembling an application but I did it in a setting that I'm familiar with like oh oh people will be able to relate to you like myself and other developers okay and I build it specifically I build it not to be honest with you I want to get it out there because I want people with functional programmers out there to give me feedback on it and by the way there's a bunch of people that have give me feedback so thank you to those who have given me ideas but the ideas I built an application using kind of this standard architecture and the standard architecture comes out of Cockburn in 2005-2006 the hexagonal architecture right and domain driven design furthers this concept where you have a domain that's pure right it's simple and it's defined in terms of your business concepts and and and validations and behavior and then inevitably you have to get into your pure code so you have this bubble wrap around it and then you push the complexity to the edges or hey it's so like if you have a banking domain you don't have to worry about it shouldn't be dealing with HTTP within your domain so if you look at the pet store structure you can identify where all this code lives right in the endpoint I know HTTP things that are in there in the repository I know that database things are in there so I can start to relate to this as an oo guy and so if we look at an endpoint right Scala has this really powerful dependency injection framework built in it's called argument passing all right so here we're doing function arguments and dependency injection but I can deduce that this is a route right it's kind of fairly straightforward and then I have a for comprehension here so I know that it's a monad that's in at work here and then I'm taking the result of executing this create call and then mapping it into HTTP things okay and if we look at the service we can see even a more complex example of dependency injection in scala as construction parameters right arakata constructor parameters but here we can see monad and we might not know what implicit czar but we know what monad gives us okay and we'll see either and we go okay well it's either T but I know that that's kind of typically how we handle business errors and then well we'll convert to a business error but this is a nice place to go okay what is 30 give me right so then you can go and look at moon and transformers and you can look at either T but you can read the concept in the documentation but then you have a real-world example that you can point back to and you can reference and go okay I can see how this materializes in my day to day life so the pet store repository is sequel and it's mostly sequel Dubey is really awesome all right so if you know sequel you can write this code and you can work with tube and you can get up and running pretty quickly so to wrap up and this is the end of my talk so by the way this is me this picture is pre beer free beer post beer okay so 400 people you know avoid you know getting hooked on the category Theory thing up front right learn just the basics and start coding and learnt grow your knowledge organically and for the functional programming community I can't tell you when like free monad became a thing a couple years back I was like man if somebody could just give me an example in an application I can understand I'd be more readily to apply and adopt free monad and what I do day to day right so the power there for functional programming so if you can give oh oh people an example that they can relate to not only do you drive or accelerate adoption of those things right but you can accelerate and drive conversation and discussion and that's really what it's all about right so there's my Twitter handle there is the pet store if you if your frog coming from a functional programming background you think I'm doing something wrong let me know and if you're from an oil background and you can't relate let me know as well because what I'm looking to do is just drive this to a point where I can document it out and I'm not quite there yet so that's it [Applause] in your day-to-day development do you use cats regularly and you find that it's still easy matter to use I guess after joining background with music elicits that gets to just can't see means you can't question so sure I came out of akka and just more using the Scala framework and features and things like that and then evolved into use in scholars at disjunctions in terms of handling a lot of this stuff but we are evolving to cats we don't use cats today but one of the migrations that we're doing for one of our one of the applications that we work on is looking to use cats in order to do that but you're right you do get unfortunate squiggly lines and certain ideas like IntelliJ but you know if you know and I think that once people see for comprehensions and they see things like Scala does or disjunctions and the power they give you I think that they're very amenable to coming on board and using them you