"Agility & Robustness: Clojure spec" by Stuart Halloway

good morning strange loop my name is Stuart Holloway thanks for having me I'm really excited to be here and I'm gonna be talking about closure spec and specifically about agility and robustness in programming and how close respect can help with that and I want to start with a very brief background of the things that worry that I worry about everyday that shape to some degree the characteristics of spec and why I want to use it I'm the founder of a consulting company cognate echt originally relevance that's since 2003 so I have 13 years of building systems for other people and you know moving from project to project I've been a closure committer since closure 1 oh and so I have had you know responsibility for a substantial open source project I'm also a developer on the atomic database so it's commercial product development so a lot of different you know kinds of software development I also run the support team at cognate echt so I get to really eat my dog food when we make software you know whether it's consulting or open source or product software and it's not working out great for people I am where the buck stops and we get to hear about it so which shapes your life a lot you know compared to my early days as a consultant where you just write your software and then you get to walk away and somebody else has to worry about it and I'm also responsible for operations for a lot of cloud software and so these things combine to have n'cole cated in me a real life cycle view of software that includes everything from you know before ideation - you know maintenance and you know working on a really brownfield and so when I think about these things I want a lot of different things and I'm going to talk about three of them today I want programs that are correct I want systems that are correct that are free from error I want to be agile I want to be able to move quickly and easily modifying systems changing them to meet needs and I want my systems to be robust I want them to be able to withstand adverse conditions and as an industry we have a lot of techniques and language for level practices and other kinds of things that help us do this and I can't cover them all today but just a sampling of some that have been important to me you see a lot of people using type systems or example based testing which a lot of people start with calling unit testing to try to ensure that their programs are correct to be agile requires a lot of different things some people leverage encapsulation so I know that I can make a change over here and it's not going to cause you know the lights to turn off on that side of the building because those systems are encapsulated from each other now people also rely on IDE s that can automate refactoring so you can take a large and complicated code base and move it without having to touch tens of thousands of lines of code yourself and people also have come increasingly and I think correctly to value what I'm going to call local concision which is that you know at the micro level when you're working on a specific problem you can answer that problem in three lines of code or one line of code instead of 30 lines of code you know spread across ten modules and if anybody like me worked with the first versions of Java's enterprise javabeans you'll know exactly what I'm talking about when you want to have local concision in order to be agile robustness is a little bit more of a greenfield for us as software developers so I'm not going to sort of lay down establish practices here but you see people doing things like chaos engineering and fuzz testing and simulation testing and generative testing but I think you know we have a lot of room to think about those things a closure as a language does not change all of that right closure programmers do not say you know don't want tests don't want types don't want those things but closure adds a particular spin that helps out in all of these areas in terms of correctness closure encourages programming with pure functions and closure also has a distinctive model for state called the unified update model in some circles and a model for flow with channels and so these are all things that help you write correctly you know out the door they help you write small things that you can compose about and reason about fragility closures real buzzword is simplicity if you make simple things you will be able to take the Legos and recombine them a different way whereas if everything is all fused together you get stuck and then you know at the language level there's not necessarily a huge amount of help for robustness but immutable data makes a big difference if you know that the data in your system never changes it's much easier to walk up to a system that's in trouble and figure out what's going on and I actually think this is probably the stealth advantage of functional programming wearing my ops hat is being able to walk up to a system and say we're in big trouble here but I know that ninety ninety-five percent of the information in the system is just sitting there in RAM and never changes because it's immutable so I can immediately rule out the class of problems that come from well when I looked at it a minute ago it was like this and if I come back and look at it again it's going to be different so and then I have this other term here which I've put in all three rows and I'm about to define or characterized at least which is systemic generality and so the idea with systemic generality is that all domains use the same general purpose data structures we're in a lot of languages you would make up a new type or make up a new class or a new object to represent every entity in the system closure encourages you to represent entities as for example maps or dictionaries and so you might walk up to a system written in C sharp or Ruby and find hundreds of classes representing different things in your domain and in closure you're gonna find one class and you don't even see it as a class right you're gonna find maps and you're gonna program with them and the advantage of this is really summed up by the perlis quote which is it was better to have a large number of functions that all work on a single data type then to have a lot of disparate functions that work on specific data types and enclosure this generality is extended by being systemic so when you write closure programs you have the ability to use these generic data structures everywhere you can use them in your code but you can also use them in your configuration files which could be written in Eden you can use them on the wire with Eden or with freshen you can use them in your durable store and so what this does is it gives you the ability to write really small code and work in a very general way and have the algorithms that do that job be much better vetted because there's a small number of them right that's kind of a downstream consequence that people don't necessarily immediately think about so you have instead of having 10,000 different functions in your system you have a hundred if you have a hundred you can spend a lot more time making sure those 100 functions are correct you can make a lot spend a lot more time making sure those 100 functions are fast and then doing this across the system means that you don't have to have toll booths everywhere in your system where you're crossing a boundary from is this my code is this my configuration I mean how many people have written something that they're totally happy with from a unit testing perspective or from a static typing perspective and then it falls over in production because there's something busted in an XML file somewhere or if something shows up in a bit of JSON that you didn't expect so taking the systemic approach is really valuable and you know closures been around for over a decade now and so we have some experience reports with what it's like to program like this and the fact of it is it's pretty good right people say great things this is a quote that's been used in you know closure talks before talking about developers the very best programmers are producing amazing things and they're doing so really quickly so this is great and if it were 2015 I would stop right now and we could all hang out for a little bit just chat and get to know each other or we could dig in and do a deep dive into the stuff that I just talked about talk about functional programming or immutable data systemic generality but I want to do something totally different today which is talk about a problem that eats at the conscience of closure development developers and that problem is that this systemic generality idea is fantastic except that we all work with specificity right when you sit down to actually work in your domain you're actually thinking about addresses or order items or models of the human body or models of equipment on a factory floor they're actually specific things and so the closure promises you know your life is going to be better if you talk about those specific things in a really general way and so what happens is people have to be disciplined in how they think about specificity right closure doesn't have specificity as a language objection objective it's kind of the opposite and so thinking about specific things is you know on you and people go through two phases with that if you're an outsider to closure especially if you come from a world of static typing it's just downright scary right everything that you look at in your traditional programs that you're used to writing that shows you how this domain is different from that domain and what's interesting about your domains appears to be gone enclosure right in the name of this generality then you use closure for a while and you come to conclude that this is very powerful in its delivering assistance not perfection but assistance on writing correct programs and being agile and writing robust programs and so then you start to sort of justify closure to your friends as a winning trade-off right we had to you know lose our ability to talk about specificity and we get this trade-off and it is a clear win right you know it's it's you know five ounces of win and one ounce of pain or you know you'll come up with your own you know numeric scoring system but it seems like it's a big win and what I want to do is take the next step and say there's a way to approach this where this doesn't have to feel like a trade-off where it's all winning and so you can program in the most generic way possible and still still deal with the specifics and that's what close respect does closure spec is a standard powerful integrated system enclosure for specification and testing of your systems and so this really answers the challenge of how do I program generically and talk about specific things and it answers it by saying not you have to be specific everywhere which is what static typing and object-oriented programming sort of the direction that they take you but saying that you can be specific in an ala carte way sort of right running alongside your actual code sort of separate place and you can do this without sacrificing generality and then you can leverage the specificity at your discretion so it's an entirely opt-in proposition there's a bunch of different things that you can do with spec or you can do know things with spec or you can not like spec and keep programming closure without spec and spec won't care right the bits are really insensitive their feelings will not be hurt if you choose not to use them and so when you think about closure and spec together you get a ton of new power that helps with these objectives that I have because you have a way to do declarative specification it's easier to look at a system and sort of convince yourself that you're moving in the direction of having it work correctly also you can automatically test your system with closure spec so when you write your specs you don't write tests and spec writes your tests for you if you've ever spent time maintaining a test suite you should be very intrigued right now also it allows you to instrument existing code at development time so you can say I want to run in a development mode where I enforce you know arbitrarily more complex programmatic validations of data and functions and you can turn that on and you can turn it on a little bit right you can turn it to four or you can turn it all the way up to eleven you can actually call instrument all which would instrument every single symbol in your system that had a spec on the agility side a lot of being agile is being able to walk up to your system and understand it and manipulate it and spec gives you several things here gives you documentation so it adds to documentation automatically it gives you explanation so when you have a piece of data or a function that you've used incorrectly spec will tell you what is incorrect about that use which is right you know you could sort of put that under the rubric good error messages on the other side of that though spec also provides conformance and what conformance lets you do is say don't tell me how my data was wrong tell me how it was right and so conformance allows you to get information about the ways in which the data conforms to your domain and oftentimes you're gonna have and we'll see some examples you know data that could be conformant to your needs in more than one way suspect helps you understand what went wrong it also helps you understand what went right and when you spec something closure can generate example data for you so you know there are a few people in the world rich Hickey for example who think only in the abstract at all times and you know never actually touch keyboards and just manipulate things with their mind but most of us benefit from examples and so one of the things that's fun about developing with spec is as soon as you've made a spec and it can even be a very rudimentary one you can then say give me example data or give me example functions that do this finally the tools that spec provides can be available anytime so they're not available only at compile time like type checking they're not available only at test time like a test suite and so you can have the same smarts that you use to understand how your system is put together in effect at layer boundaries at runtime without writing new code I mean how many of you have had the experience of you know having individual modules work pretty pretty well but have to go and write a whole bunch of special stuff at the edges just to make sure that things are happy now a lot of that you get a lot of leverage for doing that with spec because once you've written the spec you can use the spec for that job so you're going to compare this to testing and static typing and Twitter is going to have fun with it and so here's your controversy slide color coding and all we'll spend a few minutes on this and then we will look at the actual use of speck and look at some code so expressivity testing is very expressive because if you have the arbitrary power of your language at your disposal right it's expressive as your languages type systems vary greatly in expressivity a lot of Industry code is written in things like Java and c-sharp which are not very expressive and then people do cooler stuff with you know Haskell or liquid Haskell or Idris but on balance you know type systems have varying expressivity and they certainly don't express things that you only know at runtime because they don't you know sort of play at that time spec is written in arbitrary closure code so it has arbitrary X passivity just like testing does example tests really allow you to aspire to stakeholder correctness right is it correct in the sense that the person that paid me to write it is happy and spec also does that type systems you know are gradually moving in this direction but if type systems actually solve this problem then as soon as it compiled everybody's job would be over and statically type systems wouldn't have bug databases right because we would know that static type correctness was equivalent to everybody was happy and we could just move on clearly not true testing tends not to be integrated in the language there are a couple of more recent languages that really do integrate testing approach at the language level but for the most part we use testing tools that are sort of add-on types are definitely integrative in your language so in fact they're kind of two integrated and so you know cool work is happening now to sort of have types be less integrated with your language so you can sort of opt-in and opt-out of them but generally the actual industry experience with types is you have to flow them around everywhere and so you do something over here which causes a type problem over here which cascades over here and now you're over here and that's called the X shape so specs are integrated but they're integrated dynamically so you can you know adopt them to the degree that you want and where you want example tests are not specifications right they're not they tend to be sort of ad hoc things types very much our specifications right type systems are specifications although they're static in nature and spec is obviously specification because we named it that so it has to be right but they are specifications and because they are dynamic because they exist in the runtime of your code you can do sort of what you want to with them so testing with writing test by hand is writing tests by hand it's my use of the word manual in the table right if you're writing tests by hand that's what you're doing and then you have to babysit those tests and you have to keep them working or comment them out or walk up to an existing system where the test suite has 300 tests that are still passing in a thousand that are not and you know try to figure out what to do about that type systems actually can be used to generate tests but that's pretty rare so that's that's a column where type systems you know as used in industry it could really you know take off you could actually use types to say given these types I want to automatically generate examples from these types and and test from them so that happens some it could happen more and the spec it's the default all right you write specs and you can get generative tests for you based on those specs so testing is promoted for agility but when you take a systemic view of testing for agility it's very expensive because you know that you end up having to write a cascading set of tests right you have to write small tests you have to write medium-size tests you have to write tests that cover the boundaries you find redundancies in the work that you're doing and so tests do help with agility I'm certainly not going to argue that we should stop writing example based tests tomorrow but they're expensive to maintain type systems as they're used are fragile because of over specification and this goes back to the point about the general versus the specific if you say really specific things all over your codebase then when you change something that causes a pachinko effect where things are sort of bounced around through the codebase and you have to sort of update that with spec you can spec as much as you want or as little as you want and you can enforce a la carte so enforcement is entirely separate from making the statements to begin with and then reach again example tests can reach everywhere you could write unit tests the test here the mail configuration file but it's expensive right people tend to focus testing on certain parts of their system and you know less energy in other places type systems tend to reach only the code parts of your systems you don't have type systems on wires or in storage or in configuration files and things like that and of course because spec is built on top of closure it has that kind of reach so if you're coming for the why do I care we're now done this is this is why this slide is really why we built spec and what we were trying to do with it and then I'm going to use the next 20 minutes to talk about you know show you some code and show you what it looks like using it so having written specs what kinds of things can you get help with well you can find out what are the building blocks of my system because you have this declarative specification you can ask what invariants hold about data or about functions you can say make checks for that and turn those on validation you can get detailed explanations of what went wrong you can get detailed explanations of what went right you get automatic documentation you get automatic example generation you get the ability to turn on instrumentation inspect functions in development time this is a development time feature need to emphasize that turn on instrumentation that allows you to do small medium or large and complex validations of your function calls and making sure that they're being called correctly on the other side you can make sure that your functions are implemented correctly by using automatic generative testing and then you can leave assertions in your production system that leverage this same thing so you know unlike with types and with tests which tend to be kind of gone well you know once you're in production these things are still there and you can opt in to the exact amount of sort of protection you want now in order to see all this you have to know closure and in a long-standing strange loop tradition I'm just going to assume you know closure and skip past these slides I'm gonna give this talk in other environments later but for now I'm just going to assume you know closure because we got a lot to cover and we're going to talk about the actual building blocks here so we're gonna start with you know what does it mean to make a specification well if you're a closure programmer you already know how to make specifications because all the predicates in closure our specs and so these predicates cover things that you might think of as like primitive like if you're looking at it from a Java language perspective so things like a mile long or a Maya double they also cover things that are class like so things that are like a Maya ratio or a string or a UUID but it also includes predicates that cross cut things that the Java type system underneath closure doesn't anything about so you can say am I a rational number which is actually the union of types that don't have a type relationship between them but it goes further than this you know any arbitrary predicate can act a suspect so predicate sar not limited to talking about the shape of things they can also talk about the runtime values that they have so you can have a spec that says something is something a specific value like true or false or in the set 0 1 & 2 you can talk about the ranges of things so is this a positive integer is this a negative integer and really you can talk about arbitrary runtime facts maybe if you can write a function that takes an argument and returns true or false you're now participating in spec right you can write your own predicate and that predicate is now expect and you can use it in all these ways in your system of course we have collections and there is a rich set of support for collections but just to give you a little bit of a flavor of it you can say just what's in my collection so call of string is this is a collection that needs to be full of strings and strings only and then there's a lot of bells and whistles so you can say I have a collection of integers but that collection has to be of a vector shape and there have to be at least 5 integers men count 5 but there can't be more than 10 so max count of 10 and by the way all the integers are distinct all right so the integer 2 can't appear in there again you can have heterogeneous tuples so this is a you know a pain point sometimes in languages like Java where you really want kind of these generic things you can just walk up and say ok this thing is an INT followed by an INT followed by a keyword and of course everything composes so you can say I want to make a map of keywords to collections of integers so this might be you know all of the different characters in a game and then their scores or who knows spec also has boolean operators and and or so you can say more than one thing has to be true about a piece of thing you can say this thing has to be a string but this is a string that represents a SKU and my catalog system so it's a string but it also has to start with SKU - or you can have an or so here we have a system where imagine that people can identify themselves either by their assigned numeric ID or by their email you can say that a person's identifier is either a positive integer or a string now once you start making these compositions in more elaborate specs you very quickly want to have named specs all right you want them to be a first-class thing in the language so you can give them names so the deaf form allows you to give specs names and you can say things like my app / SKU is a string that starts with skew and purchaser is someone who has either an account ID which is an int or an email which is a string and now I'm going to be processing a CSV file so I'm gonna use specs to describe an existence existing CSV file out in the world which has three columns in it it has a purchaser which could be that integer or string it has the SKU which has to be a string that starts with SKU and a positive integer which is the number of things of that SKU that that purchaser purchased or whatever and the the names here are global names so these are namespace names the double colon enclosure here's your one little closure tidbit for the day double colon closure is such a shorthand for in the current namespace so this code is all running in the my app namespace so my app /q could also be double colon SKU and so the important thing there is that when you have named specs then we can share specs across projects right you can build a spec that's composed of some specs that I wrote and some specs that are in closure and all of those things can work together because we're not gonna have any name collisions specs can also talk about syntax so syntax is from the Greek it's about the ordering of things and if you're not actually a language implementer you don't spend a lot of time necessary thinking about the amount of time we as humans are using order to get meaning out of something and so spec has a integrated regular expression library it has catenation so this comes an order followed by that followed by that it has alternatives so the alt form says you know at this point and the syntax you could have this or you could have an at it has all the things you expect to have in regular expressions but these are not regular expressions of strings these are regular expressions of arbitrary data so this is more like the computer science regular expressions than like the Perl regular expressions that your might think of first when you hear that word and so when you think about what that looks like you can now start to spec all the forms in the language itself so this is a very small closure program that defines a function called greet that takes an argument called your name and then returns a string which is Hello followed by your name well the spec for that is a catenation of the name which has to be a simple symbol followed by a doc string which is optional so notice the question mark there the doc string is optional followed by some metadata well I don't even have any metadata in this example so that was also optional and then the body part is actually quite complicated and so you're taking advantage here of the fact that you can have name spects so the bees their name body or bodies that thing is some complicated spec that describes what the shape of the internals of a closure function are you can spec maps as information and this slide is essentially the replacement for oo right when you think of oo as sort of encapsulation and entities and getters and setters and things like this so this is saying I'm going to talk about a map but I'm gonna make you make a new thing right you're gonna keep passing maps around your program and when you want to be specific you're not gonna stop using Maps you're just going to talk about your Maps somewhere else with a spec like this and this spec says and you can imagine that this is a spec for you know an address book entry that an address book entry consists of a name and a street and a city and the state and the zip and optionally a street to critically here this spec does not say what the shape of street or city or those things are specified elsewhere which means this whole system composes you can take this and I don't even have to know what those things are in fact those specs don't have to exist right you can absolutely use name specs that don't exist up until the point where you have to you know program against them and do something that wants them to exist but just talking about things you can talk about things and they don't even have to exist yet so you can sort of build this in any order so that's all about specking data but you can also spec functions so when you spec a function well what is a function a function takes a list of arguments well that's ordering so that's syntax and a function returns something that's a return value so here I have a function called index of that takes a string and something you're searching for and maybe a start position and you can spec that as a function you can say well the args for index of are a catenation right any argument list our function is a regular expression that's a catenation of its arguments it's a string it's an alternative of either a string or care and then optionally a start position and then the return is Anila both natural int so my index of returns the position of something that it found or if it didn't find the thing it returns nil so this is pretty cool right this allows you not to just talk about data but to talk about functions but where it gets insanely cool is when you add the third element two functions which are semantic specifications so what are the semantics of a function the semantics of a function are the relationship between its arguments and its return value this is fundamentally a dynamic thing right you have to run the function to see and in this case I'm going to specify that index of has to categoric outcomes either I can find something or I can not find it because I have the or form I can give those things names and then I could say what each of those looks like well if it's not found the return had better be nil and if it is found the return had better be less than or equal to the size of the search string right that is a runtime thing so the search string happened to have 30 characters in it if index I've returned 50 that's a buggy implementation right that couldn't possibly be true so these are predicates of the actual behavior of the system now notice at this point that I have given you a painfully whirlwind tour of a bunch of different things that you can say with speck but I haven't actually said what happens in your program when you say all these things and the answer is nothing you say all those things and now you have you know a set of you know descriptions of data and your system sitting on your shelf and you can do stuff with those descriptions when can you do stuff with those descriptions it is absolutely up to you which of the things do you want to do with those descriptions it's also absolutely up to you so we're gonna dive in and take a look at them so we'll start with validation so validation is through a call called valid so valid takes a spec and then some data and it returns a boolean telling you whether or not that data matches the spec so here I have a collection with ABC and oops and one of those things is not like the others right oops is not a keyword so valid returns false now like most boolean functions valid cuts the universe in half but it's not very exciting to look at on a slide it's not a whole lot going on there so what you want to know is not just you know that you're wrong but what went wrong so you can also say explain to me the way in which this data does not match my spec when you ask for an explanation you get what was wrong the value oops was the problem a B and C were fine you get how it was wrong the predicate was keyword which you didn't match you get what position it was wrong at it's at position three zero one two three we're zero-based by some weird tradition that started in the 70s so now you have a detailed and precise pointer to where your problem happened and by the way this detailed and precise pointer this is all compositional so if you have you know the JSON ball of mud from hell that's got something wrong with it you know 17 layers deep in that thing then you're gonna have a path through that thing and a thing pointing you exactly where the problem happened so it's nice to know how things went wrong but you might also want to know how things went right so you can say conform conform takes a spec and some data in this case this data is actually program code and it tells you and you can follow the read here the red line it tells you how the value matched well the symbol your name was in the bees branch of the or it was in the air D one branch of another or it was in the args branch of the args branch with a sim ranch every one of those five things in red represents a point at which this thing could have been a valid function but it looks different right and the spec for defin is a pretty rich thing right there's a lot of different things that happen that are legal in defin so it's a complicated spec and conformance gives you the ability to say exactly how does this data conform this by the way also gets rid of a ton of ad hoc parsing in your own program right if you're having to interpret something that's ordered the first thing that you want to do is often give names to that order well spec gives names to that order and then you can call it on an ala carte basis if you're an experienced closure programmer think of this as D structuring on steroids right this is data-driven destructuring where you can drive the restructuring sort of anywhere you want of course you get documentation and example data so having SPECT that letter grade is a function that takes a numeric grade and returns one of the letters a B C D F then in the documentation string you get aspect addendum section that says you know here's what this is I have found that a lot of times once I starts pecking functions I don't actually put anything else in the docs string right I just let the doc string get the little spec addendum and that's all I need to know you can also get sample data so you can say well I know that a grade I'm gonna define that a grade is a number it's this American at least the grading system I have when I was in high school a grade is a number between 0 and 100 and then I could say exercise grade for me when you ask closure to exercise a spec it will generate examples that conform to that spec and show you how they conform so the reason that you see pairs here is the first piece of data is the data that it generated and the second piece is how it conformed when you're conforming as a number how it conformed isn't very interesting right because it can only do one thing so there's nothing in that second value that's interesting in that case you can also if you expect a function exercise that function so here there's some function letter grade that takes a numeric grade and returns a letter I could say exercise this function for me and spec can generate data that represent inputs to the function call the function for you as many times as you want and then return the output that results and you can eyeball the Cinco yes well 94 should be an A then 60 should be a D you know if that all looks pretty good well once you have this ability to generate data including function calls in your system you have access to some powerful capabilities for making your system more robust you can instrument your system so here's a scenario where I have a development time switch that says start server is going to be instrumented I don't even know how it works and then I'm going to call it I'm going to call it incorrectly it turns out port default is not legal when instrumentation is turned on I'm gonna get a specific error that says port was the problem that this spec failed that the problem happened in this line of this module of my program and this is not a static thing this is a running thing all right this is not you know you run you you're limited to what you can do at static time this is you're running your program and you can turn this you know you can turn this up to 11 and say you know something's going wrong here I don't understand how this other subsystem is using what I'm calling maybe I'm not calling it correctly similarly you can test automatically so you can say please check this for me when you ask spec to check something for you it's gonna say generate an arbitrary number of inputs until you get tired I think the defaults 100 it's going to invoke the function for you and then it's going to check the return predicate to make sure the thing is structurally sound and then it's gonna check the function predicate to make sure that the things semantics are sound and if it finds a problem it's going to shrink to a small repo automat reaper before it goes back to you so it's gonna find some big hairy example that shows that your program is broken and then it's going to heuristic ilish wrink that down to a tiny example so here it found a bug in a buggy deliberately buggy program with a really tiny argument set of the empty string and the string 0 and of course you have assertions where you can take the same detailed error messages and sprinkle them where you want to in your production system so you don't put them everywhere but maybe on certain boundaries in your system or certain internal places where you have presumptions you can turn on assertion you can leave assertions in your code if check asserts is off there's no runtime footprint so in summary spec is about doubling down on being a dynamic language specification is a problem but you don't need to be more static to solve it okay specification is a dynamic idea it's something that allows you to deliver simple specifications separate from your code and then pour in value invalidation in error checking in conformance in testing and add exactly the parts of value that you want so where are we this we're on closure alpha 12 of closure 1 9 so I've done we've done 12 alphas here I expect we will go beta soon so this will be beta soon people are already using it in production but it is early days we are eager to get people's experience reports there's just a ton of really cool stuff that people at Strange Loop we're doing and we'd like to know you know how it works with spec having said that take advantage of the dynamic nature of spec this is not an all-or-nothing thing that you have to jump into with both feet and do everywhere try using little bits of it here and little bits of it there be thoughtful about the danger areas and one danger area is definitely over specification right spec has tried very hard to be as dynamic as possible and as flexible as possible and to not require you to make overly specific statements but you can make whatever statements you want it's a general-purpose programming language so I predict you know five years from now I'll have consulting work going in and helping people make their specs more general and and keep things as general as they can so that's definitely a challenge area also generating data is there are a lot of interesting things to explore there which we don't have time to do today if you want to learn more about closure spec you can see the website closure org about spec and I will be out on the hall we don't have time for questions here but I'll be out in the hall for the next couple of hours and if you're interested in talking more I'd love to hear from you my name is Stuart Holloway and that was closure spec thank you

Channel: Strange Loop Conference

Views: 20,699

Rating: 4.9670329 out of 5

Keywords: Clojure, clojure.spec, functional programming

Id: VNTQ-M_uSo8

Length: 39min 59sec (2399 seconds)

Published: Sat Sep 17 2016