Clojure, ClojureScript, and Living Clojure

Welcome back everyone, this is the Change Log and I'm your host, Adam Stikoviak. This is episode 1, 71, and on today's show we're going by Karen Meyer, the author of Living Closure. She's also known as Gigasquid on Twitter, GitHub, and pretty much everyone else on the web. She's speaking soon if you're going to be at Strange Loop, talking about chemical computing at very interesting conversations we have on the show today.

She's also the author of Babar, a little language for machines with speech acts. We have three awesome sponsors for the show today, co-chip, images, and digital ocean. Our first sponsor for the show today is co-chip launching a brand new feature called Organizations. You've heard me mention it before, now you can create teams, set permissions for your teams, and improve collaboration in your delivery workflows, maintain centralized control over your organization's projects, as well as your teams with this brand new feature.

And we want you to save 20% that's huge off any premium plan for three months by using this code, the Change Log podcast. Again, that code is the Change Log podcast, head to co-chip.com slash the Change Log to get started and now onto the show. All right, everybody, we're back today. We got Karen Meyer.

Jeremy, set up this call through Twitter. How crazy, right? It's crazy world out there. Crazy world.

So what was going on to invite Karen onto the show? Probably just my interest enclosure and I came across, Karen, I guess I came across her on the top spot podcast over the summer at some point. I shut off to them. And then somebody retweeted her or something like that.

And I said, oh, that face is familiar. And then I checked her bio. I was like, oh, she should come on talk to us about closure. And that was kind of the genesis of it.

Well, I'm happy to be here. Very gracious of you to respond so quickly and be so willing to come on. We appreciate it. Yeah, absolutely.

So Karen, I guess there's an easy way to start will be, I think your bio says a bit about you being starting in ballet and then physics and then ultimately in software development. But when someone asks you kind of who you are, what's your response? Yeah, well, I usually just say I'm a closure developer because that's what I do every day and I quite enjoy it. And yeah, I guess that pretty much sums it up.

I got to it from a very windy path, like many people. So I started, I was a professional ballet dancer for a couple years right out of high school. And that was really cool. And I really enjoyed it, except for the starving artist bit, which got a little bit old, like sleeping on floors with mattresses and talkerches and things like that.

So I decided maybe going to college would be a good idea. Very pragmatic choice. Exactly. So when I was in high school, I really, I liked physics and math.

And in particular, I had a really nice role model for my physics instructor. She was an awesome woman. And so I was super impressed with her. And there was one moment that I always remember in physics that kind of always went back to, I don't know if you did this sort of experiment in school, where you kind of line up ramps that marbles can run on, and then you kind of measure everything all out, and you predict where the marble will land in a cup.

And I did all the math and everything, and released the marble, and it landed perfectly in the cup. I was like, wow, this math, physics stuff is awesome. I had a similar experience recently at the Science Center, where they had this ramp where you can roll balls down it, and if you put it at certain intervals with basic multiplication, you could determine what what keel it hit, which would make a certain tone. And each key down the line got bigger.

And it was like two, four, six, eight, and you did this square root of things. And that would determine where you would put it at on the ramp. And that, I mean, similar, that kind of in my mind. Yeah.

Yeah. I never had such a great experience. Maybe that's why I didn't like physics, because I didn't have this awesome moment in life. Well, it's amazing that you can do the math and be like, well, put this here, and you're going to hit that key there.

And, you know, it's amazing. There's a great video of a college professor. I think it's a physics professor who, I think he sets up like a bowling ball on the end of a chain or something. I might have the objects incorrect, but he does all the math like he just described Karen.

And he actually swings it from a location at his own face. And like, he's going to die or be like seriously injured if the math is wrong, and it's great learning moment, you know, for the class. And that's a, I saw that on the internet, but yeah, I never had such a great moment in physics. So that told you that you love math, basically.

Yeah. So that kind of is a catalyst of where I wanted to stay. So I went back to college, I studied physics and really liked it. And then I kind of fell into computer science after that.

But I have to ask you if you ever, I don't know if I'm completely weird, but like whenever I am taking off in planes, you know, like right at that moment, where you just the planes going really fast and you just start taking off, I always say to myself, yay, math. I do because it's so incredible. I'm like, yay, math. Well, yeah, because they got to get to a certain speed by a certain distance to actually lift off.

And some somebody did the math right. Hopefully. Yeah. Sometimes it doesn't work.

That's cool. So do you really like, do you kind of whisper a little bit or is it just kind of like an inner voice? I'd say it like an inner voice because otherwise people start thinking that. I'll say it to the person sitting next.

Well, that's a good conversation sort of a gay math. And then you kind of go into who you want to what you do. Yeah, I guess I could be. Oh, have you read this book, The Martian?

I'm like halfway through it right now. Have you heard about this? So they're making it into a movie with Matt Damon? Yeah.

Yeah. And like September, October. And it's fabulous. I mean, if you like, like space stuff, math stuff, engineer, it's just fabulous.

So it's a retelling basically of Robinson Crusoe on Mars. Like this engineer, he gets straight, or the question on, he gets stranded there. And strange circumstances of events, you know, this group thinks he's dead. He's really not.

So he has to use all his engineering skills and everything else to like survive on Mars. And it's a total math and geek best in its fabulous. So is it really, he's really Mars then? Yeah, he's really Mars.

Wow. Yeah. So I totally think I'm right. I'm sorry.

So it's not a true story. That's not what you're saying, dude. It's just I had to point that out. Right.

