Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
# 30 - Zach Tellman aka @ztellman
60 Plays8 years ago
The towering intellect of Mr Tellman is manifold.
Bit of a #Clojure joke there.
This is a LOOOONG high density episode so strap in.
Also, take your time. Breath.
And enjoy!
Go over to the web site for information and links
https://defn.audio
Recommended
Transcript
Introduction and Sponsorship by Paren Treats
00:00:00
Speaker
Hi guys, we've got a special sponsorship deal for this episode of Deafen. It's from a company that is probably new to many of you, but they're called Paren Treats. Paren Treats is a brand new breakfast product that provides balance and fun.
00:00:17
Speaker
This year, paren treats comes in two new flavours, rainbow and unicorn. Both rainbow and unicorn flavours are completely vegan, so paren treats can help you lose weight on your carbon footprint. And that's why paren treats is proud to be sponsoring Deafen, the number one vegetarian closure podcast.
00:00:36
Speaker
You can check out Parentreets online, they have two websites because of course they also need to maintain a balance. So you can find them at parinfr.open and paredit.closed for more information. Now as a deaf and listener, Parentreets is offering a special deal.
00:00:55
Speaker
you can get six packs of paren treats completely free when you sign up for their free trial. Be sure to use the coupon code DEFIN 2018 when you check out paren treats. Thanks once again to paren treats for making DEFIN possible.
Live Streaming Challenges and Guest Introductions
00:01:25
Speaker
Welcome to Deaf and episode number 3-0 and this is the first episode of this year and I think around 12 people around the world already know that we are actually trying to live stream this episode. So we apologize for all the, I don't know, trying to set up the things. But the best part of this episode is that we have Zach Talman on the show. Hello, Zach. Hey. So welcome to the show. Oh, yeah. Thanks for having me.
00:01:55
Speaker
Thank you. And of course we have Ray from Belgium. Just about at the beginning of the show. Yeah, yeah. I think he said he is having some technology issues and so we're going to ignore him every now and then. So welcome to the show, Ray. How are you? When the internet gets written in closure, we'll be all right. But for the moment, we're operating on a whole load of shit, so we have to live with it.
00:02:18
Speaker
Yeah. So this is Vijay from Holland and Ray from Belgium and Zach from the US right now. Yeah, Oakland, California. Cool. Okay. So there are lots of topics that you want to cover today.
Zach Talman's Journey in Writing 'Elements of Clojure'
00:02:34
Speaker
First of all, the book that you're writing, Zach.
00:02:38
Speaker
Where is the inspiration and why are you writing a book? Because I have terrible judgment. Yeah, I don't know. The backstory on this book is that after my first full-time job writing Closure, I immediately became an experienced Closure engineer relative to the people I worked with and so a big part of my job became training other people.
00:03:03
Speaker
uh trying to distill my sort of you know half-formed judgment of like what is good closure what is bad closure and explaining to people and occasionally if i told them you know this is not a good approach use this other one instead they would ask me why and i would struggle to answer and so i wanted to try to kind of firm up my own understanding of it and kind of also maybe
00:03:29
Speaker
have a little bit more reach in terms of these explanations rather than just whoever I happen to be working next to that day. And so that was probably about five years ago that I registered elementsofclosure.com. I was in St. Louis for Strange Loop, and I was at a bar with Chas Emmerich and a few other people. And I said, there needs to be a drunken white foreclosure.
00:03:54
Speaker
And we raced each other to registerelementsatclosure.com on our phone, and I won. And since then, I've been saying, oh, yeah, I'm going to write a book about closure one day. And I had a lot of false starts. And then eventually, the structure of the book became a little bit more obvious to me, like what I felt it should be. And so I sat down and wrote the first chapter
00:04:21
Speaker
on names in like a week while I was on vacation about two years ago. And I put it up on Lean Pub and the response was far better than I had sort of expected. And so I just kind of kept on going from there. And there have been people who paid me money two years ago who are still very patiently waiting for the book. Thank you, by the way. I'm wonderful, Zach.
00:04:45
Speaker
Come on. That's why he's on the podcast to ask you, when are you going to finish the book? Obviously, that's a hell of a long time for a book to be in progress, even though during at least half that time, I've been working full time elsewhere. I think the reason for that, in addition to me just being a very slow writer, is that
00:05:13
Speaker
The scope has broadened quite a bit from what I thought it was going to be because it turns out that trying to give a reasonable sort of proxy for my judgment requires
00:05:27
Speaker
articulating a lot of things that I didn't know how to articulate. And so there's just like a lot of reading and a lot of just kind of mulling over stuff in my head to be able to do more than, I mean, because like the Strunk and White thing, like that's sort of where the name came from. And it's becoming an increasingly inaccurate misnomer, I think, because now I kind of joke that I should just call it what is software anyway, the book, because like it's it gets much closer to sort of what is the
00:05:52
Speaker
underlying philosophy, right? I mean, names, like you can give sort of hard and fast judgment about, you know, what sort of names to use in certain situations, but a lot of the time what you're trying to do is saying, you the reader have the domain knowledge that is required to make a good decision here. All I can do is provide you a framework to kind of plug your knowledge into and sort of weigh the various considerations. And that's a lot harder than writing a style guide. It's also, I think, much more useful than a style guide. I certainly hope so at this point, but
00:06:23
Speaker
Yeah, so I've just been really struggling, I think, to write the book that I feel I would have want to have read, maybe a couple of years into writing Closure. And since I've been spending this much time, I kind of want that to count for something. And so I've been getting increasingly sort of ensconced on these increasingly
00:06:47
Speaker
abstract questions about naming and abstraction and all these other sorts of things. At the beginning of 2017, I actually quit my job so that I could spend some time working on the book and also working on a separate project. I thought it was going to be three or four months of my full-time attention and it hasn't been that.
00:07:11
Speaker
you know started reading books and finding that they didn't really quite answer my question and so that i looked at their references and i read those books and i've been just doing this breadth first search through the literature and uh you know a year went by and so um again i have terrible judgment uh but it's
00:07:31
Speaker
getting very close to being done. So I'm about halfway through the draft of the final chapter. I'm giving a talk on it in New Orleans a month from now, a little bit less than a month from now. And so I'm committed. I need to go and do this. The chapter probably won't be out before the talk, but I will write up the contents of the talk into the chapter soon thereafter.
00:07:54
Speaker
And then I look forward to stepping away from the book for a while. Like it's going to be a first draft. There's going to need to be revisions. Everything I've written in this book has undergone rewrites, but I think it's time for me to just kind of
00:08:10
Speaker
focus on something else for a little bit. So once I have a first draft to give to people, I'm going to feel comfortable, I think, not having any new updates for, you know, half a year or something like that. Maybe there's one question for you, Zach, actually, is, you know, like you say, you're a closure programmer and all this kind of stuff. But I mean, I've read half of the book and I'm skipping through the abstraction bit at the moment. I'm sorry to say, I haven't got a year to spend reading it.
00:08:40
Speaker
Well, I mean, I've really that's that's hopefully not the thing. I mean, I really hope that it actually I mean, I've read books where someone has tried to prove to you how much they've read and I find those incredibly obnoxious and so, you know, my hope here is that, you know, the book is hopefully not gonna be over 100 120 pages and it's dense but it's meant to be extremely concise and you know, hopefully is not
00:09:07
Speaker
totally unapplicable to what you're doing. And so if it feels like you've been reading for a year, I haven't done my job, right? No, no, no, no. Quite the opposite. No, it's I think I read the names bit and then I saw the second bit and I just haven't got round to it. It's in the queue. But I guess my question for you, because I started reading the abstraction bit this afternoon. Well, actually yesterday afternoon. OK, I'll tell you the truth.
00:09:32
Speaker
I was busy this afternoon with something else. So, blah, blah, blah. My question really is, is why do you think I've looked at the names and stuff. Why do you think this is specific to closure? Because it seems like a lot of this stuff is quite general, actually. It is. And that's sort of why you kind of glue it into closure. Or is it just a starting point for you? Well, again, I mean, the book is
00:10:02
Speaker
grown in scope since I named it and let that be a lesson there, I guess. But the short answer is that I don't know what an elements of software book would look like, because if there's not some sort of foundation there of a... I mean, you could do what Knuth did for art and computer programming and spend the first part of the book defining your own language.
00:10:27
Speaker
And then sort of just kind of go from there, but I don't have 25 years to go and do this. I mean, I think that if I were trying to aim at a broader audience, A, there'd be fewer people who'd be willing to give it a shot. I think there are people in the closure community are uniquely willing to go and put up with my bullshit.
00:10:51
Speaker
But also, I don't know, the choices that are made in Clojure, even though many of them are choices which I've come to disagree with, having spent two years looking at the language and the kind of decisions there, it's a well understood common ground between me and the readers, and that means that I can
00:11:11
Speaker
I don't have to spend a bunch of time explaining stuff and then exploring the consequences of what I've just explained. I can just kind of assume that people are coming in knowing what they know. And maybe one day we'll know how to write elements of software, but I don't now and don't plan to try anytime soon. So I've been trying to
00:11:33
Speaker
You know encourage people who don't know closure or know a little bit of closure but don't you know use it full-time or don't plan on sort of getting very deep into it and saying you know read it and let me know how it turns out see if this actually you know helps you with software in general not just with the closure language but I mean at the end of the day it's.
00:11:54
Speaker
The die is sort of cast here right like i made these choices i'm aiming at closure there's a lot of all the examples are in closure and you know if if other people happen to read it and find it useful i would be very happy with that outcome but it's not the outcome that i'm sort of aiming for.
00:12:11
Speaker
Well, yeah, I mean, I think it's OK. I mean, it's just a general question. So because I was I was thinking also that when I was reading it, looking back at it, I read the names part as well, was that it seemed to be aimed at a certain maturity of project. It wasn't just a kind of like a ten liner or a small library. It was about a kind of.
00:12:34
Speaker
multi-year project or a big project, let's say, something which justified some effort to think about how you segregated your functions and your names and all these kind of things, rather than just something which you could throw together. Is that right?
00:12:51
Speaker
Well, I mean, I guess saying, you know, if you're if you're using this now and you'll never use it again, do whatever, you know, gets you to, you know, from A to B is a very short book and probably not a very helpful one. Right. So but I mean, also, a lot of code that we write is throwaway, not because we want it to be throwaway, but because it's too hard to make it.
00:13:11
Speaker
something that can remain useful over time. I think that we're incredibly bad at doing that. It's a hard problem, so I don't mean to say that this is our fault for being crappy programmers. I just think that we have gotten very good, in a lot of cases, at writing throwaway code and building stuff up from scratch because it's too hard to go and reach back into our
00:13:37
Speaker
get history and like pull out code that is actually something that we can use in this context as opposed to just kind of taking the lessons we learned from that code and carrying that forward.
00:13:46
Speaker
What do you think the difference is that, I mean, because one of the things I thought about with functional programming was that maybe there would be more stuff that you could carry forward, a bit less kind of context required. But I know from the book you talk more about that everything sits inside of a context, which of course it does, but there's a sort of global context and then there's a sort of narrowing of those contexts as you get down to your specific program.
00:14:17
Speaker
Right. I mean, so this is something that I've actually so I've been doing a small edit to the abstraction chapter and one of the things I talk about. So like the one of the aesthetic of closure, right? The thing that we're sort of told is you have a bunch of these functions are sort of floating out there and then you go and just kind of reach out and you pluck them and you put them next to each other and you compose them and then you let data flow through them, right? And so you and it's easy, right? And that's a that's a really compelling idea.
00:14:46
Speaker
Right that we just have these like perfect functional like orbs floating up in the air and we can just go and kind of pluck them and use them however we want. I have a suspicion you're going to drop these in a minute.
00:15:02
Speaker
The only way that you get that sort of indirection, this sort of complete separation where this orb is being used with this orb now, but we can totally rearrange the whole system, is if no one cheats, no one kind of looks under the covers, no one goes and presumes that they're being used with this other thing over here. And I think that
00:15:24
Speaker
Cheating is the only thing that makes sense in some of these cases, right? Because a lot of functions we write will never be used with outside of the sort of context that they're in. And we should be able to rely on the details of how we're going through that. That sort of coupling is not inherently bad. That coupling is what makes it possible for us to go and build something.
00:15:45
Speaker
The example I give of this is the mitochondrion. This is the little organelle that sits inside each cell. It goes and does cellular respiration. It's the powerhouse of the cell.
00:16:00
Speaker
all the markings of an independent organism. It has its own DNA. It has its own cell walls. But two billion years ago, it got absorbed into the eukaryotic cell, and it hasn't left sense. And so it can't exist outside of that context anymore. And it's been shaped to the needs of that context because it produces a lot more ATP than it itself needs. And if you were to go and cut it out and drop it in some sort of other environment, it would die.
00:16:28
Speaker
And so even though we have these things that are functional, they are referentially transparent, they have all these qualities that make us think that they should be able to be used anywhere we want to use them. But in practice, I think that unless we have a lot of discipline in terms of how
00:16:50
Speaker
much we depend on the nature of the implementation, then that's not true, right? It's sort of false indirection. And I think that that's extremely true in Clojure as it is anywhere else, which is why, you know, I mean, if you contrast how the Clojure ecosystem looks to say like the node ecosystem, like we don't have one function libraries,
Challenges in Clojure Code Reusability
00:17:09
Speaker
right? We don't have a left pad library. We don't have these other sorts of things. And I mean, nor should we, I think, because
00:17:17
Speaker
If you have to go and kind of understand the the api of a given function like what shape of data does it expect what kind of data does it return. That's a lot of work to just get one function's worth of utility right if you have a whole library like the surface area of the api is relatively small to all the stuff underneath and that actually makes it worth learning.
00:17:36
Speaker
That means that within that library, people can go and make these things that are more coupled and are only purpose-built for the purpose of the library because people aren't going and reaching in and pulling out one function and saying, oh, I just needed this. Thanks.
00:17:54
Speaker
With that said, I think that in some libraries that I've written, I've taken pains to say that they have MIT licensing, because that allows you to go and just copy paste code as long as you put like a little inline attribution there. Because in some cases, there are things that are generally useful. And in some cases, you don't want to go and just create like your own little catchall utility library that has a bunch of functions that you think might be useful to someone someday.
00:18:16
Speaker
But like at least they can if they ever want to so that was a very long-winded answer to your question, but hopefully I I'm really I'm wondering like you you're using this analogy between I don't know biochemistry and then computing Do you think that is going to be? Like easy to relate to or is it from your background or certainly not my background So
00:18:43
Speaker
I think that, I mean, I've had to cast a pretty wide net in terms of the reading that I've been doing because there's basically one paper in the entirety of computer science that reports to say what abstraction is, and it's not a particularly great definition. And if you want to do that, there's a talk that I gave, which I kind of go into more detail. So it's a paper called proof of correctness of data representations. And the
00:19:13
Speaker
Short answer is that I could go and I could come up with an example. I can come up with some sort of test application and I could go and craft a whole bunch of examples where I say I'm going to define what the customer is and what the data model is and all this other sort of stuff and then I can go and sort of play around with a bunch of examples. But I think that that runs the risk of overfitting the examples to a very particular domain.
00:19:34
Speaker
And the nice thing about the physical world is that we all kind of understand it already. And so I can draw analogies there, which are imperfect because the physical world doesn't work exactly the way that software does.
00:19:50
Speaker
It's close enough, I guess. I mean, there are some people who have gone real hard on the whole like software should be more like biology thing. Anyone can go and watch Alan Kay's talks from the last 20 years because there's basically like a talk and a half worth of material between them. And he talks about this a lot because he has a biochemistry background and I'm not as
00:20:12
Speaker
Convinced of the utility of that analogy as he is but I do think that the mitochondrion example is a good one Because it talks about how something which purports to be independent isn't right and I think that that that's a that's a very natural sort of thing and so I think that you have to Be careful about trying analogies, but I think that there are very powerful analogies that require a lot less Build up to kind of have the necessary impact and that's that's sort of what that's why I use that particular one
00:20:40
Speaker
To look at other languages for a moment, you know, especially functional languages, a lot of them talk about abstractions as part of the language. So you have abstract data types, you have higher kind of types, you have existential types and all these kind of things. But I noticed that you kind of
00:20:58
Speaker
You dodged a lot of that monadic type discussion. You don't want to get into that stuff, which is fine. I mean, you know, who does, you know, but but but they're claiming all of this abstraction in their type systems. Is that something that you did think about challenging or because I know that Rich did it in one of his talks and so. Yeah, I mean, so I did think about whether or not I wanted to try to do this. And I realized that after kind of
00:21:26
Speaker
getting halfway through the chapter, I realized that what I was focusing on. So the paper I mentioned, proof of correctness of data representations, is like one of the earliest things about how do we prove that a data structure is correct, right? This was written back in like 1972. And there's been a whole lot of academic focus on this sort of question of how do we construct proofs, right? That's kind of the artifact that every paper needs to have for it to get published.
00:21:49
Speaker
Even in cases where it's just talking about an interesting engineering result, people still need to have some lemmas in there to get it past the reviewers. And that's fine. But that's sort of a cultural thing rather than something that I think relates very much to what is actually useful in software. And the thing that I advocate in the book is that people should stop talking about software being correct. They should start talking about it being
00:22:20
Speaker
self-consistent, where self-consistent means if we look at the implementation in terms of itself, like as sort of a self-enclosed little bubble, it does what it's supposed to do. But that's a completely separate thing than is this abstraction, is the software useful, given what it is that I'm trying to accomplish.
00:22:38
Speaker
And since that has to take into account the world, and the world is not reducible down to a finite number of elements that we can go and construct a proof around, all of these tools that we have, all these higher kind of types, all these other sorts of fun little toys that academia has given us,
00:22:54
Speaker
Don't help us, right? I mean, and I don't mean to go and say that writing self-consistent software is easy or a solved problem or like not something that type systems can really give us a lot of leverage on. I just don't think that it is actually the hardest problem. The hardest problem is dealing with the world and the environment that our software sits in and making sure that our software continues to adapt as the environment changes around it.
00:23:16
Speaker
Isn't this something similar to, I remember reading an article by, I think probably one of the person who wrote IO or that one of those languages, that his idea, I'm sorry, I'm not really good with the names, I'll look it up later and then put a link to there, so that, you know, I think it's similar to what you're explaining, that the types are only useful within the system, but at the surface area, you know, you need to have dynamicity or dynamism to deal with the external world. Is it something similar?
00:23:46
Speaker
I think that that's part of it, certainly. I think that this is orthogonal to the question of dynamic versus static types. I do think that having some dynamism at the edge of your system is helpful because the world doesn't...
00:24:01
Speaker
The world doesn't have schemas, right? And so at the end of the day, we can go and we can have something that says, OK, you give me a bunch of bytes and I'm either going to say this fits exactly what I need it to be or no, and then tell them to like go away because they gave you malformed bytes. And that's OK, because if the computer is talking to another computer, they're both sort of rigid enough in that way that that that works most of the time.
00:24:24
Speaker
What do you think about these companies like Yelp and all these other things, which are essentially trying to force a schema onto the world? Because they're trying to do that. I mean, all of these like Unix utilities that are essentially becoming startups, they basically say, OK, well, the schema is location, rating,
00:24:45
Speaker
And that's it. And I guess, of course, maybe you're going to say the same as I'm thinking now, which is, well, they start like that, but actually they evolve into something much bigger and their schema becomes very baggy and horrible. But that's where it starts for sure. Well, I mean, I don't know that that's what I would say, actually. I mean, I should say that, sorry, I cut you off there. Was there anything else you wanted to say? Nothing useful.
00:25:13
Speaker
We'll cut him off completely from the episode anyway. I did actually work for one of those companies that tried to have a schema for the world. It was called Factual. And it was actually an interesting one because in addition to having some well-formed data, it also tried to be sort of a foreign key for all these systems. So it had an ID that it would map onto a Yelp ID and onto a Foursquare ID and onto, I think, like 30 different sort of services, all of which try to capture facets, right?
Software Legibility and Structure
00:25:42
Speaker
And I mean, Yelp is an interesting case because the only things that we can measure, the only things that allow for us to kind of build these indices are things that are either enumerations or scalar values. And so Yelp goes and says, OK, you have a rating, and I'm going to give you an average of the rating, or I'm going to do some sort of weird
00:26:03
Speaker
slightly sketchy illusion of good and bad reviews based on possibly them trying to scam the business owners into paying them protection money. But that whole thing aside, they also have all these reviews, which are just bags of words.
00:26:21
Speaker
Someone could say, oh, three stars because the service was slow or three stars because whatever. I live in the Bay Area where apparently the fussiest people in the world live because they'll go and give them like two stars because the decor wasn't quite up to what they would expect given the price scale or something like that. It's ridiculous. You can do sentiment analysis and other sorts of things. If you look at Amazon's things, the reviews, they'll go and pull out common phrases and stuff like that.
00:26:49
Speaker
At the end of the day, it's a much more amorphous kind of data that doesn't lend itself to this kind of quantification that computers kind of need to be able to deal with the data. And I think that that's a
00:27:04
Speaker
recurring and sort of unsolvable problem, right? Because there is this amorphous data and we're trying to make it sort of very well-defined so that we can actually do stuff with it. The other kind of thing that I'll do, and this is a longer answer and
00:27:19
Speaker
I should ask, do we have some sort of time limit here? Because I've been reading and thinking and writing about this for a year, so I can talk for a while. We've got hours. It's 8 o'clock now, 8.40. We can go for another hour and a half. I was actually thinking the other way around that you might be heading out the door, but if you've got time, keep going. No, not at all. It's fairly early here. We've got nothing else to do, so we are happy to hear your thoughts.
00:27:48
Speaker
So there's a book that I've referenced in a couple of talks and that I think is a really great book called Seeing Like a State, which is the subtitle is, I'm paraphrasing here, but like how projects to improve humanity have failed.
00:28:07
Speaker
Basically, it gives a bunch of histories of cases where the government has looked at its citizenry and said, I don't really understand what the hell you guys are doing, so I can't really help you. I'm going to go and create a model for how you guys live your life so I can start to get traction on this. The problem with this is that since the government
00:28:31
Speaker
the sort of system that it creates is not optional. Even if the model that it came up with is completely ridiculous, people don't get to opt out of it. And so they have to kind of conform to the model. And so the government kind of destroys the structure that was already there without even realizing that it ever was there because they're just like, oh, look at all these people living according to the rules I set up, right?
00:28:56
Speaker
So the author, James Scott, he calls this the government trying to create legibility, to create a legible sort of environment so that it can go and kind of analyze it and respond to it and all this other sort of stuff. And for him, legibility is this thing, which is this kind of pipe dream that they should just go and not try because they end up causing more harm than good. There's another book.
00:29:23
Speaker
which I don't know if this is what James Scott was referring to, but it's a much earlier book called The Image of the City by Kevin Lynch. And in it, he interviews a bunch of people who have been living in some city for a decade or more and asks them to describe how do they get from one place to another place? What are the landmarks that they pass? What's their mental series of steps here without them actually doing it? They're just sitting in a room and narrating how they would get there.
00:29:50
Speaker
And using this, using dozens of these sorts of interviews, he builds a little map of what are the common landmarks, what are the pieces of the city that sort of stand out for people, that people sort of navigate and triangulate by. And some cities like Boston have very well-defined landmarks, and some cities like LA or Jersey City
00:30:13
Speaker
are completely ridiculously landmark-less. And so people say, oh, I just turned left at 111th Street. There's nothing there that helps them navigate this. And so for Lynch, the idea of legibility is very important because it's what allows people to go and traverse a space. Something which is legible is a well-designed city. And it's interesting. And I've had a couple of conversations with people because
00:30:44
Speaker
One of the most common examples of a bad bit of city planning is this place called Brasilia, which was Brazil's capital in 1965. They built from nothing. It was this planned city, and they built these huge super blocks where everyone was supposed to live, and they built the government buildings in the middle, and they had these huge freeways connecting them. Just from the get-go, when all the people, all the laborers that came out to build the city were done,
00:31:11
Speaker
There's nowhere for them to live because the plan hadn't anticipated they would want to stick around and so they kind of lived out on the outskirts of the city where there's no utilities, no affordances for them at all, right? Because the city just had this kind of plan and the plan was what it was going to be and it's what the city still is, right? It hasn't really changed much. And so people didn't find it a very pleasant place to live because the city kind of imposed upon them its sense of how their life should be.
00:31:36
Speaker
Around the same time, though, there's another city that was built according to the same kind of philosophy, which is Chandigarh in India. And Chandigarh is interesting because I've talked to a lot of people in India. I was actually just in India last week for enclosure.
00:31:53
Speaker
And they like Chandigarh. Chandigarh has a central area. It's very well-planned. There are rectilinear streets. There are well-defined street addresses. It's a very respected bit of city planning. Actually, I lived there for almost one and a half here in Chandigarh.
00:32:12
Speaker
Yeah, so I mean, it's something where like, I haven't heard anyone say a bad word about it, right? Yeah, exactly. When everybody loves this place because of the planning, that's what sets it apart from other cities in India, which are much more organic. Right, right. That's the kind word. And yeah, I mean, but it's interesting because I've actually not been to Chandigarh and I would love to go because I want to kind of see this for myself.
00:32:37
Speaker
But if I were to try to articulate what is the difference between these things is that Chandigarh's boundaries are not set by the original plan. The city has grown around it. And so what the original plan was is it was a seed, not an absolute set of boundaries that people sort of had to live their lives within. And I think that that's a really important difference.
00:32:58
Speaker
where structure is important. We impose structure with our software because that's what the computers need us to do to make these problems tractable, but it's also what we need to do to make them fit in our head. We have to impose some structure. We can't just say, oh, you know, whatever, give us some data. We'll figure it out. Even in dynamic systems, we do have expectations. We don't just say, give us some bytes. We expect it to actually be a particular data type with certain invariants and will fail at runtime if those invariants don't hold true.
00:33:28
Speaker
And so I think that the real question is, do those invariants, are they at the root of the system, right? And does that mean that the entire thing has to be kind of thrown away if those invariants ever change? Or do we have invariants which kind of exist in parts of our system and we have sort of more flexible glue that fits those different rigid pieces together so that we can go and we can replace pieces of our system, but we don't ever have to throw the entire thing away.
00:33:55
Speaker
But do you think that closure hits the sweet spot between not having too much structure versus at least we have some structure. It's not going to be just bytes everywhere compared to the very strict rigid type systems that are going to tell you that, OK, this is the invariant, covariant, whatever, at a very, very detailed level description of what I mean by a type in Haskell or in other statically typed languages? So where do you think?
00:34:24
Speaker
Is closure is one of those languages? Or do you think there are some other languages that you think are going to be much more in a sweeter spot like this?
00:34:31
Speaker
You know, it's a really interesting question. I don't know. I mean, I think that the space here and this sort of quote unquote sweet spot is not very well-defined. I think that the major contribution enclosure is immutability outside of a well-defined type system. Like that doesn't really exist anywhere else. And I think that that's an enormous step forward
00:34:54
Speaker
in terms of having dynamic languages. I will say though that a lot of the code that I write is actually pretty well defined, isn't changing very rapidly. And the fact that I can tell Clojure something's true, but it still discovers and rediscovers it at runtime over and over again is slightly maddening to me. And so I do end up going down into Java because Java
00:35:17
Speaker
Well no one's favorite language is a really good way of going and saying like this is just what it is right and that allows you to kind of be much more rigid about this and so the way that I've come to think about closure and this is very informed by
00:35:33
Speaker
the sort of systems that I built with it is that it is the flexible glue in between these other pieces. And the other pieces can be written in Clojure, but often they're like Java libraries, right? They're just big old chunks of code that we kind of like pull up. And what we're doing is we're writing the thing that connects these different pieces or connects these pieces to the world.
00:35:51
Speaker
And I think it's exceptional at that. But the sort of purest idea that we need to go and write everything in Clojure at all levels of the system makes very little sense to me because I think that it's good as a host language, or rather as a hosted language, and is able to sit atop these pre-existing chunks of complex functionality without having to go and actually do everything from scratch.
00:36:21
Speaker
I have a question based on what you're talking about. I think a couple of minutes ago that there are some things in Clojure that obviously you're explaining the closures, one of the strengths that is being a hosted language. That's one of the interesting things that the power of Clojure comes from.
00:36:39
Speaker
And you said there are some things that you don't agree with with enclosure. So can you give us some ideas about which ones or which concepts that you don't think are not that useful or why don't you agree with them?
00:36:53
Speaker
I don't think that there are any large-scale things. There are certainly parts of the language that I don't think are useful. But I'm very sympathetic to the fact that you can't just start ripping things out of closure because someone somewhere uses them and you can't just go and say, oh, well, it turns out that STM wasn't nearly as game-changing as we thought it was to the trash heap with it, as simplifying as that would be.
00:37:19
Speaker
So a lot of the choices that I take issue with actually mostly circle around how nil is handled in the language. My favorite and most inexplicable thing is that the git method has a check at the top of it which says, is this an associative data structure? If not, git for the number one will always return nil.
00:37:44
Speaker
And the problem with nil enclosure is that nil is a valid anything. And so it's going to go and cascade halfway across your code base before somebody does something that you can't do to nil. And then it throws an exception. And then you have to go and walk the entire thing back and figure out where did this nil come from. And the fact that git will return nil for anything means that let's say you have some sort of arrow expression where you're doing a chain of accessors and you forget to actually put the
00:38:12
Speaker
data structure at the front, then it'll do a lookup of a keyword on a keyword. And rather than saying very reasonably, hey, that doesn't make any sense. It's just like, all right, no, whatever. And we're kind of off to the races there. And I think that there's a lot of choices there that
00:38:29
Speaker
are weird you know for instance calling nth like nil is a empty data structure calling nth on nil will return nil even if you say oh yeah what's what's the millionth element of nil and it's like oh it's nil you know and that's not.
00:38:48
Speaker
helpful, right? But what do you think is the right behavior there then? I mean, should should it be like, well, I mean, in the case of an exception or well, no, I mean, I would think that and if we were going to say if we're going to say that nil is an empty collection, and it's a little bit flexible as to what that collection is, you say, you know, nth is an an empty collection, then saying, you know, what's the first element of an empty collection should throw an index out of bounds exception.
00:39:18
Speaker
I mean, I think that this is kind of an interesting question because I've been actually putting off writing the nil part of the book for a while because I've been trying to figure out what is it I'm actually trying to say is the right thing to do here. And in the idioms part of the book, I say,
00:39:38
Speaker
I'm trying to be very descriptive rather than prescriptive in terms of the practices. I'm saying, just here's what we do in the language. You might not like it, but doing it this way is going to make it easy for other people to understand. And the problem with the nil thing is that a lot of people will go and put this when x check at the top of their function, such that if it's nil, then I'll just return nil and short circuit.
00:40:07
Speaker
on reflection is a terrible idiom. Because it just means that nil yields nil, yields nil, and then you have to go and figure out what's going on. And so I think that you have to be very clear as to what nil represents the absence of.
00:40:23
Speaker
And if you're able to say, so nil is the absence of a map, right? So you shouldn't allow that to nil to become the absence of some other data structure further down the line, because now it's completely ambiguous as to what this thing represents the absence
Clojure's Handling of Nil and Laziness in Data Processing
00:40:34
Speaker
of. And so that's something that I've been thinking about for a while. That's just an example, but I think that that's a
00:40:45
Speaker
something that is very easy to sort of Monday morning quarterback about, right? And I don't mean to go and say, Oh, man, that rich hickey, he really doesn't know how to design a language, does he? But it's, it's still, I think, we don't talk about this very much. And, you know, for good reason, because it's kind of a distraction from getting stuff done. But I think that, um,
00:41:09
Speaker
This podcast is a distraction from getting stuff done, so it's OK. All right. Well, I'm in good company here, but it's.
00:41:18
Speaker
This is our way of not getting anything done. I think there's a lot of these little sorts of things there. Can I just talk about the nil thing a little bit more? One of the things that some people say is if you use the reduce function or whatever, there's some sort of identity function or some sort of canonical value for everything. So nil does not matter. It should never be anywhere because
00:41:45
Speaker
you kind of always know something about what's missing or do you see what I mean? I mean, this is the argument that comes up. So how do you, I mean, we are what we are as far as Nilla is concerned, you know, it's floating around there, but in theory, in principle, you should be able to say, okay, well, you know, if you're, if you haven't given me something, well, I can give you something back, which is, you know, zero or an empty list or whatever, you know, some kind of canonical starting point.
00:42:13
Speaker
I mean, I think that's true, though, I mean, I don't know. It's something where if I'm going and I'm saying I want to, so take the update function. It is convenient for us to be able to call update on a map which doesn't have a key and to take nil as an indication that the key wasn't there. And of course, it's a little bit overloaded because maybe it also means that there actually was a value there and it just happens to be nil.
00:42:41
Speaker
But that's a useful compression of the code, as long as we're willing to just agree that in this context nil means this. And the problem is that there are a lot of different contexts where nil means a lot of different things. And if we could keep that all very straight in our head, then everything would be fine. But we can't, and so problems arise.
00:43:00
Speaker
And so I don't like certainly like, for instance, get could require that you have a not found argument to it, right? And it just always requires you to tell you what this is. And so maybe you could say, oh, it's still nil, but you have to be explicit about that at least, right?
00:43:15
Speaker
But that makes your code a little bit more verbose. It makes it a little bit noisier because you have all these sorts of values there. And I think that concision, rightfully or wrongfully, is a big part of what went into the design ethos of Clojure. Just having fewer things in the AST to specify a particular problem.
00:43:40
Speaker
And if that comes at the expense of some ambiguity, then that's a price worth paying. And I don't think that I can speak as to whether or not that's true. But I do think that that's very much part of the design ethos. And so you have to just kind of take it as it is.
00:43:55
Speaker
And going back to the STM things, why do you think, because I remember when Closure 1.0 was released and of course until almost until 1.3 or something, this was one of the biggest topics in every book and this was one of the things that you talk about. But obviously hindsight, you know, that gives us better picture. So why do you think STM didn't get the level of or didn't live up to the reputation in terms of adoption?
00:44:21
Speaker
So actually, do talk about this in the book. So spoiler alert. So go and write a book. Obviously, if you need to check, come on. Come on. I'm just going to start reading for my book. No. For answer for this question, go and write a book. It's a little DLC for your podcast. So the short answer is that
00:44:45
Speaker
I mean, so atoms didn't exist in closure initially. I forget when they were added. I think it was before 1.0, but they weren't initially part of it, and they were kind of just like an STM light. And it turns out the STM light is all we really need. And because the cost of using an atom is that you have less granularity in terms of the state containers, and also you have less throughput because you have to retry more often because there's sort of a little bit more contention on those pieces.
00:45:12
Speaker
But it's atoms are still fast enough because we're not doing huge amounts of like logic inside this little update functions. And I talk about this a little bit in the book where I analyze it as sort of a queuing theory problem, where I say, you know, if we if we assume that, you know, we have a millisecond update function for a thing,
00:45:31
Speaker
I think it was a microsecond update because it's like adding some stuff or whatever. It requires something like 600,000 updates per second before it actually starts to contend enough to give you 50% overhead, like half the time you're having to do a retry.
00:45:50
Speaker
we're not writing systems that have that much contention. And I think that the secondary thing, which, again, you can say in hindsight that this was predictable, is that if we did have that sort of system, we're not scaling at the level of a single big machine with a lot of threads. We're scaling with a bunch of different processes that are all talking to a database. And databases have well-defined transactional semantics. And that's where those transactional semantics have the most value.
00:46:19
Speaker
And so I think that that's why it's not very useful. It's basically just a slightly faster and much more complicated version of atoms. And we just don't need to deal with that complexity. It doesn't really give us very much.
00:46:37
Speaker
The other thing that's, I mean, again, maybe just to change gear a little bit in terms of the language, is there was a significant complexity brought around with reducers. I don't think you talk about that in a book, but maybe you do in the next track. I don't think about reducers at all.
00:46:58
Speaker
I mean, for better or for worse, since I first conceived of this book back in 2012, there's been very little that's been added to the language, which I think has changed how people use closure.
00:47:11
Speaker
spec has a chance of changing it. But going down the list, there's been core logic, core types, there's been reducers, there's been transducers. There's been core async, which has changed some stuff, but I think that it's almost been exclusively on the front end. I don't think that people use it particularly much in backend systems and where they do use it, it's not actually because they need to be using it. And so all these different pieces
00:47:40
Speaker
They're fine, and I think that the stability that we have is not something to sniff at, but there just hasn't been this much stuff. Reducers, thankfully, just exist in a little namespace. They've made the implementation of the underlying data structures more complicated.
00:47:59
Speaker
And as someone who's written alternative data structures, they've made my life a little bit harder, but they don't really change very much. I think transducers have made things more complicated because now when people make an arity mistake, it yields this thing that's going to create this ridiculously opaque error.
00:48:16
Speaker
And I don't know. I mean, I'm sensitive to why that happened. In fact, as an author of an alternative, like a stream library, having transducers save me from having to go and write a variant of every single closure core sequence function. So like, yay transducers. But
00:48:37
Speaker
It's I don't think that it's changed how people approach the language and in as much as I'm trying to, again, be more descriptive than prescriptive, I feel pretty comfortable just ignoring that.
00:48:49
Speaker
The reason I mentioned, actually I meant to say transducers, not reducers, because I feel like the one of the things, if we think about what is like interesting about functional programming is laziness and transducers flip that. So don't you think that's a big change that, you know, actually all of the kind of the way that you process data suddenly has to be eager. You have to think about that.
00:49:15
Speaker
Well, that's a really interesting question for a couple of reasons. One of which is that I talked to Rich about this, and he said, so I mean, I don't think he's gone on the record, but he said, if he had thought of transducers earlier, he would have made laziness much less of a default option in the language. Because you need to have some sort of way to compose stuff where you're not doing like N many passes over the collection each time that you want to do a series of operations. That doesn't work. That's a non-starter. And so laziness is an obvious way to do that.
00:49:43
Speaker
But it brings a lot of stuff along with it. And this is actually something that I'm talking about in the chapter I'm currently writing, which is on composition. And one of the things I kind of talk about is I say that there's this thing that I'm calling a process, which is a sequential set of operations where you're either pulling data in from outside the process, transforming the data that's within the process, or pushing data outside the process.
00:50:09
Speaker
And so this could be a thread. Typically, it's a thread. This could be one of the old Unix processes. This could also be a chain of callbacks. This could be a core async go routine. There are a lot of things that have these properties. But for the purpose of just thinking about a thread, in the most common case,
00:50:28
Speaker
Uh, you want to be pretty clear about what the different steps are in your code. You want to be able to say, okay, this code is pulling stuff in, right? Because this is, this is reliance on some other thing, which is outside of my process. As opposed to this is something which is going into transforming data that I already have and lazy sequences.
00:50:44
Speaker
conflate those quite a lot because when I give you a lazy sequence it might be a fully realized in-memory data structure that I just mapped over and so now it's a lazy view into that or it might be something which is actually like reading from a file or reading from the network or something like that.
00:51:00
Speaker
And I think that that actually is something which, again, this is one of the few cases where I'm advocating for a different style of programming than people typically do in Clojure, which is to say that you want to have something be
00:51:16
Speaker
you want to distinguish very clearly between things which are operations that are reading from somewhere else and operations which are just transforming data that you already have. And the interesting thing about transducers in that context is there are a couple of things that you can't do with transducers. You can't do sort because sort requires you to go and hold the entire thing in memory.
00:51:40
Speaker
And I think that if you kind of consider this in the case of lazy sequence, we can call sort on a lazy sequence. And what that does is it goes and realizes the entire thing and then copies it into an array and then calls like Java's array.sort on it. And that's OK if you already have the data in memory, because presumably if you can fit one, you can fit two of them. But if it's an infinite sequence, calling sort on it is going to cause a lot of issues.
00:52:09
Speaker
That's one of those sorts of cases where it gets kind of complicated and I think it's worth looking at how the GNU sort thing works because what it does is it goes and pulls in pieces like chunks of the data and then it sorts those in place and then it spills at the disk and then it keeps on doing that until it's exhausted all the incoming stuff and then it does like a little merge sort of all the chunks that it spilled over the disk.
00:52:31
Speaker
And of course, if it isn't too big, then it will never do that. It'll just keep it in memory. But this is something that is able to deal with much larger file sizes than it might otherwise have to. And in part, that's an artifact of the fact that it was like written for the PDP-11 or whatever. But it's, you know.
00:52:46
Speaker
This is a very clear separation between the active reading in and then the act of sorting, right? So there's something which is going and pulling in only a bit of data and then calling sort on that and then pushing that out. And that's a much more sort of regimented approach to this. And in some cases we can say, okay, well, you know, I know exactly what the data is that I'm sorting. It's just like a little config file or something like that. I can go and I can, you know, read it from disk lazily and sort it. No big deal. But that means that we can't
00:53:12
Speaker
This gets back to the whole question of reusability. Now we have this sort of assumption baked into our code that this works on any lazy sequence except the ones that are too big. Please don't do that. And that's kind of a very fragile thing. And I think that being more deliberate about that and thinking more carefully about when we're dealing with realized versus unrealized data would be a helpful bit of discipline to have.
00:53:40
Speaker
So I was just wondering what, so you built this, no, we would like to talk about the project that you're working on from your sabbatical. So can you give us some idea about what you're working on and what is it about?
00:53:52
Speaker
Yeah. Keep in mind that I haven't really perfected the elevator pitch for this. So it's more of a thing. It's OK. We have one and a half hours. Think of it as a very long escalator pitch. Yeah. I hate escalator pitches, mate. I mean, we had an escalator guy recently. I don't think it's working out. It's not a good model. Maybe one of those really long airport, like the little moving sidewalk things. It's a very long terminal.
00:54:21
Speaker
Basically, I want to write a tool for what I am tempted to call exploratory data processing. There are tools we use for this thing where it's not that we know how we want to get between A and B, it's that we're looking for a path between these things. A lot of the tools we use to write code presume that we know where we're going and how we want to get there. But I think that most of the time that we're writing code that's not true,
00:54:51
Speaker
And in fact, we would benefit from having tools that are more focused on that exploratory phase. And we do have some tools that sort of fit this, right? We have the shell. The shell has these sorts of things we can pipe together. We have the REPL. The REPL is an excellent tool for trying to figure out how do we get data from this shape to the other.
00:55:09
Speaker
And then we have stuff like Python notebooks, which are for data analysis, which is a sort of subset of data processing where the end result is meant to be something that is consumable by people. Like we can kind of, you know, it's either a small set of numbers or some sort of picture or something that we're good at understanding.
00:55:29
Speaker
The problem with all of these things is that the exploration process is captured as a linear set of things that we typed into the computer. That's what happens when you type history at the bash prompt.
00:55:41
Speaker
It's like, here's all the things you typed. The problem is that the exploration process is not linear. It's branchy, right? We're trying a bunch of stuff and we're backtracking. We're trying a different thing. And that narrative, that sort of structure of that branchiness is in our head for up to an hour after we did it. But after that, it's gone, which is why I know people who have the last five years of their bash history sitting in a file somewhere, but it's like,
00:56:05
Speaker
of useless to them. You don't know which one. Yeah. Exactly. How do these things relate to each other? Like, oh, was this thing where I write to this file? Was that necessary for this other thing to work? I don't know. And if you have this sort of discipline of making all of your bash things one-liners, where you're just going and building up this ever longer sort of concatenation, then that kind of works. But that's also not great, right? And so having sort of said all that, kind of what I want is Git for rebels.
00:56:31
Speaker
I want something that kind of captures the branchiness of this exploration such that if you try 100 things and the right answer ends up being four things, you shouldn't have a big list of 100 things. You should have four things in front of you and then everything else off to the side, right? There should be this sort of daggy
00:56:46
Speaker
topology to this that you can go and you can kind of you know, concatenate like compose on to you should be able to go and sort of pull stuff to in and you should be able to most importantly, search through it. Such that you know, now this is actually I think, a much more useful kind of representation of the history of your exploration. And even like, you know, a year, five years later, you can go and look at it and kind of get a sense of what it was you were doing, right. And I think that this gets to
00:57:13
Speaker
something that I was alluding to earlier, which is we don't build stuff to be reused very often. We just build stuff that is one-off throwaway stuff. Because if you go and write this little crappy script that parses a log file and gives you some statistics about it,
00:57:31
Speaker
Going and parameterizing that and writing like documentation and all this other sort of stuff, it takes at least as much time as writing the scripted. And we almost always, I think, or at least I almost always opt for just throwing it away and writing it again six months later when I need it.
00:57:45
Speaker
The net effect of that is that having been a professional programmer for a decade, I have a decade's worth of experience at writing stuff from scratch, not a decade's worth of tools in my toolbox. That seems like a not optimal set of circumstances here. I should be able to go and
00:58:05
Speaker
copyright attribution allowing, you know, be able to reuse stuff and, you know, take stuff that was part of an overall set of operations I was doing and be able to sort of pull this up, right? And so a really important aspect of that is saying, you know, each of these steps needs to be like a functional transform on data, because we have that, then we can take any subset of that and just kind of lift it up and say, this is a function out, this is reusable, right?
00:58:28
Speaker
And you, I think, need to have some sort of type system there, so it's a little bit more explicit about what shape of data it needs. It needs to be a lot more concrete than what the bash environment gives you, which is like, it's text. But there's stuff to learn there. And I'm kind of waving my hands very wildly here because
00:58:49
Speaker
The original plan was to work on the book for three to four months and then spend the remainder of 2017 building a prototype. And it turns out that 2017 was all about the book. And so now 2018 is all about writing the prototype. And so what I hope to have by the middle of the year is like some very rough kind of screencasts I can do that are sort of like proofs of concepts and everything like that. And by year's end have something which resembles what I'm describing here such that I could, I don't know, do a Kickstarter or something.
00:59:18
Speaker
and sell it as a developer tool. A few people have asked why I'm doing open source stuff where I'm writing a whole bunch of immutable data structures under a GitHub organization called Lucuna. There's also something there that does a bunch of geometric primitives and stuff like that. That's all little scaffolding that I'm building up or foundational stuff for this tool.
00:59:44
Speaker
because you need to have something which is a series of sort of pure transforms over data. You need to have good, immutable data structures.
00:59:51
Speaker
And because it needs to have sort of geometric primitives, you need to have that. And I'm writing the entire thing in OpenGL because, well, that's just me kind of because I like OpenGL. And- Is it something similar to, I recently saw a link about something called Luna or something? So yeah, so there's just not dissimilar. Is there any conceptual, yeah.
01:00:16
Speaker
I mean, so what Luna says is it turns out that basically you can treat any pure data structure or any pure sort of set of computations as like this sort of DAG data flow. So like you have the tree, which is like the sort of normal expressions. And then if you have a let binding, then you can go and you define it. And then it kind of gets as an inward edge sort of elsewhere. And so you have a DAG.
01:00:43
Speaker
What they have is they say, OK, you can write code, or you can build out the DAG. And then there's this isomorphism between the two, such that what changes in one affect the other. This is speaking more to a bit of fussiness that I have. But one of the things that all these tools have, and this is something that I've been struggling with a lot in terms of finding prior art that I feel like I can build upon,
01:01:07
Speaker
There's a whole class of tools that do visual effects or sound effects. There's something called Max MSP. There are other sorts of things that allow you to go and say, I have a node. This node represents a transform over graphics or sound, and I'm going to drag wires in between them. Because I feel like that allows people who do not think of themselves as programmers to not be scared of the programming that they're doing. The problem with this approach where people are literally dragging wires in between stuff and rearranging nodes using their mouse is that it turns into a mess.
01:01:36
Speaker
And people spend a lot of time going and trying to group stuff and everything like that. And it's awful, right? It's an awful way to go and do this. And so the way that I've described this as what I'm looking for, and I don't know precisely what this looks like yet, is I want per Reddit for DAG editing.
01:01:52
Speaker
Right. Because what Peredic gives you is this structural editing where you're not fussing with like the individual parentheses or trying to kind of like, you know, get everything just so what you're saying is this is now connected to this or this is now outside of this or anything. And these are just simple mechanical transformations where, you know,
Zach's Vision for Data Processing Tools
01:02:09
Speaker
it doesn't require you to go and be fussy about where everything is laid out with respect to each other. And the Luna thing I was very excited about, but then you see when you watch the video, you know, someone goes and takes a note and they kind of drag it out and I'm like, but why, right? Like who's asking for this, right? And I think that that's,
01:02:29
Speaker
That's fine. That is not a substantive critique of the Luna thing, but they're also going in a bunch of different directions. They want to go and make it as a general-purpose programming environment, which is not what I want. I want mine to be more straightforward. That seems a bit more like a stretch call. Making these kind of tools very generic enough
01:02:51
Speaker
is that makes them I don't know I mean for a given scope they look really nice for example if you're building like a domain specific languages like VHDL or VLSI programming sort of stuff you know they have these primitives that you can use and they have these even the CAD tools that you use they have very specific set of goals the very moment you stretch the scope then these things become I don't know super messy I mean
01:03:18
Speaker
Well, that's the thing. So this is also something that I'm kind of am alluding to in the book, which is I'm trying to come up with these diagrams where I talk about, oh, we have interfaces and we have these things. But if you've ever used a code dependency visualization tool, they come up with this weird bird's nest of lines between things and it makes nothing clear. And I think that
01:03:44
Speaker
For certain things that you're doing where there is this very clear linear chain of I'm trying to get from here to here, I'm trying to turn data from this shape into this shape, and you're not doing this complex orchestration, you're not trying to write general purpose software, you're not trying to write a UI or something like that that has a lot of these sorts of things that are tied together or all fan in and fan out from a central point of control, then I think that that works. But I think at the moment that you say, this is
01:04:08
Speaker
Superior to text or like at least a good sibling to text as a general purpose way to understand our code I don't believe it.
01:04:22
Speaker
That's not to say that these tools can't be useful, but I think that a lot of them are claiming to do a lot more than they can reasonably expect to. And I think a lot of that, I don't know what the LUNA tool is, like what its funding is, or whether it's an academic sort of project or commercial or whatever. But a lot of the other tools that I've looked at have been commercial, have been venture funded. And the problem with venture funding is that if you're going to go and try to solve one problem, you're going to try to solve them all.
01:04:50
Speaker
Because that's what you need to tell them. You need to find a path to being a billion-dollar business. And put blockchain in it. Or something. Just come up with whatever the buzzword du jour is. And I think that a fairly unfortunate casualty of this was Lighttable.
01:05:07
Speaker
My table, I think, was a really good medium-sized idea. It had some good incremental improvements to how to do text editing, how to do development. But they took a million dollars in funding from injuries and Horowitz, and that was it. Because you can't go to injuries and Horowitz and say, we have a moderately better text editor. So now, like, oh, well, we're making a better spreadsheet.
01:05:30
Speaker
right? And I don't know if they're going to succeed, like fingers crossed. They're all very smart and dedicated people, but that's a go big or go home kind of outcome. And I think that frankly, the state of development tools is poorer for the venture capital kind of ecosystem that surrounds it because
01:05:52
Speaker
There are very few things that we can do with software that will be these sorts of home run wins, where it just kind of transforms how everybody does software. Like the way that you go and you create better tools is by identifying a narrow scope of a problem you're trying to solve and building a tool which is purpose built to that problem.
01:06:08
Speaker
Do you, I mean, I guess you have watched the Brett Victor stuff. Why wouldn't you have? So I have this theory that, you know, he goes back to Doug Engelbert all the time and to Alan Kay and all these kind of guys and he's done some stuff with his feedback loop between the visual and the text and he's done some stuff about
01:06:34
Speaker
Oh, you know, stop drawing dead fishes. And there's a lot of these nice things, and now he's with his dynamic land. But I don't know why, but I have this suspicion, and maybe as you can say I'm wrong, but I think he's just catfishing the whole industry.
01:06:51
Speaker
Well, I think he's actually been pretty upfront about this. I think a lot of people have watched one or two of his talks and then been like, oh, he has a new idiom for programming, right? That's not what he's saying. What he's saying is, here is a type of interaction that I think that we should be aspiring to.
01:07:09
Speaker
And the thing that was interesting about Lighttable, which frankly it didn't achieve, but what it was was something that was saying, you know that thing that Brett Victor hypothesized should exist? We did it. And so I think that that was very exciting, legitimately exciting. I paid money for the Kickstarter because I wanted to see what was going to happen there.
01:07:28
Speaker
And the fact that it didn't quite achieve it is fine. That wasn't a disappointment to me. But I think that when Brett Victor says, it's not that he's coming up with something which is a better way to design circuits, or a better way to animate fish, or what have you. He's just saying, here is a type of interaction that we should be aspiring to.
01:07:46
Speaker
It worries me a little bit, though, that the reason why I call it catfishing is because of this discussion we've had, which is, yeah, that's a nice aspiration, but are we ever going to have a tool like that? Or maybe we'll have 100 tools like that that do something for circuits or do something for particular types of drawings. Is that what we're trying to get around to, do you think?
01:08:14
Speaker
I mean, I don't know. So a friend of mine recently shared a quote with me which I liked, which I think was Oscar Wilde, and I'm paraphrasing here, but he says, any map which doesn't contain utopia is not a worthwhile map. Right, because that's what gives us something to aspire to and progress comes from reaching for that sort of utopia. And so
01:08:36
Speaker
People like Brett Victor are important. I think he's clearly a brilliant guy. I think that he's doing a good service by making people imagine a better future. I think that the fact that people sometimes think that he's the messenger of a better future as opposed to just kind of like sketching it out is not his fault. It's theirs.
01:08:55
Speaker
But that is something where I don't mind that. I don't mind going and waving your hands. I think I do mind the fact that the only people who get funding are people who are trying to realize that utopia as opposed to people who are trying to incrementally move in the direction of it.
01:09:15
Speaker
I'm going to go and sail out into the ocean and either I'm going to come back rich or dead. It's not sustainable anything really. I think it's very harmful to every aspect of professional programming. Isn't it just feeding greed over progress?
01:09:40
Speaker
I don't know. I mean, so I've lived in the Bay Area more or less my entire life, right? And I know people who work in venture capital, like this is something where it's something that's there. And I think that there is a there there, right? And you can reasonably point to a lot of examples of where people swung for the fences and actually accomplished that.
01:10:09
Speaker
And you know, you can call it survivorship bias and it is, but that also means that there is a possibility these things can exist.
Impact of Venture Funding on Software Development
01:10:16
Speaker
And I think that, you know, one of the- What example would you give of that actually? Because I'm a bit skeptical of it.
01:10:24
Speaker
OK, I mean, you can go and you can just look at like, I mean, they go back to why they call it Silicon Valley, right? You have like Fairchild and all the kind of semiconductor stuff like semiconductors. Yeah. Yeah. But and so so like and there's been other sorts of examples.
01:10:45
Speaker
I'm reaching back to the past for a reason. A lot of the stuff that's going on right now is just people doing arbitrage on this. I do not think that Uber represents meaningful innovation and this sort of thing. There's a lot of stones that you can throw at this.
01:11:06
Speaker
I think that if you were to go and articulate one of the few really great aspects of the kind of American culture around business, it's that failure is allowed and encouraged in some cases, right? Bankruptcy laws, these other sorts of things are extremely lenient in that sort of respect. And it means that people can go and swing for the fences. And if they fail, like, poor them, they go work at Google or something like that.
01:11:33
Speaker
There is an ecosystem that allows people to go and dream big. It's a shame when those big dreams are Uber for pet shampoo or something like that. I don't want to seem like I'm parroting the Peter Thiel talking points of where are jet packs because he's a
01:11:56
Speaker
vampire who is in many, many ways a reprehensible person. But there's truth there. I mean, people wouldn't be saying that if there wasn't some sort of truth there and people wouldn't be continuing to invest there if there weren't some value. I think the problem is that the noise has just overwhelmed the signal to a great degree in the present. I think we're getting way off topic now though. Yeah, that's true.
01:12:23
Speaker
I think we riffed on the entire Silicon Valley. Can I just make a start? At the beginning of this episode, I was going to say something to you, actually, because the episode before this was with Zack Oaks, and now we have Zack Telemann. So I was asking Vijay, actually, whether or not we're now not allowed to have anyone on the podcast. It isn't called Zack.
01:12:45
Speaker
Because they're going to change their names. Yeah, I think that. Well, you know, I mean, you should be aware that, like, it was a very popular name right around when I was born. So just make sure that, you know, you target a bunch of, you know, American dudes who are in the early 30s and like, you'll be golden. I think the gender balance works.
01:13:06
Speaker
But what is the female version of Zach? I mean, is that a female version? Oh, there is one. It's a biblical name and not all of those have like male and female, like, you know, equivalents. Oh, okay. I'm not aware of this. Isn't it Zil?
01:13:25
Speaker
Zach and Zell went up the hill. Sorry. Anyway, so I think we can get back to a bit of closure before we, wow, it's one hour 15 minutes. Okay. So how did you get into closure? Of course. I mean, we talked about, you know, post closure era. Can you give us like, you know, pre-closure era and what were your frustrations that pushed you into closure?
01:13:50
Speaker
Sure, yeah. So I went to school for computer science, and for three of the four years that I was at school, I was pretty sure I wanted to work in video games. And after having actually looked at what that was, I realized that that was actually not a thing that I wanted to do.
01:14:08
Speaker
Yeah, but I was coming out of school with a focus in graphics and computational geometry and you know something that I I still to this day, you know Really enjoy just a sort of a thing. It's it's it's a very satisfying thing to make computers Show you images that are very, you know, kind of visually stimulating and
01:14:32
Speaker
The problem, though, is that if I didn't want to work in video games, the number of things that did graphics were pretty limited. And I ended up at a company that did video surveillance software that was trying to do video analysis. And they were coming up with custom UIs to do video playback and show search results and stuff like that.
01:14:50
Speaker
And so they were a C sharp shop. They were doing actually a desktop application. And so I got deeper and deeper on like a low level Windows graphics routines and stuff like that. And after a number of years of that, I kind of looked up and realized I was going in a direction I didn't want to be going in.
Zach's Transition from C# to Clojure
01:15:07
Speaker
And so I started looking for a new language. And what I did was, for each new language, I tried to go and write a little OpenGL wrapper in it, which is a terrible way. Kids don't grow up to be me. This is a terrible criteria to go and choose a language on. But I tried Ruby. I tried OCaml.
01:15:33
Speaker
I tried, I actually played around with Erling a little bit, but they didn't have OpenGL binding, so I kind of, you know, tossed that aside. But then a director of engineering at the company I was at was Tom Fahlhaper, who did Closure Pretty Print and a few other things. And this was like, you know, way back around the time of 1.0, like maybe a little bit before.
01:15:54
Speaker
And he was very excited by Clojure because he was an old Common Lisp head and he was talking about it a bunch. And so I thought I'd give it a try. And according to my very rigorous metric of how quickly can I start getting 3D graphics on the screen, Clojure was far and away the best because I just had to go and take the existing Java bindings and just kind of poke at them.
01:16:17
Speaker
And so that was the first thing that I did with Closure was my first ever open source library was called Penumbra, which was an OpenGL wrapper for Closure, which as far as I know, I was the only ever active user of because it was not a very good API. It was extremely customized to what was sort of fun for me at the time, right? And tons of macros, all this other sort of stuff, because OpenGL is an extremely
01:16:45
Speaker
verbose API and there's a lot of sort of wasted stuff and like, oh, I can just like write a macro here and write a macro here. And pretty soon it's like, you know, something that only makes sense to me. I even had something that would take closure and translate it into like GLSL shader code.
01:17:00
Speaker
Yeah, and of course, it did basic type inference and other stuff, but it had a bunch of holes that only I knew what sort of code you could and couldn't write. And so it's on GitHub, and I just had kind of let it fall aside. And people were like, hey, should I use this? And I'm like, no, you really should not. But that was sort of what got me started.
01:17:23
Speaker
It's a slightly atypical use of Closure because it's an extremely imperative API that I was building on top of. It's an extremely imperative use case in general, but it allowed me to play around with this stuff. I was much more productive in Closure to do little toy graphical demos than I was in C++. I just went from there.
01:17:47
Speaker
So I ended up leaving that job and going to Google shortly thereafter. And Google, of course, did not have closure.
01:17:58
Speaker
But I was only there for a short period of time before a local startup that was doing Clojure asked me if I wanted to join. And I kind of hemmed and hawed for a few months, and then I left. And I was working full-time in Clojure and have been with very few exceptions ever since. So that's just been kind of my story. And I've been fortunate in that
01:18:21
Speaker
Oh, most of the companies I've worked for have been very happy to have me kind of do some open source work during my day job, which accounts for sort of the sheer number of libraries I've managed to crank out over the years. And yeah, I don't know that that's sort of that at a very high level.
01:18:40
Speaker
I remember that didn't you do a talk about the macros that you learned from the composition of the macros was a problem after. Yeah, I've actually done a couple of a couple of versions that so I gave a very in-depth example of like a graphics foreclosure and a talk called distilling Java libraries, which was a ways back.
01:19:02
Speaker
and then sort of reprise that material in one that was called Always Be Composing. That's one I've seen. Yeah, that's a favorite example of mine because I think that as long as you're just kind of talking about, oh, we're going to transform this data into the other data, unless you go and push that data somewhere, do something with it, all you're doing is kind of raising the ambient temperature of the room. And so I think that that's actually a really
01:19:29
Speaker
I mean, it's interesting, right? So like we were talking about Haskell and sort of strict type systems. And I think it's telling that Haskell is really good at writing compilers. And that's because that's a very, basically it doesn't have side effects per se, or like if it does, it's really much at the edges. It's just turning one shape of data into another shape of data. It's also an extremely well-defined problem because you get to say what the inputs and the outputs are. And if anyone wants to write something that doesn't fit it, you just go and kind of, you know,
01:19:56
Speaker
give them the finger and give them some sort of parser error. So that's a really good fit for the very prescriptive approach to that thing and also to the strengths of functional data or functional programming, which is data shape to another data shape.
01:20:18
Speaker
But I think that when you really want to start judging, is this a good approach overall, you have to talk about, well, now that we have our data, what do we do with it? And sometimes it's literally just sending it over a queue. Sometimes it's printing it out to the screen. But for the most part, in real production stuff, we're doing something non-trivial with it. And I think that you can't
01:20:39
Speaker
really safely ignore that. And that's also been a focus of a lot of the libraries that I've worked on. Certainly the most popular ones have been like Aleph and Manichold and other stuff, which are like very much about side effects, right? And how do you deal with that? And I think that that's an important question for, you know, anyone to go and look at. You can't just go and say, oh, we don't talk about that, right?
01:20:57
Speaker
Can I just interrupt you by quickly saying thank you for Aleph, by the way? I think so many people are using that and so many people we talk about, we talk about programming and Aleph is one of those things which I think, I don't know what the stars are on GitHub or whatever, but I know that in the Closure community that you're very treasured for that library because it is superb. Thank you very much.
01:21:24
Speaker
Well, I'm glad.
Hype vs Functionality in Aleph and Critique on Clojure's Spec
01:21:25
Speaker
I mean, I think that, like, again, it's one of those things where it came out just as, like, Node.js was coming into a sentence. And I think a lot of people are like, oh, adventure and stuff. I know I should like that. And so I sometimes question, how many people use Aleph because it's the best solution for the problem? How do them use it because it seems cool? And, like, you know, it's fine for me either way, I guess. But it's something where, you know, it was very
01:21:52
Speaker
Advent, it took advantage of sort of the hype cycle, and I think that that accounts for at least some of its popularity.
01:21:58
Speaker
Yeah, that's just you being modest, I think. OK, so we just have one before. I think we are almost one and a half hour, but we'd like to know your thoughts about spec as a conclusive question for this episode. Obviously, you need to come back again because we have a lot of material to cover. There's not enough time for us, but I know we'd like to conclude this episode with this question.
01:22:24
Speaker
I'm taking a wait and see approach. As I said, I think it's the first thing that has been added to the language in the last five years that seems like it might actually change how people use the language.
01:22:39
Speaker
the way that it's been sort of rolled out and a lot of the other sort of stuff around it is a little bit, I mean, it follows a familiar pattern, but it's still like very frustrating because, you know, the errors that you get out of spec are not good. Yep. And whenever this is brought up, someone from Cognitex will quite rightly point out, well, you can write a function that would go and roll it up and give you a better message.
01:23:04
Speaker
And they're not wrong, but to push such a crucial aspect of the UX of this new feature onto the community is baffling to me. I cannot understand why they would go and just leave that as a exercise for the reader.
01:23:25
Speaker
I say this baffling, but it's also very much in keeping with how they've talked about these things, which is you have these features which are powerful, but they're this core, and then they leave the remainder of the connective tissue to the outside world as something that people can choose, and that gives the freedom of choice.
01:23:45
Speaker
But I think that like that's sort of a false freedom in many respects. I think that like closure in general would be much stronger if Cogetect had a blessed set of libraries for solving certain problems because that would encourage people to go and collaborate on improving the tools themselves and the documentation around them and all that other sort of stuff. But like instead what you get is stuff like tools depths, which is like
01:24:11
Speaker
Well, we have two fairly popular build tools, but we're going to go and build another one, which is different and more minimal and tickles our aesthetic sensibilities better. I understand why they're doing it. I also understand that the fact that it's being done by Cognitec doesn't mean that it comes full formed out of Rich's head or something like that.
01:24:36
Speaker
I talked about this at the conge in an unsession because one of the things that I talked about in my talk was that I think that Closure has a broad but shallow pool of tools, like a broad but shallow ecosystem.
01:24:50
Speaker
And I think that that in some way comes out of the kind of people who like lisp languages, right? This is a curse of the lisp. And so like to some degree, we're just self selecting people who like can't help but go and build a like, you know, 12th iteration of a problem which is already solved because we like how our smells, right? Yeah.
01:25:12
Speaker
but it's also I think something that comes from the top in some respect in as much as no one is willing to kind of just come in and say like if you don't have a really good reason to do this differently just do it this way and those defaults matter they make they are something that absolutely would help the community grow because it would allow people who are coming in to
01:25:39
Speaker
Accomplish something right not just kind of go and sort of float in the you know void with all the little orbs around them wondering like what is it supposed to do with all of them like you know they actually would allow them to get somewhere and i think that the meantime to accomplishing something substantive in a language is an enormous predictor of whether or not people stick around.
01:26:01
Speaker
And I was fortunate in that my completely bizarre criteria for selecting a language did actually get me somewhere quickly. And so I actually sort of built on that initial success. And I would I think that we're not talking about outside of maybe the ClosureScript ecosystem where I think that there's a stronger story for some of this stuff, but I'm not a front-end developer. So this is sort of all secondhand. Like there's not a conversation of if we want people to feel
01:26:29
Speaker
Great. If they want to feel powerful using Clojure, what is the 10 starter projects that they can work on that will make them feel really awesome? What is the 15-minute blog? Which was a total lie in many ways, but it was a brilliant bit of marketing by DHH. The 15-minute blog was exactly what people wanted. They wanted to go and take something that seemed hard and complex and time-consuming and made them feel like they could basically be a superhero.
01:26:59
Speaker
Yeah. And so the question was originally about spec, but I think that spec. Yeah, of course. I mean, it's not just, I think you're touching.
01:27:11
Speaker
Based on spec how it relates to the other parts of the ecosystem. Also you're making a point which is kind of crazy really that the number one complaint from every single closure survey is error messages. This is from closure programmers that have taken the pill.
01:27:34
Speaker
you know, we're in there, we're doing it, we're already, you know, we're already converted. We still don't like the error messages. So, and it's the one thing which is, you know, it's a big stick to be closer with. You know, if you go, you know, we've got to meetups and stuff like that. It's so annoying when the sack traces come up or, you know, like you say, you get a spec error and it's just a mile of text.
01:28:03
Speaker
Yeah. And I mean, it's good scaffolding for better messages. They are correct that, oh, there's a function here. You can transform it, blah, blah, blah, blah. Well, just do that then. You know, it doesn't have to be perfect, but do something which is just nicer.
01:28:18
Speaker
Put a bit of effort into it. And I think that there's also something that I suspect here. So back when schema first came out, I was also working on something that was sort of similar in that vein because data shape validation was important, clearly. The first startup that I worked at, Runa, had enormous issues because it was just going and using printed closure data structures in a database and there was no validation or anything. It was a goddamn nightmare.
01:28:48
Speaker
And so there's clearly a need for this, but the thing that I got stuck on was how do you give good error messages?
Improving Clojure Usability Through Error Messages
01:28:56
Speaker
And one of the problems was if you go and just put some sort of bare predicate in there, which inevitably you have to, right? There's no way that you can go and you can avoid that. How does that roll back up and how does that actually get explained as anything other than here's a printed version of a closure function that failed for some reason, right?
01:29:16
Speaker
And I think that the conclusion I came to, though I never really quite figured out exactly what that would look like, is that you had to go, and when you specified a predicate, you also had to specify some sort of generator for an error message, like some sort of explanation of what this failing looks like, such that these sort of things are on lockstep, because just having the validation doesn't really give us enough information, unless you were actually able to pick apart the function and somehow infer what it was checking.
01:29:43
Speaker
like, you know, and there's some stuff you could do there. But I think that at the end of the day,
01:29:50
Speaker
you just need to go and force the person who's doing the validation to also explain it programmatically. And the problem with spec is that it doesn't do that, right? It has these really nice combinators for building validators. And those combinators are not like giving people the ability to go and describe in plain English or just in any sort of natural language, like what is it that you are trying to validate here?
01:30:18
Speaker
And since spec hasn't built that in, I suspect that the error messages will always be a little bit opaque unless you're sticking to the blessed set of validators that it can go and come up with some sort of explanation for.
Community Involvement and Technical Solutions
01:30:31
Speaker
And that's not great. And that's sort of why I buy that this can create better error messages. I buy that
01:30:43
Speaker
It's nice to have some sort of explanation where it's not just like the prologue, no, period, like, you know, at the end of the sort of thing, right? Like, yeah, so we can aspire to something better than that. But the
01:31:00
Speaker
The problem here is that I think that it's a clever technical solution to a fundamentally human problem. And I think that that describes a lot of what the Clojure core language has to offer. And in some cases, those technical solutions are valid, like kind of ways of dealing with the human problem, like immutability is a great example of that. But I don't think that that's a hammer that you can just kind of swing around and always fix the problem with.
01:31:30
Speaker
And, you know, one of the things I alluded to at the conge was that, you know, it's something where, you know, the community could step up here, right? Because it's clear that cognitive tech is waiting for the community to step up. And so, you know, if we want to have a blessed set of stuff, like maybe people just need to get together and do this. And I know that there is a closure together, I think, if I'm remembering this thing, which I think is an excellent step in that direction.
01:31:53
Speaker
And, you know, I've been sort of talking a big game about this because it's clear that it needs to happen. I also don't know that I want to be the one pushing it forward because I've kind of got enough of my plate. So I keep on kind of like talking about it and hoping that someone else will do it, which makes me really know better than Cognitech. But like, it's something which I
01:32:14
Speaker
I think that if we were to talk about what is holding closure back, and I think that it's clear that even if the community is growing, it's not growing at quite the same rate. It's no longer the prettiest language at the bar. People are not just going and picking up closure because Paul Graham told them to. That sort of moment has passed.
01:32:34
Speaker
And, you know, closure benefited a lot from being at the right place at the right time. And it's no longer there. Now it's actually being judged more on its merits than on its potential. And I think that
01:32:48
Speaker
people are still assuming that everyone who's coming to the language is willing to put up with a lot of crap, basically. And that's not true, or at least not as true as it has to be for the community to still grow in spite of this. And so I don't know what the solution looks like, but I do think that
01:33:10
Speaker
I know a lot of people who got very frustrated with the Cognitec because they were waiting for Cognitec to come down from the mountain with the solution on the stone tablets. And it's clear now that that's not going to happen, at least not in a near-term timeframe. And so it falls to the community. If we want this to happen, we have to do it. And that's fine.
01:33:34
Speaker
And I think that that's a reasonable thing. I think it's frustrating that Cognitech has certainly intimated this, but never said it out loud. And I would like to, I think,
01:33:52
Speaker
you know, see more community stewardship, like people actually just going and saying like the time for waiting is over, like we have to just go and kind of do this. And you know, frankly, whoever is willing to come up to the table and just say this is what the community should use, like, that's fine, right? Like, I think that the one real example of this in the community has been Ring.
01:34:21
Speaker
No one questions that right there's there's no official kind of.
01:34:29
Speaker
support of that is just what the community has done. And the fact that that is the one standard example should be seen as a problem, right? There should be a lot more of that in a much wider variety of cases as opposed to 13 different solutions to what is fundamentally an unimportant problem.
01:34:45
Speaker
But it is changing now, right? I mean, I think it is, as you said, I mean, Clojure is not the most beautiful language that you're going to jump into and then think that potentially it's going to be an amazing language. So now things have changed. I think hopefully more and more people will get into this and then see the wars and try to fix them as quickly as possible. I hope so. And I think that if there is a clear
01:35:10
Speaker
a place that will go and welcome them and tell them what they can work on and not go and close all the GitHub pull requests by saying, please sign the CA. We don't take documentation changes. Please fill out a JIRA ticket. Something which actually goes and says, we value your work. We are not going to go and set up a bunch of hurdles for you to go through is
01:35:33
Speaker
is going to be good because there's a reason that closure moves slowly because a lot of the stuff in closure is load-bearing and you don't want to change it quickly or without a lot of careful thought.
Closing Thoughts on Clojure's Appeal and Community Engagement
01:35:45
Speaker
But there's a lot of other aspects of the ecosystem that don't share that property and we should have a different process and I think it has to be a community-driven one to go and adopt changes. I don't know. We've talked forever, so we should probably just talk about all this.
01:35:59
Speaker
But this comes up in practically every episode. A slightly more optimistic note though is, I take your point about the popularity, but although for me, I look at closure and I still think from an expressive point of view, it is still quite a beautiful language and I don't see a better language out there actually. I look around and I look at Elm and I look at Rust and
01:36:24
Speaker
I don't know. It seems like, you know, even maybe the elixir is something which people are maybe looking at, but I still still doesn't seem quite as beautiful as the lisps to me. So, I mean, yeah, I, I agree. I mean, I wouldn't be here. I wouldn't be running a book. Like, I mean, you know, I'm being negative. Like, I'm, I'm, you know, mad because I care. Right. Yeah. Right. Exactly. Yeah. And I, I,
01:36:50
Speaker
came into closure very early, and it did not seem clear to me what was going to be the kind of ceiling here. There is a ceiling. The parentheses mean that there is a ceiling to the adoption that we're going to see. I think that that's just something that is a given, but I think that it doesn't have to be where it is right now, and it doesn't have to be where it is at this current trajectory of growth. And so the people who are here and who are passionate are
01:37:16
Speaker
you know, they have to be sort of the ones that pushes forward, right? Sort of make it succeed in spite of itself. And I think that that's what it is. And so yeah, I certainly don't mean to go and say like, you know, once I'm done with the book, like I'm out. But at the same time, it's, it's something where, you know, this has been the one language that I've really, you know, fell in love with and have been with since, you know, it was quite young.
01:37:39
Speaker
and have sort of seen how the community has changed and how the expectations of the community have changed and everything like this. And I think that all I'm saying is that
01:37:50
Speaker
There's room for improvement and for clear lines of communications and clear articulations of who expects what from whom. And I think that that's just something which I feel very viscerally that this is sort of something that needs to kind of get resolved. And I'm happy to see that there is progress in this direction, but we could do with 10 times more. Yeah. So on that bombshell, things can only get better bombshell.
01:38:19
Speaker
Exactly. We will try to conclude the episode. Obviously, thanks a lot Zach for your time and showing up on the podcast and being our first guest for the live streaming. There are at least 21 people watching this and thank you for watching the video. I'm not sure how this is exactly going right now because I'm not watching the video myself.
01:38:39
Speaker
But please give us your feedback. And a couple of things that we want to cover is that there is a Dutch closure day that we are organizing in March 21st, April 21st, sorry. So the call for proposals is open. So please go and check it out. And if you want to talk about anything, go ahead. And we have amazing sponsors all the way from Switzerland and Finland and everywhere. We've been tweeting about it a lot. And we'll be there. And I think Ray will be there as well.
01:39:09
Speaker
We'll also show up at Closure D in Berlin to annoy you guys there with our jokes and our other random stuff. Something about Onyx, we'll see. That's it from us for this week, I think, and our first ever episode on live thing. If this works out, I think we'll try to do this more. Zach, we would love to have you back again because we have so many other topics to cover.
01:39:33
Speaker
Sure, yeah. I mean, let's just say, once I have some sort of little demo to show here, I'm happy to talk more about that and kind of all that stuff. And of course, once the book is actually done and once the draft has been out there and people have been able to read it, I'd love to hear your thoughts. I'd love to, if there's any sort of set of reader questions, I can go and just kind of talk at length about all this stuff. So in any case, yeah. Thanks for having me on here. And have a great day, you guys.
01:39:58
Speaker
Fantastic. Before we go, I'd just quickly say thanks to Pizzeri, who does the music, and to Lubov, who does the graphic design for us. I think she's actually doing some awesome stuff for other people in the Closure community now as well, which is good to see. Yeah, so thanks to all you guys. Thanks all sort of Wouter for doing the sound and hopefully he'll
01:40:26
Speaker
be able to clean up the mess that we've made on the YouTubes today. Thanks also to the good folks sponsoring us via Patreon. We're now in Double Figures and it's really a great and humbling feeling to know that some of you are able to contribute so that we can keep our personal costs down and also it keeps us motivated to keep taking deaf and forward.
01:40:53
Speaker
We really love the idea that the community is coming together for closure. So just to finish off thanking you again, Zach. I really appreciate the time that you've spared for us. Honestly, it's been a very interesting decision, very open.
01:41:10
Speaker
As we expected, a very straight face, straight eyed, very open, very clear. So thank you very much for that. And again, thank you very much for all of the contributions and the software and the books that you've put out there and the talk. So you're a pillar of the community. I really appreciate it. Thanks very much.
01:41:31
Speaker
Cool. Well, yeah, like I said, I mean, I'm happy to be here and I'm certainly happy to see the stuff used because the only way I've ever been able to learn is to put stuff out in front of people and, you know, out of sheer terror that I'm going to look like a ignorant jerk, like work really hard to kind of, you know, make it make sense. So, you know, this is this is a little bit more off the cuff than I'm used to, but it was a lot of fun. So thank you. Awesome. Thank you.
01:42:30
Speaker
It's actually gone.