Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#10 - Spec.ial
61 Plays9 years ago
A discussion about spec
For detailed information and links, see the show notes at
https://defn.audio/2016/09/21/episode-10-spec-ial/
Recommended
Transcript
Introduction of Hosts: Ray and Vijay
00:00:22
Speaker
All right, episode 10. Welcome to Daffod. Ray McDermott in Belgium. And this is Vijay Kiran in Holland, or the Netherlands, depending on how you see it. So how are you doing, Vijay?
Understanding Holland vs. Netherlands
00:00:38
Speaker
Oh, I mean, there is a CGP Grey video explaining, you know, what Holland is and what Netherlands is and all the whole crap.
00:00:45
Speaker
but technically I'm in the Netherlands and but I'm still in Holland as well because this is the part where I live in is actually part of the Holland which was I think one of the provinces at some point.
00:00:58
Speaker
Okay.
Belgium's Regions and Language Differences
00:00:59
Speaker
I'm actually in Flanders, which is the northern half of Belgium. So there's three parts of Belgium as well, like there's Flanders, there's Wallonia, and then there's the Brussels region. So I'm actually very, very close to all three, but I'm in Flanders. So is it the place where they speak Flemish? They speak Flemish and Flanders, yeah. They speak French and Wallonia. And they have different names for towns. If you're in Wallonia, then they're called the Flemish towns, something else, to what the Flemish people call it.
00:01:28
Speaker
Okay. Wow. Yeah, it's really good. Yeah. Interesting. There are these road signs that say you're going to Antwerp, for instance. Yeah. Yeah. But if you're French, Antwerp doesn't exist. If you're a Wallonian, sorry, if you're a Walloon, that doesn't exist. Okay. Only, only, only Enver exists. Oh, wow. Okay. So you have to go towards Enver.
00:01:51
Speaker
it is probably only only the french people that that actually translate the names of the places because i remember when first time i came here and i said okay this is the Hague and then for the french people it's lahai or something like why what is lahai the Hague okay why do you have to translate place names just leave them alone you don't translate my name you know
Celebrating 10 Episodes: Reflections and Community
00:02:12
Speaker
They're like proper nouns. Stop translating shit. Anyway, we don't want to offend any French audience. French language is awesome. My apologies to the French people. I didn't want to pick on them.
00:02:29
Speaker
Anyway, so let's get on to the show. This is a very exciting milestone for DEFIN because this is our 10th episode. So when we started, I think like five months ago or so, we thought we were going to be just a pilot and then we get canceled and, you know, everybody will be just writing. Just laughing at us. Exactly.
00:02:51
Speaker
But it has been an amazing experience and we hope to continue this and the numbers were pretty awesome. There is a lot of feedback, plenty of good feedback from the community and we are very excited to have a lot of guests over the period and also we would like to have more guests over the period as well. So this is something that we are looking forward to.
00:03:13
Speaker
And I think we want to try and get the focus a little bit more global, don't we? We've had Robert from South Africa, we've had a few of the guys from America on. We really haven't had, given the fact that we're in Europe, we really haven't had enough Europeans on, so we're going to try and correct that over the coming months. Definitely we'll have some people from the euro closure that's coming up.
Expanding Global Perspectives and Guest Contributions
00:03:35
Speaker
So we're going to make sure that we're going to hit our diversity quota.
00:03:41
Speaker
We're going to hire a local. Then I'll start like this, and I'll keep speaking like this, like an Indian, you know. That'll be amazing. I'll be just keeping doing the proper Indian accent. I actually couldn't tell any difference, to be honest. Could it? Do that again. Do that again. That's racist. That's the opposite. That's not me being color blind. That's even me being voice blind. No, I think I need to talk like Apu from Simpsons.
00:04:09
Speaker
Thank you, come again. I apologize to my Indian friends now. I think we are very excited to have a double digit episode of the podcast and we have been doing it like every two weeks consistently and thanks to the community support and people listening in.
00:04:35
Speaker
And obviously we couldn't have done this without amazing guests showing up and teaching us a lot of stuff. And hopefully the folks who are listening to this, hopefully you're getting some value out of it. And we'll continue to do this as long as possible. And we plan to bring in more guests in and talk to them. And so you'll get all the closure knowledge embedded across the world channel through this podcast to you guys.
00:05:04
Speaker
It'll be always the latest, the greatest, the hottest vegetarian closure stuff you can possibly deal with. Exactly. Actually, the other thing we're doing is we're experimenting with going very long, aren't we? We've went kind of like for an hour, then we went for an hour and five, an hour and 10, an hour and 15. Last time it was an hour and 30. We're going to go for like, we're going to pull an all-nighter one of these days.
Experimenting with Episode Length and Engagement
00:05:28
Speaker
We're going to push in the boundaries. Exactly.
00:05:32
Speaker
And then we'll know who are the hardcore fans. There'll be just one person somewhere on the planet trying to figure out what the hell is this, and then continues. This is going to end, right? And then you'll be asking other people. This should end at some point. But yeah, it's been a very long episode. But I think it was very informative, the last one with Michael and Lucas. I mean, it was amazing.
00:05:53
Speaker
It was really good. I think those guys really gave us some gold, I think. It's a great journey they're on as well. I think they're doing great stuff for the Closure community. Obviously, big data is an awesome place that Closure can really help with. I'm really a big fan of their work. I think they're doing great stuff and I'm really hoping that we can make more use of it in a future commercial setting as well.
00:06:19
Speaker
But kudos to you, Lucas, kudos to you, Michael, if you're listening. Thank you very much. Yeah, thank you very much. So we'll be bringing in a lot of new guests, and of course we'll continue to do this. And before we get on to the show's main topic, first of all, let's
Clojure Events and New Interactions
00:06:35
Speaker
have some couple of interesting things. So the news and events. So there is a closed tray happened in Tampere, I think, in Finland. And all the talks are on YouTube. Obviously, they have been tweeted everywhere.
00:06:52
Speaker
We'll add some links to our show notes so you can check that out. And Euroclosure is going to happen in October, obviously. We've been talking about it a long time and Ray and I are planning for something interesting to do at Euroclosure.
00:07:07
Speaker
We are working on the details, but both of us will be there and maybe there will be some sort of a recording of the speakers or people who are in the community. We'd like to do a couple of interviews with them. That is certainly on the board. And we'd also like to give away some swag goodies during the euro closure. So once we have more details, we'll tweet about it. We'll tell the community and we'll announce it in the podcast as well.
00:07:37
Speaker
So those are the news and events. And because this is, we thought, hey, we keep introducing guests all the time. And I see a lot of people actually are very excited by having a guest on the show. So we thought, hey, we'll have a special
Introducing Comedy with Deaf Ray
00:07:53
Speaker
guest. But this time for your impure amusement, we'd like to introduce you to Defray. Hello.
00:08:09
Speaker
self-styled closure comedian the nations of all
00:08:48
Speaker
So it's basically a joke. That's a nice way to offend like a bazillion people. That's how it started. But actually, all the fun in Lisp, actually, was the beginning of Lisp. It was defun. It was defun. But the problem with defun is that, actually, you literally remove all of the fun.
00:09:16
Speaker
fun you take all the fun out of lives should be da fun that's what it should be if they're talking to the kids these days you want to have da fun start with da fun yeah with closure it went more better and they literally removed fun and it is da fun you know and this particular podcast shows that all the fun is being removed from closure so luckily
00:09:50
Speaker
And DefJoke takes two parameters. It's a setup and a punchline. DefJoke, it's pretty awesome. But the first implementation of DefJoke, I'm afraid, was a bit of a failure because it had absolutely no side effects. So I re-made DefJoke.
00:10:24
Speaker
If laughter is present, then the steam is increased as a side effect. So with that macro in place, we're now able to perform high order jokes. High order jokes, DJ. High order jokes is where you get a joke, and then you take back a joke. That's the high order joke.
00:10:51
Speaker
heckle. So VJ, give it your best shot. So I need to tell a joke or something or? You need to make a joke about my jokes about how bad I am. That's what a heckler is. Fuck's sake. I'll cut this bit. God damn it.
00:11:16
Speaker
Okay, you want to be harassed? Fuck, I'm not used to harassing white people, man. Okay, we take that one. So I'm going to outsource it to you. All right. One final bit. Okay. Yeah.
00:11:49
Speaker
that I've created with DeafJog is about, it's actually about the way our industry works, it's about how everything in this whole business about algorithms where you want to set up random stuff, the one arm bandits, they have all these bandit algorithms through Netflix, et cetera, and what is the interesting thing
00:12:20
Speaker
And every bit of IT is basically working on a one-arm bandit principle. And I'm going to give you some examples of that. First example is business asks IT to do something. It's a total fucking one-arm bandit. We haven't got a clue what they want. They haven't got a clue what they're asking for. They might ask for something where they get all sevens. We can do it in five minutes. Normally, it's not like that. It's going to take a week. Why? Don't worry. It's a one-arm bandit of fun. That's what you get.
00:12:49
Speaker
Then we get the job of finding bigger stars. Okay, right, IT. What are we going to use? What are we going to use? A bunch of white frameworks. Which one are we going to use? I don't know. What are our bandit? Bam! White frameworks. They're in JavaScript. Awesome. Yeah. How is JavaScript going to work today?
00:13:18
Speaker
JavaScript, looking at the browser. Well, hello, Tom. What are you going to do today? How are you going to work on CSS today? One arm bandit. Everything's good. Right, JavaScript's view of V8. How's V8 going to work today? I've got no idea. One arm bandit. JavaScript view of ECMAScript. Which bit of ECMAScript is covered in any of the browsers? The V8s. The languages. The bits of hard. I don't know. One arm bandit. Java compiler.
00:14:00
Speaker
It's one out bandit all the way down. Thank you very much. That was our...
00:14:13
Speaker
our comedic interlude with Deaf Ray. I think this is like, I remember the show on comedy, sorry, what was that again? Cartoon Network some time ago. That's called Sheep in the Big City.
00:14:33
Speaker
And then in that one, after every show, at the end of the show, there is something called Ranting Swede. So it's basically a guy coming onto the stage and ranting about shit for like two minutes continuously. They're like meatballs. They're meat, but they're not balls. They don't bounce. So why they're called balls? I'm getting pissed off with this stuff.
00:14:52
Speaker
We should have Defray interlude every now and then. Let's try and bring him back if we can. Yeah, but we are very tightly run show, so we might need to give him a couple of parenthesis every now and then. Not real money or something. We will close your coins. We will close your coins.
00:15:20
Speaker
Let's keep his jocks in parentheses, though, that's for sure. Yeah. OK, let's get on to the main discussion. So today we're going to talk about specs.
Deep Dive into Clojure Spec
00:15:29
Speaker
we have been contemplating what to call the show because we were thinking spec shell as in spec is already there in special and so this is a special show about spec and then there was something like spectacularly awesome show or whatever but we'll let you guys decide you know what kind of show this is anyway so the point is we're going to talk about spec
00:15:54
Speaker
So first of all, what exactly is a spec? So we have seen the announcement from Rich Hickey a couple of months ago, if I remember correctly, somewhere in April, I suppose, as the first incarnation of spec was unleashed onto this world by his Holiness Rich Hickey onto the world. And he said, OK, this is how thou shalt not write static typing shit on your closure, but thou shalt write spec or something.
00:16:23
Speaker
So the idea behind spec is fairly simple as far as I understand, because we have been trying, closer is a dynamic language, right? So we have been trying to come to terms with how to write correct programs or get some sort of a guarantee on, hey, my program is not going to blow up at runtime. This is the standard argument that static typing people have, and again, it's dynamic programming usually.
00:16:50
Speaker
So one way to do that is essentially writing a lot of tests and then checking everything. But there is no easy way to communicate to the other programmers what your function means, actually. So type system does that to a certain extent because when you're writing in a statically typed language, for example, you can say, hey, my function takes an integer, integer, and a string.
00:17:15
Speaker
For some reason so the number of times you want to repeat and number of lines you want to print and the string itself Something like that. So there is a function So that is that has been fairly useful because you can you can when the call site you can check What kind of parameters your function is going to take and you can guarantee that you can never pass it a double double and a character, right? so that's the basic idea behind type checking that gives you some sort of a guarantee and
00:17:43
Speaker
Now, on the closure side of it, because we don't have any static typing involved, there were a lot of tools like Schema, for example, that was very popular from now called Plamatic Schema, if I remember correctly. Plamatic, yeah, that's right. Originally the Prismatic guys. Exactly. So, Prismatic guys were making it. But that was very nice because you could define the shape of the data, because usually you're interested in the shape of the data.
00:18:07
Speaker
not just the types themselves, and how they relate to each other. And also, you want to have a bit more control on specifying, OK, this map must have these keys. So you're talking about the content, not just about the type. So that was very, well, I'm just giving like, I think we're just giving a bird's eye view of what it is. I'm pretty sure long time closure views are small. We also had the closure type, core type as well. Yeah.
00:18:35
Speaker
So it's a gradual typing thing, isn't it? It's kind of struggling with this notion that we don't want types everywhere because they're not useful everywhere on the trivial things, but they are useful on some things, like you say, when you want to communicate some interface or where things are getting a bit sticky or a bit hairy, or you will need to do some...
00:18:59
Speaker
some proper kind of thinking or testing about those functions. Exactly. So this is more like a surface typing, right? The outside of the program should be able to tell you, hey, you cannot pass these things. You cannot do these things. Well, actually, I think that's one use of it, isn't it? But I think we'll talk a bit later about the fact that spec offers a lot more than that as well. Yeah. So it does give that kind of thing.
00:19:26
Speaker
from a kind of contract perspective, that's what types of, that's what you're talking about, isn't it? Yeah, exactly. It's kind of like some contract to the caller. Yeah. So the contracts are, I don't know if anyone who is listening to the show is familiar with Racket. So Racket has this contract system.
00:19:44
Speaker
that's basically making sure that your program has some sort of a, well, they have different types of contracts. They have, I think, for functions and for data structures and they have creating a combinators for the contracts. In my understanding, I think the ClosureSpec is more or less similar to the contracts in Racket because they try to
00:20:10
Speaker
like one part of the program, not knowing what the other part is doing. So you're preventing those kinds of issues. So the usage of a function versus definition of a function or making sure that you know the types, making sure that you know the data and giving rising appropriate error messages saying, hey, I expected this to be a Boolean and you gave me a keyword or something. So that kind of things. So that works pretty well in Racket. In my understanding, maybe obviously,
00:20:40
Speaker
The the best way to get information from people is being wrong on the internet, right? You know, just tell somebody something wrong and then they'll make sure that you get the right answer That's what my opinion is if it is wrong, please You know just just hecklers on on reddit or something. Anyway, so I think I think there's most I think because raka is based upon a lot of moss because obviously
00:21:05
Speaker
Racket and contracts, there's a lot more stuff underneath it, isn't it? They've got more, their type thing has been going for a bit longer and they've got these more kind of hygienic macros and those kind of shit stuff. Their contracts, I think, are more complicated than spec is, but on the other hand, spec has got, spec is actually offering more affordances than contracts as well with the testing stuff.
00:21:31
Speaker
But yeah, I mean, that's, you're right. That's what people want, isn't it? They want this kind of, at the surface, they want this contract. Yeah. And also the guarantee. And also the guarantee and the communication, right? I mean, the communication between one programmer to the other, because type systems are essentially, of course, they're communicating with the programmer. So when you write code, when I read that code, I know what the type is and what it is doing.
00:21:56
Speaker
but it doesn't give me enough of constraints that you're going to put around it because it's not just it's only talking about integer integer or number number and string so it's not talking about what what is its name what is its purpose and what kind of properties that particular
00:22:13
Speaker
element can have so I need to specify because I'm calculating I think before the show we were talking about an example where there is a weight of the car and mileage of the car right and I want to make sure that the weight is less than the mileage you know otherwise it's I don't think there is any car in the world that just has more mileage than its weight in the absolute numbers. Well actually mileage is zero at the beginning
00:22:39
Speaker
So, sorry. Your test is a fuck up from the beginning. It's really the other way around. No, it's just... It's a terrible example. See, that's the... You're wrong on the internet. Exactly. That's the advantage of being wrong on the internet. Actually, I'd like you to write that spec for next week.
00:23:04
Speaker
So, wait. I'd have done work for a car company, you know. Let's not spend time on it, Vijay. No, come on. Okay. So, enough... You've got other examples here. Your general point is well taken. Yeah, enough about car technologies because those suck. We all know that.
00:23:22
Speaker
What are we talking about there? Oh my God, the thing about the workflow, that's what I was going to say to you, because the biggest problem, I think, because we're talking about types and contracts and all this other stuff, and that's all fine.
00:23:36
Speaker
what we want to avoid with uh what we like about closure is all this REPL stuff all this stuff we can be free and we can just have the data and we can be very data-centric and very data-oriented and you know we can just play with our own maps and evolve it at the REPL and build it up and that's really what we win with closure isn't it?
00:23:54
Speaker
And we don't want this spec stuff to get in the way of that, whereas types do, don't they? That's the biggest thing that I think we want that balance, don't we? We want the balance between kind of like the freedom, the creativity of a language where types are not imposed upon us, but we want the kind of affordances of types where we need them. Yeah, that's true.
00:24:18
Speaker
Well, it's a different kind of thinking. So once you get used to the dynamic thinking, then you're not essentially thinking in terms of types, but you're thinking in terms of pure data. But the point is, how do you then guarantee that, hey, my program is correct enough? So there are multiple ways. I mean, one of the ways that the type system guys come up with this, if you have the right types, then essentially you have the proof
00:24:43
Speaker
that your program is correct because the compiler is is validating it but still the burden of proof as in you need to define what what what a correct program is in types so you need to specify but compiler is going to help you that that's pretty good with with the static statically typed languages
00:25:02
Speaker
But there are some situations where you can't actually prove it. I mean, there is no formal proof. Of course, I can spend more time. But there are some, the relation between inputs or between inputs or outputs and inputs, how do you express in a type system or how do you express it as a proof? So that makes it even more complicated. So that's what the specs are going to be helpful because it is still dynamic language.
00:25:33
Speaker
And so what about higher kind of types and things like that in Haskell? Well, because in theory, you can have a kind of, what should we say, almost like an algorithm or a kind of set of semantics around the types with higher kind of types. Yeah, that's true. To be honest, I'm not an expert about it. Well, we know we both are not experts, so we can just exchange our
00:26:01
Speaker
Well, I've heard people talk about it on the internet so therefore I'm a kind of expert, you know.
00:26:11
Speaker
Are you a regular listener of deaf and podcast? All I mean is that it may be possible. I guess the downside about that is you have to spend a lot of time pleasing the compiler and that could be something that you're happy to do. I know these guys who do this type checking stuff are really into it and they
00:26:34
Speaker
they believe that they can get more correct stuff through Haskell and F-sharp and all these other things, whereas I personally see it as a burden. I think it's just a different style, isn't it? We do end up wanting the same kind of thing. We want the best of both worlds, don't we? Exactly. The idea is that we
00:26:57
Speaker
Our goal is the same, right? Our goal is to make sure that we write correct programs or we need the tools to write correct programs. So there are multiple ways of achieving it and type systems are one of those. So the argument here for specs is that specs
00:27:15
Speaker
remove a couple of limitations or don't have the limitations that types have that for example what we can do or what we can prove so that the advantage is that you can communicate better with other programmers you can communicate better with other tools for example you can communicate better with during compilation time and everything and also most of the time we're not just interested in the
00:27:40
Speaker
in the type itself, we are interested in the value, right? I mean, we can say, hey, there's an integer, it is an integer, and we can we can keep saying that. But what we're interested in is, hey, whether my apologies, I'm going back to the car again, you know, a mileage to the fire again.
00:27:58
Speaker
So if you say mileage, I mean, you can't fucking have mileage like 2000 kilometers or something, you know, that's on a full tank. Mileage is basically per 100 liters or something, right?
00:28:11
Speaker
Oh, okay, so you're talking about fuel efficiency. I thought you meant like, you know, the number of miles that you've covered. No. Oh, God. See, that is the conflict. Semantics. See, semantics. That's true. So we can keep saying it is double, but you know that the mileage means something different to you than to me.
00:28:31
Speaker
Yeah, we've just invigorated it now. That's good. Exactly. So that's where the spec is going to help because I'm going to write a spec that says, hey, this is what mileage means. And this is what the mileage property is. And then when you're reviewing my code, you can say, what the fuck? Mileage is kilometers. Why is it like this? Why is it kilometers per liter? Exactly. So it makes
00:28:54
Speaker
more sense there the whole specs idea but now the most interesting part with specs at least that you know it has been uh in closure we keep saying everything should be a library right but in the case of specs these are put into core so why not a library i mean why why specs are special like special forms
00:29:19
Speaker
So this is something fairly, I think you were explaining that Rich Hickey was explaining why.
00:29:27
Speaker
these things are part of the core, right? Yeah, I think his argument was that even though it's not a language change, he wanted to make sure that it was sort of universal for all Clojure programmers to have this set of tools available to them. And that makes a lot of sense because, like you said just a moment ago there about communicating, you know, if everyone has the same kind of tools and it makes communication between developers and between teams and between
00:29:56
Speaker
companies or whatever. Much more straightforward if they're all operating on the same tool set because the situation we were in before was pretty ad hoc where we had schema and core typed and check test. It was all a little bit ad hoc, a little bit bricker brack.
00:30:19
Speaker
one team could use one standard. It's still possible, of course, you can still use different standards. But the defaults, and I think that's what I like about this approach is that the default now becomes a pretty good default, a pretty good set of choices. Whereas, and you don't have to look beyond the core environment to get a very good, very powerful tool.
00:30:40
Speaker
So I think it makes sense that it is part of the core because then you have some sort of a uniformity when people adopt this. Then you have a uniform way of communicating it because, as we'll probably explore later in terms of the error messages, in terms of the effect on the ecosystem, it makes sense that everybody uses some well thought out system, right?
00:31:05
Speaker
Otherwise, look at schema, for example. There are some libraries which are op schema, which is pretty good, and then some libraries which don't because that's not the default thing available in the language that you can just pick it up. That's why I think it makes more sense to make it part of this one. Also, I think that is also the reason. I don't know, maybe we should ask Alex Miller or Rich Hickey that,
00:31:28
Speaker
There are a lot of alphas. They're getting a lot of feedback from the community. Like, how is it going to pan out? I think we're at alpha 12 now. It's definitely unusual. We see it from the mailing list. Yeah, exactly.
00:31:43
Speaker
There's certainly a lot of heat. There's a little bit of light, I think. Yeah. But these kind of changes, I mean, these are fundamental and part of the core. And I think it should be part of the core, not just a library. Because if it is just a library, then you have this. Of course, it is still optional, right? I mean, you don't need to write specs.
00:32:02
Speaker
You don't have to. Exactly. You don't have to. So you still have an advantage of writing it because that helps you with, hey, now I've written a program, now I want to guarantee whether this program is doing what I wanted to do and I want to communicate my intent. So which tool I would reach for. So this is something that I think is very interesting. Yeah. Yeah. I think the other thing as well is that if you're
00:32:28
Speaker
If you're building tools or whatever, or if you're building libraries, then
00:32:35
Speaker
to start thinking, okay, well, I know schema seems to be very popular, so I'll invest my time there. And I'm sure some people have done that. And now they're kind of sad because it's kind of going to become a bit less popular. Whereas with this thing, if you put it in the core, and we know that the rich and the rest of the gang are behind it in the core team,
00:32:59
Speaker
then the two vendors and the library guys, and ourselves, of course, we can feel a bit more comfortable that the investment we make in this spec will have a long-term return on investment. I think that is also a reason to put it in the 1.9. Yeah, that's true. I think it's one of those
00:33:22
Speaker
fundamental, you know, to use a cliche in a word and like a game changers, you know, this is this is, this is the tool that that's part of the core. And this is something that you can reach out for. And they're expressive. Now we can. So what can you do with with a spec so you can
00:33:38
Speaker
Just one final point, actually, was the obvious library stroke user spec is going to be ClosureScript. That was something which wasn't actually unified beforehand. And I saw David Nolan's talk at ClosureTrader, who mentioned earlier on. And that's one of the things he mentioned in that talk is that
00:33:58
Speaker
Parity with closure is a very important thing and it's the big work that they're doing now enclosure script is to Keep parity with the the alphas So they're a little bit behind but they're only like one or maybe it's two alphas at the most behind So this will also be very nice that you'll be able to translate the specs or use the use the power of specs enclosure script as well as enclosure proper and
00:34:23
Speaker
Yeah. So what can you exactly do with it? So you can specify the, it's essentially adding some sort of a type, I don't want to call it type specification, but a specification for a given data structure. So it could be for a function, it could be for a data structure,
00:34:43
Speaker
It could be even for a macro, for example. So this has been one of the interesting things with macro is that you have this runtime and then you have this compile time and you can get errors in a pretty strange places that you can't debug properly. So the specs helps you to identify, okay, where is my error and what is happening with that one.
00:35:04
Speaker
So there are lots of combinators available in InSpec. So you can say, OK, this has to conform to this particular predicate, essentially. So you can say all the parameters should be like this. And I think Stuart Hallway has an amazing series on YouTube explaining the screencast, explaining all this
00:35:24
Speaker
So I just don't want to, yeah, there is no point in me talking about it. If it is coming from the source. Yeah, we should make a link to those. Exactly. So I really recommend that those are bite-sized, I mean, smaller 15 minutes screencast explaining what is the leverage that you get by using specs and what are the tools that you get and how can you practically use specs to improve your programs.
00:35:50
Speaker
Now the other, so how do you check these things? So you have this, the conformance testing and the validity of your code. Now, once you run the specs and quote unquote, or run the validation on it, you get all the results or the errors, but you get it in a form of a data structure, right? I mean, you get it as a map.
00:36:15
Speaker
I think you can have it as both, can't you? You can come back just as a string, or you can have it as this. Yeah, you can ask as a string. But I think this is a... I'm still making up my understanding of trying to get in terms with...
00:36:33
Speaker
having it as a map versus just putting it as a proper error message. It still seems like a strange or a difficult choice because if it just prints out a huge map with all the crappy things in it, I need to dig through.
00:36:50
Speaker
It is essentially like, well, I don't want to compare it to a stack trace, but you know what I mean, right? I see the huge map detail and I want to get into the stack. It's almost worse than a stack trace in some way, because there's an order in stack traces. Yeah, exactly. So it's guaranteed. Yeah, yeah. But yeah, I think we've seen some stuff on a mailing list, like you say, about errors getting worse.
00:37:19
Speaker
You know, I saw some discussion that, oh yeah, everyone has to learn how to read specs. It's like, for Christ's sake, I thought it's meant to be optional. You know, so if the call language is going to emit errors as spec failures, well, Jesus Christ, you know, it's not very friendly. I mean, the whole point about this thing was to try and make it a bit more friendly for beginners and to help it to spot errors and things like that. So I really hope, and we can ask Alec about that. You know, surprise guest, spoiler alert.
00:37:47
Speaker
Hopefully, we're going to have him on the show pretty soon. We hope so. We'd be better to come on now. We can ask you a bit about that because I think the opportunity is definitely there to improve matters.
00:38:07
Speaker
Hopefully that's taken. I think the map thing is quite interesting from a tool vendor's perspective. I think you were saying earlier about that there was some concept of not wanting to vary it too much. Yeah, exactly. Because the idea is that if the results of a spec are shown as a map, then if you leave the tool vendors like the IDEs or Emacs or anybody,
00:38:31
Speaker
to decide how they are rendered how they are i think they do count as two vendors i know it's yeah yeah of course in my mind vendor is a bit more derogatory i mean people are doing amazing these are all open source stuff and they're giving stuff away for free so you know they're doing it for love not not to sell shit so
00:38:50
Speaker
Anyway, but the problem is that... Are they getting calmer? It's not their... Yeah, of course they are. The universe is loving them. Exactly. There is some universe Jews flowing into them.
00:39:06
Speaker
So the fundamental issue there is that it depends on how the tool interprets the map of results. So this is one of the contention point because we just discussed mileage, right? It means different thing to you. It means different thing to me. You're wrong. Well, I don't think 2 billion Indians would say that because we have advertisements saying mileage, amazing mileage.
00:39:33
Speaker
No, no. Actually, we're both wrong and we're both white. That's the fun thing about it, you know. That the contextuality matters, right? Exactly, exactly, exactly. And that's your point about the error messages. Exactly. If cursive is going to interpret or show these results in a different way, then e-max does, or VI does, or nightshade does. It'll probably do it in a better way, I think. Yeah, not better than e-max, though. But, OK, I understand. It will have more colors. I understand you want to get a free license from Colin.
00:40:05
Speaker
I'm happy to give my money, it's okay. But there is a fundamental contention point here, but in my opinion I still think that when you're running it without any tools or something it should still be friendly. I mean it is user experience, right? I mean you can't ignore it.
00:40:23
Speaker
Yeah, that's right. Yeah. I agree with you. I mean, there should be a decent universal sort of baseline of at least OK error messages. Exactly. Because we're talking about specs, and you can test them during compile time, and you can also use it at the runtime. That means at runtime, I'll end up this year in the log.
00:40:44
Speaker
So there, I see a completely different picture. Well, all the Clojure programmers are smart. They can figure out shit. But you want to reduce these brain cycles people spend on understanding the error messages. Because this has been a big talking point about Clojure since the beginning. Clojure error messages suck. So there have been multiple tools that have been built around it.
00:41:06
Speaker
So anyway. I think, but actually it's interesting, isn't it? Because I think there are two parts to this. I think one part is the kind of like the forming of the error messages. Yeah. Because I think that they're, I think the engineering team at Cognitec, they're struggling to have, to find a way to present good error messages. Yeah. I think there are examples out in a while, but I think for whatever reason,
00:41:32
Speaker
Maybe it's just engineering budget or whatever. I think they still haven't found a really nice way to go elm on this shit, as they say. Yeah, exactly. I mean, the elm guys are doing pretty great, by the way, right? I mean, if you see there are messages there. Well, I haven't used it. So this is still the demo effect, probably. You just see some tweets every now and then, and then you say, wow, that's amazing. It can just pinpoint the information. But I think that's the same potential.
00:42:00
Speaker
Sorry, please. So specs have the potential, I mean, to be like Elm error messages, right? But it is not the default. That's the problem. I think part of the problem, I mean, you have to remember also what Elm is. Elm is a type language. So in some respects,
00:42:20
Speaker
It's fed more data than the closure equivalent is. But they definitely do some nice things. Other guys like Cohen and Bruce, Bruce Hammond and Colin Fleming, those guys in their respective tools are trying their best to find nice ways of expressing configuration errors or other kinds of errors.
00:42:47
Speaker
And my point is that for whatever reason, those guys are finding it difficult to, they've got the data, but they're finding it difficult to express that message in a kind of human way. And that's partly because
00:43:01
Speaker
of the semantics of English or the semantics of the era or whatever. And I think that's a hard problem, to be honest. That's true. I wish them good luck with it. Please make it happen, but I don't exactly know how it's going to work. We've got some examples out in the wild, so work it out. It's definitely not a student exercise. I know they've got some serious engineering brains on this thing, so it's definitely not an easy problem. But what I think
00:43:28
Speaker
It's the other part of this error messaging thing, which was a problem for closure, was the fact that because it's a dynamic language now, it's macro stuff, transforming macro to form, from the macro outer form to the inner form, as you keep on recursively expanding the macros, and then you get an error halfway through, then it sort of bonks, and you kind of lose the context,
00:43:56
Speaker
Now in theory, this should help there. In theory, the transformation of macro should help. Now again, I want to separate that out from the kind of forming of the error messages, but the pinpointing of where the error occurred at least should be done better. Because that's one of the biggest problems I think we've had in closure from day one is
00:44:14
Speaker
Any messages are shit, that's for sure. I'm not going to pull any punches on that. They're often really terrible. But the thing, and what you end up doing is just sort of saying, oh, what did I do last? I'll undo that. Oh, what's the difference? Oh, I see. It's not always that obvious even. But what I was going to say was the bit that
00:44:35
Speaker
The bit that's horrible is the bit where you suddenly get this error message, and you just don't know what it's telling you. You've got no clue. And it's got tribal knowledge, basically, on the use group. So I think it's probably that. Have you done this? Have you done that? And it's all just tribal knowledge there. And we want to get rid of that tribal knowledge crap. The compiler should know where the fuck the thing went wrong. And I get why it's hard, but I think the spec thing should help. And I've got high hopes.
00:45:04
Speaker
Fingers crossed. We'll see how it pans out. But yeah, I mean, I think there is a lot of community feedback come again. And I see a lot of discussions on the mailing list. And hopefully, we'll get to a place where specs are going to be a nice default thing that we can work on.
00:45:23
Speaker
so that the runtime checking obviously you can you can use specs to check during runtime as well because you can use the provided functions like valid or conform for example you can even do that during runtime so you can say hey this is the data that I got
00:45:39
Speaker
does it conform to the spec that I have? Now I can take a decision or throw an error message or something. So specs are there during compile time and during runtime as well. So that is really helpful. And the other advantage is that... Oh, by the way, that's optional as well, isn't it? You don't have to do that. Yes, exactly. You can choose on the
00:45:58
Speaker
to conform. So just use them as a sort of documentation. Exactly, yeah. There is no have to at any point, so it's all optional. So the tools are available. If you want to use it, you can use it. And now because we are specifying the behavior of the functions or the properties of the functions,
00:46:19
Speaker
The one thing that's really exciting about specs, for me at least, is that you get automatic generative testing, automatic property-based testing.
Generative Testing in Clojure Spec
00:46:27
Speaker
That is amazing. That's a spectacular advantage that you get because you don't need to write tests separately and then you just generate them.
00:46:38
Speaker
Spectacular. Yeah, spectacular. You've done it, yeah. I think they should just name it spectacular. They should really, yeah. Yeah. Okay, so anyway, yeah, I agree with you. I mean, because that's also, I saw Stuart Holloway's video about that, about how to leverage these testing things. Yeah. And there's some really nice use cases there as well about how you can
00:47:01
Speaker
modify the inputs and the functions and the properties to tweak the generative testing models so that they give you the right type of data, the right type of testing. So you can take all the defaults, but you can also tweak it to say, okay, well,
00:47:21
Speaker
Yeah, this give me a lot of non-zero values. Exactly. So you can write your own generators. Yeah. Yeah. I think there are a couple of very nice talks on Closure TV. For example, on Euro Closure, there is a talk about generative testing in a lot of places. I mean, the central idea being that you don't write tests to check the values, but you write tests as properties that your code should conform to. I think, yeah, I think that the fundamental
00:47:51
Speaker
conceit behind some of these things is that unit tests are laborious and boring. And all they're often doing is kind of badly, essentially, specking out the behavior of a function. And I remember, I don't remember, I know for a fact, there were people at work this very day. Well, not this day, so someday, hopefully they're off. But there are people that work on the open source, I'm sure.
00:48:20
Speaker
Writing tests, writing tests. Let me do my test. Oh, you put your outsourced too and then... Yeah, yeah, yeah. Writing tests, writing tests, writing tests. What the fuck are you writing all these tests for? You're just doing what the machine could do far better and they don't get tired. It's like the sort of terminate argument, it doesn't get tired. It never gives up.
00:48:44
Speaker
And also, it's better at giving you the heuristic-based estimation when your program is going to fail. So that makes more sense. Make the computer do the grunt work. You don't have to think about, OK, how many possible edge cases are there and how many unitars do I need to write.
00:49:02
Speaker
But again, the fundamental advantage here is that because you're using specs, you're specifying the properties of a given function. So that gives you this amazing leverage of generating tests or generative tests. So that is something that is pretty cool. So there are lots of information online. I think we can link to all of those things.
00:49:26
Speaker
A couple of things that before we wrap up I did sorry just just one small part is that I think there's a lot of
00:49:35
Speaker
I think what's interesting about this is back to this sort of you know, not exactly anti Java or anti type checking people but obviously Generative testing is it's good for those guys as well because in the end it tests the heart of your function You're not just the types that are being passed in so anything that sort of I would say anything that promotes the ease of use of that thing then
00:50:00
Speaker
then you're kind of winning because if you're writing a typed system, then you have to write some properties separately from it. This is where I think Rich calls it leverage or leverage. He calls it leverage, I call it leverage, but I can still be friends.
00:50:19
Speaker
So, the basic idea is that you make some investment there and you get a lot back and you get a lot of rewards for doing one thing. Whereas in the type system, you still have to write your unit tests or you have to write this other thing.
00:50:36
Speaker
this property-based testing thing. So if you're a Haskell programmer, you have to use QuickCheck. If you're a Java, all these checks, yeah. Well, if you're a Clojure programmer, guess what? You can write your things, you get all these advantages, and the testing comes from here, which is superb.
00:50:53
Speaker
But we still need to see what is the effect on the ecosystem once specs reach the release mode. We're really curious how the tools or IDs are going to pick it up and how many... Going back to the community feedback, because the specs are now essentially making some of the closure code backward incompatible.
Backward Compatibility and Versioning Challenges
00:51:18
Speaker
So that is something that, for example, the require in the namespace thing. There is some discussion on the mailing list about it. Essentially making, because people were using the... Yeah, the symbol. Yeah, the symbol, instead of using the symbol directly calling require in the namespace.
00:51:36
Speaker
Now it is now enforced by spec and it is raising an error and it should be a keyword nice symbol exactly so that that is the Kind of things that that we might face and and I know Alex Miller has been opening some nice pool pull request for the program for the for the open source software where you need to fix the code base, but there seems to be a
00:52:00
Speaker
at least some sort of a common understanding in the community that hey, spec is going to help us, so we should adopt it and then use it in one go. But this is the first time Closure has ever broken the backward compatibility promise, right? I mean, there wasn't much issue in the past with all these releases from all the way from 1.0.
00:52:20
Speaker
Well, I think it's interesting, isn't it? Because there's a sort of debate about whether that's really a backward compatibility issue, or whether it's just a kind of bug fix. Because it's really an interesting problem, because on the one hand, I count it as a bug fix. So supporting broken behavior doesn't count as
00:52:43
Speaker
breaking back with compatibility in many ways. I look at this thing with Sun, Oracle. I can't remember if it was Sun or Oracle, but they changed something to do with the way that ... Oh no, it was when Oracle took off Sun. They changed the copyright string, I think, in their system properties, and they changed it to be Oracle, not Sun. It was either one less word or something.
00:53:10
Speaker
It broke a lot of code because people were, well, I'm looking for Sun Microsystems. That's what I'm looking for. I'm looking for the Sun Compiler. I'm sorry, mate, but that was not a valid use of that thing. They were mourning and bitching. Oh, why did you change this? No. That wasn't the right thing to do.
00:53:34
Speaker
In this case, it wasn't take advantage of. Often, most of these library guys would have just made a mistake. It would have just went past the compiler. The problem with it is, actually, is that
00:53:46
Speaker
It's the ripple effect that's the problem, isn't it? Of course, in my opinion, it should be corrected. The interesting problem is the fact that if I change it, if it's like that, then, ah, okay, well, if I upgrade my version, then you have to upgrade your version, upgrade your version. That's the problem, I think, is that you're forcing people to do upgrades.
00:54:09
Speaker
code that worked before now doesn't work anymore. At some point you need to move forward and then remove the wires and release wireless earpods.
00:54:22
Speaker
Well, I mean, this is a very benign change. I think this is not a radical change. This is a small wart that's being removed that was essentially a bug that allowed this behavior to go wrong. So I think removing that little wart is okay. I'm all for that.
00:54:41
Speaker
Yeah. So you're going to buy the airports? The airports. When I first saw the advertisement, I was like, god damn it, they're removing the white things. But then I realized, after a couple of days, I was taking out all the fucking wires from my bag and they were entangled. I was like, fuck this thing. I'd rather lose my earbuds than fighting with the shit wires dangling all the time. Yeah.
00:55:06
Speaker
Actually, I'm wearing a pair of wired headphones now, but only for the sake of this podcast, actually, because I bought a pair of wireless ones, and I'm far, far happier with them. The only reason I wear the wired ones now is just because I don't want to have the interference and I don't want to experiment for this show. But I will do that in the future, and honestly, I think
00:55:32
Speaker
I hate wires. You have to have wires for some things, but I think they've done all right. We're off the topic by a fucking mile now, though. I think it's fine. I think they're doing all right. They're actually building a bridge as well. They've got a little plug, so it's okay. So, back to compatibility is returned.
00:55:55
Speaker
Anyway, what I was going to say was there's that small thing, and like you said, a better tooling. Hopefully we'll see the error messages coming up and the other things. One of the things that Rich was talking about as a goal for Spec, actually, was the versioning part.
00:56:16
Speaker
One of the things that Elm does, and I don't know if you know this, but what Elm does is, let's say you make a change to some type or some function. It knows, it's aware of what the Semva spec is, what the Semva contract is. And if you make a change to your program,
00:56:38
Speaker
it will tell you whether to bump the patch version, the minor version, or the major version. So it's really nice, yeah. And what he's saying is that that's what spec will allow us to do as well. It will allow us to understand whether we've actually made a change that breaks something in a more mathematical sense. If we're removing one thing from a set, then okay, it's fine. We can do that.
00:57:07
Speaker
And I think that concept, it's not something which Speck delivers on now or whatever, but it's maybe something which
00:57:15
Speaker
Maybe, as you could imagine, boot or line again, or, you know, clothes jars, or... Yeah. There could be some tooling around that environment to say, ooh, you know... This one should look awaiting, yeah. There's a plugin. Actually, it's not a plugin anymore for line again called pedantic. Yeah, yeah. And that pedantic plugin does certain things about the dependencies and that kind of stuff.
00:57:39
Speaker
You could imagine something, maybe it's like that here, where you could say, okay, this version, I see the spec here is like that, and the spec. It's gonna take a while to get everything specced up, I guess, to the point where that's useful. But I think there's more chance of that happening with spec being in the core. Because I think Ambrose Bonas Sargent always says, oh, come on guys, do the core type. Put it in the libraries.
00:58:05
Speaker
But, you know, I think people can't be asked. I mean, I'm sorry, but it's just not something... I wish him the best of luck, but I really... I think it's somewhat quixotic to think that everyone's going to do it when it's a non-default. It's not part of the normal thing. It's, you know, the only real benefit is for
00:58:26
Speaker
for the greater good. The nice thing about spec is that the actual library author gets some benefit. Well, you could argue that they get some benefit with core types as well, but you get a lot more benefits with using spec. With all these kind of packages that come together. So I think that you'll see a lot bigger adoption of spec than you have of these other platforms and these other toolkits. Anyway, I think that's pretty much it, I think.
00:58:54
Speaker
Wow. Yeah. Of course, spec is still evolving. There are a lot of offers and I'm pretty sure people are checking it out. We'll post all the links that we know of and we'll put the show notes on defn.audio as usual, and you will see our episode on SoundCloud and also on iTunes.
00:59:19
Speaker
And it would be very nice if you guys, if you folks can, you know, give us some feedback or at least, you know, rate it on iTunes and SoundCloud, then we become even more popular and then we get to have more guests on the show and instead of us boring you all the time. So that's pretty much it from us, I think. And we'd like to give a quick end credits, Ray.
00:59:44
Speaker
Yeah, just a final thank you to Pizzeri for the intro-outro music. He does a good job every week. He's always there for us with his vegetarian intros and outros, the Malin hamburger. Yeah, I think that's very good. Well, what can I say? Happy 10th episode, Vijay. Happy 10th episode to you as well.
01:00:11
Speaker
Before we finish off, actually, I think it's quite fun because me and you met for, I don't know, half an hour at Dutch Closure Days, and we've spent far more time doing this podcast than in person or anything
Podcast Growth and EuroClojure Plans
01:00:22
Speaker
like that. We're going to be together for the first time again after that at the Euro Closure. So it will actually be good to see you again and to hang out. It'll be really good. And I've really enjoyed doing these shows. We've done the first 10. It's been good fun. I think we can do another 10.
01:00:37
Speaker
Of course. I mean, it's all your idea, obviously. And I'm really happy to be part of this one. And for the folks who are listening, I mean, there is tremendous amount of work Ray puts into the show. I just usually on the Sunday evening, I just show up and then plug in the mic and then start blabbering into the microphone. And then I just go to sleep. I cut most of it out in fairness. That's true. That's true. But yeah, I mean, this has been an incredible opportunity for us to, you know, every other weekend.
01:01:06
Speaker
talking to you and also, you know, having all these guests to learn from. And hopefully the people who are listening, they're getting some value out of it. And we'd love to hear from you. And we hope to take it to, I don't know, triple digit episodes, hopefully. We'll see. Wow. Well, that would be pretty phenomenal. All right, mate. See you next time. See you next time. Bye. Yeah.
01:01:54
Speaker
you