I just needed to bring us back to reality there. Yeah. Well, that's why I clarified it. See, really on Mars.

Right. But I like it. I mean, Scott movie too. See, see, we just talked about really Scott two shows ago with Prometheus.

And I think he's fallen from grace a little bit with me, although Adam liked Prometheus a lot. I like the name Prometheus. What about you, Karen? Do you like Prometheus?

I did not see that. So let's have to put that on my list. Yeah, putting your list. It's definitely one of the two home theater.

If you have home theater, don't just watch it on anything. Just home theater it if you can. Anyways, well, cool. So we got to learn a bit about ballet into physics and some of the appreciation you have for math and whatnot.

So at what point did you start getting into software development and what was that like for you? Yeah. So I got into software development doing physics. I started programming in Mathematica doing computer simulations of some simulated annealing.

And that was super interesting. So after I graduated, there was a lot of opportunities for software developers and they were looking for people in just general science fields. So I just kind of fell into it that way. And I discovered I really liked especially the feedback of programming.

I mean, if you think of a lot of the science experiments, you don't have the fast feedback a lot of times. But in software development, you definitely do. And it's a bit artistic too, which I really like. So yeah, I did job programming, Ruby programming, and then I met Closure.

And I just kind of fell in love with Closure. And I've been lucky enough to work in it every day for the past almost two years. So I'm extremely happy. I still like it.

Well, we definitely want to ask you about Closure. That's kind of the thrust that is called before that. I also want to ask you about your internet handle because it's quite a squid. It's like one of these things that you would see it and you never forget it.

But can you tell us the genesis of that? Okay, so this is like way back in the day. I don't know if you remember this when there was a thing called AOL chat. So I was working at a company and during lunch, we would all like play Half-Life together.

And so my Half-Life avatar was, player name was Squid. So we signed up for like AOL into Messenger. And I put in Squid as my name. And like it was taken.

So then I put in Make Squid with also taken. So then finally, Gig Squid was not taken. And that's who I was. Gig Squid was born.

Well, that's much better alternatives. Usually people just throw like the year they're born at the end. And it's like, that's always kind of dorky. So I think you did a good job with the prefixes.

Thank you. And you've held that handle for a while then too. Because I mean, well, it was for every go. Yeah.

Yeah. 20 years maybe. I haven't actually been on there for a really long time. It was born.

It was born there. Awesome. Well, let's get back on the closure here a little bit. You fell in love.

You've been working with it for two years. It sounds like what was it about the language in your experience that turned you on so much? Yeah, I guess I've been asked before. And I never got a chance to study LISP in college.

So I don't know whether it was kind of LISP that I fell in love with or closure. But I mean, closure gives you access to JDM and job interop and concurrency and all that. So I mean, it's pretty sweet. But the simplicity of the language really, really it feels to me.

So I guess maybe I put the cart before the horse a little bit. Maybe back up a split second and give the summary of closure. We've already known it's programming language and like you said, it's kind of a LISP. Can you just kind of give that overall summary?

Sure, sure. So yeah, closure is a LISP. So that means it has all these parens and the parens sometimes scare people away. But it really, you've just got to like not panic about the parens.

They kind of go away if you work in it a while, especially with an editor that does matching and automatically inserts it for you. They just, you know, it's fine. So it's a LISP on the JVM. That's the main language.

It's a dynamic language. It's got job interop. And it has immutable data structures that is really nice for concurrency. And also with an area that's really hot in Closure script, which Closure script is a dialect of Closure, but it compiles on a JavaScript and JavaScript as you know, just goes about anywhere nowadays.

So there's some really exciting advances in that. I mean, it's hard to get up with a more stuff happening every day. Yeah. So I mean, just to generalize a little bit and feel free to correct these generalizations, but you know, you kind of have this divide in programming languages between object-oriented and functional.

The LISP language, the LISP kind of tree of languages have always been, maybe not maybe always as a bad word, but have kind of had the reputation of being more academic, niche. There's always people that love LISPs and will always hop into online conversations and tell you how much easier it would be to do in LISP. But overall object-oriented has been kind of the dominant paradigm in the last 20 years in programming. And yet Closure seems to be like super popular.

So speak to that, maybe. Yeah. So I think that's a combination of things. And I think that's because Closure has a really practical side as well.

You know, it's really concerned about getting the job done and being able to interrupt is an important part of that. And being able to run the JVM is like huge, right? And also, there's just really a lot of energy, a lot of innovation in the community, and it's a really kind community, just a lot of great people. So I think that really has helped its success.

And also, you know, Richikki is pretty brilliant. So having him guide our language is really great. It was an Amazon project that upgraded from, you know, one version Closure to the other. And all I had to do was change a version number.

There was totally stable. Everything was compatible. And that's, that's really unusual. They're really focused on stability and making sure that there's backwards compatibility and the language is moving in the right direction.

Speaking of Richikki, I think Adam, you have to do a little bit of a shout out to him. Yeah, so Adam Walters was is a Closure guy who contributed to the changelog back in like 2013. And he wrote one post for us. And it wasn't even a guest post.

It was like, he was going to come on to be, you know, kind of more a regular writer and you know, life happens and whatnot. But he wrote a post called Richikki's Greatest Hits back in looking at September 16, 2013, which is really just a list of like five or six awesome, Richikki talks. And that one post was probably the most popular post of the year for us. I would almost say all time.

I would almost say like, I'm guessing here, but I see so many shares. It's always on Twitter, like it gets to be circulated. And people find us because of this years later, even I would probably say it's probably the top all time post of the changelog. Devin's a great guy, actually.

