Transcript
Speaker: Okay, welcome to Deaf and episode number 37 after, I don't know, two months, three months of summer break. Summer, winter, I don't know, depending on where you are in. So we completely forgot what the fuck we do around here. So we're starting again. But anyway, in this episode, we have an amazing guest that we have been waiting for so long to have on the show because, you know, at least I've been fanboying him forever, I think.
Speaker: Mr. Bojedar, all the way from... Bulgaria. Sofia, Bulgaria. Such a fanboy. Yes. Well, I don't stalk him physically, you know, yet. You gotta work on your fanboy, mate.
Speaker: It's okay, at least they didn't say Russia because some of the people think that Bulgaria is somewhere in Russia. Often I get asked, is this Sofia somewhere close to Moscow, whatever? From time to time foreigners tell me, do you know that they speak Bulgarian and they start speaking in Russian to me, some simple stuff. I don't have anything against Russians, but it's kind of...
Speaker: It's kind of unpleasant to consider every Slav a Russian. I don't think anybody will say on live, you know, we have something against Russians these days. So, you know, come on, you know, we are very, yes. I'm pretty sure they'll strongly deny it. So, you know, they've got the best weapons.
Speaker: That's true, that's true. I also read about them. I'm intimidated. Yeah, I mean, they're nerve gassed, definitely, yeah. It's a blast.
Speaker: I was going to tell you, actually, I went to Bulgaria for a company I used to work for. Well, I used to run a company there, and we joined forces with a Bulgarian company. And I went to Sofia, and it was in, I don't know, early 2000. And that was the first time I gave up drinking after I came back from Bulgaria, because I was so wasted.
Speaker: So you drank for your remaining life in Bulgaria, so you didn't need to drink again. I mean, I don't know what the hell happened there, but yeah. I'm pretty sure your picture is there somewhere in every police station there. I'm sure. I mean, my passport was stamped. I did go, but you know, that's the whole number. Imagine how hard my life is having to live here all the time.
Speaker: hearing to deal with all the alcohol, the crazy partying and so on. It's tough. It's very tough.
Speaker: No, it was a good time. I must admit, I only went into Sofia. But the people there were really lovely people we were working with, and the people we met there were fantastic, really good times. The place was still a bit battered from the post -communist kind of crap. But I think it's, as I understand it, there's been, you know, from people I know who live there now, that a lot of redevelopment's been going on, and you know, life is looking pretty good in Bulgaria.
Speaker: Do you live in Sofia, by the way? What have you done? Yeah, I live in Sofia. Life has been getting better. It's still not amazing. We still don't have any sidewalks or roads that are presentable to normal humans, but that's okay.
Speaker: Really, things are way better than they were 10 years ago or God forbid 20 years ago, the crazy transitional years. Yeah. All right. So anyway, enough of my reminiscences. So let's get back to what's happening in Sofia these days. So you work for a company called Toptal or Toptal. How do you pronounce the name?
Speaker: I pronounce it incorrectly because I don't speak English very well, but I call it top towel. And my native English speaker colleagues are probably pronouncing it somewhat differently, but it's top talent, short term. Basically, it's an online marketplace for freelancers, mostly remote workers in various industries.
Speaker: Okay. And so do you do closure there? I'm assuming. No, no. We are doing a lot of Ruby. Well, no. Okay. Our
Speaker: Our code base, especially on the backend side, is very Ruby -centric. We are using other technologies. We are using Elixir, Node, Python, Scala, although we are trying to get rid of the Scala bits.
Speaker: But no closure. We used to use a little bit of closure four years ago. We were using Cremon in our infrastructure. But apart from me and one other guy in the company, nobody else found closure appealing.
Speaker: Most people were complaining about it and felt that it made it extremely hard to work with the infrastructure monitoring. So we decided to abandon it in the interest of world peace.
Speaker: But how did you come to Closure then? So how did you become the developer or chief developer cider then? What was the journey? It's a very long story which started around 15 years ago. I was...
Speaker: I was first working in one company as a C developer, writing kernel drivers for Linux. The company was building a little bit of custom hardware, and I was writing drivers for their hardware. At the time,
Speaker: I was a pretty junior developer. I was still trying to decide which are the tools that I enjoyed the most. I was using Vim. I'm not afraid to admit it. I read somewhere that Himux had better support for C programming. I decided to check this out.
Speaker: I liked it, I switched from VIM to Emacs at the time and I was just doing the standard C development for a bit, then I changed jobs and I went to a company where
Speaker: many of the developers were fanatical Emacs users. This was the first place where I saw people writing their own extensions, people enjoying Lisp and so on, because the Emacs Lisp part was very frustrating for me at the beginning. I didn't understand almost at all the configuration snippets that I was copy -pasting from all sorts of blog posts, wikis,
Speaker: and so on. But my team lead in this new company was really crazy about Emacs and Lisp. He told me that Common Lisp was the greatest programming language ever. Emacs was the greatest editor. He showed me why. And he gave me one book to read on Common Lisp. It was named Practical Common Lisp. Really great book.
Speaker: And it really clicked with me. It made me a Lisp lover for the rest of my life, at least from there to now. Hopefully, I'll live long and I'll love Emacs and Lisp this entire duration. Time will tell. But I really enjoyed working with Common Lisp.
Speaker: although there were no jobs for communist developers. Over the course of time I played with all other prominent list dialects and I thought that this was going to be some hobby but never something material until closure was created.
Speaker: And at the time closure was created, I was a Java developer. So it felt oddly convenient. A practical list dialect running on the JVM. Is this finally my chance to make some money doing something that I really enjoy?
Speaker: I wanted to become a professional closure developer like so many people, I assume. And I knew that we would need good tools for this. In the beginning, it was really frustrating for me that
Speaker: We had to use this frozen version of slime that never got updated. Half the functionality in swamp closure was half baked and didn't work quite like in slime.
Speaker: It was okay. I wasn't that well versed in Emacs Lisp. I didn't know that much closure, so I was just happy that somebody had done something useful, but I was also working on others more in Emacs projects at the time, like projectile and so on.
Speaker: And I got more and more comfortable with Emacs Lisp. I felt that I can start contributing to some more meaningful projects. I really admired people like Fio, aka Technomancy, who was maintaining the Emacs stuff for Clojure at the time.
Speaker: At some point, I noticed that he either lost interest in what he was doing with Closure or he ran out of time. And I started contributing small patches here and there to Closure mode and so on. Then Phil started working on NREPO -L. He created one small prototype that
Speaker: He left afterwards. Another guy, Tim King, picked up Phil's prototype, worked on it for a couple of months. And RepoL became kind of popular. But then Tim abandoned the project as well. And I was hoping Tim pretty much
Speaker: Since the original announcement, I think that there were like five contributors to NREPO and also something like this. So after he decided not to work on this anymore, he handed over this project to me, if you hand it over Closure Mode to me.
Speaker: And I ended up maintaining them. And what was driving me was the belief that I'm working on some tools that I have to make great for me to really enjoy my professional closure career that was right around the corner. This professional closure career, however, never happened.
Speaker: I went to work in one company as something like the CTO and we had to build very rapidly a few web applications. Nobody on the team knew any closure. They didn't even know Ruby. So it was
Speaker: It was a guarantee that closure wasn't the right fit there from a cultural standpoint. Then I was the CTO of another company where we tried closure because some people on the team were really excited about it. We wrote a few services in closure. Then we saw that two people on the entire team
Speaker: had any idea what to do there everybody else was very intimidated and they were just wow this is so complex i don't want to touch this and be responsible about the epic failure that is coming as a result of my changes
Speaker: So I was really disappointed because I felt that when we were putting some superior technology in the hands of people, they would be really excited. They would jump at the opportunity to work with this, to expand their minds, thinking, et cetera. But I learned that most people, even very smart people, just don't care. Nice learning.
Speaker: Yeah, they want to get work done, but don't really care much about the technologies. In my entire career, I've noticed that less than 10 % of the people who I've worked with actually cared about finding the optimal tools
Speaker: refining some stuff. The others wanted to get shit done, which is which is fine. After all, they they call it work. They don't call it vacation. So probably it has to be hard to justify the paychecks that we are getting at the end of the month. But in my previous company, I had this bad experience and a total I never campaigned for.
Speaker: for a wide adoption of closure. Actually, when I quit my previous job, I had decided that this was my final Ruby gig and then transitioning to closure at the time I had become somewhat known because of my work for Cinder and I was getting job offers all the time. So now the dream wasn't that
Speaker: something elusive it was very tangible but then i met my current ceo he's he's a really great guy and he persuaded me to do one final ruby gig which which continued quite quite a long period of time on one hand i'm
Speaker: I'm a bit bored with Ruby, having done it for something like over a decade. But on the other side, we built a really great company, a really great team. So what's more important?
Speaker: I still can do closure on the site and I ended up doing way more closure because in the beginning, site -side erosion, IMAX list only project and then I wrote a lot of middleware
Speaker: Then we created CIDR as an extraction of the common functionality from the middleware. Then there is the CLGS tooling library, which is pure closure. And most recently I ended up being the maintainer of NREPO, piggyback and drawbridge. So more closure code for me. So I never worked with closure professionally, I guess.
Speaker: I never made money out of this, but still I got to do a little bit of closure and I still really love Lisp. I still believe that closure is the most viable Lisp that we've got. This is our opportunity to make Lisp mainstream.
Speaker: Although I'm also realistic, I doubt that there will ever be a really mainstream list dialect, but as mainstream as it can be. Let's define this for mainstream in this context. I also feel that
Speaker: Closure is a great way to popularize my beloved editor, so for me it's a win -win. I help make the Closure community a little bit better. I help make Emacs a little bit more known, a little bit more widely used.
Speaker: And I get an opportunity to balance between the things that became not so interesting for me and something to keep my mind working.
Speaker: So compared to your Ruby experience, which is almost over, as you said, more than 10 years, when you think about Ruby and enclosure, both language wise and community wise. So what do you think? Where do you think all the differences are?
Speaker: The differences are epic. I really love Ruby's community. I think it has a lot of positive energy and drive that is kind of missing in the closer community.
Speaker: Just the fact that a handful of people are running pretty much every essential project in Closureland is really worrisome. Also very few groundbreaking ideas have come
Speaker: from within the community, things are very cathedral -like, enclosure -centered, around reach, around Cognitek, after he joined them.
Speaker: which is not necessary bad when you agree with what they're doing. It's not really great when you don't agree with what they're doing, with their approach to things.
Speaker: I don't know why so many, so few people are active on the open source scene in enclosure. Maybe many people become disillusioned with the complex process for contributions in the closure core and on all the contrib projects, maybe just the community small compared to the Ruby community.
Speaker: But, you know, I see that many people come, they submit a page or two, and then they disappear on my Ruby projects like RuboCop, that there are so many committers who have been active for years and years and years. And constantly you see that somebody created some great new library,
Speaker: or came up with some crazy ideas to improve the internals of Ruby and so on. So I'm missing this. It's really great in the Ruby community. On the other hand, there are also some things that are pretty similar.
Speaker: The way that the core Ruby language is curated has been criticized heavily in recent years in the Ruby community because there hasn't been that much innovation. Now Matz, the author of Ruby, is more focused on
Speaker: stability making sure that the users are not surprised by breaking changes and so on that there are some great deals plans for the future for ruby 3 .0 but it has been taking so much time to develop
Speaker: I hear, optimistically, it will end in two years, realistically in four or five. And in the technology world, everything is happening so fast that if you're not constantly innovating generally,
Speaker: You are just forgotten, especially if you're a niche language. If you're Java, if you're C, okay. You can afford not to innovate, but if you're fighting for relevance every day, you have to keep people excited.
Speaker: But isn't there a dilemma? Because on the one hand, we need a stable language to play with. And on the other hand, if we say, hey, we need constant innovation, even because I've been writing Java for a long time, and then there has been a super static period in Java, and then nothing has changed, and that stays forever. And then in the last six months or one year, suddenly there is Java 6, Java 7, Java 8, Java 9, Java 10. Things just move too fast now.
Speaker: finding the right spot seems to be really, really tricky because we want a stable language, we want a stable language, stable features and backward compatibility, which is, I think closure people are very, or at least as closure developers, we are very proud of. You see that every now and then, either Stuart Holloway tweeting, oh, you know, five years ago, somebody wrote closure code and still it runs without any changes. So that's a big badge of honor for closure.
Speaker: But I think that generally people for some reason associate innovation with instability and it doesn't have to be like this. Why should you break the API just because you came up with some new ideas?
Speaker: Many of the things that I consider innovation are not going to break anything. So I think that we should stop saying that innovation is the arch nemesis of stability. It's the same with Truva, for instance. Nobody wants features to be deleted, at least right now.
Speaker: deprecate stuff, keep them around for five years, 10 years, just tell people that you realize that something was a very bad idea and you reconsider it, point them to a better way of doing things. I think this is great also that there is so much innovation that can happen on the level of the internals that generally users never see.
Speaker: Ruby changed its runtime several times without introducing almost any breakages. And it's going to do this again with the next release. So obviously you can be innovating and not breaking.
Speaker: stuff. For fundamental changes, they are generally a very bad idea, but you can be doing small incremental changes. I really like how Erlang are doing things.
Speaker: They even replaced some of the keywords in the language by just adding new keywords. Nothing really got broken. People got more ways of doing things, but there was also this disclaimer that we realized that this was a bad idea. For instance, non -short -cutting Boolean operators and so on.
Speaker: that they added support for UTF strings after so many years of missing these dictionaries and so on. Those are changes that many people could consider tricky and that they are tricky to do right, but they didn't break anything.
Speaker: things happen. And also with Java, I really admire what they're doing. The module change was tough. It broke some stuff. But generally, they have been evolving the language really
Speaker: In a really nice direction, adding the Streams APIs, native Lambdas, type inference and so on without breaking any code. So there are a living testament that you can be innovating all the time and you can have
Speaker: as much stability as you want. You just have to do it smart. Don't delete methods. Don't change signatures in incompatible ways. Today, there was a nice tweet by Joe Armstrong, the creator for Lenk. He was saying, when you're making changes, just add new functions, modules, whatever. Don't break the existing stuff.
Speaker: But Richard said that as well, isn't he? I mean, he has made big talks about that, saying that accretion and using sets, using addition rather than deletion is the way to go. So I think the culture is very similar. I think the interesting question to me is what
Speaker: Where is the call? Because Lisp hasn't got much syntax, so there's not much to break, really.
Speaker: Because in Ruby, you have the core language, then you have the SDK, then you have the runtime and this kind of stuff. But how would you see the separation of things in Clojure? Like where is the runtime, the core, the libraries, the ecosystem? Because that's where, I mean, in theory, Lisp should have far more innovation than these other languages.
Speaker: In theory, yeah, but who wants to be writing their libraries themselves? And for instance, one of the fundamental differences of opinions I have with Trich is that the core library should be kept tiny. If you recall, in the beginning, he didn't even want to have a string namespace.
Speaker: OK, you can say I designed the language for interoperability with a host platform. But even at day one, there were two host platforms. So because there was a really tiny core library, and you had to
Speaker: leverage directly stuff from the host environment all the time. You couldn't write a trivial program that would run on CLR and Java unmodified. After the initial release, obviously the focus on CLR
Speaker: it evaporated for some reason. I think that that might have been a bad tactical decision because it shrank closure potential market in half.
Speaker: If you were aiming to have a language that runs better on several host platforms without the need to be creating different artifacts for them, that would have been much better. I think that when they started betting a lot on Closure Script, they saw how a very thin core library
Speaker: It's a problem because there was this huge discussion that went for maybe two years about adding five or six string functions more to a closer string.
Speaker: functions that exist in Java but don't exist in JavaScript, so that they made it really painful to be writing portable code. And this can be extended to so many other things. For instance, doesn't it bother you that the IO namespace of closure is prefixed with Java?
Speaker: So what is my standard, closer way to deal with IO? I can tell you. Obviously, Rich has some vision how his language should be used, and I respect this, but I really feel that if you want to
Speaker: gain a bigger exposure. If you want to go higher, farther, and so on, you should be organizing things in a way where it would be easy to support multiple platforms without having to bang your head in the keyboard.
Speaker: all the time to make the things cross -platform. In the same line of reasoning, I think that the addition of CLGC was very long overdue. This should have happened in pretty early versions of Closure. Maybe now it is better designed than it would have been in the beginning.
Speaker: I think that if we had this earlier, Closure would be much stronger in the multi -platform space. As I know that like the principal author and the maintainer and the lead for the, I think one of the top used Closure library or Closure tooling editor and every IDE system,
Speaker: So did you ever ever try some other closure shit apart from me, Max, to write closure? So let me think. I think I used cursive once. Yeah. But I'm not 100 % certain. I remember that I meant to try it, but I'm not certain whether I tried it.
Speaker: Yeah, generally, I don't I don't use anything except the max for any programming language except Java. Yeah, when I was a Java developer, I was using intelligent ideas. So
Speaker: I'm really fond of it. I don't like ideas that much, but you can tell that IntelliJ idea was created by developers, for developers, unlike other ideas like Eclipse. Eclipse was so painful. I hated it.
Speaker: IntelliJ was cool, and when I heard about cursive, I think I played with it, but it was a while ago. I have spent a lot of quality time with Colin. He's an amazing guy, so I'm certain that cursive is a really, really great cool. Now, too, and in general, it's good that people have some
Speaker: some options. I really don't want people to force people to use Ceemax. I want them to be using Ceemax because they feel it's something that clicks with them, that makes them more productive and so on. But if they use it just because there are no other options, that's fucked up. That's not proper competition.
Speaker: Yes. This is one of the issues I had when I first started learning Clojure, was that I had to learn Clojure and I thought, okay, the true way of dealing with Clojure is via Emacs, so I'll learn Emacs as well. But then it's like, is it language? Is it the editor? There's too many things going on in my head.
Speaker: So actually, it was quite nice to be able to use IntelliJ because I was a job programmer as well and a C programmer, blah, blah, blah. But so it was quite nice to be able to transition without learning a new tool. I can see the beauty of Emacs for sure, but at a certain point, you just don't want to, you have to be convinced that it's worth the investment.
Speaker: And like you say, sometimes you just want to do something and I wanted to learn Clojure, but I didn't want to learn something else as well. And I think that's good for people who, if you're already an Emacs user and you come to Clojure, then bonus. If you're not, then you want to have a choice, don't you?
Speaker: Yeah, absolutely. And to finish my answer on the question, even though I didn't really try the other editors from time to time, I would see something like a tweet or a post about some interesting feature. And if something seemed like worth adding to Cider,
Speaker: I would do it so I definitely kept an eye on the competition and much of the competition has been extremely friendly especially in the past two years for instance VIM adopted the entire cyber middleware to power its functionality
Speaker: And we are working pretty closely with one of the most active maintainers of the Vivium support for closure programming. We are also working closely with some of the guys working on, I think, Atom.
Speaker: I hope that, I'm not mistaken, but that they have also been providing feedback on the middleware, on the main repo in general, and that has been pretty cool, before counterclockwise went under, its maintainer was also
Speaker: working on adding support for Cider and Repo there. I think he actually released a few versions that we had, but then the project was abandoned. This is also the reason why I started the work on Orchard and to
Speaker: to make it easier for more people to share the functionality that was developed for CIDR. Because with Orchard, you can also reuse this with an repo, with p -repo, with a plain socket repo, with a line -based repo, and so on. But what is it technically? I mean, what exactly is Orchard?
Speaker: Orchard is the core CIDR functionality as a standalone library, because I don't know if you've seen the architectural diagram of CIDR, but you have the client written in Emacs Lisp.
Speaker: you have the server which is in repo written in closure and you stuff a lot of extra closure middleware which is cider and repo in the server to provide the complex functionality like the debugger and so on.
Speaker: But there is one problem with this. Much of the functionality in CIDR and repo is not in repo specific, but it was intermingled with the middleware stuff.
Speaker: And some people said, OK, I want to be using this with a plain socket repo, but it's not very usable like this. And then I said, OK, so we just split Cider and repo into two.
Speaker: that the other library was named Orchardt as a node to Cider, you need Epos to bruise Cider. Now the middleware library is an extremely thin wrapper around Orchardt.
Speaker: everything important, almost everything important is in Orchard and Cider and Repo is just middleware definitions, wrapping stuff into and repo messages and so on. And I think this
Speaker: This made the potential for collaboration between tools even bigger. At some point, somebody started to work on a tool similar to CIDR running on an repo. And obviously, they can't use an repo middleware with an repo, but they can use a library
Speaker: fuck, like orchard. We're going to talk about the the preple, which is coming up in 1 .10. And you said you had some some thoughts about that.
Speaker: Well, I'm really skeptical about it because I hear that this prepo was created to make it easy to build tooling for closure. But I don't think that any writer of tooling was ever consulted when the library was created. I think that there was a similar problem with the introduction of the socket repo.
Speaker: I thought in the very beginning to several people on Cognitex team that I'm skeptical about how the socket repo is going to work out because the socket repo by itself doesn't give you much. It gives me one repo without any capabilities for
Speaker: for the clients without session multiplexing and so on. So if I want to add those abilities, I have to create something like a slimmed -down version of NREPO.
Speaker: and stuff it to the dependencies of the users. Plus, I have to ship them some libraries for completion, for debugging, and so on. So I really don't think that this solved any problems with the tooling. It solved one problem. It became easier to
Speaker: connect to a remote repo and just do some simple debugging or whatever. But for tooling writers, I think this didn't add anything. Maybe this wasn't in the scope of the socket repo. Maybe the debug interactions were the primary focus with the socket repo. Another problem was that by default, it uses Eden.
Speaker: before the request responses, which is pretty painful to handle in some editors. If for your language there are no hidden libraries, what exactly are you doing? And this was a showstopper for Emacs for a very long time. Just this year,
Speaker: Arne from Lambda Island created those libraries. And now this is viable, but for a while it wasn't. But that's not necessarily an argument against it, is it? Because Eden is the lingua franca data sort of transmission model for Clojure.
Speaker: Well, it might be the lingua franca, but if you cannot get the clients to communicate in this lingua franca, it's probably not really, it's probably not it. It's not lingua franca, maybe it's lingua something else. Lingua, lingua designable.
Speaker: The fact that you call something something that doesn't make it doesn't make it true. Before the World Cup everything was saying that Brazil are the greatest team in the world and that Germany are going to be the
Speaker: strongest competitor in the tournament, but it didn't play out exactly like this. So marketing is one thing, reality. But as a tool author, I mean, as one of the prominent tool author or even, you know, one of the biggest reach that Closure has in terms of IDEs is Cider, right? So as a person who is leading that effort,
Speaker: What do you miss from the language, from the core library or from the core team? From the core team, I miss mostly support on some things that would help us provide better features. I can give you a very concrete example. Deaf records do not have location metadata for some reason.
Speaker: So because they don't have it, something like CIDR cannot provide the ability to click on the usage of a record and go to the definition. I filed a ticket for this five or six years ago and
Speaker: So somebody supplied a patch for this right away, but it wasn't merged for so many years. It was pushed back one version, two versions. Alex Muir mentioned that probably it's going to be merged in 1 .10, but that's the same patch and modified, I believe, since the very beginning. It has just been
Speaker: Re -based, re -based, re -based. And there were a few other tickets that we found some bugs or some discrepancies and so on.
Speaker: And they were completely ignored. And you can ask me, why don't you fix those yourself? Because I see how you create the patches and they linger for four years. I don't want to waste my time. I remember how much
Speaker: We discussed those six string functions with Alex, with Trich, with Stu, for six simple string functions, which I believe
Speaker: Almost everybody agreed for a decent addition to the language. It's just very hard to be making some changes that seem really clear cut to me. I also deeply profoundly despise working with the Java code base of Closure because it's extremely inconsistent. It's weird. So many people suggested just
Speaker: doing one format commit. Yes, one format commit. Yes. But Rich is very against this because he believes that this is going to make a lot of patches harder to merge. At the pace we are merging patches. It should be okay. I think that that's a marginal concern.
Speaker: It's really hard to be collaborating with the core team. That's my pain. They don't solicit feedback on functionality that's touching on the tooling. I learned about Purepo from the commit message.
Speaker: Nobody asked how they can help us provide better error information or how to simplify building debugger, how to simplify the integration between Closure and Repo.
Speaker: That's really painful. It's like they don't care about the tooling at all. After thought, it's something that's going to sort out by itself. And then you see in languages like Elm, Elixir, people are going through
Speaker: to facilitate easier creation of tools for the developers. If I were running Cognite X, I'd certainly invest a little bit
Speaker: into empowering the two writers because obviously this is going to bring them more clients in the end of the day. I think that in general a strategic mistake that has been made so far is
Speaker: underestimating the development tooling, not working closely enough with the developers to improve their experience. But recently, there have been some steps in this direction to do that most notably.
Speaker: But I think this could have happened earlier. Apart from this, I don't really need them to create new libraries and stuff like this. I want them just to have the things that we are using working properly, maybe get some input
Speaker: on a feature or two, because the way they created the socket repo, I don't see us ever using this. And I feel that the same thing is going to happen with p -repo also.
Speaker: something that came to mind. Closure tests could have had a much better way to integrate with external tools and maybe Closure could have shipped a standard protocol that all testing libraries could implement. So it's easier for two writers to provide test runners
Speaker: just by relying on this common protocol. Now we call closure test the common protocol, but it's a very basic protocol. But yeah, I can go into many details, but probably we should rather focus on other topics. I heard just one quick note on that.
Speaker: I heard from Alex on another podcast that spec might actually be coming out of alpha once they finish the testing story. So maybe that would be quite nice if
Speaker: If you had spec there, has spec made any difference to you actually as a tooling provider? No, no. The only time I used spec was to create some basic support for it in CIDR.
Speaker: I think it adds some value, but I think that the value is greatly exaggerated. After all, this has been something known for what, 20 years, and it didn't really become mainstream.
Speaker: I myself feel that if I invest a lot of time on dating stuff and if I end up with significantly harder to comprehend messages in the end of the day.
Speaker: I didn't really improve my life that much. I could have just used some statically typed language or something like this. A lot of value is being put on the auto -generated tests.
Speaker: But I almost had no instances in my career where we had some major problems because somebody didn't test about the right boundaries. Obviously, things like this happened, but with practice, you make such mistakes rather rarely. So this was solving a problem that I didn't really feel I had.
Speaker: I think that many other people felt the same. Often the stewards of a language
Speaker: solve some problems that they might perceive that are not really perceived by everybody else. I think that prismatic schema, for instance, solved much of this problem themselves. And also when you start something in the language, like with P -REPO, like with the socket -REPO, once you are constrained by the backward compatibility,
Speaker: and two which is much worse, you are constrained by the slow release cycles of the language. So. Don't you think that they're trying to, like we talked about a while ago about having like this innovation stability thing, isn't spec there, like they're trying to spec now the core functions and the core libraries and that will,
Speaker: prevent regression and stuff like that. So overall, there may be some, like you said, maybe it's a benefit just to them. But in the end, it could be good for everyone if they make fewer mistakes or they rationalize some of the usage that's been occurring on their libraries. I think there was one problem with namespace where
Speaker: require without a colon, for instance, was removed. And this was acceptable before, but it's not acceptable now. That kind of thing. It's going to help to some extent, but really, if it found one problem... I'm just giving an example. Yeah, so almost all mainstream languages have just unit tests.
Speaker: And it seems to work pretty well in practice. So the real question you should be asking to yourself is, does Clojure have good unit tests? I can tell you it doesn't. And I have seen many, many times, especially in the early days, rich committing some stuff without explanations, without unit tests. For Oaf, he has brilliance.
Speaker: From time to time, he does a lot of repo -driven development. I guess he just verifies a few inputs in the repo and, okay, that's good. Yeah, he has some comments at the bottom of his code showing how the repo works. That's enough, isn't it? I'm joking about that, but it does seem that's the way, yeah.
Speaker: The other thing about the libraries, I think they have a significantly bigger issue than the lack of test coverage. Half of their developers, the libraries in country are effectively unmaintained. The others have like one maintainer and five commits per year.
Speaker: You can market this stability but also when you see about the. Many bucks that the report it and fixed in korei sink you can think that that that's a forgotten project that they have this tendency.
Speaker: to start some things and switch to something else. One of the services we used in my previous company that was written in Clojure relied heavily on co -racing. I think that
Speaker: uh one of the devs on our team reported like seven real bugs in co -racing and none of them were fixed and in general co -racing doesn't uh uh doesn't get uh much love uh i'm afraid that uh everything that goes into concrete event or
Speaker: Or the core at some point gets forgotten, the focus switches to something else. For instance, have you heard anything new about reducers recently? There were a big feature back in the day.
Speaker: A popular library is like two namespace. This 0 .3 alpha is probably going to haunt us forever. Closure class path, a very simple library took forever to be updated after it was broken by Java 9.
Speaker: And if this was a Ruby project or maybe just a Closure project living in GitHub, I can tell you that the breakages for the serious things would be fixed in a matter of hours.
Speaker: Maybe some different mentality. That's also a general problem of closure. The last bug -fixed release of closure that I remember was 1 .5 .1 and before this there was just one more.
Speaker: There are many bugs that could be fixed in the scope of the current major release, and it's simply never done. When I was speaking with friends who are working professionally with Closure, virtually everybody told me, in production, we are running a heavily patched version of Closure because the patches are there in Jira. We need them.
Speaker: No, nobody is issuing those bug fix releases for us. So that's something that we have to handle ourselves. That's horrible.
Speaker: Yes, so I don't really care about spec because I have real problems to care about. I want to see the actual issues tackled and then they can ship as many helper tools as they want. But for me,
Speaker: spec is something kind of useful, but it's not essential. And I would trade it gladly for many, many other improvements that I would really benefit from. And I think others would benefit from as well.
Speaker: Do you have any, I mean, I must admit, I have no idea why we have, why the core team has this aversion to releasing code outside of major releases. Have you ever heard any ideas why that might be? Because it does seem very strange. Every year we get a big drop and then nothing.
Speaker: I think it's because most of their clients weren't happy to do updates often. But I'm not certain. I just heard this a few times. It might be something true to this.
Speaker: might be just a rumor, but from what I gathered, this was mostly related to how Cognitec works with their clients.
Speaker: So on a different note, so what do we enjoy about closure, apart from all this magical stuff that I know? I can imagine how painful this is. And what my worry is, is like one of the major, major contributors, not just contributors, but also
Speaker: You are responsible for most of the developers getting into closure and then using CIDR. Their daily bread is essentially using CIDR. Every day they open Emacs and then they write code. If your frustrations are getting to a point where you're like, oh, fuck it, I'm done with this shit, then that's going to be even bigger loss because
Speaker: from 2014 or even before that, every year we see the survey and then CIDR comes as the top tool that everybody uses to write closure code. So what are the positive sides, do you think, that makes you like closure or enjoy closure a bit?
Speaker: Oh, it's a lisp and it's the only viable lisp. Frankly speaking, that's it. The moment somebody creates something I consider more viable, maybe I'm done. Because my loyalty is not to closure. My loyalty is to lisp.
Speaker: Right now, this is the strongest list we've got. If there is something better, I would be happy to move on. I think that Closure got a lot of things right in the early days. I really enjoyed, for instance, using more literals for the various collection types.
Speaker: Promoting things like when let if let and so on trading macros. There was some really cool things but the.
Speaker: the types, records and so on. But what bothers me is that almost everything I love about Closer, everything that I considered an evolution compared to the previous dialects happened in the first
Speaker: really easy source of something like this and ever since that there hasn't been anything that much to get me excited about producers they were like that transducers
Speaker: Maybe I was a bit more excited about them, but still nothing major. CLJC and the true portability aspect, this was something that really got me excited because I think that longer term JavaScript is going to generate more growth for closure than
Speaker: The market space for server -side languages is really crowded. I guess the same applies these days to the front -end, but on the front -end, ClosureScript doesn't have as strong competitors as Closure has on the back -end. For instance, there is no client -side Elixir or something like this.
Speaker: Yeah, but they're catching up, right? Every major language now has, or at least they're coming up with some sort of JavaScript side of it. Scala has Scala .js and Haskell has at least multiple implementations that they're trying to do. And even on the JavaScript side, you have TypeScript and then ReasonML, you know, these things coming from functional side. Yeah, that's why I said that it's getting crowded there as well, but ClosiveScript is
Speaker: Really close to closure, which is not the case for many of the other dialects, for instance. There is a Ruby that compiles down to JavaScript, but the differences there are quite significant. Also, closure script is maintained by the same people who maintain closures, at least on paper.
Speaker: Maybe just going back to what you said about being a lisper. What, if anything, would you say with common lisp you would like to see brought into closure? Because I remember
Speaker: You know, one of the things I've seen in libraries are things like the error handling so you can do sort of stack unwinding and things like this. This decent really I mean maybe it's just a problem with the host, but these seem quite interesting features of common list that we don't yet have.
Speaker: enclosure and I'm not a proper common lisp or a new scheme and I did a little bit of that but I can't really claim to be a proper lisp so I was just wondering given your greater insight what you would think would be kind of things that you would like to see over here. I'd certainly love to see the common lisp error handling
Speaker: I obviously enjoyed also the uniformity of Common Lisp. I'm not a big fan of shelling out to the host all the time. It just disturbs my sense of aesthetics. I can live with this, but as I mentioned earlier, if it were my show, I would have wrapped in the core everything essential.
Speaker: So we will have a few of those distractions. And for me, it's some mental overhead. Every time I see some host invocation, I'm like, hmm, that looks different. Why is it done like this?
Speaker: We don't have the appropriate data structure. We cannot manipulate it properly and so on. I think it's something that we can easily dispense with. I really like the integrated debugger in Common Lisp. I think that this was
Speaker: amazing. I guess it ties to the error handling because you get an error and you can start debugging it right away. I liked a lot the concept of images that you can save the state of your application and resume the application
Speaker: I guess that's not doable with Java, unfortunately, but it was really amazing with Common Lisp.
Speaker: that the macros, they are better. Obviously, you could do more with Common Lisp macros, but in general, I agree that doing this type of magic is probably a better idea. But there were also many things about Common Lisp that I disliked, so... But it's still on the positive note, so, you know, it's okay.
Speaker: I think that if Closure managed to get one thing right that Common Lisp didn't manage to get, this was the uniformity of the language. Closure is significantly more consistent
Speaker: Kamalisp cuts around so much legacy. When you see the file system API, it's crazy. It's a support for some antiquated file systems from a billion years ago. And that's not fun. So when you start anew, you get this opportunity to share a lot of legacy.
Speaker: Closer really, really excelled there.
Speaker: So for the CIDR thing, before we started recording you, we were just discussing because you're now finishing, almost finishing the project with Closureists together. So can you give us some idea about your experience with it? Because this has been a really nice initiative, in my opinion, to support the people who are building amazing stuff in the community.
Speaker: given the you know the lack of the things all we discussed already so how how is your experience with closures together and and what did you how did utilize that time. I have to I have to tell you that Daniel is really amazing first of all the the idea is great but.
Speaker: What's amazing is that he forced me to do this in a nice way. Unfortunately, very few companies are supporting closures together, so this cannot fund enough work.
Speaker: if just one or two people were working full -time on closure tooling for one year, I can tell you that two, three years from now, we would have tools that are 10 times better. But as I've mentioned on several conference talks, companies are extremely short -sighted and they don't see how they can empower themselves.
Speaker: Daniel pushed me to accept the commitment, which would make me do a lot of work. And I did significantly more work that I would normally do for such a small contract. Just because I really love the community, I might have
Speaker: my disagreements with the Wake Cognitec trans the show, but I really love the people in the closure community. They are the thing that drives me and makes me continuously invest into building those things because I think that those great people deserve some nice tools with which they should do their job.
Speaker: Closuries together helped push me to work on something that I postponed for a very, very long time, like the rework of the Connections API. This is going to be brand new in 0 .18, restructuring heavily the code base internally.
Speaker: pouring a lot of efforts into into polishing orchard and probably most importantly completing the migration of NREPO out of Closer Contrip. I think that NREPO is the first project to go to Contrip and to decide to leave Contrip.
Speaker: And I think that for the betterment of the closure community, a lot of other projects should leave contrip and the heavy restraints that it puts on the development. A lot of good things should happen with NREPO once the new version becomes the default everywhere.
Speaker: I have already upgraded reply or replay or however people read it. I have sent pull requests to boot, to line engine. We have created on the site a line engine plugin that allows you to run the new and repos server.
Speaker: I have created a snapshot release of Ciders middleware that works with the new N repos server and I'll do the same with piggyback. Drawbridge has been upgraded for the new N repos server. I want to be done with those upgrades so we can focus on improving the N repos
Speaker: internals and making it a much stronger foundation for closure tooling because I can tell you one edge that that uh and repo is forever going to have over p repo and
Speaker: does the socket repo, it is owned by the community, and it can advance at a pace that can never be matched by something shipped with closure. So if P repo is shipped today, I find three bugs that make it usable inside there. I have to wait between one year and 17 years for those bugs to be fixed.
Speaker: But with 10 repo, things are happening much faster. Also, the community has invested tremendous energy in building in repo middlewares. We know that this model works well, and especially after Closure 1 .7, it has become much easier to support properly Closure Script with 10 repo.
Speaker: Bruce of Figwell fame did a lot of great work with piggyback recently. Now it's so much faster and more robust than it used to be.
Speaker: So do you need really something new here or you can just keep improving the tools you've got? I continue to believe that NREPO is the most convenient API to work on Closure Tooling.
Speaker: I also think that NREPO can at some point just be put under a language server protocol implementation foreclosure and you are done. You create this server which internally just spins an NREPO, translates a few requests,
Speaker: And this is priceless for the tools which can speak and report directly that there can be some benefits for the others. Everything is here for you and it is free. Unless you decide to take some radically different approach based on static analysis, which I don't think sits well with the Lisp
Speaker: mindset, traditions, I don't know. Cool. So I think we are almost one hour, 20 minutes. That's pretty good. I think we covered most of the topics that we wanted to cover, right? Or did we miss anything? There was just one thing I wanted to talk to you about, actually, was the style guide.
Speaker: because it's quite nice that, like you say, you've done a lot of development enclosure and then you've taken the style guide approach. So how is that going? I mean, I kind of follow you on GitHub and it seems like, again, that keeps getting contributions and things keep on getting updated. It's not a huge volume website, but it seems like there's still enough interest in it.
Speaker: Yeah, I think that every language should hear some style guide because this eliminates a lot of pointless conversations. Should we do it like this, like this, like this?
Speaker: I'm a big believer that we should focus on essential things and not on whether something should be indented with one space, two spaces and blah, blah, blah. What about tabs though? Spaces. Death to all the tasks. Exactly. Good job with focusing on the important things.
Speaker: I'm just hoping, you know, Apple is going to release a new new keyboard that the tab is part of the touch bar, then it just disappears completely.
Speaker: Oh, it's still useful for indentation and completion, and it looks kind of nice. I'm a very big keyboard fan. That's the thing I love the most after Imak say yes. Yes. And I have a really nice collection. I cannot type on laptops. It's horrible. But did you remap your control key? Or how do you use it?
Speaker: Also, I have remapped my caps key to control, and I also remapped my return key to control, so I have a perfect symmetry when I'm typing. That's interesting, because I only remap caps key, and every time somebody else uses my keyboard or Mac, they just get confused a lot.
Speaker: That's on them. That's a security feature. I really like having mirrored controls and I don't like them on the bottom. It's not like I cannot
Speaker: cannot type like this, but I prefer them to be closer at hand. I do a lot of free mappings. For instance, in Emacs, I use the command keys heavily to have to press control fewer times, experiment with the space bar and so on. Typing is one of my small sessions. In the past, I was participating in typing competitions like this.
Speaker: Because I believe that you cannot be a great developer if you're not amazing at touch typing. I agree. Then again, now I think that we spend significantly more time thinking about our ideas and then typing them, but still it's very useful to be able to type fast.
Speaker: Yeah, I mean, even if you think because in my mind, it's like the gap between putting the code to the computer and then thinking that, you know, even slips down because you're telling computer in a really fast way to do what you want to do.
Speaker: I mean, I see some people hunking, you know, like, like a hundred pack, you know, sort of things. And they're really great programmers, but I get really annoyed by when they're looking for the keys. It's frustrating, but I haven't forgotten about the style guides. Yeah, yeah, yeah, of course.
Speaker: I have this thing that if there is a lingering question, I have to answer it. Otherwise, I don't feel good. What is your credit card number? Let's leave it there and then let's continue.
Speaker: I think that something like this should ideally be promoted by Cognitec themselves. I think it should be one of the articles on Closure Luteur or something like this. I really am glad that most of the people agreed that the points outlined there are really community style, not somebody's personal style.
Speaker: There is always an opportunity for improvement. Recently I was reading the advice by Stuart Sierra about namespace structuring. And yeah, that's also some very sound advice that should go to the style guide as well. So it keeps on growing.
Speaker: I also wanted to publish this as a small website, so it's a bit prettier, but who has time for everything they want to do. And most importantly, when I wrote the initial version, this was just a precursor to writing a linter.
Speaker: for it. Linters are another of my small obsessions in the Ruby world. I wrote one for Ruby itself, for Ruby Andreas as well. And I wanted to do the same foreclosure because I felt that
Speaker: what we had was pretty immature. Eastwood and Kibit are nice tools, but they're very buggy. Everybody knows this, that they are not maintained very actively. So I wanted to work on something else, but I ended up working on so many other things that the linter never actually happened. And the thing that I was thinking about this
Speaker: maybe seven or eight years ago, and still nobody has created a proper linter, maybe joker to some extent, but it's not the type of linting that I had in mind. It illustrates the point I made about too many people, too few people being involved with the tooling aspect of closure.
Speaker: The bus factor of the entire tooling ecosystem of Closer is around 10, 20. For a popular language like Closer, this seems crazy to me. In terms of style guides, do you think spec is going to change the kind of way that you do things in the style guide?
Speaker: Maybe, maybe, but I really have to spend more time with spec. Honestly, I'm avoiding spec until somebody tells me that this is stable because
Speaker: I'm way too busy to be wasting my time with .alpha, whatever. If it's another library they're going to abandon in two years, I'd rather wait a little bit. Well, it's been in alpha for quite a while, so I think you were right to wait.
Speaker: My god, I don't know if it's ever gonna get out of alpha so it will be nice to that would be nice to see so that No, everyone can move the fuck on. Yeah. Yeah. Yeah, I saw some interesting tweets Baba is to our throw away and some link to a ticket in in Jira where
Speaker: There was some discussion about significantly improved messages, both stack traces and from spec in 1 .10. I don't know whether this is actually going to happen or is going to be a conversation for the next five years, but it's really encouraging that the
Speaker: it could detect that they are paying attention to this problem. If they solve it, SPEC might become a much bigger player in the closure ecosystem. But still, in a way, it feels to me anti -Lispian, annotating stuff, adding complexity,
Speaker: It also contradicts many of the things that Rich has said over the years. I think also this is the reason why CoreType never took off. For many simple libraries, simple services, you might spend more time working on the spec annotations than on the code itself.
Speaker: Until it's really made simple and easy, I don't think it's going to be a big enclosure.
Speaker: So I think we can wrap the episode now, I think. I think we covered most of the topics that you want to cover. And Bajidhar, thanks a lot for taking your time and then spending Sunday evening with us. Obviously, I mean,
Speaker: I'm pretty sure at least 90 % of the Closure community is extremely thankful for what you're doing. And probably every Closure developer is running your code, apart from people who are too stupid to use Emacs. But anyway. I'm sorry. I think I offended everybody now.
Speaker: But that's our goal. But I think, like you said, there's a good community of editing people. I don't use your code, but I enjoy your talks and I always enjoy
Speaker: the innovations that you're making over there, and I think competition is very healthy. And I think your insights into the way that closure should be developed are absolutely spot on. And I think having a voice like yours that is very rational and very amusing as well is engaging and is very, very persuasive. And let's hope that people are actually out there listening. Yeah.
Speaker: Yeah, I can hope so. I don't, I don't care that much just about society. I will be the happiest person if I don't have to work on this and somebody else creates amazing touring. What I want to see
Speaker: It is a community which is healthy, a community in which great things are happening, a community in which more people are contributing to the tooling, so I can go back to writing toy closure applications.
Speaker: and having fun instead of thinking how to please everyone and not break shit while doing so. Because I think that many of the things that we end up doing in the open source community, we end up doing out of necessity.
Speaker: I guess I was going to make some deep and profound point, but I forgot about it. Then you have to come back for another episode and then that episode should end with the deep and profound. I would like to invite everybody listening to join me and the other people working on closure tooling.
Speaker: We can build something better for all of you together. I think that we should raise the profile of this issue, try to get a few more people involved and
Speaker: then Closier would be a much, much more pleasant language to work with. Because if Java can be made pleasant, then imagine what can be done with a language like Closier. That's a fair comment, I think. That's a deep and profound thing. Yes. I agree.
Speaker: Anyway, so I think that's it from our side for episode number 37. I think this is like a natural next season of Deaf and episodes started with a bang, I think. We are very excited to have you on this on this podcast.
Speaker: And hopefully more and more people will understand the difficulties and then the tooling will only get better. Of course, I mean, it's amazing already. I'm not an ELISP guy, so I don't understand much of the code that is running inside CIDR, but maybe one more. The ELISP is beautiful.
Speaker: I hear you. I'm pretty sure it is, but I'm not that good with that stuff because I only do some customizations with Emacs myself and that's pretty much my level. I just stopped there. But yeah, I mean, it's been a pleasure. And hopefully we'll see more and more people contributing to tools and these difficulties where we are talking in most of the episodes about these things again and again.
Speaker: So we'll get rich at some point, I think. I mean, like, we don't get rich by writing closure, but hopefully we'll get rich icky on the on the podcast. And then maybe I think we'll be able to ask some questions and then get get his opinion on that as well.
Speaker: Thanks for all your work and we hope that there is not going to be another list that is going to steal you away from Amazing Closure community. So fingers crossed. Fingers crossed. And that's it from us. Thank you. Thank you. It was a pleasure to be here. Absolutely fantastic. Cheers.
Speaker: It would be nice to be discussing all of this with beers or proper British cider. I'm still drinking again, so... I could have a zero out, hold on, maybe. Fine by me.
