Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#11 - Alex Miller
71 Plays9 years ago
We interview the famously energetic and prolific ambassador for Clojure, Mr Alex Miller
Please check the web site for the show notes:
https://defn.audio
Recommended
Transcript
Introduction and Episode Preview
00:00:17
Speaker
Okay, so welcome to Defend, episode 11. Ray MacDermot in Belgium. And this is Vijay from Holland. Just Vijay this time. Yes. You're not giving us your full name this time. That's what we keep saying, but we never know. I know there might be a surprise guest coming up on the show. Just the two of us, I think. No, but nobody else.
Euroclosure Event Planning
00:00:42
Speaker
Just the three of us.
00:00:47
Speaker
Okay, let's do a quick news and events, announcements and stuff like that. So Euroclosure is getting closer and closer and we will be there as we told you guys. And also we started thinking about, because we have, I think this is our second double digit episode, so episode number 11. So we thought this is a nice time for us to do some solid branding. So we're gonna have a new logo and updating the website and all that stuff for Euroclosure.
00:01:16
Speaker
And also we'd like to do some speaker interviews at Euroclosure and we'll get some stickers for you guys with our new logo. So if you're listening to this episode, please check out all these stickers. We're not going to give away anything else, unfortunately. So that's... I was going to say, you know you're serious when you're getting stickers. Yes. I want to see all the laptops with the stickers on it. Exactly. That's like a big commitment.
00:01:45
Speaker
It's like getting a tattoo or something for your laptop. I'm not actually sure I'll do it for my pieces. You just discouraged 50 people from putting our sticker there.
Guest Introduction: Alex Miller
00:01:58
Speaker
God damn it man. I like the back of mine all nice and clean.
00:02:04
Speaker
Okay, so that's anywhere. Yeah, so we'll be there at your closure and of course there is new branding coming up and there is not much else going on apart from The the winter solstice is up on us. So it's getting darker and colder. So I'm liking it here. That's pretty much it
00:02:22
Speaker
Okay. So for this episode, we thought we are going to continue annoying you people by making village video tree around, but we got your feedback. But we're going to go for the big shots now. So what we have today is we have an amazing guest today. He's the third contributor on Closure for GitHub.
00:02:49
Speaker
And he is pretty much second in command for Closure development. And he is also co-author of Closure Applied. And he is the chief community officer, probably, for Closure right now. So we'd like to welcome Alex Miller. Hello. Hey, Alex. Good to be here. Hi, Alex. Welcome to DeafN. Hello.
00:03:15
Speaker
I have a confession to make though. Because I've listened to a lot of your episodes and I had to confess that I'm not a vegetarian. A boy you allow me to be on anyway. At some point would you like to be? I'd dabble with it.
00:03:33
Speaker
You've dabbled with it. You've counted. Have you ever eaten vegetables? I have. No, that's enough. You're honorary vegetarian for this episode. As long as you promise not to eat any meat during the episode, I think it'll be okay. I do have a bag of beef jerky here, but I'll refrain from it during the recording.
00:03:57
Speaker
OK, so Alex, thanks a lot for joining us. And thanks a lot for, yeah, of course, coming up on the episode. And we are very honored to have you.
Alex's Tools for Closure Development
00:04:06
Speaker
It's been a pleasure to do this thing for almost 10 episodes now, or 11, not almost. So let's start with the first most important question, EMACs or something else? So I'm an editor agnostic.
00:04:26
Speaker
Oh, my god. So I'm not going to weigh in on that one. So when I started Closure, I actually used TextMate for the first probably six months that I did Closure. And then I switched to NetBeans and Closure, which was pretty great at the time. And then eventually, at the urging of my colleagues, switched to Emacs. And so I've used Emacs a lot. These days, I mostly use cursive.
00:04:52
Speaker
But I'm... That's okay, I think. Did you hear Vijay say, hmm? Yeah. He's not 100%. Sorry to disappoint you. Well, actually, I think I like a lot of great editors in Closure. And I'm glad that there's something that matches everyone's needs. Yeah. I think a lot of people, there's many ways to edit the Closure, isn't there? There's not just one way.
00:05:19
Speaker
I think the editing part of it is less important than the thinking part of it, so I don't really care that much. Yeah.
Journey Through Closure and Beyond
00:05:27
Speaker
Well, hey, I mean, Richiki gave his Ants demo in Emacs, so Emacs is the thing. I think he uses Aquamax.
00:05:37
Speaker
Yeah, yeah, I saw that. Acromax, oh my god. Okay, we don't, of course, you know, obviously, Max is the best editor, but let's not dwell on universal facts or anything.
00:05:53
Speaker
Okay, let's get on with the show. So, Alex, as we were discussing before the show, you've been involved with Closure for almost five, six years now, almost. And I remember seeing you in 2011 at Devoxx. Before we get into how did you get into Closure, how did you get your name everywhere on the internet as pure danger? Where does it come from?
00:06:18
Speaker
You know, that's funny because it doesn't really mean anything. It's one of those sort of ironic nicknames, you know, like, like, you know. Because I look like Daring Fireballs. I'm totally not dangerous at all. So that's, yeah. Because I used to have a website at my own personal blog site, used to be baconrapid.com. So most non-vegetarian, which I decided that I was going to change it to something else. And I thought, oh, I want something that's like relatively unique
00:06:49
Speaker
in the world. And I was like, hey, my wife was sitting there. And I was like, hey, honey, why don't I call myself pure danger? And she's like, that's ridiculous. And I said, OK, I'll do that. Because I did some research, quote unquote, research. And the only thing that I would find out is that there is a kind of a crappy B movie on Amazon that said pure danger. I'm like, wow, it can't be it. I've never heard that.
00:07:18
Speaker
I'll have to go watch it now. Okay, anyway, so pure danger. Welcome to the show. So first of all, so how did you start with closure? I mean, when how and when is the when was the first time? Yeah, so if I go, like, I'd say I start the story actually, back in the early 2000s, I worked at a company called Metamatrix, which is no longer in existence. But we were I built a federated relational query engine there.
00:07:43
Speaker
that would sort of knit together different relational databases and make them look like one big virtual database. So I primarily wrote the query engine for that and
Role at Cognitect: Community and Development
00:07:53
Speaker
a lot of JDBC stuff. But that eventually got sold and open sourced. And it actually still exists. It's called TIID. T-E-I-I-D. That's a JBoss project. And the code's still out there in use. But anyways, that was all written in Java.
00:08:13
Speaker
But I worked really hard on the query optimizer parts of it for a long time, and even rewrote it in Scheme at one point, trying to get a little bit better sort of abstraction capability out of it. So years later, I was approached in late 2009 type time frame. I was approached by the founder of Metamatrix, and he wanted to build a new company. Or he already had a company, but he wanted to build a new project that was kind of similar, but in the semantic web space.
00:08:44
Speaker
And so they were asking me to join and work on that sort of thing. And I said, that sounds cool. I'd like to take a crack at that again. But I don't want to use Java. I want to use, you have to agree to let me do something else. And so I knew that we had to be on the JVM and that we needed some level of, I wanted something that had better sort of abstraction capabilities. And so I pretty needed concurrency.
00:09:12
Speaker
I was really looking primarily at Scala enclosure. And I kind of assumed that the answer would be Scala. That was sort of my assumptions where I would end up. And so we were sort of hiring people and working on some initial parts of it. And we were actually developing both in Scala and enclosure for a while the same project, mostly just sort of as a learning experience on both of them.
Closure Development Management
00:09:35
Speaker
And at some point we had sort of hired, staffed up the team. And I looked around and I realized that nobody was working on the Scala ones anymore. Everybody was working on the closure one. And I was like, I guess we've actually made our decision. Closure's real. We all really like closures though. Use closures. So it kind of happened like that. Yeah. And that's really nice actually. So what was, I mean, did you actually talk to the guys about what drove that decision? I mean, so nice that you all got there, but
00:10:05
Speaker
Yeah, I mean, I think it is a combination of the people that we ended up hiring and our own backgrounds and how things were working. But I think in general, I mean, it was also that, I mean, if you cast your mind back in time, that was a time when Scala was going through some particular growing pains. So it was difficult to get the tooling to work and the compilation to work. And so some of the just sort of day to day work issues were more complicated in Scala. They were in closure and
00:10:33
Speaker
I personally found Scala to be a relatively complicated language to learn. Whereas for me, I've always done some scheme stuff in college. And scheme and Lisp always that way of thinking about the word always made sense to me.
00:10:52
Speaker
And so I took the closure very quickly. It just was a really good match for what I was doing. I had a similar thinking, actually, but I've got to be honest, because I did Scala and then with Java and Scala, and then I actually did the functional programming course by Odersky in Scala, but I ended up doing it in closure because it was easier. It was ironic that actually doing that course by him put me into, threw me into closure's arms. Yeah.
00:11:21
Speaker
Okay, so it's a you were a lisp or at heart then so and then you found closure and and you Got into closure and but initially you were not a contributor right because you used closure for building applications How did how did the contribution path start for you? Yeah, so we were as the company was called Revolitix. Yeah, also not around anymore
00:11:43
Speaker
That's a theme of companies I work for. Hopefully not a continuing theme. It is a nice exit to exit. Most of them have been bought. But that's how it goes in the software world. So yeah, we were just very happily developing what we were building with Closure for a number of years and built up a pretty, you know, 30,000 lines of Closure and several products and selling them and doing things with it.
00:12:11
Speaker
So I was really happy with the closure as a development thing and for a variety of reasons that was kind of reaching reaching its end in about 2013 and and I kind of been trying to get into a little bit more with the closure community. I'd started closure West in 2012 And so I knew you know, I met rich I knew Stu from a long time ago from the no fluff tour as we both spoke about
00:12:40
Speaker
on that tour. And so I kind of knew the people involved. And I have a lot of background at other companies in sort of concurrency and bytecode manipulation, running open source projects. I did that at Terracotta. And so I had sort of a unique skill set that, when I looked at it, looked like exactly what relevance at the time needed to work on Clojure. And so I kind of went to them and said,
00:13:09
Speaker
you know, hey, I'd really, I think I have a lot of good skills to work on sort of helping to maintain closure. And they said, you're right, we were about to ask you about that.
Community Involvement in Closure
00:13:19
Speaker
There was a, there was one of those things where it just was the right, right time and everything. And, and I wasn't able to, the relevance wasn't able to support that. And initially when I came on, so I worked as a contractor for, for six months or so before I was able to, they were able to support me as sort of an
00:13:37
Speaker
the open source, full-time open source kind of guy. Yeah, yeah. I mean, that's like a really, I would say it's like a nice match with the kind of people that we have in the Closure community and you bring this community orientedness to the Closure, which was one of the things that personally I was worried about when I started looking into Closure because back in the day, there was a lot of discussion on the mailing list about Closure's future and how the features getting to Closure remember, you know.
00:14:06
Speaker
pretty long time ago when Rich was still taking donations and stuff, or at least announced that, hey, I want to work on Clojure for full time. And obviously, there is a need for community stewardship or community management in Clojure. And I think it was like, it is amazing that you're part of this team and you're building this relationship with the community. So that's a very nice asset to Clojure community, I would say.
00:14:35
Speaker
It turns out that I have discovered that I have some skills that are particularly relevant to doing maintenance work. A lot of people don't like doing maintenance work, but I actually like it. I like working processes over long periods of time and doing just that leading, tending kind of work that actually drives me in a way that
00:14:55
Speaker
most people find really irritating. Like Rich, for example, he's a serial inventor and he's always coming up with new things, but grinding through tickets and stuff like that is not
00:15:08
Speaker
is not something that he particularly enjoys. I do a lot better job at that. That's the nice part of forming an effective team. You have people with different skill sets and different mindsets and then on the whole, you have different people to handle different kinds of situations.
00:15:28
Speaker
that is something that I really like about closure right now with the way that you're doing the community side of it and Stuart Holloway is doing all sorts of evangelism so to speak every now and then and riches being the the lead for taking closure into a specific direction so that is amazing okay
00:15:48
Speaker
So can you give us some insight into the Closure development process? I mean, how do you guys develop Closure? Is it because you're working really closely with Rich and Stu, right? So how does it? Is it like a daily stand-up? Is it Scrum? Is it Waterfall? I don't know. It's all Waterfall, man. No, it's a. Who's followed the hammock? We actually work. I mean, we're all remote, and so we
00:16:17
Speaker
We all work very asynchronously. We have an internal ticket system as well that we manage things with. And it's not uncommon for me to go a week without talking to Rich or Stu in any sort of detailed way. But we're on chat continuously and things like that. I mean, watching Rich Rourke is actually really amazing because he is time sliced more deeply than anybody else at the company, probably.
00:16:47
Speaker
I mean, he's working on closure. He's leading efforts there. He's leading the direction on Datomic. And then he's also one of the officers of the company. So there's just normal company business type stuff. And he's split across all those things. And he's, you know, chopped up in half hour blocks all day long. And he just goes from wildly different things from one to the other, like all day long. And so I have a lot of appreciation for
00:17:15
Speaker
his focus throughout the day every day and getting all those different kinds of things done. But really he sets direction. Usually then a lot of times he'll work with Stu or sometimes directly with me and sort of coming up with an idea of what we're working on, break things down into pieces. And then, you know, I'm doing a lot of the grunt work, you know, so he'll say, you know, something needs to be done, just drop in the chat room and that I'll turn that into a ticket and then
00:17:43
Speaker
I'll work on it over time. Eventually
Purpose of Spec in Closure
00:17:45
Speaker
it gets done. And I say, OK, let's do it. Now it's done. Let's do a look at it. And then Rich will look at it eventually. But all that stuff, all those handoffs are pretty asynchronous.
00:17:54
Speaker
Okay. So are you guys the main three? I mean, I know that other people are committing to the code base, but do you guys do the kind of like final reviews or something like the lieutenants? Because you've got a bigger team than just G3, haven't you? Obviously, you know, working on various projects, you've got, you know, some of the people I know on like Tim Baldrige and people like that. But, you know,
00:18:18
Speaker
Yeah, it really varies. But generally, that's where the main three that work on closure things. And of course, a lot of the ticket work is looking at tickets that are coming in from the community. So I spend a significant portion of my time reviewing code written by people who are not part of the core team. And that's something I've tried to get better at in terms of
00:18:48
Speaker
reviewing and giving useful feedback. I've spent a lot of my life reviewing other people's code at one point or another. It's actually a more important question than tabs or spaces. Spaces. It's closure, man. Spaces only. Come on, sorry. Spaces has space in it.
00:19:09
Speaker
Tap has what? Ta? I don't know. Oh my God. Let's stop this right now because we could be here all night. Sorry, that was just a mind bomb there. OK, forget it. Let's move on. The next thing, please, VJ, bring this back on track. OK.
00:19:27
Speaker
So how much, so obviously most of the time you're working on Clojure, but do you also work on the commercial projects with Clojure at Cognitec? How much time did you do you have between these two things? I almost exclusively work on Clojure. So like in the early days, I did work on some consulting projects and, and, and I have been a bit on some and occasionally I get pulled into do like performance architecture type
00:19:56
Speaker
consulting engagements and those are usually like real quick things these are usually like one or three day type things and that's one of the things that CAC Effect does is is architecture and performance assistance things like that sometimes if we're just understaffed consulting wise then I'll get pulled in for that and then I go do travel and do closure training occasionally for companies if somebody asked for that but really these days I spend all
00:20:24
Speaker
almost all of my time working on Closure itself. Not all of that is visible. In Rich's typical way, there's always projects that he prefers to talk about things after they're done instead of before they're started. There are still two or three new things for Closure 1.9 timeframe that were
00:20:48
Speaker
pretty actively working on that we haven't talked about yet. So it's more of an Apple approach than a Google approach.
00:20:56
Speaker
tends to be more like that, yes. Yeah. I think the only time I ever heard Rich saying, I regret that I said this one before it is ready. I think that was for the parts or something. Oh, yeah. He said, no. That is the only time I heard him say that. And otherwise, I mean, he's very quiet about what he is. I think until he forms the idea, right? I mean, he doesn't want to talk about it.
00:21:22
Speaker
Well, and sometimes those ideas take a long time to form. So some of the stuff that's in spec are things that he was pulling notes out from six years ago for parts of the spec stuff. Some of that's ideas that have been kicking around the back of his head since the earliest days of closure. It just took a long time for them to gel together. Transducers, I think, was the same way. It was really a merging of several different things that happened over many years.
00:21:53
Speaker
Just a quick question on that one, actually. You have this 1.6, 1.7, 1.8, 1.9. How do you decide on the cadence of releases, Alex? Is it time or features? Or what other parameters do you use for that? It's changed over time. And I think when I came on, I think 1.5 had already been out for a year or something like that. And there had not been a lot of progress towards actually
Challenges in Implementing Spec
00:22:23
Speaker
making a 1.6. And so that was kind of when I first started working on the open source stuff, it was really how do we get this in shape and get a release out because we're overdue. Really, I would, I mean, and this is a matter of it really varies in terms of my own personal feel and then what richness do you think about it. And I mean, I would love to have sort of
00:22:49
Speaker
a larger release and a smaller release every year. I think that's a good sort of, alternating between those is a good thing. I don't think the community at large really, if you look at the way big companies absorb new releases, generally they have periods where they can upgrade on a project and those periods don't come up that often per year. So you really,
00:23:16
Speaker
Putting out two major releases a year is enough. I don't think that we need to actually release more frequently than that. Right now, we're at a point where 1.8 actually came out relatively quickly. 1.9 is turning into a longer release. And we're still in alpha, and 1.8 came out in January, I think. So I don't anticipate that we're going to be done
00:23:46
Speaker
before the end of the year. But the alphas for speaking of the 1.9 series now, alphas right now so far are really focused on spec, right? Mostly. Yeah. I mean, we have been bleeding in some of the other tickets and things like that. And Richard asked me to go through and sort of identify a set of tickets that are things that the core team really needs to be involved in sort of solving.
00:24:14
Speaker
and that are important problems to people and that are thornier things. So a handful of those actually, so I put together a list of tickets and a handful of those have already had patches on them, things like that. Some of those have already gone in and then there's some other ones out there as well that we're still looking at.
00:24:37
Speaker
Okay. So there are still a couple of new things that will be in 1.9 apart from spec. Well, there are some things we've been working on. So I'm not sure if all of them will get finished and not all of them need to be in necessarily need to be in core. So some of that might be just things that are coming
00:25:03
Speaker
with 1.9, but not necessarily in core. So it's not even going to be static typing, but dependency typing or dependent types and everything. We don't need that anymore. We got that. Exactly. Okay. So speaking about spec, sorry. I was just going to say before we go into the specifics of spec, we were speculating.
00:25:30
Speaker
Should I put that, that should be in the last episode. Speculation. Goddammit. Okay. Clever a week after. Anyway, we were kind of speculating about what the motivation was to actually put it in version 1.9 because most of the things can operate outside of the language. There's no language change, is there? In one point in the spec. Spec doesn't require any language change as far as I know. Not really. I mean, there are a few things like the
00:25:58
Speaker
the checks inside the macro expansion and things like that. So there are changes in doc and stuff like that. So there are a few things that actually do tie into core.
00:26:10
Speaker
But it's more about putting a library, isn't it, than putting another language feature in, I guess. I guess my question, anyway, a long way around it, is to say, well, why did you put it in Core? I mean, I was assuming there were some reasons behind it. We speculated about why there might have been to get a common developer experience, et cetera. But what's the real truth? The main thing is that we think it's really important. So we think it should be in the box.
00:26:40
Speaker
And so we put it in the box. So that's the main thing. I mean, seriously, it's something that I think was really needed. And it's different than the other things that are out there. And it's really both other things that exist in the Closure world and other things that exist in other language communities. And it really fills in a missing part of the Closure story, I think.
00:27:10
Speaker
that Rich has been thinking about literally for many years. There were a bunch of things that sort of gave it the spark to come out now, but it's really the combination of a bunch of different things. I think it really is this idea of
00:27:37
Speaker
not trying to be apologetic about being a dynamically typed language. There's a lot of people, a lot of developers out there that are really, really quick to sort of dismiss closure and dynamic typing as a valid path to writing software. And I think what we really want to say is that we just don't agree with that. We think that is a totally valid thing to do. And it's also a totally valid thing to want
00:28:04
Speaker
some greater level of specification about the things you're doing. And the benefit of this approach that we're taking with spec is that you're in control. And so you can choose to completely ignore spec and just write your code. That's totally fine. You can choose to add specs and use them at test time, but totally ignore them at runtime. You can choose to use them at runtime. You can choose to put specs on some things, but not on other things.
00:28:34
Speaker
different specs for the same function if you want to at different points in your development process. And so this notion of really giving you control over all that is really powerful. And it's an important part of spec.
Spec's Impact on Closure
00:28:46
Speaker
And it's different than most other things like static typing, where you have to say the types, right? And you have type inference and things like that in other languages. But even so, you're specifying those things up front.
00:29:03
Speaker
You don't necessarily need or want to specify specs for everything, and that's fine. So I think it really is an important evolution of Closure. And we think it's one of the most important things that's been added to Closure since the beginning of Closure. So that's why it's in the box.
00:29:26
Speaker
Okay, so what is the elevator pitch for spec? I mean, is it is it just like, okay, you don't need to use static typing, so you can, you can use specs to validate your programs? I'd say it's no. But I've already talked about it to some degree, but yeah, it's the notion of so the reason to do it is to is to specify
00:29:53
Speaker
additional things about your data and about your functions. And then to expend a small amount of effort doing that, and then derive a large amount of benefit from doing so. And that means that you can use those not just for one thing, but for many different things. You can use them as a form of documentation. You can use them for validation. You can use them for destructuring. You can use them for generative testing, which I think is really huge. And that's one of the areas that I'm working on another
00:30:24
Speaker
piece that will come out hopefully at some point that will help talk more about that part of the story. So I just think it, you know, generative testing has been a really important thing in the Closure community for a number of years. And obviously it's been proven to be pretty successful in other language communities with, you know, Erlang and Haskell and some of those communities have used it really heavily. I think we're taking it another step farther in terms of how it's being used.
00:30:54
Speaker
Okay. So I think that's, that's really a differentiator. So given the number of alphas, I don't remember last time having when was the last time we had so many alphas for closure releases? Yeah, I mean, so we made it a choice this this release that we weren't going to like in the past, it's really been driven by kind of by our
00:31:20
Speaker
regular dev cycle of periodically Rich has time to review tickets. And so I would build up a stockpile of tickets that needed to review. And then there'd be a good Friday or something like that. And Rich would churn through them all. And he can go through them pretty fast and evaluate what's happened with screening and everything. That's not what we're doing right now. We've done a little bit of that. But primarily what we're doing right now is really we're doing development.
00:31:49
Speaker
When spec was released it wasn't I mean it went through two months of work beforehand Yeah, and actually I wrote a couple versions of a couple really bad versions of it before that by myself and I think we learned a few things from that and then through all the code away all for the better I have no have no no problem with any of that and So
00:32:19
Speaker
When Spec was released, we released it before it was done because we wanted to get feedback from it. We've gotten a lot of feedback, so that's great. There were a ton of improvements that were made before it was released. The very early versions were pretty painful to use for a bunch of different reasons. We used it internally. A lot of the cognitive tech people used it on projects. Just tried it out as a private internal thing.
00:32:47
Speaker
So that drove a lot of early feedback. And I really sort of acted in the user role for a lot of that. And Rich would release new stuff. And I'd try it out and watch feedback. And that drove a lot of changes. But right now, you're seeing sort of a development period. And there is still definitely
Managing Alpha Releases
00:33:10
Speaker
a chunk of stuff left that needs to be done. There are, I think, a couple of contention points around spec so far, or at least from my point of view as an user. There has been a lot of discussions about the backward compatibility, especially for the NS macro, for example. Also, there were some discussions about the error messages, how the error messages should be communicated, whether they are
00:33:40
Speaker
Is it the tooling that needs to be understanding the error messages that come out of it? What do you think about these two issues? I mean, is there something that you guys are thinking about or what's your opinion on it? The first one was the required. We've added specs for parts of core and more specs are coming. That's not a done process.
00:34:09
Speaker
We've really, I tackled sort of the gnarliest syntax portions of the macros first. So really across NS, deafen, and let destructuring, those three really cover the worst of it. And partly that was because, I mean, I started working on that months ago, and that was really a way to sort of flush out problems that we saw in
00:34:33
Speaker
like things that were missing. So we found a lot of gaps in spec doing that. Because we're like, I got to a point where we're like, Rich, we don't have anything to do this with. And he's like, you're right. So let me think about it. And so that drove some of the early feature work. And then the other thing was because there are a whole host of tickets that were related to invalid inputs that were passed to those macros and not caught or caught badly.
00:35:03
Speaker
And so that, secondly, allows you to sort of get feedback on all those things. And then thirdly, which we haven't really, I don't feel like I've really sort of closed the door on this one yet, but part of it is that it's very challenging to understand the full syntax of something like destructuring just from the docstrings alone, or even the reference docs alone. And so,
00:35:30
Speaker
And I know that because I expect it. And so to expect it, I had to do a lot of work reading code. I mean, you just really have to read the code. And then I also do, I spend a lot of time using things like CrossCLJ to go out and look at how people are actually using things out in the wild and then
00:35:48
Speaker
I also test tons of open source projects. Yeah, I've seen your pull requests in multiple projects after the spec compatibility things, I think. Yeah, some of that was like a month before it was released. I was out there trying to knock down before it got out there. So when I did that, I found there were a handful of cases where either there was code doing things that
00:36:17
Speaker
we would consider invalid, but things that actually succeeded. And so the require stuff falls into that category. And then people doing things that were invalid and that were ignored. And so things like using keywords in the or map of a map structuring is something that doesn't fail, but it also doesn't do what you think it's doing.
00:36:44
Speaker
usually basically your defaults are ignored. And I found a number of cases of that out in popular open source projects where people thought there were defaults that were not actually being applied and things like that. So for me, those kinds of problems where you're doing something wrong
00:37:03
Speaker
and you're not getting any feedback about it at all. To me, that's a clear bug. And so I have no regrets about breaking your code because of that. And I say that in a really breaking in terms of you're now getting an error. I consider that code already broken, but it was silently broken. So I don't mind complaining about that. The require one's kind of an interesting one, because of the way the NS macro works, it actually would
00:37:31
Speaker
do the thing you expected it to do. If you used a symbol instead of a keyword, because that actually got turned into a call that got evaluated. And so but you know, there was no documentation anywhere that says that that's a valid thing to do. And that was never the intention. So I'd say that has
00:37:54
Speaker
You can choose to see that how you like. So it was code that was never considered to be invalid, but happened to actually do the thing you wanted it to do.
Spec's Role in Error Detection
00:38:03
Speaker
And now it's not doing the thing you wanted it to do. So I have some sympathy for that. Yeah, that's true. So where I'm at right now is we're in the alpha stages. And so if my question is, is there so much of that that we are really going
00:38:22
Speaker
cause errors to come up in people's code that was perfectly okay before in terms of doing what you wanted it to do, that if that causes so many problems, then maybe we need to grandfather that particular usage of it in. If we only allowed require an import to be either a keyword or a symbol,
00:38:45
Speaker
in particular, like that would cover the vast majority of these cases. So we wouldn't have to completely open it up, but maybe we could make it slightly more tolerant. But if we do that, we then make it that way for forever. Yeah, yeah, that's true. And at some point, you need to draw the line. Or we could open it up, but then check for that and emit a warning, for example. So we could say, this is deprecated. We're going to close it down next time.
00:39:12
Speaker
in the next release or something like that. But we've decided not to make a decision on that for now. And there was sort of an initial big flood of that right when that alpha came out that's died down considerably. So I'd say it's still in the wait and see. But do you expect these kind of cases to pop up while you're filling up the core code base with specs?
00:39:43
Speaker
Well, I mean, I wrote a lot of specs in the most commonly used things in Closure. So, I mean, I'm covering NS, deafen, deafen-minus, let, when let, if let, all those things. And there are really three different use cases that I saw over and over again. And like I said, I think one or two of those fall into this category of that sort of thing.
00:40:11
Speaker
And the other ones are real bugs. So I don't know. I don't know until we do more with it. I have done some more that's not released yet. But the other thing I've played with is actually specing functions. So some of the core functions, things like just stuff like map and things like that. And it's actually interesting. I think those failures, when I see them, are actually more interesting to me than most of the macro ones.
00:40:38
Speaker
The macro ones tend to be usually because somebody is not as familiar with closure, whereas the function ones tend to be, I actually wrote a bug in my code and before I wasn't being told about it, but now I am. The big thing is that what happened before was that if you have some code that calls map and you pass it something that's not a sequence or something like that, it's seekable, then the error you get
00:41:07
Speaker
is down inside a function, a method inside the RT class enclosure. That's where the error is reported. And so you get this stack trace with an error coming out of RT saying something's not whatever. It falls through into some last case and throws an error at that point. So there's several stack frames on the top of the stack that are not related to your code.
00:41:33
Speaker
Whereas if you have a spec and that spec is instrumented right now, then you get the error at the point where you call math with an invalid argument. It points to not the line in RT, it points to the line in your code and says, at this point, you called something with an invalid thing. That is a much better error message. It's much better located in terms of where you're pointing at. We haven't talked about the error message part yet,
00:42:02
Speaker
The scope of those specs are much narrower than these big syntax DSL-type macros. And so you don't really have as much of that problem of the error message being complicated. Those are pretty good. And so I am looking forward to having some of those specs in there and being able to let people turn those on.
Improving Spec Error Messages
00:42:25
Speaker
because I suspect that people will find real bugs in their programs that they were not aware existed. So. I was just going to ask you, Alex, if you found a few little glitches yourself as you were going through some of the core libraries or is that something you'd rather just keep amongst friends? I found one of those require cases enclosure itself in one of the test namespaces. We found one enclosure script too. So those were
00:42:55
Speaker
I haven't found much yet beyond that. I do have a set of specs for spec, which is kind of an interesting thing. And so I did actually find some bugs in spec using spec. It's code writing code specs, checking specs. Exactly. The cool thing was Rich one day on chat was like,
00:43:26
Speaker
Hey, you know, if you spec form, spec slash form, if you spec form, then you can build tests for everything in spec. And I said, what? And he said, well, if you build a spec that describes all of the different forms of the specs, then you can use the generator for that spec to generate specs. And then you can use each of those specs to generate data.
00:43:49
Speaker
pass into
00:44:04
Speaker
blowing things where I was like, oh. Yeah, yeah, yeah, that's true. But that is the thing about the lisp and recursion, right? I mean, if you think about Haskell, if you think about other things, they are like, okay, values have types and types have kinds and then somewhere it stops. But in lisp, they keep going again and again and again and there is no bottom in this one. So it's a true sense of recursion.
00:44:28
Speaker
Okay, so the other other issue that we're talking about is the error messages. So there have been some discussions about that one too, right? Yeah. And, and I think those are, you know, I think those complaints are, are well founded, to some degree. I mean, I mean, I, I believe me, I read more of these speakers than anybody else. Because I was debugging, running it on dozens of open source projects and found lots of them. Yeah. And there are a combination of these,
00:44:56
Speaker
the DSL macros that we've added specs for, things like NS and let, destructuring, and defn, really destructuring NS in particular, those two are really, really complicated. I mean, they're like 50 plus lines of spec for each of them. So there are some particular problems that drive those into being hard to generate automatic errors that are
00:45:26
Speaker
really good. So they're kind of on the, in my mind, kind of on the outer edge of that problem. They're exhibiting all the worst aspects of that problem. So like one of the things that comes up is fan out. So when you have a big fan out with an alternate or spec is going to try to evaluate all of them. And it's going to report errors that the thing you're doing doesn't match any of the 15 options.
00:45:55
Speaker
And so you're going to get 15 errors. And so that has this inherent problem in it that you're going to get this large explosion there. I think there's things that can be done, though. And there's a bunch of different things that can be done. And there are targeted changes that would help in all of those. And then macro errors, in particular, are doing this thing where you're matching the arcs past the macro.
00:46:25
Speaker
And so when that gets reported, it gets reported as like a list of the arguments instead of a call invoking the macro with the arguments. Okay, that in itself is just it's confusing to read the way it's it prints out right now, but it's that's totally fixable. So and then there's some other problems around in particular around regex is the fail at the end, like cats, the fail at the end, things like that, the way those are being reported. And so there are a bunch of
00:46:54
Speaker
individual problems that I think contribute to making the error messages harder to read than they could be. And so I've been experimenting with some of those and I have no doubt that we will make more changes with it.
00:47:09
Speaker
So I don't see it as a done area.
Release Strategy for Spec
00:47:14
Speaker
Of course. A little point on that, actually, Alex, is this kind of like error messaging thing, a little bit like test check in that you want the smallest possible failing case type thing. That's the kind of logic you want to apply to it. Yes. And so one of the things that I've got sitting around somewhere is a thing just to sort the thing that matched the farthest
00:47:38
Speaker
up to the top of the list of problems. And so that in itself, that's usually the problem is that it's how do you determine intent, right? The user intended to do something, and they failed to do it. But of all the possible options they could have done, which one is the one that they were actually trying to do? And the one that got the farthest into matching is probably the closest. And that's something that Colin had
00:48:07
Speaker
had pointed out when he did his stuff with cursive.
00:48:11
Speaker
And I think that's, from having looked at a bunch of them, I think that's a generally, that's a good heuristic. So I think we'll leverage that. I'm sorry, go on. I was gonna say the kind of, I think the thing I looked at Bruce Hellman, and also when you look at Ellman, things like this, which is the sort of poster child for some of these error messages, you know, you want things like, oh, you've said that, do you mean this? Is that the kind of thing that ultimately you'd like to get to?
00:48:38
Speaker
No, so we're not gonna do all right I think I think that should be that should be part of other languages. It's like oh you have this error. Do you mean to write it in closure? So I mean like what we've done is that we've made the the explained printer is now pluggable, so There's nothing that's preventing you from plugging in
00:49:06
Speaker
some sort of external thing that does that now. So, you know, we've drawn a line that's on the other side of the line. I don't expect to do that part. But it's totally, you know, it's totally feasible for someone to do that and then plug that in as the explain printer for
00:49:28
Speaker
For spec and then you get those out. So out of the box the specs error messages will be in terms of data structures No, I mean what you get now is You get you get an error printed. Yeah And so that's not that's not data. That's that's an error and that's what you get now But the exception that's being thrown has that as the message and it has it's an X info that has the X data Which is the explain data?
00:49:58
Speaker
Okay. So you have all of the tools to be able to do whatever you want to do with it. Okay. So wrapping up with the spec discussion, so how much percentage do you think is still coverage of the core is needed to bring spec to a release version like a beta or at least one of mine? I don't know yet. I have a discussion table to talk about this with Rich, but
00:50:26
Speaker
I mean, I have a list of things that are things that I think we must fix or do, things that I think we should fix or do, and things that Rich needs to weigh in on whether or not we're going to do them. So I have a big list of that kind of stuff. But it seems like it is nice to have this kind of a band-aid sort of approach that you just need to put specs in one go rather than putting these things in multiple situations or multiple versions.
00:50:55
Speaker
You mean in terms of adding the 1.9? Yeah, exactly. So adding specs to all the code libraries. Oh, yeah. Yeah, I mean, we didn't ever really seriously consider creating it a library that was independent from the code because we wanted to be able to integrate it more. And we really didn't want to spend time on integrating it with multiple versions of Closure and dealing with differences and stuff like that. We really wanted to focus on making spec great and putting it in the box.
"Closure Applied" Book Overview
00:51:25
Speaker
It's just a matter of difference in priorities. Okay, cool stuff. So I'd really like to talk about the book, Closure Applied. Fantastic book, by the way. I mean, thanks for writing it. I think it's you and Ben Van Greg, right? Did I pronounce it correctly? Yeah.
00:51:42
Speaker
Yeah, I mean, this is like a very, it fills a nice spot in the closure book, real, so to speak. Because you know, you have this programming closure, you have Joy of Closure, you have plenty of other books as well. But this is really practical guide, you know, talking about how do I start with, how do I model my domain? So when I started with closure, I think probably the same time in 2011 or something or 2010,
00:52:11
Speaker
So because I've been so much used to Java and every time I used to think about, okay, I need to create a class, I need to create this kind of stuff. So all these questions, I mean, the book has been really helpful for me at least in structuring large programs or structuring closure programs in general. So can you give us some quick summary for the people who haven't read that book yet, the central ideas of the book?
00:52:35
Speaker
Yeah, so it I just want to mention the holidays are coming up. Yeah, make great gifts I recommend buying them 15 or 20 at a time and give them to everyone. Yeah No, so I mean Ben actually started working on the book before I was involved and had already talked to the publisher and everything and he was actually looking at doing something a book that was sort of talking about closed the closure ecosystem and so he really wanted to talk about not just
00:53:04
Speaker
how you use Closure, but how other libraries can be used with it and things like that. And so through a series of conversations, I got pulled in and I kind of hijacked the book. So, and no, I mean, we had a lot of long conversations about it and ended up, and the direction changed. And we really, the goal was really, you know, okay, I've learned Closure syntax and how do I use it? And like, Ben had
00:53:33
Speaker
It was at the time a cognitive consultant cognitive tech and had been on a bunch of different, you know, fairly significant closure projects. And I had spent a few years doing, you know, production closure before I was at cognitive tech and then did a little bit more few projects after. And so it was really like, can we distill down the things that we see people, we see people being successful with in terms of how they build applications. And so,
00:54:03
Speaker
It's really broken into three parts, foundations, applications, and practices. The foundations part really talks about domain modeling, collections, and sequences. Those are the three chapters in the foundations. The application sections talks about state, managing state enclosure, doing concurrency and parallelism, creating closure components,
00:54:32
Speaker
And we really got pretty deeply into query sync and that sort of thing. And then composition. How do you put different pieces together into an application? And then the last section of practices is more sort of orthogonal things like testing serialization formats. We're talking about things like Eden in transit. And then how do you actually deploy?
00:54:55
Speaker
the app into something. Okay. Are you working on the next edition of the book already? Probably releasing along with 1.9. No, I mean, we're not working on anything right now. So it's to some degree is driven by the publisher. Okay. So it's a matter of them telling us that they're willing to do a new edition of it. I think some degree that has to do with
00:55:21
Speaker
you know, how, how much they've sold to the first one. And then how many things have changed. And at some point it will make sense to do a new edition. And, uh, you know, we'll, uh, we'll, we would be happy to do that at that time. There are a lot of topics we left out. And so we were really trying to, um, look at like, what are the things that are really important? And, uh, we were unabashedly, we unabashedly ignored things that we,
00:55:47
Speaker
did not think for that important. So whole topics like macros, like macros are not mentioned at the whole book. That's true. And that's not that they're not important, but they're not essential. You can write apps without macros, and you're totally fine. And so we just decided that was a... And plus also Pregmatic has a whole book about macros from Colin. So we decided that was not as critical. So you're going to write a new book that says Closure Applied, now with macros.
00:56:16
Speaker
Well, I mean, I think that would be one topic that like would be would be great to add. And there's there's others people mentioned stuff to us all the time. But and then the other thing I'm doing right now is actually working on a new third edition of program enclosure pragmatic, which is Stu Holloway's book. Yes. And then the second edition was done by Aaron Bedra. Yeah. And sort of I'm working on revising it for
00:56:42
Speaker
It's now, I don't know when the last edition came out, it was like 2011 or 12 or something. Yeah, pretty long time ago, yeah. The swan book. I still read that book, though. Once a month, I still get that book out and have a look at it. It really does explain things. Some things really, really well. Yeah. Like the set theory. I don't know why, but the relational stuff, the set stuff really has got a great explanation in it. And I keep on going back to it, you know. Yeah, and there are parts of it that are at this point
00:57:09
Speaker
sort of no longer relevant, like there's things about def struct and stuff like that. There's parts of it that aren't as relevant anymore. And so some of doing a new addition will involve removing some
Organizing Closure Events
00:57:20
Speaker
of that stuff. Some of it is just updating and tweaking the text to be taking into account newer things that exist now that didn't exist before. And then there will also be, there will be a whole chapter about spec. There will probably be a new chapter about transducers and reducers.
00:57:39
Speaker
And so, things like that. So, we'll add some new content on things that have been created. I don't think Core S is in that book either, is it? It's not, and that probably will not be added. We cover it a lot in Close Reply. True.
00:57:58
Speaker
Most of the things I had to say about it, I tried to say enclosure flight, so probably will not add anything about that in there. Somebody else can do the closure Bible. Yeah. Yeah. That would be great. But do you have any time for the third edition to come out?
00:58:12
Speaker
No, it was originally the draft was supposed to be done by the end of the year, but I've only really started on it, so it's way behind. When a writing book is really, really, really hard work, I mean, I can imagine. It's ridiculous the amount of time it goes into it. Okay, so to the people who are listening, so if you haven't bought Closure Applied yet, go and buy it right now and then read it.
00:58:38
Speaker
And then buy it again. And then buy it again. Yes, keep buying it until you get it. That's my opinion. And of course, there is going to be a new programming enclosure. There is a swan book, right? The one with the swan on it. Yeah, that's the swan. Pretty soon. That's pretty cool.
00:58:54
Speaker
Okay, so we'd like to talk a little bit about Closure Community before we conclude. So first of all, I know you've been pivotal in organizing all sorts of events around Closure, CONGE, both East and West. And now Euro Closure, obviously, along with Cognitec folks, and Strange Loop, of course. So how did you start with these events? I mean, was it something that you were doing before? Or
00:59:23
Speaker
Well, so Strange Loop was the first one that I worked on and it's still my baby. But really that was just driven out of a desire to have some sort of a, like, I was doing a lot of speaking at that point. So I was doing a lot of traveling to conferences, other places. And I was like, well, this is silly. There should be a conference in St. Louis. So I should have my own conference. Screw this thing. I was like, it's not that hard. I know what goes into it. I've seen it.
00:59:56
Speaker
got into it, and it's been really a rewarding part of my life. It is one of the best conferences I've ever seen. Well, I was never there, but I always wait for the videos and I always wait for, you know, that's pretty amazing. Okay. Yeah. That's great. The variety is fantastic, Alex. That's one of the things that impressed me about Strange Loop is that it's like you managed to get a lot of people from a lot of different environments, a lot of different subjects, languages,
01:00:17
Speaker
And so I was wonderfully naive, I think was the way to put that.
01:00:23
Speaker
even like cultures, you know, so it really feels like it's a kind of crossover type of conference. It's like, which is pretty rare stuff like all you can eat buffet sort of thing. Yeah, yep. The idea is to get people who are from different, different cultures to sort of talk to each other, both from like academic industry, different languages, and that sort of thing. So we do a pretty good job of that. Yeah. And then the
01:00:53
Speaker
I started Lambda Jam and Closure West at later points, and then that quickly, I quickly realized that was too much for me to do. All three of those events is just a side thing in my evenings. It's just too much. So Lambda Jam, I gave away, and that's kind of the one year in the US has died off, but I think the Australia one's still going. And then Closure West, I sort of gave to contact when I joined them. And so I still run Strange Loop, but
01:01:23
Speaker
Now, Cognitech runs Closure West, Nacogne, and EuroClosure. In the past, I've done a fair amount of work with that. These days, I'm doing as little as possible, actually, around those so that I can focus on working on Closure itself. And so, Lynn Grogan really does all of the awesome stuff that happens for all those conferences. And I'm as out of it as I could possibly be, other than sort of
01:01:49
Speaker
working on sort of the technical program aspects of it, which I still am pretty involved in. OK. So there has been some, speaking about the community, there has been some criticism around how Closure is managed. I mean, it's not like a completely open source project because it's been managed mostly by Rich and Cognitec.
Closure Management Style and Future Vision
01:02:09
Speaker
So how do you address these kind of criticisms? I think that the biggest thing is that I think people have
01:02:17
Speaker
expectations that are just different than our expectations. I mean, I see this in conferences too. The times when people are upset are when what they're expecting to happen is different than what actually happens. That's the biggest source. There's some Buddhist philosophy here, I think. I think Rich and Stu, and me to some degree,
01:02:46
Speaker
Like we all have been around for a while and from started in closed source days and went through a bunch of different generations open source. And there are a lot of people, a lot of developers that are, you know, have only been doing open source development for a few years. And sort of the default these days, I think is much different than where we started from. And so if you look at
01:03:13
Speaker
People who are used to doing open source now, they expect certain things out of a project. They expect to be able to make pull requests and use GitHub. They expect it to be a collaborative experience. Closures just run in a different way than that. Rich really looks around for problems that he thinks are important to solve.
01:03:42
Speaker
and tries to work on solving those problems. And they're not necessarily problems that, I mean, he's really looking at problems that are important for the industry to solve. And that's where closure came from. I mean, to some degree, I think he wanted to write Datomic and didn't have a good language to write it in.
01:03:59
Speaker
And so he stepped back and said, OK, well, maybe I need to make a better language. And he spent a lot of years working on trying to come up with that. And because he's a really smart guy, I think he succeeded. So he built something that was really useful for other people to use. And I think he really is interested in, and I think if you look around at sort of, I think, the descendants of closure, I mean, if you look at Elixir or
01:04:29
Speaker
some parts of Elm or a lot of languages these days have, uh, or things like a Julia or a bunch of them are JavaScript. I mean, a lot of these things have like now have things in them that I think I would say they're, those things came from, or were informed by closure. Uh, and so I give Rich a lot of credit to sort of, um,
01:04:54
Speaker
sort of seeing farther ahead and working on what were really important problems. And that means that he's not as interested in sort of getting, taking, you know, your random function that you want in the closure standard library and adding it to closure. It's just that.
01:05:11
Speaker
This is not where his focus is. And that doesn't mean that that function's bad. It just means that he focuses on other things. Yeah, fair enough. Well, there is always this kind of discussion happened since the beginning of the open source stuff. As you're pointing out, these days, everybody thinks that open source means putting your project on GitHub. And back in the days of, well, you remember SourceForge and other crap.
01:05:41
Speaker
Even before that, having just an add-on series somewhere, those days were much more different, I would say. How do you see the future of closure? Is there any long-term vision that we should be aligning ourselves with? I think it's continually surprising to me how many things Rich has thought about that don't exist yet in closure. There are a lot of things that
01:06:11
Speaker
he spent significant time working on that haven't seen the light of day yet. So, you know, our rich in particular, but I'd say, you know, our focus from a language perspective is a long term one. And so we're really trying to build a language that I think closure has a very different growth arc than most other languages. Like most other, like, if you look at like Scala is a good example, like,
How to Contribute to Closure
01:06:39
Speaker
It grew and then it got really hot. I think because it was addressing things that people were having problems with in Java and it was really an evolutionary language from Java. They were really trying to build bridges there. Same thing with Groovy is another great example. It's like trying to take Java and make it better or whatever.
01:07:00
Speaker
And I think Clojure has had a very different curve is that the number is really spiked or anything like that. It's just continued to grow over a long period of time. And I think it's actually a really healthy way for a project to go. You don't have any control over that to some degree. But it doesn't need to solve every problem or be the perfect language for everyone.
01:07:25
Speaker
to be a really good language for a lot of people to solve hard problems. And I think it really does address the issue of complexity in particular, which I think is the most vexing thing that we as developers have to deal with every single day. And I think it has more tools to deal with that than other languages.
01:07:46
Speaker
As I told Rich once, it's the least worst language I've ever used. And he took that as the great compliment it was. Yeah, yeah. I'm glad that Rich wanted to build Datamek, and then he built Closure, and he stopped at the programming language instead of thinking, wait a minute, I should write an operating system. Oh, wait a minute, I should come up with a new architecture processor or something. Fortunately, there was a dead point, yes. He didn't go to the list machine. The list guys didn't stop there, did they? He didn't go to the list machine level or anything.
01:08:15
Speaker
So, as far as I know. Oh yeah, we never know. And then he comes up with another word and then says it gives the dictionary meaning of it and then he says machine. What is a machine? Okay.
01:08:33
Speaker
So before we conclude, a couple of things that we still like to ask you. So one of the things is that you're also, I think, a big part of announcing the new Closure.org and ClosureScript.org, right? And related to that, also, how can people get involved and how can people
01:08:58
Speaker
help closure because obviously it is an open source project and obviously Rich and you especially listened to a lot of community feedback. So where should folks start if they want to contribute? So I think you mentioned the websites and that was something that Rich was really behind, has been behind for a long time but it took the right set of ideas and like
01:09:27
Speaker
the right set of people to say, okay. Getting all the right people to agree that we should do this, that we should overhaul each of those things was harder than doing the work to do a large sharing. But I'm really happy that those things are out on the site and that we're able to take PRs there and push changes up. Usually, if somebody sends me a PR, that's a good thing.
01:09:56
Speaker
I merge it in a couple of minutes. Things that are easy to merge, get merged immediately, pretty much. And then there are a bunch of things that are just undone. And there's a bunch of tickets in the doc sites. This is a GitHub closure closure site and closure script site. Those are the two projects. And those have a bunch of tags, a bunch of issues in them that have help wanted tags on them. And if you send me good,
01:10:25
Speaker
content for those, I promise I will read it and review it and merge it if it's good. Yeah. And there are especially things in the sort of in the guide how to area, those are really, you know, those don't have to be those just have to be factually correct, pretty much to be useful. And then they don't have to be even if they're not complete, you know, they can be follow ups to make them more complete. So
01:10:52
Speaker
even partial work there is useful. Things in the reference area are things that typically need to go through a little bit more work. Sometimes there are things that I can vet. Sometimes there are things that I have to take to Rich and have him look at. And so sometimes those get a little stalled out. And so I have too many things on my plate always. So between the open source libs and Closure and the docs and all that stuff. So certainly I can use help
Closing Remarks and Community Appreciation
01:11:21
Speaker
reviewing things or writing content for those, there's more to do there than I have done, for sure, or could do. Okay. Yeah, but they do look really, really good now. I think as resources, you know, we can fill another series of shows best upon all those documents, so thanks for that. I'm really happy that some of those guides exist on the Clojure site that didn't exist before or existed in other less notable places. Yeah.
01:11:51
Speaker
So I'm really happy to have a place that I can point people to learn about destructuring, or thread macros, or whatever, or spec, and just have those be things on the site. And when there's bugs, people can just send me a PR and we can fix them. I've taken tons of those on the spec guide, and people find all sorts of little problems in there.
01:12:14
Speaker
That's great to have. I'm totally, totally happy to take those. And I think we all, we really appreciate your energy and the things you've done for the Closure Community, Alex. And it's been a real pleasure to have you on the episode, actually. You know, we've learned a lot of stuff today and obviously there's a lot of stuff coming down the pike. So that's exciting times, I think. Yeah. I mean, I think that's I can tell you from the inside that
01:12:40
Speaker
There are a frightening number of ideas that Rich has. Enough to fill a lifetime of development, for sure. Nice. We're really excited to have you on the show as well. Thanks a lot for joining us. Maybe we should just finish with a couple of softball questions or something.
01:13:05
Speaker
Well, is there anything else you want to say Alex? No, no, no, no, come on. Do we get the tough ones out of the way first? No, is there anything else you'd like to say or talk to the community about that we haven't mentioned so far or is there anything else that you'd like to mention and why you've got this chance to address the huge audience that definitely brings it to you?
01:13:32
Speaker
I'm very appreciative of everything in the Closure community. It's great. I mean, it's really, you know, every day I open my email and my Twitter and see new things and I'm surprised and excited by new things. And so I think it's fantastic that the Closure community is so interested in trying new things and learning new things and pushing Closure in different directions. And that's fantastic.
01:14:00
Speaker
It's my pleasure to really just watch. Okay, so that's it for today, I suppose. Thanks a lot for joining us, Alex, again. And we hope to see you at one of the events soon. And thank you for making it into our second double digit episode of Deaf Animal.
01:14:25
Speaker
And a quick, of course, we'll post all the links in the show notes. And you'll probably, you're already listening to this on iTunes and SoundCloud and everywhere else. And we'll tweet about it. And a quick shout out to our music creator.
01:14:45
Speaker
Yes, Mr Pizzieri is doing his melon hamburger. Maybe it's Alex who's just tucking into a bit of beef jerky now. While he's quiet towards the end there, he's gnawing on some raw meat. While we listen to the melon hamburger outroying us. Yeah, thanks to Pizzieri, he does a good job and you can visit him on SoundCloud and give him a bit of love, that would be really good.
01:15:12
Speaker
Yeah, so thanks again Alex and it was a great conversation. So I guess we'll say goodbye. Yeah, that's it. Goodbye. Bye.
01:15:39
Speaker
you