I worked with him about, yeah, a little bit ago, too. So he's a great guy. Yeah, we're after that post, we're like, you know, write some more stuff over. Yeah, you should be a smart guy.

Yeah, we'll link that one up in the show notes, kind of become a classic. And yeah, Richikki gives great talks, great presenter, obviously a very smart man and seems like he kind of invented Closure almost in a vacuum. Do you know any of the history of the creation language? I don't know his personal, like how he came to it all.

I know that he did work on it just solo for quite a bit before it was presented to, I think, a mailing list. And then everybody was like, wow, this is really cool. You know, can I help, you know, make it better? So then he had a few people just really help put a shine on it and bring it to the first version, real version.

So very cool. Well, let's get back to the language a little bit. And one thing that you mentioned was that you said it runs on JVM and that's huge. I think why is that such a big deal?

Just because the JVM is so production hardened and it's so efficient in what it does now after years and years that it's just great to be able to run on that sort of platform. And you can see that with the explosion of languages that are running within that ecosystem right now, like Scala and, you know, JRuby and Groovy and all the other ones. Right. Yeah, and I think that because there are so many Java developers, so many people that are familiar with the JVM, not only is it like production ready and hardened and has all these years of mind put in or thought put into it.

It's just also kind of a comfortable, you know, kind of a relaxing but just a nonconfrontational, what's the word I'm looking for here, Adam? It's just an environmental use to where if they're going to be switching, you know, the way they think about programming from an object oriented mindset to a functional mindset, which closure asks you to do if you're coming from the other side, it's nice to have at least something that's familiar. I think you're thinking expectations of the expectations of working on the JVM or as such and because of that, you can operate in more of a comfortable common manner than maybe chaotic that you see in the craziness that is open source these days, which is the next newest hottest thing, disrupting the newest hottest thing from yesterday. Yeah, right.

Don't you have access to all of the libraries? You do. Yeah, there's there's full job, I don't know, that's the most part wrap or free. So it's it's very comfortable to work with other Java classes and libraries.

So yeah, I mean, if you're looking for kind of a low risk, kind of try it out, you can either carve off a little section and just add a jar and try there or even in your tests, you know, you can just write some tests and closure and see how it goes. So there's lots of ways to introduce it to your team and get used to it when you can just say, oh, well, this is Anna's jar. Yeah, and it sounds like a nice way to bring up a adoption as well as allowing people to turn the water as opposed to, you know, completely jumping off or into the pool, so to speak. Right, right.

Awesome. Well, I think we do want to ask about popular use cases, like when closure makes sense, when it doesn't make sense, like what's being used for the types of software that you can build with closure. We do need to take a sponsor break, so we'll take a minute here from one of our awesome sponsors and we get back, we'll talk about what are the best times to actually use closure when we're back. ImageX is a real-time image processing proxy in CDN and let me tell you, this is way more than image magic running on EC2, this is way better.

It's everything your friend and developers have dreamt of, output to PNG, JPEG, GIF, JPEG 2000, and several other formats. And if you're like me, you've ever argued with your boss or a teammate about serving read the images to non-read devices, you'll appreciate their open source, the pinnasy-free JavaScript library that allows you to easily use the imageX API to make your image responsive to a device. Now all of this takes a platform and the imageX platform is built on three core values, flexibility and quality, performance, and affordability. When it comes to flexibility and quality, ImageX has over 90 URL parameters that you can mix and match to provide an unlimited amount of transformation that you need for your images.

And they take quality very seriously. And because of their commitment to quality, several top 1000 websites in the world, trust them to serve their images. Now when it comes to performance, ImageX operates out of data centers filled with top aligned Mac pros and Mac minis, and they're set up for a completely streaming solution. This means your images never hit the disc.

Images are served by the best SSD-based CDN for delivery around the world anywhere extremely fast. And while we're talking about speed, almost all the image processing happens on GPUs. This means transformations are super fast when compared to competing virtualized environments. And lastly, it's all about affordability.

Everyone wants to save a buck. That's how the world works. Because ImageX processes close to a billion with a B images per day, they're able to make certain optimizations at scale and pass those savings on to you. To learn more about ImageX and what they're all about, head to imgix.com.

Once again, imgix.com and tell them Adam from the Change Vlogs sent you. All right, we're back talking about closure with Karen Meyer. And we're interested in closure for a few reasons. First of all, I'm an object oriented person, at least I have been.

I'm very interested in functional. I tend to write more and more of these days, functional style inside of my object orientation, probably a lot thanks to Gary Bernhardt and some of his influence on me. But also because it seems like it's very useful in production applications. And so I'm curious like what are some awesome use cases for closure?

How's it being used out there in the wild? And maybe on the flip side of that, when is it not a great idea to reach for language? Sure. Well, I mean, closure is a general purpose language.

So it's good for lots of things. Where it really shines is when you have to deal with concurrency. Because you have a very composable, simple language, functional, and you have mutable data structures. And that really just lets you handle concurrency very nicely.

So as a result, you can see a lot of big companies banks and financial retailers. It had a lot of adoption lately. If you go to Walmart, and you get a receipt from Walmart, your receipts are all going through a closure program. What?

And that's crazy. Yeah. So it's out there and people are using it in lots of places. Big companies, startups, just everywhere.

It's in the places you're going to expect it then. Well, it's a general purpose. So you can just really use it anywhere. I just love the idea of this invisible infrastructure that so many people don't have to care about.

