Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#39 - Cult member echo chamber FTW with Dmitri Sotnikov aka @yogthos
69 Plays7 years ago
#39 - Cult member echo chamber FTW with Dmitri Sotnikov aka @yogthos by defn
Recommended
Transcript
Welcome and Introductions
00:00:15
Speaker
Okay, welcome to Deafn episode number 39 with Mithri all the way from Canada. Hello. And this is Vijay from Holland and we have as usual Ray from Belgium. Hello there.
00:00:35
Speaker
So, welcome to the podcast, Dimitri.
IntelliJ vs EMACs Debate
00:00:39
Speaker
First of all, I think there are two questions from my side. One is, I think I want to start with the most important question to whether to continue this episode or not, EMACs or something else.
00:00:50
Speaker
Ah, yes. I actually use IntelliJ. That's it. I'm going to close your world now. God damn it. A friend of mine actually at work does use Emacs. He's been trying to convert me. We'll see if it happens. No promises, but I'm open.
00:01:14
Speaker
That's pretty bad. That's a really bad way of saying, oh, I know a brown friend who has a brown friend. Oh, wow. I get to say that, by the way. You know some nice white people, I guess. Exactly.
00:01:36
Speaker
I don't know if you do, actually. Believe me.
Origin of 'Yoctos'
00:01:40
Speaker
And your internet persona, what is Yoctos? I knew this would come up. It originates, I was into crafting missiles for a while.
00:01:57
Speaker
all the existential horror and so on. And, of course, all his cosmic entities have those weird and pronounceable names. And there's one that's called Yogg-Stas-Aus-Lung. And I kind of just mangled it. And then it turned out to be really handy for online handles, because it's completely unique, and nobody takes it. So every time we go to a new site, I have a handle ready. But then it also became a bit of a personal joke, because in Lovecraftian missiles,
00:02:24
Speaker
It's often, you know, the protagonist discovers some cosmic knowledge beyond human understanding and just drives them mad and people look at them like, you know, they become crazy about us from society. And it's kind of like how people view lisp often, right? It's like this weird language with weird parens and once you learn it, that's it, you're lost in the world.
00:02:45
Speaker
It's a deep story. It's not just your cat running across the keyboard or something. I thought there's going to be a bit more mundane, but this seems to be super deep. Okay. Did you discover Yoctos or Lisp first then?
00:03:02
Speaker
I actually discovered the handle first, and then I just kind of worked it into... Okay, it became the thing. It became the thing, yes. It's like, GNU is not Unix type thing. Joktos. Exactly. It's not existential horror.
Dimitri's Java Journey
00:03:18
Speaker
So how did you get into Clojure? Walk us through the history of you getting into Clojure. Yeah, sure. When I went to university, there was kind of like that standard program where it was mostly focused on being the Java factory.
00:03:31
Speaker
And they learned object-oriented programming and a lot of Java. And basically, I thought that's the way you develop software, right? You make objects and patrons and classes, and it all makes sense, and then they start working in the industry.
00:03:47
Speaker
And of course, when I was green and new, I didn't really know any better, right? And I would work in those Java projects. And I would have this feeling like, wow, this is so complicated. This is so hard, right? But I knew maybe I'm missing something. Maybe I don't understand, and there's going to be some purpose to it at some point.
00:04:04
Speaker
What did you find complicated about it, Dimitri? Because it's interesting to me what you found. What did you find that was complicated? Well, I mean, specifically with Java, it's the use of patrons, right? Like stuff like dependency injection, AOP, like the way app servers work. And then this patrons just, they're supposed to make things very generic, right? And reusable.
00:04:28
Speaker
But ultimately, when something becomes so difficult to reuse, that it's more code to reuse it and to write it from scratch, it kind of allows the purpose at that point. And that's why I find often happens with Java projects. You try to make them really generic. And by making them really generic, you create these really complex systems that can solve every problem, including the one you might have, as opposed to writing the system that solves the problem you actually have.
00:04:54
Speaker
I mean, did you actually try and use generics, for example? Because I always think of generics as a good example of something which looks fairly simple on the surface, but actually is quite complicated once you start getting into it.
00:05:08
Speaker
For sure, it's a good example that you can get a lot of complexity there. But I think in the language, if you do have a statically typed language, like Java, generics are a good idea because the alternative is something like Go, where you end up just writing the same code over and over. So this was potentially where, again, dynamic typing actually is an easy way to solve a problem without introducing mental overhead.
00:05:31
Speaker
But I think in Java, it goes far beyond generics. It's just all the patterns you have. And also the shared mutable state. It's something you don't even realize that's a problem until you use something without it. Because that's the only way you write code. It's kind of like telling a colorblind person, you never experienced color red. And they're like, well, I don't know what I miss the grade.
00:05:56
Speaker
I bit, yeah, right? And I think for me, it's just the complexity kept growing and I felt...
00:06:05
Speaker
literally exhausted working with Java. For a while, I was actually thinking of switching careers because I was not enjoying what I was doing.
Exploring Functional Programming
00:06:12
Speaker
I really felt like I was exhausted and I wasn't getting anything done. I had absolutely no time to do any side projects. I'd go to work, I'd write my code, I'd go home, and I would not want to touch the computer. I would not want to write code. After a while, I started thinking about it. I was like, okay, what are other people doing? This can't be the only way you solve problems.
00:06:35
Speaker
And the other thing that was on my mind was the fact that kind of like Moore's law is kind of PGM grade. And we started moving towards multi-core architectures. And I knew I was not smart enough to write multi-threaded code in the imperative language.
00:06:51
Speaker
with threads and mutexes and locking. Like, you know, I can manage two threads, maybe three, but that's it, right? So if you're looking at the world where multicores are going to be the norm and you have like, you know, eight, 16, 32 cores. Did you ever read the Java concurrency in practice book? Because that is like, that's what Rich Hickey reckons was the kind of motivation for him to write the language.
00:07:20
Speaker
I mean, it's been years, but yeah, I think I've read that one and a few others, right? And I was like, I realized, you know, this is something like I want to be able to do. And I just like, I couldn't practically see myself doing it. I just, I'm not smart enough to do that. Like people who are kudos to them, but it's not me. And I was like, yeah, like right at game motivation to look, is there other approaches to deal with concurrency? And the first actually functional language I looked at was Haskell. Like I did kind of like a bit of a review.
00:07:49
Speaker
and Haskell seemed to be the most pure, the most functional one. I was like, okay, you know what? I might as well dive into it. And I really enjoyed it, right? Because it was a real learning exercise. All of a sudden, I wasn't just kind of like learning new syntax or learning some new libraries or APIs. I was really learning to code in a different way. And it was like a mix of being frustrating and enjoyable because on the one hand, you kind of have to throw at everything you know
00:08:16
Speaker
and just start from scratch. But on the other hand, it's a really rewarding experience because you're really learning something new. And once you spend some time with it, you really realize the value of that approach, right? And like, Haskell completely sold me on functional programming. And for a while on static typing as well, actually, to be honest, like, I was one of those people telling people that, you know, like, types are the solution to all your problems, you know, it compiles, it runs, and so on. I've been there, I've done that.
00:08:44
Speaker
I've since gained a bit more nuanced perspective on another. We've got it here, guys. We've got it in one tip saying this. I have changed my perspective. And you know what? I don't think static typing is not valuable. I do think it has its own value and I think it has its trade-offs.
00:09:07
Speaker
And my main issue with the way static typing is presented is not with people advocating for it and saying it's valuable. That's perfectly legit. My issue was saying that my way is a highway, right? That's like if you're not using types, you're being unethical, or you're being lazy. Because we don't have any evidence for that.
00:09:26
Speaker
And just before we go there, let's just like you, you were talking to Haskell, you were preaching the benefits. What changed your mind about that to bring you closure? OK, yeah, that's actually a good segue,
Clojure over Scala
00:09:38
Speaker
right? Because so what happened was I used Haskell. I kind of like I liked it. But I also realized, you know, realistically, I wouldn't be able to use Haskell for work.
00:09:47
Speaker
And JVM is what I'm familiar with, and I'd like to keep working with a JVM. So my options were basically Scala or Closure. And I kind of played with Boss for a while, but what I kept finding was that... It was kind of funny, because originally I was like, ugh, parens. It's just so many parens. And especially coming from Haskell, where you have like no parens, right? I was like, wow.
00:10:07
Speaker
Well this is ugly but at the same time like playing with both scull enclosure what i found was i kept constantly looking things up in scull like every time i open the editor i have to google and figure out how to do something and after using for a few months i still be doing that meanwhile was closure code that just wasn't happening.
00:10:26
Speaker
Part of it was the fact that I had the REPL, and anytime I was confused, I could just run the code and see what it's doing. But the other part was there was just the syntax was so simple and regular. That was a light bulb going off in my head, realizing that you can have this stupidly simple syntax that's extremely expressive and extremely flexible. All these benefits that you get from structural editing, being able to serialize it easily, being able to use macros on it,
00:10:55
Speaker
And you don't think about the language. The more I used closures, the more I realized I was thinking about the problems I was solving, not the language. And that meant I could use that brainpower I was using to think about types, about syntax, about all the different ways you could do things in a particular language to actually focus on other things, on things that was of interest to me. And language kind of became incidental.
00:11:21
Speaker
And I think that's the biggest value of closure for me, is that it's incidental to me. I don't think about closure when I work with closure. I think about my problems.
00:11:30
Speaker
And Closure is very small and gets us away. So given that now we have this new languages coming on JVM, for example, I see a lot of tweets around about ETA, the Haskell on JVM. So what do you think about that kind of approach? Because you say JVM is the biggest reason why, because of the familiarity, because of the libraries and all the stuff available. So what do you think of these kind of languages, or at least ETA?
00:11:56
Speaker
No, I think they're interesting. I think it is a really good approach, and especially considering it's able to leverage existing Haskell ecosystem. You get this language that can both leverage Haskell and Java ecosystems together, which is really neat.
00:12:10
Speaker
Right. And I just think like functional, like statically type functional languages are worth exploring. Haskell is a well-designed language. And I, you know, like given options between like Haskell and Scala, right? I definitely prefer Haskell myself. Of course. Yeah. But, but I also like languages like Elm that like taking the step back from Haskell, whereas, you know, they went with strict evaluation versus lazy. And they do think like it makes it easier to reason about.
00:12:40
Speaker
So, yeah. So how long have you been doing Closure now? About professionally, probably for about eight years. And I started using it like very early, like probably 1.0, so about pretty much since it came out.
Web Development with Clojure
00:12:56
Speaker
Like even before it became viable. And that's actually how I ended up with Luminous, right? Because when my team started using Closure, there wasn't really an established web ecosystem for Closure.
00:13:08
Speaker
And we actually ended up writing our original project that's still in production now using servlets. Because we're all familiar with the Java ecosystem when you have servlets worked. So we're like, OK, the strings thing looks kind of cool, but you know what we're doing. But eventually, we switched to ring. And we realized the effort of putting projects together was kind of non-trivial. And we wanted to have a template that worked for us. And that was the origin for a luminous template.
00:13:37
Speaker
Yeah. So because in one of the things that in the closure world is that, you know, we are, or at least the community is again, it's the frameworks and then we pick, you know, libraries together. Um, of course, first of all, I mean, luminous is amazing work. I mean, now, nowadays I don't start any project without luminous anyway. So.
00:13:56
Speaker
I just keep adding all the things everywhere. And then just even for if I want to do something, I'll just generate the template and then see how you build the template and then just pick the parts that I like. So that was very, very nice. I mean, extremely useful and extremely, I mean, beginner friendly, even for the dumb areas like me. So coming back to the luminous part, because finding the right libraries and then making sure that they're working together. So how do you feel about that?
00:14:24
Speaker
Problem enclosure. I think there's a legitimate problem rate because I kind of agree with the notion of not using frameworks and using libraries and composing them. You know, having the user having the power to just decide how they want their application to be structured. But the gaps there is unless you know the ecosystem well.
00:14:45
Speaker
You can't really do that effectively, right? So if you're a beginner and you're just coming to closure and you're like, okay, how do they build a web app? Well, you know, just go look through all those libraries, figure out which ones are still maintained, put them together and good luck.
00:14:58
Speaker
It's not really realistic, right? So we kind of need this middle ground, and I think templates do provide that, where somebody can put things together for you in a workable state, you can run it and focus on actually doing things you find interesting, and then learn things as you need them, right? Maybe you want to swap out the templates in the language or JDBC library or something, and then you kind of figure out where it's hooked up, and hopefully it's not too complicated.
00:15:21
Speaker
And go with that, right? So that does seem like a good approach to
Clojure Libraries vs Frameworks
00:15:25
Speaker
me. But I don't really see the value the frameworks provide over libraries in principle.
00:15:32
Speaker
Right, because especially in Clojure, where libraries are mostly data-driven in terms of API, it's very easy to pipe them together. Like, I get a library, I see what shape of data it returns, maybe I massage it in a trivial way and pass it to another library. And it's very easy for me to build up my application that way. Whereas when I work with a framework, I kind of have to buy into the whole opinion of the framework and how it wants me to solve the problem.
00:15:57
Speaker
And it works really well when I'm solving the problems the way the outer of the framework thinks and envision the solution. But it completely falls apart as soon as I need to step sideways, right? Because then you have this whole inversion of control happening. And I don't find that's helpful because it leads to this indirect code that's harder to reason about.
00:16:15
Speaker
But I think like we could have more higher level libraries and closer, for example, and it's just I haven't had the energy to do it in luminous, but like one example would be something like authentication. You could have a library that manages, you know.
00:16:30
Speaker
registering the user, logging in the user, doing all those things, and just initialize this with a map where you give it the routes you want to use, and then give it the functions that actually handle the specifics of authentication persistence and loading the users, and then just plug this library like a module, and off you go, right? And again, you can do this without using the framework. You can just have smarter, bigger libraries that use other libraries. So what do you think about? Because friend and buddy are meant to do these kind of things.
00:16:58
Speaker
So I think like I would love to see that, right? I think that that might be the way to move to the next level of making closure apps easier to build because it is true that the initial stage of kind of putting the little pieces together is a bit tedious, right? Because you have to do those common things every time you build a web app, you know, sets up authentication, sets up your users, sets up the database and so on.
00:17:22
Speaker
And Luminous solves some of the most painful points of that. But I think you could go a lot farther and be more opinionated. Yeah. But we do have friend and buddy, as Ray was pointing out. Right. So what do you think of those libraries? Well, actually, I use Bitey and Luminous, right? But I do find it's still a fairly low level. And it's a good example that we have a lot of these libraries that effectively do the same thing.
00:17:52
Speaker
They have slightly different APIs, and there's no fundamental difference between them. And we have a lot of that happening in the community. I would really like us to move past making the simple libraries that solve a problem that's already been solved, and start moving towards building more interesting libraries, just like ping a stack. It doesn't have to be the ideal stack.
00:18:15
Speaker
But just the stack that most people use, right? And just say, okay, that's the stack we're using. That's what's popular. Let's just accept it and move on. And not keep trying to reinvent it. I think that's a really nice argument. But the thing is that maybe this is something, of course, everything is personal opinion in this podcast. So I don't need to put that disclaimer up front. So what I find in enclosure, for example, if you see all this React,
00:18:43
Speaker
based templates, not templates, libraries. There was one library comes in and then there is like 20 other React closure script things show up. Somehow, it's a nice thing because everybody differs in a small way or something. But in the end, I think somehow,
00:19:02
Speaker
the community gravitates towards at least one thing being the thing. Otherwise, we have RAM and Quiescent or whatever. I mean, what not. There has been like 20 or 30 ways of using React and ClosureScript programs. And now pretty much everything is reagent, reframe, or at least that's what the community has settled on.
00:19:21
Speaker
So I think it does happen organically, right, that people gravitate towards a specific stack. But yeah, I don't want to discourage people from also, right, like, experiments and trying things. But I think it would be nice to have kind of this official almost stack to say, you know, like, if you're not sure and you're not trying to experiment and just want to get work done, here's what you should use, right?
00:19:41
Speaker
And the value for me in that would be that maybe we could, a lot of libraries right now are run by individuals, right? Like even Luminous is mostly individual effort by me. But I really would like to see it more driven by organizations and community, right? So you have a bigger bus factor.
00:19:59
Speaker
And then once you have this one stack that's popular and a lot of people are contributing to it, it's easier to do bug fixes, it's easier to do maintenance, and the work gets amortized across more people, right? Because it is a lot of work to maintain open source projects. And it's hard to fault people, right? Like often we kind of get upset that people abandon their project, but it's like it's a lot of work.
00:20:19
Speaker
They're doing this under a free time, usually. Isn't that the closure way, though? I mean, closure itself seems to have a bus factor of one, so every library should also. That's a joke, by the way. I know the guys do work on it, so yeah. But yeah, it's before I get the slam mails coming in. We'll never get rich, Hickey, on this podcast.
00:20:48
Speaker
But I think it is like a necessarily a problem with smaller and niche communities, right? Because we just have less resources to work with. It is what it is. But we can strive to improve.
Clojure's Evolution and Strengths
00:21:00
Speaker
I think it's the truth. I mean, to sort of Vijay's point about personal opinion, you know, I quite like the idea that the problems are never really solved, you know, because I think that they rarely are actually. And an example I sort of just thought off the top of my head is they're like,
00:21:18
Speaker
There's this whole component system thing that started with Stuart Sierra and then we have the guy from Toilets who did the mount stuff and then we've got Integrant from James Weaver and we've got various other ones and I think and what they're always trying to do is always trying to say well, where is the
00:21:40
Speaker
Where is the actual heart of the problem here where is the what is the api what are we trying how are we trying to empower users to do something that is more like i think we're still trying to find what is idiomatic. In the coach community and i think that's quite interesting that even what is really idiomatic is still just isn't really settled law yet you know.
00:22:05
Speaker
Yeah, no, I agree with that completely. And I think I've seen the change dramatically from eight years ago to now, how people use it and what people do. So there is definitely value in exploration. But at the same time, I would say just by sheer act of using Clojure, you're so far ahead of most languages.
00:22:27
Speaker
Because the language, it's true, right? Like, just by sheer act of having immutable language that's simple and consistent and has, it's very stable, it has a large ecosystem and can rely on, right? All those aspects, like, for example, if you're working with something like Node, right? Like, built in the React app is way more work than built in a reagent app.
00:22:50
Speaker
In many, many aspects, right? So just by picking closure, you're just like solving all those problems. And partially... But hey, if you use Nord, you get like a million libraries though, you know, one per every line. There is that! Not necessarily a good thing, but...
00:23:10
Speaker
But the worst part is every one of those libraries is going to be packaged differently using different tools and different testing methods. It's a song like Little Garden, right?
00:23:22
Speaker
And that's very frustrating because when you try to put those libraries together, they all do different things. And I think that's another part of Closure because in a lot of languages, they're trying to add same features as Closure. JavaScript best practices look very similar to ClosureScript best practices. But the problem is you're kind of bolting this onto existing ecosystem and language.
00:23:45
Speaker
And that means your language is getting more complex and it's getting bigger. And when you see projects, now you see lots of different styles. You can open a JavaScript library and see callbacks, promises, and the sync code all in one library. And it just shows how that library evolved over time. Whereas Closure be saying, this is how we're going to do things and being opinionated from ground up. And having all those novel ideas from the start,
00:24:14
Speaker
means the code tends to be a lot cleaner and you have a lot less decisions to make about how you're going to do things.
00:24:27
Speaker
things like JavaScript and Scala to some extent as well is that you end up with people having kind of opinions about like what is the right way to use this language and then that becomes a kind of optimized locally for those teams and then if you join that team and you happen to be more of a functional programmer than an object oriented programmer
00:24:49
Speaker
or you happen to be more of a scholar Z programmer than a standard scholar programmer, let's say, then everything kind of breaks down. Or in the JavaScript world, if you want to use a meetable JS, then you're kind of like on a small edge of the community. It's definitely not the default. Anyway, my point is that it's kind of down to developer discipline in languages, especially like JavaScript, rather than being the default like enclosure.
00:25:19
Speaker
Absolutely. And the problem with that also, even if you're not working in a team, but say you use a library from somebody, every library has its own flavor and style, making it much harder to understand how they work and how to use them effectively. Whereas with Closure, it rarely happens. I've read many libraries because the documentation is not ideal often, so you end up reading the source.
00:25:41
Speaker
And I find it's really easy to just sit down and reach for Closure Library and understand it fully, which I have trouble doing in a lot of other languages. I've literally never contributed to a single Java library, even though I use it for a decade professionally. Because every time you look at it and you're like, oh, this should be an easiest thing to fix, and you open the project and you see a million classes and you're like, yeah, I have other things to do right now.
00:26:06
Speaker
Yeah, but so if you're talking about you know of course you know there is a lot of complexity but seems like you know JavaScript became like the language where everybody can jump in and I know you know you've been of course you know you participate in a lot of discussions where you're leading a team and you're bringing up especially you bring up the idea that
00:26:30
Speaker
Closure is very easy to get started with for beginners. So how do you see the contrast between these two then for beginners? Well, I think the reason I think JavaScript is popular is just because anybody can open the browser console and start writing JavaScript. The barrier is literally zero. It's not there. You open the text editor, you open browser, off you go, right? So that obviously makes the language incredibly popular and incredibly accessible.
00:26:58
Speaker
And I would say this is the biggest barrier for closure adoption, is that it's not easy to get started with.
00:27:07
Speaker
And the caveat there is if you're starting on a team that's already using Closure, or you have somebody to mentor you who knows Closure well, it is easy to get service, because they'll just point you in the right direction, tell you what tools to use, help you out with any initial problems you have, and it can be a really great experience, right? But if you're just starting on your own and you don't know anybody who uses Closure, it's really daunting.
00:27:28
Speaker
Because even in terms of editors, your options are either Emacs or IntelliJ. Nothing else, yeah. And they're both complex. Once we learn those tools and internalize them, they're amazing professional tools. But if you just want to play around with Clojure, it's not great. It's not like popping up VS Code or Atom and off you go. And the things that make Clojure nice, like the REPL, people don't even know about them, right?
00:27:56
Speaker
Even though you have this grapple, you have this nice tool, in practice, most people don't realize they can use it, especially from the editor. So you can recompile the replications and see that it takes a minute to compile and go, it's like, this language is garbage. What am I doing? What is your program for onboarding new developers into Closure?
Onboarding with Clojure
00:28:20
Speaker
And what is that experience generally?
00:28:22
Speaker
So that's interesting, right? Because my team hires top students quite regularly. And they're straight-up universities. They've never seen Clojure before. They've rarely seen functional programming or like very superficially was maybe like, you know, a course on scheme or something. So we kind of developed a program basically where we use Clojure distill just to get them to read through on the first day.
00:28:46
Speaker
Then we get them to play around with a few workshops to do kind of like reagent apps, read some Brave Closure, and start throwing them on our projects like literally within a week or two.
00:28:57
Speaker
where we have like small bugs or something and we give it to them and they try to solve it and they make a pull request and somebody sends down with them and reviews them. We do a bit of better programming. So in general, we find it's really easy to know onboard people. Like within a couple of weeks, you can get somebody who's never seen functional programming and get them to write useful code. And caveat being that you have experienced people on team who can set them straight and help them out when they get stuck.
00:29:24
Speaker
But for a lot of applications, I think there is also a difference if you're solving problems like on foreclosure where you're trying to figure out how to do puzzles versus writing real world apps. For a lot of code, it's actually fairly straightforward. You're just moving data around from A to B and massaging it in some way. And that's like 90% of most web applications.
00:29:45
Speaker
Yeah.
Luminous Stack Overview
00:29:46
Speaker
So what is your stack generally? I mean, the kind of stack that you use. Of course, I'm pretty sure you're using Luminous everywhere. But Luminous comes with all sorts of plugins, right? Right. So we use Luminous. We use Postgres for Datastore primarily. We use Reframe on the front end. We recently actually started using Keyframe.
00:30:07
Speaker
because we find that the way it handles routing is kind of nice with the controllers, and we are using Ratchet now for routing, because it works on both client and server, so it's really nice to be able to help, especially if you're doing SPAs, it's handy. It's kind of like really nice in batteries included, so it provides the stuff like swagger out of the box, it introduces interceptors for in, which is really handy.
00:30:37
Speaker
And that's, yeah, that's basically our stack. So we actually use Lumo for deployment scripts, because we use Kubernetes. So we generate the JSON for the Kubernetes for enclosure script. And the friend from work actually recently published the open source library, called viewer, that kind of basically he extracted from the stuff you're doing for making those little scripts for driving the Kubernetes builds.
00:31:05
Speaker
We can link it maybe like in the comments later or something. So yeah, so that's basically our stack. Okay, so what is the most, most difficult thing? Because I think we bashed enough around, you know, about the error messages on this podcast. And now we have an alpha that is trying to fix some of the issues already.
Handling Errors in Clojure
00:31:25
Speaker
So what do you think of the state of that problem that we have as a, you know, as closure team?
00:31:34
Speaker
Yeah, I think it's, I definitely think it's a barrier for beginners because like first time you see a closure stack trace, it's a bit daunting.
00:31:42
Speaker
I also think you quickly realize that it's actually not that bad. Because of the immutable nature of the language and the pure functions, usually the error happens to be on a line, that's the last line of stack trace. So you just scroll down the line, even if the error is meaningless, you go to that function, look at it, and if you're writing reasonably short functions, it's pretty easy to figure out, oh, I did this, I did that.
00:32:05
Speaker
And you have the raffles, so you can try it out and see what happened, capture maybe some inputs. So I don't think it's as big of a problem as people make it out to be, but at the same time, I think it could be improved. And I'm really glad Cognizect is now taking it a bit more seriously. And it looks like we're trying to make tools for making our reports nicer. I do think spec in general, especially the concept of spec, is really great and really useful. Because I do think you should be validating your data as the edges.
00:32:33
Speaker
And spec provides a nice way to do that. And then once the data is in my business logic, I don't think I should be validating that problem. I can assume that it's already been sanitized and by the time I start doing business logic, it should be in good state. So partially structuring your applications in that way helps as well. But also, I think spec could be improved in terms of API.
00:33:02
Speaker
Because I feel it's its own language. And it's heavily, it's very macro-driven, right? Where we always talk about having everything being data-driven and closer. And spec is kind of like the open sort of that. So I find there is a bit of mental overhead in figuring out how to write specs effectively and compose them effectively. And it doesn't really represent the shape of the data, which would be my biggest complaint with spec. When I have heavily nested data structures, the specs for them don't really tell me what the data will look like.
00:33:31
Speaker
And I think that's really valuable because that's one thing I find schema does really, really well. You can look at the schema and immediately tell what the data is expected to look like.
00:33:41
Speaker
And there is a library for medicine called SpecTools that we're using at work. And it has a data spec syntax, which lets you use schema-style syntax with spec. But unfortunately, because of the nature of spec, it doesn't always compose well with actual specs, and there's some quirks you introduce. So it's kind of like improve some things, but make some things worse, so it's still not really ideal, in my opinion.
00:34:04
Speaker
Can you expand a bit on spec being a language and macro-driven things? Do you have an example in your mind that you can explain the limitation that you're facing with spec? Not anything concrete of my head, but more like if you look at the spec, just the public API for it. That's fairly large. It's a whole new set of functions you have to keep in your head.
00:34:34
Speaker
that are different from the closure core functions right ideally unlike rishi had like some of the stocks talking about that right like we said that one of the biggest advantages of closure is that you learn the standard library p.i. and i can transform any kind of data using that and you have to learn new syntaxes and rules and semantics for it but spec introduces that trade.
00:34:55
Speaker
It does have its own semantics and its own rules and its own set of functions you learn. And if you're using them day to day, it's not really a problem, right? But if you use specs sporadically, you're always going to have to come back and look into documentation for it and figure out how to do things.
00:35:10
Speaker
I think some of the words that they've used are a bit, I mean, again, it's like, it's like any opinion. But I think, I think things like spec slash cat, for instance, to say that, you know, this is some sort of array of values seems weird to me.
00:35:28
Speaker
So words like that, it's not natural, I don't see that in any other function of closure. So those are the kind of things that I kind of think are a bit weird, because I can see, like you said, you have spec and and spec or, which is, well, yeah.
00:35:49
Speaker
Okay, I see what you're doing there, you know, because you have, you know, you have to have that your own version of the ands and the ors, I guess. Bit of a shame, but okay, you have to do that. But then, Kat, where is that coming from? You know, and multi, well, multi is more obvious, because it's a multi-method. But there are there are various ones which seemed like they're a bit disconnected from the standard syntax. Yeah. And that seems just, you know,
00:36:18
Speaker
Puts me up a little bit. That's a good way to sum up the issues I have as well with some concrete examples there. And that's a problem I've never had using schema, right? Because with schema, it's all data-driven. So now, if I need to compose schemas or modify them, I just use regular closure for that.
00:36:40
Speaker
So there is no extra language to learn. And I really like, I do think you could have schema style syntax using spec semantics and getting the spec benefits. And I really would like to see like completely data driven syntax on top of spec. Like hopefully somebody like maybe like data spec and spec tools or something matures enough where you don't really see a spec. Yeah.
00:37:06
Speaker
I think that's very likely to happen, actually. I think inevitably, there's going to be some tooling on top of Spec from the community. We use those Metosyn tools as well. And obviously, those are great guys. They're doing awesome work there. But like I said, it's a work in progress. I think one of the problems for me with Spec is that
00:37:33
Speaker
We're like two years in and it's still alpha. And that's like, well, come on, guys, you know, shit, I get off the pot, you know? So I really hope with 1.10 it moves out of the alpha world into just that is spec, because there has to be some end to this alpha bullshit, you know? Yeah, no, I agree. And also, like, if it is alpha, I don't think it necessarily should have been packaged in a core.
00:37:59
Speaker
There's a dependency of the car. It would've been nice to keep it separate, and then once it's ready, they actually put it in the language. Closure has been really good about not introducing breaking changes, but this will necessarily have a breaking change when they change the namespace, and it really has to go through and change their spec from alpha to non-alpha. It almost got, I think, maybe oversold in terms of readiness, because a lot of people jumped onto it.
00:38:26
Speaker
And a lot of people are using spec now, but we don't really know how it's going to change in the future. I remember there was a comment there from Alex Miller or Rich Hickey himself that they're thinking about working spec a bit.
00:38:38
Speaker
There hasn't been any details on that. I still remember reading that they were going to make it more programmable. That definitely will help, to your point about making it more data-driven. If it's more programmable, if there are more tools to
00:38:56
Speaker
to program, like, to generate specs and stuff like that, then that would be a good chat. But again, I don't see how that's necessarily a breaking change. I mean, I think where there's a lot of criminal criminal analogy at the moment, and that's the kind of thing which is a bit annoying about quota to some extent is that, you know, like you say, why why introduce it in the core if it's alpha and you are going to break it and you're going to change things?
00:39:20
Speaker
Because it's in a lot of code now. It is really in a shit lot of code, even all of Clojure. Right. And I think, yeah, like Clojure being a lisp has this huge advantage that we can express most things in user space as libraries. We don't need to add them to the core language.
00:39:47
Speaker
And to me, if you look at most languages, after a decade of use, they end up with a lot of craft. And we talked about this earlier, that closure usage patterns have changed significantly since 1.0 till now. But the language largely stayed the same. And I think it's primarily because we have good metaprogramming. We can do things like core async or Spectre or even spec as libraries.
00:40:17
Speaker
So, and to me, that's the best of both worlds, right? Because we can try this new idea, see if it works out, people can start using it, and then we get a better idea. Now we don't have to either deprecate something in the language and force people to write their code, but we're also not affecting existing projects using this code because they can just keep using the library and they're fine, but now we can move on to something new gradually, right? And the core language, I think, should stay small and unopinionated.
00:40:44
Speaker
Right? Because if you have a small core, you can use it in many domains effectively. And you don't have to create a language that's really adaptable to every domain and sync up every possible use case for the language. People can create libraries for their use cases. And that's something that's not possible in all languages or not to the same extended list.
00:41:03
Speaker
I kind of had that, I kind of had a bit of to and fro with Alex about this on the Twitters. Because I think that spec kind of has like, there's a lot of discussion about, you know, you don't need to, I think Stuart Holloway says this quite a lot, you know, it's that you just need to write the library, you know, don't worry about it, you don't need to change the call.
00:41:25
Speaker
And my argument as well, yeah, but that's not what spec is. Spec is not just a library. Or if it is just a library, well, it's like it got a special place because it's a library which always comes with the code.
00:41:42
Speaker
So I think that if you could have that as an option where you don't depend on that, well, maybe you could put more things into these, strip out the core, strip out all this string stuff, strip out all the XML stuff, strip out loads and loads and loads of things, and have it all available via depth.edin, that's fine for me.
00:42:07
Speaker
Yeah, no, I agree with that as well, right? Like, if it's going to be in the core, I think it should be solving the problem holistically. And I definitely agree that something as fundamental as air reports and shouldn't be left up to kind of like, well, community will do it at some point, somehow, right?
00:42:22
Speaker
It's just, it's too fundamental. And yeah, if spec was released as completely separate thing from core and Cognite said, okay, here's this new idea we have, you know, it's contracts, it works with all those problems, use it and build stuff on top of it, that would be cool too. But because you are kind of recognizing that, yes, this is a problem that needs to be solved in the core language, solve it fully, right? Don't do this kind of halfway thing and go, it's like, well, community will handle it.
00:42:51
Speaker
But I think, I think cognitive is, it's like, you know, as you said, you know, if you're using closure, you're more interested in solving some domain problems.
Improving Clojure Onboarding
00:43:00
Speaker
So I think they're too busy solving domain problems to actually fix closure problems, which makes sense, you know, because the language is too good to solve other problems. So they're too busy with that one.
00:43:09
Speaker
Yeah, and I absolutely see it, right? Like, I mean, like, obviously, you know, I have no affiliation with Cognitex. So it's like I say, as a pure speculation, but my feeling is that they focus on their consulting business, right? And that makes sense, right? Their company, the new two years. So the problems they're going to address are the problems their clients have.
00:43:28
Speaker
And onboarding and user friendliness are not that problem because they're going to be working with their clients and teaching them. And that's the thing I mentioned before, like my work. Yeah, we don't have any problems onboarding people because we just sit down with them and teach them for a week and they're done and they're good.
00:43:43
Speaker
It's a big problem for growing the community at large, right? Because it needs to grow organically and it's going to be growing from people who are going to try Clojure on their own. And if their experience is poor, it becomes a really big barrier for adopting Clojure in general, right? Like I said, ClojureScript solved huge problems that are still unsolved in JavaScript.
00:44:05
Speaker
And overall, it's easier to use. It's like you're going to get your project done faster, go and see it. But if you don't know how to get started with it, you're never going to try it. So it's a moot point of that, right?
00:44:17
Speaker
Yeah, that's true. But before we get into next topic, so we've been talking a lot about specs and there is a lot of discussion between static typing versus specs, right? So where do you see the value? I mean, should we all say, you know, fuck it. And then we go to, we just wait for ETA people to finish their shit. And then at least there is a company behind it. Their product is the language. So we all switch to ETA or we should think, no, no, no, this is still the better way.
00:44:44
Speaker
I think spec, or at least gradual typing, is fundamentally a better way. And here's why. So we'll come back to the whole static typing thing, I guess. So what happens? What do types tell us? Types are primarily a tool for telling us that code is self-consistent. They're not telling us the intent of the code.
00:45:07
Speaker
And there are languages like co-create that force us to express a whole program as a specification. But you know what? At that point, your program is written in your types. And who is helping you type check that? You still have to manually read the specification and understand that it's correct, and you can have bugs in your specification. There is an insertion cert example in Idris that's about 300 lines long.
00:45:31
Speaker
Like, I can write in dynamic language in under 10 lines. And I'll have much better understanding that those 10 lines of code do exactly what I want than this formally provable 300-line proof, right? Like, a good example, another example, right, like, from math is Fermat's last theorem. I can state it really easily. I can test it for specific use cases I have really easily. But a general proof, you know, there's maybe, like, you know, a handful of people in the world who can understand it.
00:46:00
Speaker
And the proof that you can't understand has no value. And the thing with static typing is that you end up being restricted to a set of statements that the type checker can verify. And every other statement, whether it's correct or incorrect, has to be thrown out. So that's kind of the limit. You write some code for the type checker, not for the human reader. And a human reader can learn to think kind of like a type checker.
00:46:27
Speaker
But ultimately, you're not writing code for people to read at that point. And the problem is with simple examples, people always say, it's like, oh, you have type inference and HM. You never have to write types. That is not the issue. The issue is I have to structure my code in a specific way now. Like in Haskell, I can't just put a log statement somewhere in my production code. I have to design my core application around pushing the side effect to the edge that can be expressed via Monad.
00:46:54
Speaker
And that's why monads are so prevalent in Haskell as opposed to any other languages because that's the only way you can solve this problem because side effects are tracked by your type system. And there are benefits to that. They completely accept that. You get some guarantees you wouldn't get otherwise.
00:47:12
Speaker
But those guarantees come at a cost. And the cost is that now you're structuring your code in a specific way. And in cases where this makes sense, like a compiler, for example, you're probably going to structure your code the same way anyways. So there is no additional mental overhead. But in a lot of real world applications, that's not the case. And then your code becomes more convoluted. And now the compiler tells you it's self-consistent, but you don't know that it's doing what you want it to.
00:47:39
Speaker
And so it's like, well, I know it compiles. I know it runs. I'm still going to have to write tests or provide specs or do something like that to know that it's really doing what was intended. So it doesn't obviate you from that need. And I think spec provides this really nice milligram because you're literally providing a specification for what your program is meant to be doing. And by writing the specification,
00:48:09
Speaker
at top level, you're kind of guaranteeing that all the rest of the code is doing what it's supposed to. You don't need to provide a spec for each individual helper function. You just need to provide it for your API. And once you have tests and specs on your API, you have really good guarantee that your code is doing exactly what you want it to. And that's why I don't see it as a real problem in the functional language of this.
00:48:33
Speaker
Do you think that there will be an advantage to a language where we can specify the types of the boundary, but within the core, we don't need to have statically-typed system? Potentially. I mean, that's kind of where gradual typing systems try to go, right? But I think you could go in further. I really like the approach of airline dialyzer, where it's a linter, right? And what it tries to do is it looks for code that's obviously incorrect, as opposed to trying to prove that it is correct.
00:49:04
Speaker
If you think about a closure code, if you're working with immutable data, each time you do a function call and you pass some data in, you can treat it as a binding. You say I pass it on the map or a vector or whatever, and it has those values. Now I know it has those types. As I navigate down the tree, I can track those types. Whenever I use it incorrectly, I can notify the user that, hey, you had a map and you tried to do something on it.
00:49:30
Speaker
Yeah, yeah, I don't know if you've been watching Mike Fikes recently on on Twitter, but he started to put some type, you know, doing some work on type inference in closure script, where, you know, you can
00:49:45
Speaker
If you're going to do like an ink operation on a string, then he can tell you that's a failure. Right. No, that's exactly a perfect example of that. And he's done some amazing work on that regard, right? And there was a recent talk from Andrew, I forget his last name, the guy who works in CLJS time.
00:50:04
Speaker
And he talked about doing a similar kind of system as a library foreclosure. And I think that would address, honestly, 90% of annoyances with type mismatches in Clojure.
00:50:16
Speaker
Because the linter will be able to quickly tell you, hey, use this. You meant to use that. And there's going to be that maybe 10% case where it's indecidable and could either give you a warning or just leave you alone. And then you'll have your specs and tests, which ultimately I think are what's really telling you that your code is doing what you intend to trade. And there is no shortcut for that.
00:50:36
Speaker
Like, and I think that's for me at least, right? That's a real issue, right? Like, types don't tell you the code is correct and they can only help you pretty much as much as linter or just in a different way, right? They give you a different set of guarantees, but they're not guarantees about your code being correct. And I think that's a really important distinction. I think the way I look at it as well is that
00:51:03
Speaker
The joy that I get from closure is the fact that I can use the REPL. And I can just start evolving a program from some simple data structures and some simple calculations about what this thing means versus that thing. I don't need to type anything. I don't need to know what the types are or anything. I can just do it from data structures and from data and from function composition.
00:51:33
Speaker
And I think that's, arguing about types, you kind of lose this piece, you know, which is the fact that you can just program something. Because that's really the win that we have with Clojure, I think, is that you can just program something really nicely, and then you can decide whether or not it's appropriate to put some types on top later.
00:51:57
Speaker
Yeah, I absolutely agree. And like to add to that, like I find in many cases when I solve a new problem, I don't know what the solution is going to be. So I don't know what the types are because I might try different approaches. And like you said, when you try it on the repl, you can try this or try that. And I find like often I'll gain understanding of the problem by solving it. And then I might completely throw away the original solution. And now that I know what I need to do, write a completely different solution for it, right?
00:52:24
Speaker
And the types kind of, they prevent this kind of thinking, I find, right? Because now you have to think about your types first, and you formalize the thing. And now you kind of fill in the blanks, right? But if I don't know what the thing is, how can I formalize it?
00:52:39
Speaker
Yeah, this is the thing to me is like looking from a type's perspective, it's just looking at the wrong, it's like you've got the wrong end of the telescope. Right. And I mean like to do a bit of kind of like a digression, right? I also find interesting like the discussion about types. To me it almost like it feels like people are putting the card before the horse because
00:53:02
Speaker
Even in studies like there was a recent github study right like on like you know other type dynamic typing or static typing is effective. And that's already too early to have the discussion might be because what you should be really looking at let's look at a whole bunch of projects in github.
00:53:16
Speaker
compare different languages, compare large numbers of small, large, all kinds of projects, and see if you see trends. If you see statistical trends between languages. And then let's say we see that statistically Haskell projects have less defects than Java projects. People open less issues, updates come out more often, whatever. Then we can make a hypothesis and say, well, maybe the Haskell type system is what's the driving factor here. That's the difference.
00:53:42
Speaker
Then we can set up some experiments around that and say, OK, let's test those hypotheses as far as I write. But the opposite happens. People say it's like, I think types are really useful, and that's what's solving the problem. And look, now let's try to prove that types are what's solving the problem. It's circular.
00:53:58
Speaker
But I think that there has been something like this. But there has been something like that research, right? And then it was inconclusive that having types or no types are going to give you any benefit or not. Well, for sure. There's been a lot of... I think Dan Lu has a whole page of all the existing research, right? Exactly, right? It's been around for 50 years.
00:54:21
Speaker
And we still are saying, well, maybe, maybe no. At some point, you have to say, maybe if there is a difference, it can be very significant. Yeah. I think part of the problem is that it's very difficult to, because what you tend to find is that certain languages, like JavaScript, and maybe even Java as well, is that you've got a broader spread of programmer skills and programmer experience.
00:54:50
Speaker
And it's very hard to factor that in because often, you know, I mean, this is a joke about closure that you tend to get, you know, kind of more experienced programmers and Haskell. You tend to get more academic programmers, more, you know, more mathematical programmers who may be a bit stricter and
00:55:08
Speaker
you know their code may be actually better than just doing a sort of inverted commas. They might be better programmers because it's a smaller community and very self-selecting. It's very difficult to factor out those kind of human factors over the type factors.
00:55:25
Speaker
But I think by that logic, you should see even bigger difference, right? Because if you're saying more experienced programmers are using functional languages, static typing like in this language as a code should be way better than languages that are used by beginners and intermediate programmers and so on. But we're not seeing even that, right? Like even in this languages that are used by very advanced developers,
00:55:48
Speaker
who know what they're doing, we still don't see the benefits, right? Or at least not a large benefit. And I think another thing, I forgot.
00:55:58
Speaker
Like we've seen this with object orientation, right? Like it's been sold as a panacea, right? It's going to be, code is going to be reusable. We're going to reduce coupling. Like we've all heard that. Everything is natural to model those objects. And what it turns out, smart people can make things sound really, really good on paper. You can, like if you're a smart person, you can rationalize anything and make it sound great. That's why empiricism is important.
00:56:24
Speaker
If something sounds great, but it doesn't pan out to be great, we'll know empirically. But if you have those discussions around, it's like, well, on paper, this sounds really, really good and we should all just dive in and use it and forget every other approach, that can have some repercussions. And after 20 years of use of OO, we're now realizing that a lot of those benefits have been oversold or non-existent.
00:56:49
Speaker
And I feel like we have the same kind of atmosphere with static typing right now, where you cannot question the value of static typing. You're immediately considered to be ignorant, or you don't have the experience to talk about, or you just don't get it. And no, you have to come out. You're unethical. Exactly, right? You're unethical. Oh, man. Let's get into that one. Come on. Jesus Christ.
00:57:18
Speaker
Why is this happening? Why are people trolling us this badly? I feel like it's the sunk cost fallacy, right? Because to get proficient with Haskell, you have to invest a lot of time into Haskell.
00:57:31
Speaker
And once you invested all this time, it's really hard to say, well, maybe the benefits aren't great, right? Like I spend a year learning and you see it like from people literally say it, right? It's like, oh, how long have you been using Haskell? Oh yeah, that's nothing, right? Once you use it for a decade, then you start seeing benefits. It's like, really? I might not be programming in the decade. Right? So it's like, yeah, like when you make this big investment, it becomes kind of like, you know, people buy monster cables and you know, yeah, they can hear the difference.
00:57:59
Speaker
Well, yeah, but empirically, in a double flying test, maybe you can. So I think there's a bit of that happening, right? And people obviously get offended when you start suggesting that maybe those approaches and those effectibles you claim it to be. And I think, right, like my position is it's not that static typing is not effective. You're right, like maybe it is. And I'm willing to say that maybe for some people it's way more effective.
00:58:29
Speaker
But not everybody thinks the same way, not everybody works on the same domain and solves the same problems. And until we know definitively that one approach is strictly superior to the other, we could be exploring both. We should be encouraging people to build systems and languages that explore all different kinds of approaches, not just saying, okay, that's it, that's the way we're going to do things.
00:58:49
Speaker
I think the unethical thing to me is in itself an unethical approach though, because just to go meta as we like to, because I think if you say that something is unethical, then you're shutting down discussion, you're shutting down and you're basically saying, hey, all of these life support machine systems, everything that's kind of important to us should be ripped out and immediately replaced by this system that I love.
00:59:17
Speaker
Because everything else is literally against, you know, the good things that humans need. And that seems like a hell of a claim. You know, everything else is literally unethical. It literally should be torn down because it's, you know, it's offensive to human health.
00:59:39
Speaker
That seems as a hell of a claim. On no evidence, you know? Yes, right? And that's a problem, right? If there was concrete evidence to just static type and reduce defects across the board statistically significantly, right? Yeah, OK. I can buy the argument that if I'm making a medical system, maybe it is unethical for me to use something that could potentially introduce defects that I would have got otherwise. But when you have no evidence for that, that's a really wild claim, right?
01:00:08
Speaker
Yeah, yeah. I think we should go in the other direction completely. We should say something like, if you're using static typing, then you're causing global warming or shit like that. Yes, exactly. Yeah, I mean, your compilation cycles are actually causing global warming. You should use dynamic languages. So there is only one compiler running. You only run bytes of code. So save the planet, use dynamic languages for some shit like that. I think we need to start this propaganda. If using dynamic languages is unethical,
01:00:37
Speaker
But there is an interesting thing, though, because I've been working with a lot of Python code these days because of machine learning. I'm interacting with a data scientist and everybody. So I mean, it's fucking horrible. I mean, the problems that they have are magical. I mean, there is no standard tooling for dependency management. They're just waking up that, oh, we can build larger programs with Python. So let's get started with all this shit.
01:01:06
Speaker
But the same problem exists in Clojure as well, if you think about refactoring, right? So how do you cope up with that one? Because this is, let's keep the whole less bugs bullshit aside. You know, maintaining code base over the period, which is having types versus maintaining code that is like Clojure or Python. So because you've been involved with a lot of projects, so how do you see this thing play out in Clojure?
Benefits of Immutability
01:01:34
Speaker
So I think for me the biggest tool for maintaining large projects and reducing complexity has been immutability. Because if your data is immutable and your functions are pure,
01:01:50
Speaker
The scope of things you have to keep in your head to work with a particular function stays constant. As your project keeps getting bigger and bigger and bigger, if I open up a file from six months ago and look at the particular function, learning what it does takes the same amount of effort as it did when the code basically signs. But isn't that an argument for type system, though? Because then you're not type system, but probably languages like Haskell, where you are essentially forced to write pure functions.
01:02:19
Speaker
I don't think so, right? Because if you understand why you need to use a language like Haskell, you understand how to structure your code in a way where a majority of code is going to be pure. And if you don't know better, you're not going to use Haskell anyways. It's a moot point. But I do think I literally treat every namespace on a project as its own library.
01:02:43
Speaker
You don't have to split your project physically into multiple libraries. But it is helpful to think of which namespace is a small library with a small API of maybe a couple of functions at the bottom and the rest being helpers. And your whole project is structured of the small independent components that can be reasoned about individually. And you grow this bigger and bigger. And I think the idea is to try to write as much declarative code as possible, where you just have these pipelines of transformation
01:03:10
Speaker
And then you can reason about those and you don't have to reason about the details of a library. Like for example, if you take a library like CLJHTP, it has a ton of code in it, right? I don't ever worry about the code inside of a CLJHTP, I just worry about its API because I pass the data and I get data back. And that's predictable, right? And that's a boundary, right? And again, that's where you can put specs or schema or something
01:03:35
Speaker
And I find if you use this approach, growing your code bases is not really a problem enclosure, right? And this is a dramatic change from imperative dynamic language, just like Python or JavaScript, where everything's coupled via state.
01:03:50
Speaker
And at the same time, you create some types, because object-oriented languages encourage you to make a lot of types. So now you've created this problem of having a lot of types, and language isn't helping you manage it in any way. So of course, it's difficult. And I think a lot of pushback against dynamic typing comes from people who use those kind of languages, and that's their only exposure to dynamic languages. And dynamic typing is way on the bottom of a list of problems in those languages.
01:04:16
Speaker
Yeah, that's true. I'm wondering what you think. I mean, this is like maybe it's a kind of like web thing. You know, with APIs, do you think that there's a tendency in it? I mean, I've seen it myself. Anyway, there's a tendency in APIs to kind of get a bit objecty.
01:04:33
Speaker
Even in the closure world, you tend to do things like you have a client, or you have a particular service. The REST APIs tend not to be very composable. Yeah, and I think, I guess, that's almost like a natural place for those kind of objects to things to arise.
01:04:58
Speaker
I mean, people are trying to do different things with stuff like GraphQL, for example, where it's more like a query. But I don't think that's necessarily problematic at that level, because often you will... At least the code might seem the way the structure is. APIs tend to be fairly stateless.
01:05:19
Speaker
So most of the logic that deals with state and UI state specifically moves to the client, right? Because you can like in the SPA style in the reframe DB usually for us. And then we just make those service calls to do, you know, get a query, get some data. So in that sense, it's not really object-oriented because we're not keeping states on the server.
01:05:39
Speaker
But you naturally do group, I find, functions almost the same way as classes, right? Because a namespace becomes kind of like a class with all static methods in it. And it's a really nice way to think about it if you're coming from object-oriented programming.
01:05:54
Speaker
And I don't think that's necessarily wrong, right? Obviously, there is appeal to object orientation because it is popular and people find some aspects of it intuitive. So we shouldn't throw the baby out of the bathwater either. In cases where it makes sense, let's use it, right? That's fine. But in most cases, we don't really need it. And we should strive to have code that's data-driven and functional.
01:06:19
Speaker
So looking a bit into the future, so 10 years or more Java programming and then almost 10 years or almost nearly 10 years.
01:06:29
Speaker
Maybe even more, yeah, 10 years. Of course, you're not, I hope you're not writing Clojure before it's Hickey. So where do you see, I mean, are you picking up any other languages or some trends that you think that are going to be useful in the web or in the domain that you're working in? Like Rust or any other languages? It's kind of funny because I looked at other languages once in a while, but I just don't see them introducing anything fundamental.
01:06:57
Speaker
It's a different flavor, but a lot of interesting things end up in Clojure really fast. Things like core async from Go channels or reframe and reagent are good examples. A lot of the stuff gets to Clojure pretty fast, and the best part is you can do it yourself in Clojure pretty fast. A language would have to introduce something really fundamentally new for me to actually consider moving to it.
01:07:25
Speaker
And I'm just not seeing it, right? And, like, we really haven't seen it since inception of computer languages, arguably, right? Because Lambda Calculus came out pretty early on. Yeah, yeah. That's the thing. I think we're all going back to 1959s again and then writing Lisp again.
01:07:44
Speaker
So from the point of community, so what do you think about Closure?
New Clojure Book Announcement
01:07:52
Speaker
I know you're extremely active in Reddit and all sorts of places, and you wrote to almost, I think the second edition of your book is already out. Also, I have exciting news. I am working on this third edition. I'm doing a joint this time with a friend from work.
01:08:06
Speaker
So we're going to update basically everything to latest and greatest, but we're also introducing Reframe, which I didn't really talk about before. We're going to focus on Reddit instead of Composer and like a lot more talk about SPAs and hopefully Electron and React Native if we get to it. So what we'd really like to show with a new edition is that you can use Closure full stack.
01:08:30
Speaker
Literally, from shell scripting, to server-side work, to web apps, to mobile, you can just list one language and not worry about it. One ring to rule them all. That's right. One parenthesis to rule them all. Hopefully the one-percenthesis argument is coming sometime in the year next year. That's right.
01:08:53
Speaker
I don't need to because I use Emacs, so it balances automatically. We don't think about it. But is it still called web development with Clojure then? Because if you're going all the way like, I don't know, the whole stack and maybe are you going to write like list machine in Clojure and then the whole stack? Probably won't go that far, but no, I think it still makes sense, right? Because it's still going to focus mostly like on server side, client side.
01:09:19
Speaker
Like I would argue mobile apps and stuff are still kind of under purview of web development because you're using the web stack to build them ultimately, right?
01:09:27
Speaker
Yeah, yeah, yeah. Super cool, super cool. But is there any timeline or something that people can go and check, like the raw editions or whatever these people call? We're hoping to wrap things up, hopefully by end of the year. We're kind of like in chapter five, we're looking to eight to nine chapters. So we're halfway through. Scott Brown is my co-author, and he is kind of working right now on chapter five, I think, as we speak. So we're hoping to have something soon.
01:09:58
Speaker
Yeah, yeah, yeah. Like I know Primatic, they do kind of those early editions where you can buy... Yeah, something like that, yeah. Yeah, completely ready. So it's all up. I'll talk about that. Perfect. Okay, so any other topics you want to touch upon on?
01:10:18
Speaker
One quick one I'd like your opinion on actually, Dimitri, is the kind of... Something I'm excited about anyway, which is the sort of revolution that Deps.Eden is bringing. Yeah, it's interesting. On the one hand, it's a new build tool, which fractures our existing build tools.
01:10:40
Speaker
On the other hand, I do see how it reduces the barrier to entry, right? Because now you can just get closure. It will have its own way to read libraries. And if they're publishing GitHub, now you can get them without going through Maven and so on. So I just think it adds value. I'm not entirely convinced it could have been done as a lane plugin, for example. But I can see the argument the coding tech makes for why they did it the way they did it.
01:11:09
Speaker
So I guess we'll have to see. I really hope it will at least integrate with Lane at some point. And I think people have to agree more. Well, it should be around, actually. I think, Lane already, there are tools to integrate depth to Eden with line again. Right, yeah. No, that's what I mean, like driving it from line again as a plugin or something. Yeah, that's already there. There's a line against tools. Yeah. Yeah, so I think as long as it becomes kind of seamless,
01:11:36
Speaker
I think it's nice, and I do think it gives us more options. But I haven't really used it much myself, so I don't really have a strong opinion on it one way or the other. You've got to upgrade Luminous to go with the CLJ new, come on. Then we can get the latest greatest is Gitchars, and we don't need to worry about this Maven stuff.
01:12:01
Speaker
But I think in real-world projects, you're still going to be relying on JVM libraries that are enclosure rates. But you can still do that with depth.eaten. I suppose I can do that. And Viya Shahs as well. So it's no problem. So yeah, maybe what Lane should do is really just get rid of its own dependency management and just farm it out to CLJ devs. And then just be more of a build tool as opposed to dependency management tool.
01:12:30
Speaker
But I wonder how we're going to cope up with all the force pushes people are doing, you know, with these good shots everywhere. Like, that's going to be amazing. Oh, well, you know. But at least, you know, it's not like fucking Requirement.txt or some shit like that, so it's slightly better. I think using tags is probably a decent compromise. And you're going against Master, that's like YOLO. Yeah, exactly. So you have to have at least some process.
01:12:58
Speaker
I'm not sure there is a single language that is able to solve this dependency shit in a proper way. I mean, every language has the same problems. And since the pearl days are now, the only thing that you could do is basically, OK, you know, and do the and on CVS, check out the whole shit and then compile it yourself and then hope that it's going to be OK. No, it's a hard problem, right? And by the way, it's just just just to mention that if you go on, you never you never depend on master. You always depend on a particular shah.
01:13:28
Speaker
So you're never really tracking the commits. You're only ever tracking, depending on the one version of it. I mean, yes, people can overwrite it. I get that. Exactly. That's not good practice, let's say. That's not how things should work.
01:13:48
Speaker
Yeah. But yeah, I mean, I think you're right, Dimitri, right? I mean, this is a really hard problem to solve. I mean, we haven't been able to figure this shit out in any, I don't know, any language so far. Every language has its own, you know, I don't know, workarounds for maintaining your dependencies properly. Exactly.
01:14:07
Speaker
Yeah, but at least I think this is the weird part, though. I mean, we are we are so maybe I'm getting older and older. And then so, you know, everything, everything is fucking cynical now. Like, oh, you know, we can't get this shit run properly anywhere. So what I'm going to do is completely package my entire fucking computer.
01:14:28
Speaker
Exactly. So put every shit into that one and then just ship it. That's way easier than to actually solve that I can run this code anywhere I want. That is the state we are in, which is amazing. Coming from the JVM, when you look at Docker first time, you're like, oh, so we had this for decades.
01:14:47
Speaker
Yeah, exactly. It lets you Docker compose and stuff, lets you add databases and so on. But just the idea of packaging your code, like a node, like a Docker container or a node app is basically an Uber driver.
01:14:58
Speaker
Yeah. And I think people complain about Maven, but you look at every other dependency management system, like NPM, and you're like, yeah, they knew what they were doing. Stuff with NPM is like, oh, why didn't you specify a version for the library or dependent on it? I'll just depend on whatever version is available. Exactly. It's the worst idea.
01:15:20
Speaker
But the nice, nice thing, nice thing, you know, quote, unquote, nice thing, is that the proliferation of this idea is across languages. I mean, every time I go to Python, the first thing I have to do is install pyenv. So I can actually have 2.6.2, 2.6.3. What are the bullshit that is? And then the JavaScript guys started the same shit with multiple environments. And then Ruby people have the same thing. It's just crazy. I mean, it's
01:15:46
Speaker
Instead of solving the problem, they're like, oh, this is basically forked from Ruby multiple M. So we're just going to use Python compiler in it, and then we're done. So anyway. I think we need to move to things like Nixos and stuff like that.
01:16:01
Speaker
Yeah, of course. It's like that XKCD, you know, like a 15th standard. Let's bring one more standard here. Well, you can't fuck with Nixos, so that's a good thing. Yeah, that's true. That's the immutable thing. They can have that in a t-shirt for free, you know.
01:16:24
Speaker
Anyway, so, but of course, you know, we have our own problems to solve with all the dependency shit. I didn't use Jepsi Eden, by the way, so maybe that's the magical thing that's going to solve everything. I've got to say, I've been using it a lot in the last few months and I really like it.
01:16:43
Speaker
So, you know, I think I've taken the red pill, however, is the blue, whatever these pills are, I've taken one of them. I've taken the depths pill. And it really is nice. It's very enjoyable. Yeah.
01:16:59
Speaker
But isn't this going to be tricky to say, hey, which version of this library we're using? Yeah, that's FC 7994432DBBCCA bullshit. Well, I like Dimitri says, you can tag it. It's no problem. Yeah, nice thing that's going to become a bit of a best practice, right, that you're releasing. But then if somebody pushes a commit to a bug fix and gets merged, they can just start using that commit right away. And then when the tag comes up, you'll swap to the tag, which is handy. That's true.
01:17:28
Speaker
But I don't think in general, the situation we have with tooling and the language enclosure is so much better than many other languages, and especially mainstream ones.
01:17:39
Speaker
Like, for all the complaining. This is a small point there. I mean, the reason why I like depth.eater and things like that is because you don't have to run build tools. I mean, to me, I have closure. What am I building code for? I mean, I know there are some interrupt things, but fuck that. If I don't need it, why am I building anything? I don't want to build
Clojure's Stability and Adaptation
01:18:02
Speaker
anything. I just want to write my code, put it on GitHub, and then run it somewhere.
01:18:08
Speaker
Yeah, and I think... I like that. As a side effect of that too, right, is with Closure, like you're not like with Scala, like every few releases, they would break the bytecode compatibility, right? And you have to rebuild the whole world. Like the fact that we're able to package libraries is just source, and you just pull all the source in and compile it against your version of Closure, compile it in JVM, that's huge.
01:18:34
Speaker
Because it makes your language so stable. At work, we updated to JDK 10 recently from JDK 8. We haven't had to change a single line of code. We waited for Lane Engine to fix up the couple of bugs they had, a nice enclosure script compiler, and then we're just like, oh, we'll just update a couple of dependencies and done. But Java projects to this day aren't able to do that. IntelliJ still runs on JVM 8.
01:19:00
Speaker
They're not here like Spring. I know a lot of people working with stuff like Spring, right? And yeah, their companies are basically just keeping it frozen because it's too much work. And with Oracle having this aggressive update schedule every six months, using Closure, right? Like you're basically insulated from that. You know, like we just update JDK version and as long as Closure compiler runs, we're cool. Like that's amazing.
01:19:30
Speaker
So anyway, we've expanded the time limit now. Yes. I don't talk a lot. Yes.
01:19:40
Speaker
Amazing discussion, by the way. So I think we are almost at one hour, 20 minutes. Yeah, pretty much. Again, thanks a lot, Dimitri, for joining us all the way from cold Canada. Yeah, absolutely. Thanks for having me. It's insistibly warm, not that our plant is cooking. We had a 40-degree weather a couple of days ago, which is not usual for Canada.
01:20:09
Speaker
Oh, you mean 40 degrees Fahrenheit? No, no, Celsius. I wish. What, 4-0? Yeah. What the fuck? Okay. It was the hottest day I think in September in like past like 75 years or something. Okay, because I thought Canada is always in my imagination, you know, like people are drowning in snow and you know, like with seals everywhere. Yeah, but bubble warming is a thing, VJ, you know. It's happening.
01:20:35
Speaker
We know this is because of the static compilers, you know. Yes, I think I think we should start spreading these words slowly. Yes. Hashtag static compiler. Static language causing global warming. Yeah. Good point. We should like say, you forget Bitcoin. Look at static compilers. It's like we're compiled like anything that doesn't have a raffle, right? If you don't have a raffle, you're on ethical.
01:21:05
Speaker
And the worst part is writing your blockchain shit in Haskell. That is the ultimate crime. That is the next level.
01:21:17
Speaker
It's like killing dolphins or some shit.
Balancing Perspectives on Clojure
01:21:20
Speaker
I was actually thinking that in this podcast, we've been having a lot of closure people, of course, because we just want to live in our own bubble and then tell each other that everything is awesome.
01:21:39
Speaker
At some point, I was thinking, we should invite other people to basically get insulted by them or insult them. So maybe we should try that experiment at some point. Get Martin Odersky and Philip Wadler and tell them that you're the reason. The world is burning now. They're not going to show up in this podcast anyway.
01:22:00
Speaker
But what's interesting, the debate was people who are really, as long as they're willing to have an honest debate, it's interesting because you get a different perspective and different opinion. And I just want to reiterate my position too, that I have absolutely no problem with static type where people use anything that is valuable and interesting approach. Come on, don't be diplomatic. Don't do it.
01:22:27
Speaker
Don't middle ground us, you know? Come on, exactly. No, but at the same time, my experience, I personally, in like 20 years of doing development, I have not found the value of that approach, right? So when I talk with people who have, I'm curious to see, you know, get in their head and see how does
Closing Remarks and Community Support
01:22:45
Speaker
their mind work? Like what problems are they having that I haven't encountered and why?
01:22:50
Speaker
and you know why they find this value like it is interesting to me because i don't see it i don't find it obviously i write real world software and i haven't for a long time so you know show me what it is that you see that i don't see yeah but that's like talking to cult people you know so on that bombshell good luck with that
01:23:16
Speaker
We have come to the end of the episode already. Again, thanks a lot, Dimitri, for joining us. It's been a really fun conversation. Thanks a lot. For this particular cult podcast, yes.
01:23:32
Speaker
So so that's the end of episode number thirty nine of course you know that the credits you know that's with the inventory are also known as yoke so sold everywhere on the internet and he's the dynamic typing fanatic who doesn't like style typing as you heard already.
01:23:52
Speaker
And of course we are on the web and if you think we're doing decent job, we have this Patreon thing going on and we did a slight modification to our website which basically saying we're now pushing everything into SoundCloud as our website. So all the links etc should be there in the show notes on SoundCloud because we don't have time to maintain all the
01:24:15
Speaker
Multiple channel media empire that we have so we're trying to focus on one thing So if you like the podcast feel free to hit us up on on slack Closure in slack we are on deaf and podcast and you know the Twitter sun shit and everything We usually respond to people and Ray gets into arguments with them. Yeah, and it's much more fun over there Get the begging ball out as well a little bit. Yeah, I
01:24:40
Speaker
Oh, yeah. So we of course, maybe you guys should do that rather than that you do that. Yes, please. Go ahead. Yes. Ask for money. Yeah, because we are we are, you know, desperately poor closure developers. We need money.
01:24:56
Speaker
No, no, it's really nice. I mean, we've got some Patreon support, which is really good. And one of these days, we're actually going to say what we're going to do with the money. We do a little bit of money with like we have to spend money on SoundCloud and stuff like that. But I think we've actually
01:25:12
Speaker
funded water to come to a conference so that he can he's now going to be using closure. So we've, you know, we've kind of brought one on, you know, the Patreoners help to bring a new closure developer into the world, which is good. So if you want more of that, give us a dollar or two, it'd be really good.
01:25:32
Speaker
Yes, so the link will be everywhere online. So that's it from us. And so please give us money and have a nice day. And that's it. Bye.
01:26:11
Speaker
you