Simplicity Ain't Easy - Stuart Halloway

you can you can don't do it during the talk but later if you want do a Google search for simple programming languages or simple programming or simple whatever and just follow your nose and the reading is is downright hysterical I'm gonna share some samples of that so people use simple to meet a lot of different things one thing that often means is it has something to do with keeping count writes a scorekeeping thing so having one of something is simple and two of something is some somewhat more complicated and three of something and in fact some of you probably remember the interminable thread on the google group had people read this thread write the title of the thread was simple things should be simple and it was all about the stuff the Chatswood really care about right was all about automation effort around shipping some simple hello program right the basic automation and it was all about counting and how many lines how many lines are this how many lines are that how many a boilerplate how many tools is all about counting and the presumption here is that a small count is simple and a big count is complex let's think about that there's a bunch of arrows all connecting something or going in one direction that's pretty simple and if I add more arrows pretty much the same amount of simple hat tip too rich for this example then I go and add one of them or two of them wrapped in a different way okay and that starts to be complex and obviously if I wanted to take more time in keynote I could make this really complex right we can have you know more more things but the complexity here is coming not from numbers it's coming from interactions and varieties of interactions and things working in different ways another thing that people talk about when they talk about something being simple is maybe beginner-friendly so there's a great quote here from the O'Reilly net blog most important gauge of any programming language is how easily a novice programmer can maintain a significant program in any problem domain Wow I just want to let that sit there right right somebody actually stated this it was not on April Fool's Day to pick any profession you want and translate that the most important gauge of any basketball playbook is how easily a junior varsity high school athlete can compete in the NBA Finals this is this is the most you know it's a wonderful example of that fellow sort of in 21 days for dummies a school of thought and embarrassed to O'Reilly I don't think that that is widespread and O'Reilly at all but since we're Dean is into the day it's rate to time so we'll do name-calling a related one and this one actually has the word simplicity in it simplicity should be fairly simple to read learn and understand Python is good PHP is great C++ and Scala not so good well one who's here today Britton Ashworth I think had a quote that for me really undercuts this sort of ease of learning argument if you are really concerned about ease of learning and that was your primary measure for something being you know insert any positive thing here where are you gonna end up and I think that ease of ease of getting started is certainly of value right that's that's absolutely something that well I shouldn't say absolutely this is one of the problems about doing a they we need talk about words is you become incredibly paranoid about your own words it's silly retract the word absolutely it is certainly in many settings of value that something be incredibly easy to learn I would argue that one thing you could sort of tweak that value a little bit is that if I'm gonna pick a hobby that I'm going to spend a few hours on it would be really nice if that was easy to learn right plants and zombies is great right you can learn that extremely quickly it's not a really good basis for building a career right being able to learn something in an hour is is doesn't seem to be a good way to build a career of course given that we're talking about closure here at the conference I would be remiss not to talk about syntax for a moment because there are a lot of conversation about simplicity that is about syntax and so you get this great quote we need constructs that are natural to humans not mathematics this is actually a sub bullet point to simplicity and the constructs should be consistent with the normal average non-mathematical trained brains the red highlighted words are the places where this is at maximum miss rhetorically but these are all words of people throw around as generic positive I mean anytime you see the word natural or normal or average non-mathematical is a little bit more domain-specific but natural and normal and average are all our rhetorical trick words right they used to have some meaning in the deep darkness of time but it's gone whatever it once was and so this is basically we're going to pick one word simplicity and then we're going to sort of weasel that with a bunch of other weasel words another one that's good is minimal maybe simple is minimal so you get this nice quote if the semantic model of a language is clear if the rules are simple and precise the language will be more productive to use less is more that's actually not half bad and has nothing to do with simple but it's not half bad the amusing part of this is that this is from a technical article explaining what language job so minimal is minimal is valuable but I don't want to really stop there either uncomplicated may be simple as the opposite of complicated some of you perhaps seen this cartoon which is a great cartoon so if you can't read the red boxes the product on the top is an Apple product which just has a button the product in the middle is a Google product which just has some where you can type in the find button and the picture on the bottom is your app so these things are all made this in this matters I think this is a great cartoon to show anybody who's doing usability design if you're worried about usability this is a great image this is from twitch if anyone doesn't read it it's fun cartoon on occasion and I want to be clear that a lot of these things that I've talked about when people use the word simple to describe it I don't think for the most part that they were being malicious they weren't actually doing malice to the word simple but they were actually trying to state something that they wanted and to some degree the things that they wanted you know possibly put up against other constraints were good things all right how many people want their programming environment and the tools they use to be convenient friendly to learn easy familiar minimal and uncomplicated that all sentence sounds great so interestingly one conclusion that you might come to after looking at all these things is I give up it's hopelessly subjective and I've been grabbing all these quotes from you know blogs and the web the great thing about the web is it's sort of like the law rights right anything that can be thunk has been before and so I wasn't the first person to think this maybe we should just give up right so one man's simple is another man's complex this is per this particular blog post was from a person who took umbrage to martin fowler's refactoring book and the particularly was that the conclusion that they came to was that 90% of MIT refactoring was making things shorter those of you who worked at relevance remember back in the day when I said that no no function event that could ever be longer than seven lines and if you showed me when I would prove that it was wrong in some way so I haven't on occasion I've been on the martin fowler's side of this conversation this actually harks back to an earlier implied definition of simple though doesn't it right it was about count all right this is a counting sort of counting characterization of simple if it's got a few things in it it is therefore simple and it has a lot of things in it it's the opposite of symbol which since we haven't defined simple again I'm not going to leap to conclusions and say what word would be the opposite of it this is not correct right simple is not subjective simple has an objective definition the definition informs designs and that's really important right this not only does it have an objective decision but you should care about it if you write programs and unsurprisingly right none of this is closure specific at all right everything I want to say today to the extent that it is useful at all is going to be useful in closure but also outside also simplicity is fundamental so what does it mean it's actually literally quite simple simple means not compound that's it not compound right and in a lot of the original usage this notion of being not compound was literally like compounds medicines right and so medicines that were made of one thing were called symbols and people who went out and looked for them there was actually a verb right simply I'd hard let me go out and do some simply alright I'm gonna go find some symbols that I'm gonna use to treat your rash or whatever and so how do we get from this which is a terrific definition and we're gonna do all sorts of fun things with this how did we get from simple becoming so complicated do you think I do not plan to wake up tomorrow morning with any major problems so in order to understand this we need to turn to one of the greatest programming minds of the twentieth century CS Lewis little-known fact so on the left here we have a nice picture CS Lewis and on the right we have this wonderful book called studies in words that see a slow stroke definitely pick it up when Amazon play this game to see what speaker can get most people going over names on buying something and on the right there is a bottle of really P scotch that's just product placement it actually has nothing to do with the talk it was in actually the book was next to it in my house but other than that just coincidence and a key element that informs this book is the notion of verb aside now in a closure context we're used to thinking nouns and verbs and kingdom of the nouns versus functional programming but actually verb itself has kind of been verb assign in right because where does it come from it means word re verbum is word and so herbicide is actually not the killing and CS Lewis being a language weenie herbicide is not the killing of verbs it's the killing of words and the specific killing is in his opinion is the fact that people are far more interested in expressing their opinion especially I approve or disapprove of this message than they are in evaluating and describing and being analytical about things and there are a lot of great examples of this in American English particularly potentially politically incorrect one I like to use those in my talks is that in English at one time there were a bunch of specific terms for different kinds of mental defect right they had meanings right so idiot and and these world many of these words if you actually look up their origin they actually had definitions now the social science and IQ testing and so forth that supported those definitions may or may not be well-founded but they had specific definitions what do they all mean now I don't like you they don't even mean they don't even mean anything about your tell right they just mean I don't like you and in that context you can sort of understand what simple is did simple become a generic term of praise or a generic term of disapproval trick question she kind of kind of became both right so let's look at how the original definition of simple ramified over time we start with not compound and then we get sort of three branches the first branch is unconditional so you have the notion of simple as being unconditional but thing in itself and so you say - really abuse words closure is simply awesome right what is what does that even mean it's right closure is generic praise word generic praise word it is it is in and of itself awesome and it actually was very difficult to come up with things that are in and of themselves good CS Lewis as a devout Christian his examples about this of things that were true in and of themselves were usually religious examples so he would say that you know God is simply good chocolate is good to me but not to my dog right so chocolate is not simply good there is a second branch of evolution of the meaning of the word simple which is not duplicitous and this one has a really amazing series of transformations you go from I'm not duplicitous right I'm not of two minds I'm not of compound mind if you will I'm not duplicitous I'm not guileful and in fact if I'm not guileful what we know about people who are not full of guile is they don't tend to notice guile and others all right so I'm unaware of guile and actually I'm credulous and then by the time it's finished being dumped down the word actually just means stupid alright so you are a simpleton and then finally you get the beginnings of the meaning that people are back at a little bit when they use it simple in debate and that is uncomplicated and the uncomplicated meaning is actually complex and that it has multiple sub branches uncomplicated goes towards easy wow it's so simple to do that it also goes to not posh right I live in a simple home you know that sort of thing and the not posh one sort of further branches to is it a positive or a negative distinction to be posh right and when I say my home is simple am I saying it's poor and second-rate am i insulting myself or am I saying you know unbelieva positive way and all of the senses of simple under the not duplicitous branch and under the uncomplicated branch kind of eventually head down to the sort of this general appealing 'no sand disarming miss and so simple becomes an emphasis word that is inoffensive to the extent that whether it's positive or negative it's unthreatening right so yeah i am a simple man right i think there's there's some small positive notion to that probably depending on how i say the word but it really is just you know a generic term and all these examples really aim at the part of when you start using the word in these ways really aim at the part of rhetoric which is called pathos right we've gone from appeal to analysis to appeal to what when is pathos appeal to emotion which is nothing wrong with there's nothing wrong with appealing to emotion appealing to emotion without having anything else is somewhat pathetic which is related to pathos now i wanna make a a tiny digression which was which really floored me when i was rereading Louis's book because I didn't really realize what a computer or he was right it's not something that people generally talk about but he makes the observation the specific observation that how words grow like this is a persistent data structure he actually says words grown as a tree right what does ramify mean it means to branch out but the original nodes are not gone you can still access them you can still get back to the original meaning and so Luis is quite specific that words evolve like a tree they do not evolve in a mutational way right like they don't have metamorphose in place and so one thing I want you to go away from the closure conference realizing is that mutable programming is like liking mosquitos better than trees things that metamorphose in place are really mosquitos another hour so we can talk a minute about mainstream object-oriented programming and in mainstream are all objects are compound they're the opposite of simple from our definition right that's the that's the dichotomy that I'm laying out here simple versus compound and objects give you a lot of stuff they have methods they have polymorphism they have types and interfaces they have namespaces they have structure they have uncontrolled mutation in most languages and it's difficult to explain closure some of you are probably going to go home and want to explain closure to an object-oriented programming or convince a team of object-oriented programs to give this a spin and it's not particularly constructive to say closure rocks oo sucks or to say oh oh rocks and closure sucks right I mean the whole notion of being passionate about simplicity would be to say let's break it down closure does not stand diametrically opposed to all of these things on this slide in fact it's not opposed to very many of them right these are going there's a ton of good stuff in Noah but the good things in OA are delivered in most languages in a fashion which is both complex and complicated so features in or delivered as compounds all right you get objects and they have all those things built into them those compounds tend to contain more than you need right it's actually rarely the case that you would need everything that objects give you say in Java and this snowballs from the language into the libraries right using oh with all these features compounded together leads to a snowballing of complexity and complication in libraries that are built in this pattern but we want is the goodness of objects but we want to deliver ala carte we want to deliver it as simples and if you look at what closure does and this doesn't really need to be stated much to this crowd it delivers every single one of the features that objects delivered in the other picture but it delivers them a la carte and so I've drawn all these the pieces spread out and then I have also added a dotted line around the foundation what is the one thing in the old world that we absolutely just stand against as closure programmers the uncontrolled mutation right the other stuff is fine it's it's a positive good all right but we want to have it delivered a piece at the time the other thing is we we're going to have an interesting discussion about the relative importance of different things right and maybe you don't agree with this relative importance so we can talk about it over beers later but we have a foundation we have a superstructure now let's talk about this with a few specific examples from closure so it's it's well I'm good to draw a picture but it may help to see some particular examples so polymorphism polymorphism is delivered a la carte enclosure via protocols and so this is from a recent check in the closure the diff protocol diff is a generalization of equals so instead of the notion of I want to compare something and find out yes it's equal or no it isn't I want to compare something and I want to find out what's different about the the first thing what's different about the second thing in what's shared by both things all right so diff the function which you don't see here does that and then the notion of comparing things for difference is actually built around being able to compare the different equality partitions in closure and it turns out that that set list and map are the three pieces that are needed in this particular case but the thing that's going on here from a simplicity perspective is that the protocol is being delivered as a simple ilyich heart it's not being compounded back into Java dot util dot set it's not being compounded back into Java dot util dot list it's not being compounded back in the Java dot util by mouth I'm not going to be on this because anybody who's been awake for the last two days who already talked about this in a whole talk she'll talk about protocols yesterday he made the specific some of the specific points about what's good about delivering this as a symbol right we extend to existing types and I do want talk about one side effect though one thing that falls out of this because this is was kind of surprising to me as we started to use protocols inside closure that the implementation contract is not equal to the caller API that can be true in the Java or C sharp app as well right we can have and then you would call it adapters or bridges or you know who knows what design pattern but it just falls out of delivering things this way that dissimilar is not a function that any clients ever going to call they actually call a function diff which delegates under different circumstances to dissimilar and other things and that notion of using protocols as the implementation contract is a positive consequence of having delivered a simple thing to begin with and it's a it's a side benefit if you owe namespaces in closure names the naming of things is on the cart through bars and so a name could just be a roll name it could point to data they could point to a function it could point to a class or to a polymorphic function and namespaces themselves are mere Maps I substituted the word mere and for simple realizing that I was getting myself in some sort of recursive trouble there the native space piece is really powerful because even namespaces are a good idea at all it's nice to have them available everywhere to everything else implementation reuse is delivered ala carte so if you look at this examples taken from closure dot Java dot IO if you look at the stream implementation it is a map of keys to functions and then various classes like buffered input stream have the protocol IO factory extended to them using that map but also not having to have a special mixin API right there's no special API for mix-ins with closure protocols what's the API it's the collections at the point that Marko granny had made earlier today right this is exactly the same point that he was making about rigging that because things are built out of symbols they're built out of values and functions you don't have a special API for building mix-ins now you might choose to write a collection processing function of some kind to help you make make sense if that use case came up you know multipliers and that thing wouldn't be simple then I would talk about that in terms of creature comfort and convenience but you don't have to syntax again giving us a list we have to keep coming back to this this one is particularly funny because the proponents and detractors seem to agree this is Paul Graham and you can't see it from this quote but the context should be followed by Lisp is simply awesome this looks strange not so much because it has a strange syntax but because it has no syntax this is from a blog post that could be summarized as Ruby rocks Lisp sucks and it says the problem with Lisp is that it doesn't have syntax so much that it has no syntax this being a a rocks sucks kind of blog post it also uses a lot of other words as generic terms of praise or criticism it uses the word technical to mean bad it uses the word regular to mean good the word sensible to mean good and their word clean to me good so if you really wanted to take the amazing thought that went into this Pro Ruby anti closure argument you could actually reduce it to this sucks because its technical and Ruby rocks because it's regular sensible and clean with none of those words defined by the way it's a rhetorical trick on my part all right as I'm telling this story right have I said anything about how much closure or will being actually rocker suck I haven't said anything right I may be moved you slightly emotionally like anti some hypothetical Ruby people you don't even know right so it's like a character assassination of some person I haven't really proven anything here I'm not being analytical right I'm drinking a beer and it's a Saturday afternoon so in what way though is syntax simple it's simple in that in a particular setting you have only one thing in play you don't have a compound in place so when you look at and this particular example is true for lisps in general right open parenthesis followed by verb and so people who find lisps simplicity to be beneficial appreciate this right it could be a function or an operator or a method call or an import or metadata or control flow scope it doesn't matter open parenthesis verb go a second example closure specific bindings bindings are always housed in a vector and this is a particular point you want to make when someone's talking about by the irritating parentheses enclosure is not full of parentheses and in fact it uses different punctuation in order to enforce simplicity right so when I see square brackets in code I know that names are being bound to something and all these things work in basically the same way and in particular they have access to what what is closures amazing sleeper feature that looks really creepy when you first start but this grows on you destructuring are these all get access to the same goodness because of that not binding right so I will point out here's the advanced version of the conversation which we can't here but there there are two wrinkles to this particular slide I actually have notes at the bottom slide which you can't see they're two wrinkles to this one of the wrinkles is binding which doesn't let you to destructuring and there's a reason for that and it's still simple or actually you could argue that there's that it's complex and warranted also fun and definite from the others and there's a more elaborated version of the simplicity argument but I think he's in play there as well we don't have time for that now so argument from Authority it's simple this is a particularly good one and this is one that I flubbed the first time the rich and I were teaching together I was conflating in my vocabulary rebels and shells and everybody almost everybody does this actually somebody was wrong on the internet about this just like 48 hours ago and it's been all I can do to not go on the internet and try to fix it but there was I think it was it was probably some of you if you follow the closure hashtag it was some Python programmers first reaction to closure and then the hacker news it's read there was a big conversation about whether the repple was special to Lisp or not and in the entire conversation it was clear that in the minds of both the pro and con arguers on the point that rapid shell were synonymous well rebel and shell are not synonymous and they are both compound things neither one is simple however which one is made of simple things the repple right the repple is one of my favorite things in closure now because it has an acronym to remind you that it's a compound of simple things what simple things is it made of read eval print in a lot of time beating up on the fallout of failing to be simple because I think as the closure crowd you probably already have felt this pain and that's perhaps why you're here but just think for a minute about what this I mean this maybe doesn't matter very much in arguments about she'll versus the repple but what is the fallout from not perceiving re and P as being different things what do you end up with well okay the reader converts serialization into data structure eval does stuff and P prints stuff if you don't have R&P in your world if you lived in a bereft world without R and P you would have to invent data interchange formats okay all of JSON and XML and all the problems that they cause fallout of not understanding this distinction and you've probably heard Lisp programmers complain that we invented s expressions you know 50 years ago this XML stuff is silly which is a whiny way to say it right because because it's because it's important and it's too easy to discredit them when they say it that way but it's important to it it's only understood to be important when you realize what the fallout of this is all right and not only is it not simple it's also in my view a stratification problem right that if you don't have reading and writing of data structures at the bottom then rediscovering that later it's upside down and it causes all kinds of problems I mean how many people have ever been seen in a website that got burned by somebody eval in JSON because they didn't have a reader but there's a ton of downstream problems that come out of this yeah what about VARs closure bar is actually suck right and why do they suck they suck because they don't deliver this promise of simplicity originally now for things that VARs might let you do yesterday rebinding air-handling redefining and global mutable state and as they're delivered today they are less good than they could be right as they're delivered today fathers are rebind of all you could remind them for air handling you to find them you shouldn't use them for global mutable State fine we're not going to worry too much about that and the code that he talked about yesterday the changes that are in master now make rebinding and error handling one simple and redefining a different one right redefining is one use case it's supported by def rebinding an air handling or one use case they're supported by dynamic now you can all count so somebody should probably raise their hand here and say well Stu they're not one use case you've clearly got two use cases call out in the chart there but really error handling is a sub case of rebinding and I think the reason that rich called it out yesterday is because it was a motivating use case for him when he designed it and so but those two and the flipside that is if you can come up with a motivated argument for where those who ever be different then they're not simple enough yet and it's a perfect example of the kind of design thing that we know rich was talking about when you're analyzing what you were thinking when you woke up I think these two things are the same they're really part of the same simple they're not a compound I don't need to tease them apart any further I'm done but I did have to kind of use cases so let me just sort of document that structure closure delivers structure a la carte and so you have this ability to say I'm gonna have a map and I'm gonna do all my map stuff with it key word access nested access what have you and I can switch to records and records just deliver structure write records document structure but do nothing else so records have first name last name address whatever but that structure delivered ala carte without any answer area stuff and the API remains the same right all this stuff all the calls right everything is still data it still looks like Maps now this is the point in the talk where I have lied to you because records don't really deliver structure Alucard what do they deliver they deliver type and they do these are for all kinds of stuff right they implement all these closure interfaces and so thinking about records for a while you might realize that there's something simpler underneath there is a distinction between data as information right which is what records are for and mechanism and so you end up having def record being built on top of a simpler thing def type right and def type really is a simple thing and the only ways in which def type is not simple you start talk about giving getting type and field access in the same go that's actually pretend like that didn't happen we'll talk about it in a minute so what's the most important thing to do if we're different thinking about using simplicity as an organizing metaphor for how we think about designing good code looking at closure for inspiration wanting to do this in our own code what rich said in his talk is that who needs to be a really harsh criticism of this thinking we do okay we're gonna look at this and say we think this is good we need to use that waking mind and ask ourselves what trade-offs do you make in the name of simplicity because all those things that I named earlier all those things that people call simplicity that weren't more valuable they just weren't simple the first thing I want to say about this is that there are no trade-offs in defining simplicity right in this talk I'm squatting on the correct definition simple equals not compound all the definitions that I gave earlier all the definitions that come out of the pathos from uncomplicated too easy to simpleton and all that stuff those are literally follow-on definitions they are not the original definition more importantly simplicity is fundamental it's literally fundamental if you look in the dictionary one of the definitions of simple is fundamental so if I win right we get to kid we get to keep this what is fundamental me yeah those are easy simple right it's at the bottom in what we'll in what specific sense what other word in English is related to fundamental foundation right so it comes from Latin fundamental right that means the foundation and the point that I'm making here and by the way again I'm gonna have to make this is gonna be your Socratic homework assignment so you need to have a Socratic dialogue with yourself in which you pick any of the other definitions of simplicity from the beginning of this talk so easy to learn or made of a small number of pieces or minimal and make that your foundation and then try to build stuff with it right try to design stuff with that as your foundation and then try to get to simplicity as a follow-on or a derivative concept and see how that works for you and then try it the way I'm recommending is the correct way which is make simplicity your foundation and design things that way and see where that gets you and if I had an extra power I think I could have a lot of pathos appealing slides to make a stronger argument or a stronger emotional appeal that making simplicity the foundation is the right way to go but try for yourself now I've just actually performed another rhetorical trick because I told you that I was going to talk about trade-offs but what did I didn't do I said this is not a triumph right there's no trade-off made here there was no alternative choice from a design but that there was no other goal other than simplicity that I was comparing it to I used it as a rhetorical trick to go back and just piss on the other definitions of simplicity one more time but there is a really big trade-off that closure makes that compromises simplicity and it's systemic and it's painful and what is it it's living on the JVM all right it's living on the JVM so why don't we make why did which make this trade-off what does the JVM give us it gives us a performance it gives us power it gives us reach right we're not lists we're not on an island the JDM trade-offs include primitive operations conforming to the Java collection api's lack of tail call optimization weird earlier on performs that don't represent how to do work the right way but are necessary so gym class and proxy alternate numeric operations unchecked integer math and so forth and these bubble up to more painful and more perhaps regularly occurring API trade-offs if I'm consuming a Java API I may still have to deal with the uncontrolled mutation I will have to deal a lot with premature abstraction which we remove that's called distracting de stranding right going back and getting really bad abstraction and turning things back into sets and maps I have to deal with implementation inheritance annotations and pattern bloat and I put bloat there with a question mark because I would normally make the argument that patterns are just bad period but that requires another hour so we'll just say that that too many patterns is bad and then you can all agree with that because it's in the definition of too many and then you get eco system trade-offs so there's a perception in the Java world of binary delivery that's pretty hostile right to a lisp we don't really need to have compiled binaries match up with each other but it causes pain points in various serialization we're spending time worrying about XML and JSON API version linearity this is actually an ecosystem trade-off that everyone's dealing with right now all right this is actually probably doesn't really fit in this flag but I wanted to mention it because it's an issue right there's a presumption of version linearity and how we deal with deployment that's not really true with a get anymore but there are a lot of tools that think that and then living in the Java ecosystem we actually have to wrestle with a lot of tools or ecosystems right so it now works on NetBeans and it doesn't work on Eclipse and tomorrow we get it working on Eclipse and then it doesn't work in IntelliJ IDEA I mean this is the pain reward trade-off for being on a big platform where lots of things happen so there's a ton more I would like to say about the ecosystem trade-offs there are a lot of specific things that we do in the ecosystem trade-off land that are complex and complicated because we're on the ecosystem and we have to make really hard design choices and I think there are really fun conversations here and they are around things like how Leiningen lives on top of maven those kinds of questions have a lot of interesting stuff that happens there we're gonna have to save it for a beer at barbecue the other thing you want to talk about is using this to improve your own designs so it's great that to some degree or not the rich has drunk from the well of simplicity in his visit enclosure on us but I'm going to be more than just a consumer of these benefits all right I don't want to have a superficial head start using closure just because there's a bunch of good stuff already there I want the things that I write and the things that other people in the community right to also embody this kind of simplicity and so there's kind of a and now now this is I'll call this my this is opinion subjective portion of the talk there's kind of a formula you might follow that's right everything else was fact there's there's a model you can follow to try to make things simple and I'm gonna walk through this in the design of a specific API so broaden your context tease apart known compounds so when there's something already floating out there that's a compound break it apart into simples find new simples go directly to data asleep on it and I'm gonna go through these steps in the design of a specific API and how we got there so with closure went to one - I made a great effort and other people that community made a great effort to get a bunch of things in contributed into closure so that certain projects wouldn't have as many dependencies into closure and one of the things that didn't get there is a wonderful little function that Chaucer wrote called show and what show does which is putting his head as hands yet again rich looks at chancellor's code and puts his hand his answer so what show does is gives you reflective introspection over the Java thing you're working with I think closure is a kick-ass environment for exploring Java libraries and I'm not the kind of guy that goes to Java doc I'm much more likely to look reflectively at objects and understand what they do so I wanted this and I propose that we promote it forward and rich put as heavens hands just like we just did and the problem here is that this API is well let's walk through the issues and see where we end up so broader context it turns out that the compiler needs reflection too so if you're gonna write something that's gonna be reflective it's not just replica sumers right there you have to think about other potential consumers and this is one of the things you might not know when this rich just told you some users would reflection don't have classes in hand other uses of reflection must have classes in hand java api is from a reflection can't be instantiated by normal code i can't create a java dot light dot method all right our Java dot Java leg reflect method or a java.lang reflect field the only thing I can do is get them from a class which means that they are not useful as a baseline for reflection if my goals include people that don't have a class in hand and people that do have a class in hand so the first cut that I took at writing code that would solve these problems worked as follows there was a repple api designed to replace chalice show called describe which called a more data-driven api so i'm calling down with something simpler reflect which had a pluggable implementation via a protocol that allowed me to use different reflectors in particular to handle the different use cases of people who have a class in hand or people who don't a set of predicates were used to limit the results and then a regular format protocol printed things out as a table and so now you've got a reflection API to look like this described string named last and so this finds Java dog nut string the print out tells me things that start with last and then prints all things might be inadvertently funny now what's that and I said this hands again yeah so this is the first design that I showed rich and I was painful so this this does not suck compared to a lot of stuff that's out there any news right you know there's a nice little mini DSL for describing and it wasn't just name there were bunch of little predicates and you know lots of little helpers so that all the wreck would use cases were covered and this actually did cover the repple use cases and the compiler use cases but iterating through it we said okay maybe this is still compound given that the whole point of this talk is using simple as a design principle this is still compounder what things are conflated in here well there are multiple entry points both describe and reflect is that really necessary all right if we can find a world at which there's only one entry point that would be better there's explicit wiring right so the API actually had slots in it where you dropped in the next step and then slots in it where you dropped in the next step there were specialized matchers specialized mattress feels like failing on the promise of having general data and there was custom printing at the end and so the next round which is currently in and looking for feedback was that there's a single function reflect which uses the reflector protocol that part was good generic wiring and the generic wirings already in closure right I don't need to have all these lil API slots to channel one thing to the next we could just use the arrow operators predicates are just generic functions right there's no special thing there there could be a really cool closure dot dated a match that did that but there's not there now and then another simple print table so instead of having something that could print out a nice tabular representation of reflection how about something that prints out a nice tabular representation of what anything and so the new version looks like this you arrow reflect java.lang not straight you grab the members you filter anything you want you print table now this is not as concise as the inferior API but it would be if we had closure dot they do not match right we have a way to do mattress in the middle and that would be fully composable and the big thing here is what was originally a compound of solving the reflection part which was done okay and doing the filtering which was compounded in unnecessarily and doing the printing which was compounded in unnecessarily has now been realized in three separate pieces whether which still represents work to be done so one of the reasons that I jumped to the wrong way to do it is I wanted to kind of solve the complete problem and one of the things that falls out of wanting to be simple it is needing to be a little bit more patient so the practices that we saw here broadening your context it's asking who the other users were teasing apart known compounds right so finding out that printing and filtering all this thing's were separate idleness looking for new symbols getting straight to data and several iterations of sleeping on it without having any alcohol or how to get there it's really good Newcastle so there's a ton more I would like to say about this one thing I'd like to say is I do think that there are other things that compete with simplicity as a decent foundation as a decent place to start and I think there's interesting discussions to be had about that but we're done we are at the end of our time here you

Channel: ClojureTV

Views: 20,152

Rating: 4.9634705 out of 5

Keywords: clojure, programming

Id: cidchWg74Y4

Length: 50min 0sec (3000 seconds)

Published: Sun Dec 16 2012