And even though we have so many problems with software and security and, you know, there's tons of leaky abstractions out there, there's a lot of stuff that's power in businesses and communities around the world. And most people don't even have to have any clue that there were seats from Walmart coming through closure. Yeah, exactly. That's pretty cool.

Yeah, the kind of nice thing too is now with closure script, you can have closure on the front end and on the back end too. So you just really have a single language that you're working with, which is kind of nice for me, you know, I'm developing. I don't have to go and switch to JavaScript or, you know, copy script or anything for the front end. I can stay within the same ecosystem.

So closure is good. Does that work pretty much just like any other transpiler would work? Yeah, it uses the Google's, and this is the unfortunate thing, uses Google's closure compiler, but it's like CL than SU, but it's, you know, closure and closure, which is unfortunate. Namely.

Namely is cool. Yeah, but yeah, I think it's good for just about anything where you wouldn't want to use it. I could only think maybe embedded, you know, we have really a small footprint because, you know, the JVN is pretty large, although that's changing out, you know, with, with closure script and JavaScript. So if you can get small enough to put JavaScript on there, you can probably get small enough to put closure script on there as well.

What about the receipt application that you could think of as an outsider? Why do you think they chose closure over, say, another way to do receding for Walmart? Is it because Walmart is a closure company or is it because that was, you know, one of the main languages or is there a reason why that was the best fit for it? I can't talk to their reasons for their reasons.

I think in that scenario, like that kind of scenario, why does closure really fit that kind of scenario? Yeah, well, I mean, it's a JVM, right? So you're running a lot on the JVM and then, again, current currency that you're doing things effectively. And then it's less code, right?

I mean, with closure, it's really concise. So you have less code to maintain and you can compose things and break them up very nicely. So it's just a nice place to be, I think. How about readability?

Aside from the parentheses, let's just zoom over the parentheses, which I think I probably can get over that. But at the same time, maybe just because it's foreign, but you know, the order of the arguments is flipped, I believe, isn't it pretty strange to read at least at first? Well, maybe at first, but I think once you get used to it, then it's like really a really simple syntax, right? I mean, what comes first?

It's always, you know, the function or the operator and then all the other stuff is afterwards. So it's very beautiful and it's like, this is a thing that comes first all the time. I don't really think about it. So yeah, I think that actually improves its readability.

It reminds me of Adam and we're at Space script. Do you remember that talk? I do. Yeah.

Yeah, pretty interesting. And we were sitting way in the back. So we couldn't see the slides very well. But it was cool because he showed how like after they had kind of built this foundation of these functions and closure script, a lot of the features that they needed kind of fell out of the fact that the language is designed in such a way that adding additional features later on was very easy and it was got certain things for free.

Yeah. And he was showing different code blocks and he showed the changes from one slide to the next to add the next feature. And you know, the feature would be like when the rogue is complete, like wipe out the block of the row. And I was so far back that I could only really see the shape of it.

I couldn't read any of the code. But it had this very, I don't know, like an attractive shape. You know, sometimes you can just look at a program from far away, kind of a squint test. Yeah.

And you can tell if it's like poorly factored or not. Exactly. And this, even though I couldn't, I couldn't understand it from from Latin or from Hebrew, it looked really nice. And I wonder if that's appealing to you or if it was just because I was so far away.

No, I'm sure that's a part of it. I mean, it's just, you know, you get the joy factor of working in language too that you find pleasing. And oh, we haven't talked about the raffle yet. The raffle is like a huge part of it.

So the raffle stands for a redevelop, apparently, but it really allows you to just interactively, I like to think about it. It's like sculpting your code. Like you can just get in there and get your data structures and just manipulate it in and get like super fast feedback. And you can even poke at running code and explore that way too.

So the raffle is an incredibly powerful feature that just kind of really aids your development, I think speeds up. So yeah, that's a really important part of it too. Very cool. One thing I was going to ask is when you mentioned kind of sculpting your data in the raffle, one thing about functional programming and some of this could be my lack of understanding.

So feel free to like educate as well here. I will not be embarrassed if you educate me here. It's like, you're just kind of passing around this bag of data through these functions and I'm down with transformation and like changing and all that. But it seems like it seems like you could benefit from structure around that data, you know, from some object orientation.

Do you miss that ever inside of closure or is it just kind of like once you get used to it, you're just used to passing bags of data and it's even that even correctly you do that kind of just pass what I consider a hash Yeah, I mean, it's all based on those data structures like math, data structure and like a vector data structure. Those are core. You do organize your functions and you organize them usually by namespaces. So you can almost think about the way that you maybe organize objects, you'd use kind of namespaces for to you keep groups of related functions in a separate file or namespace and then include them in whatever you're working on.

So yeah, you can definitely organize your code. So it's not just you know, just playing functions everywhere. Okay, you mentioned the community. You said it's kind of has a great community.

Can you dive into that at all and give us some more detail? Yeah, it has a very vibrant community. In fact, there is a Slack channel now that just started up, it used to be IRC, but somebody opened up a Slack channel, I think it's called closureion.slack.com. But I think it's got almost pretty much 2000 people from like around the world.

Yeah, and it's fabulous. You know, there's all sorts of different channels for different people's interests, you know, if they're in, you know, England or Russia or wherever, sometimes by a geography, sometimes by interest, they've entered a clear script or atomic. But you know, it just brings everybody together and talking and sharing hints. There's all sorts of interesting libraries that are being created every day.

Let me see, there was a there's one that just came out the other day that was really cool. Somebody put out a couple of screencasts called Porens of the Dead. So it was creating a closure script game. He'd only done a couple screencasts yet, but I watched them, they're fabulous.

So he kind of codes it all as you're watching through Emacs and the raffle and closure script and everything. So I think it was the first video is probably about 15 minutes and the second one was 12. And he pretty much had like this working closure script game. It was awesome.

We got to find out when I added them with that thing up. Yeah, friends with friends with the dead. What do you know about the media communities and conferences out there for closure? Oh, there's a lot of good ones.

So closure conge is coming up in November. So that was actually the first closure conference. And after that, there have been all sorts of other ones that have sworn up. There's closure West for the West Coast and now there's your closure for people in Europe.

And I think there's some other ones I'm forgetting their names, but some more and more are coming up with popularity. And so that's great. There's local community groups everywhere. I help run one in our local city, Cincinnati, Ohio.

I help run the Cincinnati functional programmers group. That's great for people too. Oh, and there's one coming up too. Strange Loop.

That's not just closure, but it's a lot of different languages. But closure has a strong contingent there as well. That is fabulous conference. I guess while we're on the note of Strange Loop, might as well mention your awesome talk chemical computing.

Yeah, yeah. So that's one I am going to be talking about when coming to Strange Loop. So yeah, chemical computing kind of a strange thing. So I'm actually really excited that the talk had accepted because it's it's the idea that came from papers that I got in a book that was entitled unconventional programming paradigms.

So right off that really appealed to me. That would scare me. So we're different people. I'm like, oh, scary, by the way.

Yeah, so I really like to be able to step back and kind of approach problems that we take every day and just think about it in a completely different way. I find that really interesting. So what chemical programming is is it's not actually programming with real chemicals, which I mean, that would be super cool too. That's not what it's about.

It's about abstract. So you're using the kind of the metaphor of a chemical reaction to do your programming with. So it would be, you kind of think, so if you can take the example of like calculating a max, like, you know, max of some numbers, right? You can think of, we'll say two numbers, like five and three, you can think of as molecules.

And when these molecules react, they react according to a certain rule. And the to find the max, the rule is if you have a five and a three, two molecules, you're going to return two new molecules that are the same number as the biggest molecule you had in. So a five and three would react and return a five and a five. And basically you just do this with a big, you can just imagine like a big list of molecule numbers from one to 100.

And then you mix them all up and you divide them into pairs. And then each of those pairs reacts with one another. So it becomes two more numbers. And then you mix them up again.

Until you just have one number. And then you do the same thing. Right. And then as they react with one another, you will eventually, and this is the tricky part because you don't really know when you will eventually get them all to be the same number, which is the maximum.

So you can take a quote measurement, which would be take a look at all these number molecules and say, do a distinct on it. And you should have, you know, the number 99 or, you know, 100, wherever you ended up, calculate the maximum, and you have your result. But yeah, that's a tricky bit, trying to figure out where to end. But the kind of awesome thing about that I found kind of experimenting with it and doing things that way, is that this model really allows you to just turn concurrency up to the max.

Because there's no sequences and there's no sequentiality. And if you think about it, like we, as programmers, we iterate over loops and do so much stuff in sequences, like all the time, if you would just think about how you normally calculate max, that you just realize, wow, there's other ways to do it. I don't really even need to have do stuff in order like that. So it's kind of interesting way to think about it.

And that's kind of what nature does, right? Nature doesn't line everything up and put it in a loop and process it all. Well, maybe if you think about time, you have 24 hour loop and just kind of keep it every day. It's a rainy day.

I like that. It seems like a whole different way of thinking about things. And is the purpose of these types of exercises is to just basically kind of get us out of our rut of thinking about solving problems in the same way. So I'm trying to do with this talk.

And also just spreading the knowledge round of another way of thinking. I think when you have cross fertilization of two different fields, like computer science and biology or nature inspired solutions, that's an area where you have a lot of new ideas and research and innovation. And all the papers that I got all this information from right now, all the ideas are just in research right now. So there's nothing in the wild that has been used, but there could be, right?

So this is kind of putting the knowledge out there and the seeds in people's minds and what might inspire them like to think about this in a different way. Maybe they'll help them solve some sort of concurrency problem that they're having. Who knows? What it might spark.

So that's an exciting part to me. Sounds like there's a little bit of a pattern here because not only do you have this upcoming chemical computing talk, which by the way, you have a nice rundown on your website. We'll link that one up in the show notes to those who can't make it to start your loop this year. But you also have a programming language of your own.

You also say that you're into AI and you're into robots. You have this thing called a bar. I don't know if that's how you say it, but that's how I always said it in my head. I had to say it either.

I don't know. It's the elephant. It's a big bar. It's a big bar.

I don't know. Well, see, there was a there was a cartoon called a bat bar. Yeah. And I was I was gonna say a bat bar, but I could be wrong.

Remember the elephant cartoon? I don't remember how they pronounce it. That's what it's named after. I'm almost unsure about the pronunciation.

Well, it's your language. So you can pick the how to pronounce it. I will go with that bar. I'm almost started his bad bar.

I'm almost certain. Okay, I was a fan of the show. So I like that show too. Tell us about your language.

Yeah, so I kind of have this habit that I'd like to try to dig into papers and kind of understand them. And one of the papers that I was looking at was by John McCarthy and was entitled elephant 2000. And this was had a lot of his they weren't entirely fleshed out by his ideas of what a programming language of the future should be. And I think it was entitled for the year 2000, right?

Okay. So he had some very interesting ideas in here. And one that really aspect that really appealed to me was the idea. And we talk about cross visualization that from philosophy of humans all speak in the language, right?

And if you look at the things that we do with our language, you can abstract that to kind of hire a higher level. Like what? What do we try to communicate with each other with our speech? For example, if you say pass the salt in English, and then you say pass the salt in Japanese, you know, you're meaning the same thing, even though you're speaking different languages, you're meaning you are want to, you want to request someone to do an action for you.

So that kind of boils it down to a different level. And he thought that philosophers, you got this from philosophers that this would be the same sort of principles would hold true if you wanted to communicate with somebody from Mars, right? You would still need to have requests, you would still need to have assertions asserting something, like a fact. You would still have to have something like queries, you know, asking a question.

And those are, and not only that is the way that we would communicate with machines, right? Machines would have to, and computers would have to communicate with us on this level. And we can see the ones that I mentioned are pretty easy, right? We tell computers facts, you know, basically x is seven.

And we do queries, you know, what is the value of x? We do requests quite a bit at a lot of times. But some things that he mentioned in the speech acts, were aspects that our computers don't regularly have. And these are, you could have beliefs, and you could have, you could try to convince someone of something that might change your belief.

So it might affect your future actions. So that was kind of an interesting one to explore with what a computer might make of that. Another is when you, when somebody asks you to pass the assault, and you agree, you have made a kind of obligation to fulfill that request by kind of accepting it. So there's all sorts of these interesting kind of philosophical, higher level, how do we interact with each other?

And how would that drive interacting with computer? So that was kind of a roundabout exploration. So I created this language to kind of explore some of this. So I made the language through Closure, I used Instaparts, which is a great parsing language.

I made my own language to give, be able to have beliefs and speech acts in my realm or in my computer program. And then I used this to control like my AR drum. So yeah, so you know, the whole, you could maybe get a goals and beliefs and communicate it with each action. This is kind of interesting.

So that was kind of fun. I had one point where, you know, it would, it would fly up until it believed that it was high enough. And that was, you know, three meters or however it was. And it was kind of fun debugging that.

So I say and stop when your three meters high, say you believe the three meters is high enough. Yeah, I have, I have a belief. So when it flew off and I got stuck on the ceiling, I'm like, oh, you have a faulty belief, right? I believe there's a ceiling there.

Yeah. So it's kind of a different way of thinking about and debugging programs, a different way of interacting with them. Very cool. The syntax is pretty interesting too.

When you read through some of your examples on the read me, just the way that you restructure, you're almost counter to what you said earlier about Closure, like it's kind of hard to read. But in this case the way that you're asking the program, it's sort of like similar to English, you know, it's very English-like. Yeah, it was like there's an on purpose. So I used the Closure program to create a new language that had no prints.

It also is kind of funny because when you start to use things like convincing and requesting, you're kind of humanizing it to the machine at this point, right? Because you're trying to convince it to power off, you know? Exactly. So I start to have some kind of thoughts.

So how long have you been doing this? How long does this project? It doesn't kill us. Oh, this one's a few years old.

I think I did it in like 2013. Is it stable? Is it where it's at? Are you playing with it anymore?

It was mainly just kind of an exploratory thing for me. So I haven't been adding to it, but you know, it's out there and I've had I've had all sorts of interesting people comment on it. And in fact, I found that there was another real programming language, not just my toy programming language, that actually had speech acts in it. This is called the star programming language.

So this is a language I think it's used privately right now. I think he just open sourced it, Starlang, but a full-featured language that has a notion of speech acts in it. I mean, not the requests and not the beliefs and some other some other acts, but very awesome. That's all things that I've never even heard of.

So very cool things to be exposed to. Even in terms of speech acts, when I first hit your home page of the bar or bat bar, I was like, what the heck is a speech? Is exactly right. This is why I love like looking at these papers.

Because I read elephant 2000, I had the same thing. I came to speech acts and I was like, what the heck? What is that? So it's kind of like just a thread that you can pull on.

And then you can say, oh, speech acts is from this philosophy, John Searles and just follow the thread and through trying to just understand just like a couple paragraphs of this paper. It takes you off in different wonderful directions that you never existed. When you start talking about reading these papers, it reminded me, I think it's the independent is independent Mac developer. I think it's super mega ultra groovy, which is smug as this company name, which is hilarious.

But he does like audio synthesizing type of software. And I saw a talk of his years ago where he says that he reads research papers as a competitive edge in like the indie dev scene to like give himself a level above everybody else. And so he'll like go read an academic paper about signal processing or about some sort of audio intricacies and he'll work that into his software into his product because nobody else is doing that. And he's bringing these ideas from academia, which oftentimes they just kind of stop there on a shelf, so to speak, and bringing them into kind of a capitalist economy that was very interesting.

But your take on it's just as interesting where it's like we can actually reach into these other areas and bring thoughts out that otherwise we never would have been exposed to. And they can actually make us better developers. They can affect the community in a kind of foundational way. So it's pretty cool.

Sure. Yeah. And this is actually one of the strong suits of that I see in the closure community too, that there is a real friendly give and take with the academic community and industry that you'll see at the closure conferences, there'll be speakers from the academic world. And so they we learn from them, and then they turn around, and then they learn from us too.

And that cross-fertilization is just valuable everywhere. Well, let's let's break there. We do have some closing thoughts. So let's break.

We'll hear from a sponsor and we'll be right back. I have yet to meet a single person who doesn't love DigitalOcean. If you've tried DigitalOcean, you know how awesome it is. And here at the Change Log, everything we have runs on blazing fast SSD cloud servers from DigitalOcean.

And I want you to use the code CHANGELOG when you sign up today to get a free month, run a server with 1G of RAM and 30 gigs of SSD drive space, totally for free on DigitalOcean. Use the code CHANGELOG. Again, that code is CHANGELOG. Use that when you sign up for a new account, head to digitalocean.com to sign up and tell them the change logs sent you.

All right, we're back. We got Karen here. We're talking now about her book. I didn't say that before the break, my bad, but we've been waiting to talk about this book because this whole call has sort of been an introductory guide, maybe even preface to your book potentially, but your book is a guide for those wanting to get enclosure.

It's described by your about here on Amazon. The guide is, this is the guide that's perfectly thorough, but gentle in terms of introduction for closure. So what is this book? Why did you write it?

Where did it come from? Right, so I think one of the unique things about this book is that it's a combo. It is two parts and it's part of an introduction in the first half. And then in the second half, it's a training plan.

And I structured it that way from trying to run. So I had been one of these people, everyone would run and I was like, oh, I wish I could run. Are you actually running with your feet? Yeah, like driving with your feet, like driving.

And I was like, and I would try it. And I'd be like, I just can't, I can't do it. You know, I would try running for 15 minutes and I would just be like, I was going to die. So I was like, this is just too hard for me.

I just, I can't do it. And then I ran into one of these kind of like teacher self to run programs that was like, he's in the 5k that had this thing like you just run for maybe a minute. And then you walk for five minutes and then you run for another minute and then you gradually build up over the course of, you know, seven, eight weeks. So you can finally actually run.

And this was like, I mean, I guess I should have figured this out earlier, but it just was mind opening for me that I just didn't have to do it all at once. And the reason why I was having such trouble was I was trying to do too much at once. And I thought, you know, this can apply to so many other areas. And in fact, I had, I was at a user group and I was talking to a fellow that wanted to learn closure.

He said, yeah, I picked up a closure book and I read it over the weekend and I tried it all. And I just, I just don't get it. It's just too hard. And I was like, that's the same thing like when I was running that if you're changing, I mean, the way that you think object oriented is kind of just a drastic difference from functional.

It's a different way of approaching problems. And that it's, it's just kind of like learning to think and do something in a new way that you just really can't do it all at once. I mean, maybe some people can, but I certainly couldn't. And it took me a long while to kind of mold my brain to think in a different way and approach problems that way.

So this book was all about kind of approaching it and giving people the path that says, yeah, it's okay. Let's ease into it. Let's start simple. This is not going to happen.

You're not going to pick up this book. And all of a sudden be totally knowing how to code closure in like two days, right? It's going to take seven weeks. And at least for me, and I hope other people out there that just that knowledge of, okay, it's not going to happen right away.

And that's okay. It's just a very valuable thing. So it provides a structured training plan between week one and week seven. It starts off using some open source website called foreclosure, where you can solve problems with the community in a kind of almost a test driven way, which is nice.

And then it moves into doing some cottas. I've made a GitHub repo and it's called Wonderland Cottas. So you're doing cottas for closure and developing your skills and bigger chunks. And then the final week is actually developing your web app.

And by the time you're done with that, you've had your brain a chance to kind of think a different way. And it becomes a lot easier. And you can run a 5k. And you can run a 5k.

I think this is a great example to pause on the tech side of things from this conversation and just say that this is to me, it seems like a really great example of living your real life, not just in front of the computer, and having profound new thoughts that totally impact what you do in your day job in programming. I think it's amazing how learning to run and influence you to write this book. And then, hopefully, potentially influence so many people out there to take their time learning closure through your book. Yes.

That's really cool. I mean, it's amazing to see that. Yeah. I think it's a great conceit for an intro book.

I loved when I just saw that it was an intro slash training plan for closure. And I almost feel like I need a training plan more than an introduction, because I've talked to people about it and I've seen this in tax. And I've got a little bit of an intro already, but a training plan, that's something that I feel like I can really execute on. Sometimes you have a book that just intros you doing a language like, well, now what do I do?

I just write a blog, make a web app, but one that actually takes baby steps with it, with you through it is a great idea. Yeah, I mean, it totally depends on your learning style, but hopefully this will key into the people that appreciate that as their learning style. I have a question about the Wonderland closure cadus. And the question, I guess, is why you chose cadus over Cohen's since Cohen's are so popular and they're very similar to cadus.

Right. So, yeah, so I guess a lot of people are, what's the difference? So I'll give you my definition of it. Maybe it's not your definition of the difference of them.

I would think of cadus being a little bit bigger, Chuck's problems than Cohen's. So that's just my interpretation of it. But is that yours or do you have a different interpretation of it? My interpretation was just more or less learning something through iterative practicing, not so much the variant to the two.

I think isn't Cohen's the purpose is like it's test driven. That's like the whole thing with Cohen's, but with cadus, it's you do the same thing over and over and over again. Is that right? Or am I off?

That could be. I've heard various definitions, but I'll tell you, I'll tell you what it is. And then I can tell me what King of it falls into. So the Wonderland code examples, they're independent little closure projects and they do have tests.

So they come with tests, failing tests, and you need to provide the code to make those tests pass. And then once you have a solution, you're welcome to share that as a link in the read me to so people can learn from each other as well. So I don't know exactly what King of that falls into. That's what it is.

Well, you can probably ask five people and get six of them. That's true. I was just curious because they, you know, by definition, they seem pretty similar. And I was just thinking like with so many Cohen's out there, you know, sometimes you might ride the coach over the popularity of other Cohen's to popularize yours, for example.

Oh, okay. Yeah, no, I got inspired just because the book follows the light examples of Elson Wonderland. So the repo, the exercises, the Wonderland exercises take their inspiration from Lewis Carroll. And he actually was a really big puzzlest.

So he really enjoyed doing puzzles. There's there's an alphabet cipher that he had published. There was, I don't think he originated this, but he would is documented that he used it with children a lot. It's the it's a river crossing puzzle.

I don't know if you've ever heard that, where you've got like a fox and a goose and a bag of corn. And then you've got to get them across the river and you can, you know, whatever cross one time and not eat each other. So that's sort of thing. I do love your appreciation.

I'm not sure if it's that way or not, but for just the some of the art that comes with it. So when you read me, you've got Alice kind of peeking, and that's what she's speaking into. I think she's finding a door that's super small and she's going to go into it. But you know, with each of these, I'm not sure if you call them, they're called katas, then each individual one is a kata.

Yeah, that's what I call them. Like you said, but the terminology is up for grabs, I guess. So in that case, you got, but you have this art and this playfulness. And I love, so since I asked you about Cohen's, I do appreciate your appreciation for Alice in Wonderland and how you've played each of these katas off of probably some of your appreciation for that book.

Yeah, yeah. Thanks. Yeah, it's just Alice in Wonderland is a fabulous book that speaks to people on so many levels. So it's one of those books that our stories to can read several times and still never get all the nuances that are involved, you know, from everything from the plot to the characters to the, you know, the ways they speak, things like that, you just there's always this constant, onion effect that you can keep going layer by layer deeper, no pun intended back to of course.

Yeah, it's timeless. Well speaking of inspiration, I guess we should go into our closing questions now and our closing question that we ask pretty much every guest is one about inspiration. So if you had to pick somebody out there who would be your hero when it comes to programming, somebody who inspires you a mentor or a role model, who would you name as your programming hero? I would name Jim Wierick.

He actually passed away last year, but I had the privilege of working with him and getting to know him personally. And not only was he a brilliant man, but he was one of the kindest and most inspiring men that I ever got a chance to know. So for, I'm sure you've heard of him, like he was a conductor of the regular. So just a beautiful man.

He was kind to everybody, you know, it didn't matter whether you were a programmer or not, a lot of time during lunch breaks and we'd finally got our drones together. You know, the janitor would be coming down the hall and we'd say, oh come over here, I'm going to show you something and like show him how to play the drone and show him the code behind it all and everything. And he was just a naturally just beautiful person and a wonderful teacher. So yeah, very inspiring.

Amen. I want to think we hear Jim as a hero often and he well deserved. I think we had Justin Searles on. It's been a while now, but I definitely remember him having similar kind of affectionate words for Jim and we had Adam and I both, you know, have Ruby in our roots.

So we were affected and still use right to this day. I'm not only the software lives on, but you know, just the kind of man he was, still affects and still like closing the hearts of many people to this day. So absolutely. Have you want to take the next one?

Well, the next one is always a fun one because it allows you to be a little introspective and more shout outs to popular open source that may or may not be popular yet. But in terms of your radar, what is out there, either in just in programming or open source, what's out there that's interesting to you that if you had a free weekend, I'm not sure how often that happens for you. But if you had a free weekend, what would it be that you had gone? Well, there's like new stuff all the time, right?

At least for me, there's like shiny stuff, I'm like, oh, I don't want to look at that. But right now I'm just, I'm really just entranced with the chemical programming and the chemical computing and just kind of looking into that a little bit more and there's more papers about that and maybe practical applications or practical potential applications because they're not in the wild and distributed computing, self-organizing systems and self-healing systems. So I would probably like to explore a little bit more in that area. As far as other kind of cool libraries and languages, one that I've contributed to quite a bit in the past months is Pixie Lang.

And that's a new language by Timothy Baldridge, and he's a really smart guy, but it's a lisp. Again, but it's made in our Python using the PyPy tool chain. So it compiles down natively, it's super fast and can access native libraries. So it's kind of exciting, different.

It's closure inspired, but it doesn't necessarily stick to be compatible with closure. So it has magical powers, do you know what those magical powers are? I think that it's supposed to be fast and light, but it's a great language if you, especially if you want to use fairy gifts. I think the package manager is named Dust, which are people, right?

So you can pick see Dust. Yes, I love it. Always a plan where I love that. But that's a fun project, and they're very open in contributions.

And friendly, there's a nice chat room. So if you're looking to get involved in the cool language, nice people, that's a nice side project. Okay, we'll link that up in the show now. So for those listening, if you've listened to the show before you know that we take pre-throw show notes, so we do a creative job on that, this is episode 171.

So you can find everything that we've talked about today. It's included at changeall.com. One, seven, one. Any closing thoughts, can before we take it home?

No, I think I've said it all, but it's been fun. Well, I do want to mention that your book living closure is available for order now. So it's not like it's a pre-order. She's written it's out there now.

So if you wanted to go check it out or vision it for that, I'll link that in the show up for that. But check out the book, have fun learning, closure if you pick up the book. As you know, we release the show every Friday. So come back here next Friday.

If you're not subscribing yet, you want to iTunes and subscribe and while you're in the nozzle, you're going to rate the show if you've listened to it before. We also ship a weekly email on Saturdays called changeall weekly. You can find that at changewall.com slash weekly. And because we love those kinds of words, we also have a nightly, which is essentially GitHub training on crack.