Become a Creator today!Start creating today - Share your story with the world!
Start for free
00:00:00
00:00:01
#58 - An "Assum" Easter Episode with Erik
65 Plays6 years ago
We chat up with Assum guest - Erik Assum to talk about maintainable Clojure, rock-climbing and more!
Erik's Talk: https://youtu.be/Tq7r97G4b7Y and his OSS is on https://github.com/slipset
Enjoy!
Recommended
Transcript
Introduction and Guest Humor
00:00:16
Speaker
Welcome to DeafN, episode number 58-ish, I think. We took a bit of a break willingly, and we thought there was enough of DeafN already, but then we realized there is not enough of DeafN already, so we're gonna get back to
00:00:35
Speaker
recording a nice episode for everybody who is staying safe and healthy and staying at home in this strange times. And we decided we're going to get an awesome guest, literally. So we looked for, how do we spell awesome in Norwegian? It turned out to be A-S-S-U-M, I guess. So welcome to Deaf and Eric. Eric, awesome.
00:00:58
Speaker
Thank you. It is a real honor and privilege to be here. I'm sad for the program though, because you've had like important and brilliant people before. And I guess now it's just going downhill since you have to reach out to me. No, no, that's... I mean, there were a couple of episodes where there were no guests, so that was our low point already.
00:01:22
Speaker
completely, you know, levels and levels, you know, we've set the bar incredibly low for this show. Okay, good. So I mean, you know, in fairness, you're just about clearing Eric, but you know, yeah.
Eric's Programming Background
00:01:40
Speaker
So maybe I think it's good to have a quick introduction about what you're doing right now, Eric.
00:01:49
Speaker
Yeah, so I'm a programmer at a Norwegian company called Artok and I've been there for two and a half years and been programming since 95, I think, professionally. That's 1995 life for, you know, for the young people. Oh, I mean, I was thinking 1895 or 1795 because I'm used to race time period, you know.
00:02:19
Speaker
Yeah, so, but the thing is that I think I look upon myself as a fairly normal programmer, like nothing special. And that's why I'm a little bit confused why I'm here. I mean, why you are here as in why you're in Norway or?
00:02:42
Speaker
No, why am I on the different podcasts? It's like you've had Zach Tillman, you've had Stuart Halloway and these people that are super brilliant, and then you have me working as a programmer in Norway and would probably rather be rock climbing or something.
00:03:00
Speaker
Yeah, but it's okay, though, because I think the point about the point about our program is that you don't come on here and code, you come on here and talk. And we've both talked to you plenty, Eric, and we know you can do that. So you already pointed out that we only invite brilliant guests onto the podcast. So, you know,
00:03:21
Speaker
Previously, previously, before they made us. No, no, that's not true. So I think maybe we can start with something that's more recent. And you gave a really nice talk at Close Your D,
Dynamic Languages and Naming Challenges
00:03:33
Speaker
Eric. It was really, how do you say that? You're putting your knowledge out there. And maybe it's instead of me paraphrasing and then bullshitting my way through that one, it would be nice if you can talk about what you talked about at Close Your D.
00:03:50
Speaker
Yeah, so I have a colleague who said that he wants to find this big problem that he wants to work on and solve. And I think that the thing that I'm really interested in is writing, like, what is good code? What is good code? How do you write good code? And that's one of the reasons I wanted to work professionally with Clojure is that
00:04:22
Speaker
It seemed like a fun tool for writing your own little toy programs, but does it scale when you were several developers working with it over time? The talk that I gave at ClosureD was some of the observations that I've done that when you work in a dynamic language where you don't have to name that many things, what are the pitfalls you can fall into?
00:04:48
Speaker
What are the things that you might do if you program in Java where you have to name everything that you should maybe bring over closure even though you don't have to name everything.
00:05:01
Speaker
Yeah. And because I mean, obviously it's almost 25 years of coding. Yeah. So what was the journey? Because obviously the lessons that you're putting into closure programming are from different, building different sorts of systems over the
Programming Evolution: Perl to Java
00:05:22
Speaker
years, right? Yeah. So I started out work, started out working in OCC. Oh yeah. Okay.
00:05:31
Speaker
Yeah, my my education is in Simula, which is sort of the first object oriented programming. If you don't listen to Alan Kay. Yeah. And then I got a summer job doing some stuff in OCC, which was basically just text transformation. And from there, it was easy to transform into web development, because at the time it was done in Perl. Yeah. And
00:06:00
Speaker
In the early days of web, there was a lot of sort of not so interesting stuff to do. So I amused myself with trying to write more obfuscated Perl code, which is, you know, not so hard, but, uh, you can write it even more, um, ugly or dense. And I found that one of the reasons I, or one of the things that I really liked about Perl was you could explore the language.
00:06:27
Speaker
It's like many different ways to do some things, which when I came to Java, it felt like boring. It's just one way to do things. And you have to write a lot of stuff to get that stuff done. And I remember
00:06:45
Speaker
from starting out in Java, it was like, why do I need these classes, these objects? I have maps and lists. That's what you use in Perl, right? And why do you have to tell the compiler that the thing is a string, but when the compiler knows it's a string, it's just a lot of stuff that I found really hard with Java.
00:07:09
Speaker
Yeah, I think one of the things about things like Ork and Perl as well is that the feedback loop is incredibly tight, isn't it? You know, just like any kind of shell interpreted programming. You know, you write a script and... It was built to get stuff done, whereas I felt Java was not. Yeah. It was like, eventually in Java, you could get stuff done, but I mean, I can still not read the contents of a file into a variable in Java.
00:07:39
Speaker
I think that's a funny characteristic observation, though, because I think C, for example, is not as verbose as Java, but the feedback loop isn't as quick, especially when you get into C, C++, the compile, linting, the compile, and then the linking, then the linting, then you run your program. I think there are plenty of languages that get things done that don't have immediate feedback loops.
00:08:08
Speaker
But it is painful though. But I think Java is designed to get things done, but it's just, it's designed to get things done in what they consider to be a safe way. I think that's the sort of value proposition, if you like, of Java is that what we will give you is an environment that is safe to run on different platforms.
00:08:31
Speaker
Yeah, but I think Java's value proposition is more towards the businesses and the enterprises than it is to the programmer. It's not fun to program in Java, but if you have one Java programmer, you can just exchange it for another one. It's safe.
00:08:51
Speaker
It became like that, right? Maybe initially Java was fun probably with maybe 1.2, 1.1, or maybe 1.5 level. Yeah, exactly. And then later, I think with the Java EE stuff came in and then I think the whole fancy stuff started. And it's really funky that we have Java EE and then J2EE and then
00:09:18
Speaker
Uh, the book, uh, uh, what was the book about, um, uh, effective, no, no, not effective job currency. Uh, no, the other book by, um, the guy who, uh, that kickstart the Ruby on rail sort of movement. So they had this, uh, no, I mean, he made the Ruby on rails, but there was a book, uh, that, uh, started spring as well to lightweight Pico containers and all that stuff. And then we started going in that direction and then spring became like fucking bloated shit again.
00:09:47
Speaker
Yeah. But I think in the beginning though, as Ray says, uh, job was kind of cool. You had these applet things, right? You could create like animations and stuff in the browser, which you couldn't do with Pearl, right? Yeah. Well, also I think the fact that you could run Java, like I was used to running to C and C plus plus the fact that you could write Java without doing memory management was quite an advantage, you know?
00:10:15
Speaker
Yeah, but then there I came from Simula, which was garbage collected and it was object oriented. So basically when I, when I saw Java, it was like, yeah, it's, it's, uh, it's a Simula in a different language. Uh, and it's, it's got this virtual machine. And I think Jamie is a winsky wrote a really nice blog post on that, that what you brand as Java was like three different things. It was the virtual machine, which were, yes.
00:10:44
Speaker
which we're using in Clojure, then there's a standard library, and then there's a language. And I think that the virtual machine and the standard library was a good thing. Yeah, I think that's what we are exploiting, quote unquote, exploiting in Clojure and other languages as well. JVM as a technology is really, really mature and useful. And I think that's one of the
00:11:11
Speaker
But also, aren't you, aren't you like, you're glossing over the fact that, you know, a lot of the big projects and the big frameworks are written in Java. And, um, you know, without those big frameworks or those big libraries, it's actually quite difficult to do a lot of the work you want to do, you know, cause you can't always just do that in Clojure or, you know, or write it from scratch.
00:11:36
Speaker
Yeah. I don't remember who that was, but there was a recent podcast. I think someone talked about how, um, Java sort of delivered on this promise of writing or no, it was rich Hickey. Of course we had a rich Hickey lunch talk week and in one of his talks, he says that, uh, C plus plus couldn't sort of deliver on this right reusable, um, code because of memory management.
00:12:03
Speaker
So nobody could agree on who was to clear up the memory and Java delivered on that. And that's how we have this huge ecosystem of useful libraries and frameworks.
00:12:16
Speaker
Yeah, I think that makes sense. But coming from Perl, obviously, as you said, there is more than one way to do it, the Tim Tony or whatever. And I remember writing some Perl web applications. Then I switched to Java. So how was the transition for you? Was it too far in the past? Or
00:12:40
Speaker
What from? From Pearl to Java. I found it really painful. It felt like you could not get shit done. And I didn't understand why we needed all these classes. Yeah. And, uh, regexes were not a part of Java at that point. And Pearl was all regexes. Yeah. So, um, yeah, that was painful.
00:13:05
Speaker
And also the whole, like when you did web programming with Perl, it was CGI, right? It was super simple. And then suddenly you have these applications or servlet engines and you have servlets. And now why would you, at that point you had template libraries for Perl, right?
00:13:25
Speaker
Yeah, yeah, yeah. And then someone comes along and you don't even have JSP yet. You're writing servlets. So you're sitting there with a Java class and you're string concatenating HTML. Now, the one that managed to sell that is, you know, it's incredible. Yeah, that's strange times. Anyway, I mean, luckily, I think eventually JSP showed up. I mean, not a better one, but slightly more useful, I would say.
00:13:54
Speaker
Yeah, because then you had JSPs, which were like, that's like PHP, right? Because you have this, it's a class that's inside out. And you had a bunch of bad Java code intermingled with HTML code, which was also horrendous. But then tag libs came along and things became sort of usable, I think. Yeah, I think you had a lot of templates, like velocity and stuff like that, which became a lot nicer. Yeah.
00:14:23
Speaker
But at that point, we were sort of at the company that I was at there, we had Java things that were generating lists. And then you had JSPs, which generated XML. And then we had XSL on top of that, which transformed the XML into HTML so that we had reusability all over the place, right? Beautiful. Yeah. I mean, that's kind of what the
00:14:52
Speaker
Yeah, I'd kind of forgotten about the whole XML, XSL world. Yeah. Yeah. Which in a way is kind of cool because XSL or XSLT is functional programming in a way. Yeah. Yeah. It's just done in XML. So it's really painful. Yeah, exactly. Yeah. It's like, it's like chocolate wrapped in shit, you know? It's like chocolate wrapped in shit. Yes. Nobody wants to eat it.
00:15:22
Speaker
I'm sure there are plenty of businesses running on XLE transformations. I know some of them, so that was rough. Well, I mean, to be honest, it's like a lot of this shit. It never goes away. We're using XML still.
00:15:38
Speaker
and XSLT for some security protocols like SAML still use this shit and like there are all these weird wonderful things like ASN1 that still get used in certificate creations so you know none of this shit really ever dies you know. No but then I think the problem with XML was that we were using it all over the place and it was I think it's a nice format that you can
00:16:07
Speaker
Build interfaces on top of right because it's it's declared so you know exactly what goes where so yeah But the problem was that we were hand coding this shit and hand reading it
00:16:17
Speaker
Yeah. And also for every possible type, it's just XML and then one more schema and then that gets put everywhere. I know it's a data interchange format. It's a data storage format and all the new things. Yeah. I mean, to be honest, as an interchange format, I thought XML was pretty decent, to be honest. Yeah. I mean, now we're stuck with JSON and YAML. Yeah. I actually preferred XML over JSON and YAML.
00:16:46
Speaker
I mean, I don't want to write configuration files in XML. Yeah, exactly. I think YAML is better for that. I don't want to write configuration files in JSON. No. But I think YAML is good for configuration files. I so totally disagree. OK, that's right. The thing is that... Now you know why we invited you to put us in our place, you know?
00:17:14
Speaker
You have to, uh, we have to define configuration. That's the first thing we have to do. Right. And when I say that I hate YAML it's in terms of, um, configuring, um, like Amazon stuff, AWS configuring servers and all that stuff where I think that.
00:17:33
Speaker
this declarative approach is failed because you want to be able to do this programmatically. You want to be able to store some state. You want to, you know, you want to do this enclosure. You want to program your thing. It's like, it's like a program. No, sorry. We're talking across purposes. What I mean is if I have to hand code something, I would hand code YAML rather than hand code these other things. But I completely agree with you that infrastructure should be called.
00:18:00
Speaker
Yeah. And not, um, YAML. Yes. But my bottom out into some serialized format that could be YAML or XML or just no, don't, don't give a shit really, but you know, I don't want to, I don't want to program complicated things like that in it. Yeah. For sure. It's one of the reasons I'm staying out of ops is that the tooling there is so horrendous. Oh yeah. It's a, it's, it's a fucking mess.
00:18:28
Speaker
I mean, if you, especially if you go to cloud, then it's a, you know, YAML based sheet has, you know, probably cloud formation and everything. And they have JSON based sheet as well. And then you go into Kubernetes. That's another weird crap out there. And then you have, yeah. And then you have all the Terraform stuff and then.
00:18:45
Speaker
There is some weird, weird, weird crap there. But I think there are a couple of. Well, I've got to say, I mean, I think to your point, though, Vijay, I think Terraform and HashiCorp, as a company, are actually making ops tolerable, at least. Yeah. I would say that they seem to be listening to developers and understanding what the pain points are.
00:19:13
Speaker
I've been quite impressed by the HashiCorp tools to be honest and we use them for various configuration things at work and I think they're pretty good. They also take a kind of semi-immutable approach as well. If you think about what
00:19:35
Speaker
what kind of reacted to the DOM, Terraform sort of does to your infrastructure. Now you don't always want that to happen to your infrastructure. And that's a pain in the ass when you want to do something else. But this notion of having a declarative model that you say, you know, I want my infrastructure to look like this. And it essentially does a diff and makes it happen. Yeah, it applies to changes and it's keeping the state somewhere remote. But the problem for me is sort of what
00:20:05
Speaker
what the language you're coding and looks like it's not it's not at all elegant it looks it looks like we tried to do this declarative thing and then we need it for loops oh yeah yeah yeah absolutely and then yeah yeah soon as things get cheering complete you've got problems here
00:20:22
Speaker
But actually, by the way, on that point, I think we were, myself and Vijay were at a conference recently, Fostem, we were looking at this thing called Quix, or Geeks. Geeks. G-U-I-X. G-U-I-X. Yeah, Geeks. Geeks, which is a kind of scheme version of Nix.
00:20:45
Speaker
And this kind of concept of immutable infrastructure is gaining ground. That could be something that could be interesting for you, Eric, because then it really is kind of proper FP. You can think about your entire operating system as sort of disposable, one shot things that you really do just
00:21:09
Speaker
that you create once and then throw away. It's problematic for stateful things, like databases. But for many things, it's quite nice. And it's less so. It's much nicer. Yeah. So how did you get into closure then, Eric? Well, that's a couple of years ago in 2013, I guess. I was working on a Java Spring project.
00:21:40
Speaker
sort of getting interested into functional programming. And I bought a couple of books on Scala and a couple of books on Clojure. And at the time, I thought Scala was the thing to do. But then I saw this talk by Boudel Stocka, a fellow Norwegian. She's living in London now.
00:22:02
Speaker
Yeah. And she basically during this talk, uh, coded up a full CRUD application in a hundred lines of closure and with, with templates and everything. And it's like, I was on my day job, that would have been a thousand lines of code. And then I got the possibility to do a side project and basically I couldn't be.
00:22:28
Speaker
arsed with Scala's syntax. So I figured I'll try, I'll try Clojure instead. And it basically got me to where I want it to be. But are you following Bodo into the typed language? Come on.
Clojure's Simplicity vs Java's Complexity
00:22:47
Speaker
So are you following Bodil into typed adventures as well? I remember I think she moved into Haskell a bit and then Rust a bit as well. Yeah. No, I'm not following her there. I sort of fell off in Closureland. But what's kind of interesting is that a lot of the things that I found nice with Closure was that you get stuff done, which is kind of easy, but not simple.
00:23:18
Speaker
So you have this, uh, like you can slurp things from a file, right? Yeah. Uh, this is easy. It's not simple. Whereas Java has, uh, input streams and buffered readers and whatnot, which is simple, but not easy. Yeah. And you have the, the bean library for, or the bean function for, uh, for closure, which lets you read, um, Java bean. This is also easy.
00:23:47
Speaker
But maybe not simple. So I got into closure for all the easy stuff. And I guess I stuck here for the simplicity. Nicely put, yeah. So one of the things that I think in the beginning you're talking about the scaling up closure to multiple teams, et cetera. So how big is your team and how are you handling that? Because this has been one of the
00:24:15
Speaker
discussion points everywhere. And then like, oh, you know, dynamic languages, they can't scale and it's difficult to maintain large code basis. Yeah. So we have a fairly, fairly simple product implemented in a fairly difficult way, if you will. So we have some 40,000 lines of production code, which has been written over since 2013. So over seven years.
00:24:47
Speaker
with a fairly stable bunch of people. Started out with the founder. He wrote like a lot for the first two, three years. Then we got one more on board. Then I came and then now we're four more. So we're about seven on backend. Okay.
00:25:09
Speaker
And then the whole application is a closure, closure script or? No, it's closure and then it's a JavaScript on the front end. Okay. And why JavaScript? Because there were two founders, one on the back, one on the front end and the one on the front and he knew JavaScript. That makes sense. Yeah. So now they're converting all their stuff to TypeScript and that's sort of when I stopped contributing to the front end.
00:25:41
Speaker
So there was no push for, oh, you know, we have all this closure and it makes sense to have closure script in the front end. No, we have a little piece written in closure script as well, but that's a side thing. Okay. Yeah. So it seems this is sort of not a critique of my current colleagues, but a critique of programmers in general is that we seem to be very sort of complacent
00:26:09
Speaker
It's like, oh, I know this stuff. I know my Java. Why should I change? It's not that bad. So trying to show people a better way of working is futile. But it is really tricky, right? Because
00:26:27
Speaker
Let's not go quite that far, though, Eric. Let's stop the wrist slashing at this point. I don't think all hope is not lost. But I think one of the problems with selling ClosureScript, to be totally honest, is that it depends on the people you're selling it to. And it depends on the problem you're addressing and all these other things.
00:26:55
Speaker
Yeah, and I think it's like the tooling might be, and I'm not talking about just compiling Clojure, but like all the tricks and all the trivia that you know about CSS and know about JavaScript and you know about the libraries. Exactly. Then you don't exactly know how to solve these problems. You don't know how to use ClojureScript in anger. Yeah. And especially if you've already got like a fairly complicated application on the front end,
00:27:23
Speaker
the prospect of porting that over the closure script without any, it depends on what you perceive to be the actual value to the business and the value to your ability to deliver that business. Because JavaScript's dynamic, you can do things quite quickly. You know, people, they're not always looking for the most perfect solution. They're looking for a practical solution. So if you've got a thousand or 10,000 lines of JavaScript,
00:27:53
Speaker
the cost of porting that could be quite high. So I don't blame people for not doing it. No, but I find that colleagues that work in, or friends that work in Scala, and they're sort of introduced Scala in a company where a lot of people do Java and they're not interested. It's like, oh, I have to learn something new.
00:28:21
Speaker
Yeah, yeah. There is a balance, right? Because when you're trying to solve a problem, there is a balance between, okay, I know all this stuff and that can solve these problems because it's proven that it can solve the problems. And now I don't know anything about this new shit. And then now I have to figure out everything.
00:28:41
Speaker
And I don't even know whether it is going to solve my problem in the same way or not. So I think for the Greenfield projects, it makes more sense because you can just start off and then it's easier to start a new technology. But if you want to port something, it's it's mental. I've been working on a bunch of Java programs or Java projects where I wanted to convert to, you know, earlier I wanted to convert Scala and later to Clojure. Yeah. And it's
00:29:09
Speaker
It is not something that really makes sense to me. If it's only me, then it's fine, but there's a team. So the team has to want to do this and the team has to be motivated to learn Closure or Scala or whatever. And your application has to be written in such a way that you can actually start rewriting it because it doesn't
00:29:33
Speaker
And that's something that's gonna have to be done over a long period of time. So you have to be able to bite off small chunks, rewrite that and then continue because if you have an app of like 50,000 lines of code, then it doesn't make sense to stop shop and re implement it in whatever other language. Yeah.
00:29:52
Speaker
I mean, you have to be really suffering. That's the point. Yeah, you have to be really suffering with that, you know, with like you're completely unable to deliver any new functions or you're finding bugs. Things are failing left and right. You know, I think that those are the kind of motivations that make people change.
00:30:09
Speaker
I would, I don't think people, I think there are a lot of nine to five programmers for sure, who, you know, who don't give a shit what language they're programming, just want their money. And that's, that's fair enough, by the way, it's okay. Yeah. There's nothing wrong with it. No, I mean, it's a job, you know? Yeah, yeah. They're just, they're just punching out code for someone, you know, for some big cooperation. So fine, you know, let them do their work, you know. But I think if you're kind of like passionate about a particular, like,
00:30:40
Speaker
beauty or elegance in a programming language or a programming environment. And I think that's what makes you come to functional programming in general, isn't it? But a lot of people don't understand what the, sorry. That's when you start putting everything to arc. Yes. You can really get shit done. Exactly. Yeah.
00:31:03
Speaker
But I think the reason why these days my stupid brain starts to think in terms of a more managerial perspective, because I've been managing people for some years now, I think the whole idea of, OK, let's introduce new technology.
Adoption of New Technologies
00:31:18
Speaker
I think the whole idea is function of three different things for me, the people who are working in the team and that one, and then technology. And then third one is the business context. So the whole change is a function of all these three. And I can't just change one thing and expect that it's going to work. If I introduce a new technology, people are going to fucking leave. That's it. They're like, okay, I don't like the shit I'm leaving. Yeah. And that's a problem.
00:31:46
Speaker
And sort of our line of work is that I jokingly say that probably even in these Corona times, I can have 13 new jobs tomorrow, right? So if someone does something that I really don't like, I can just leave. So you have to be really careful with that. But flipping that over is that I think for us having closure as our language has given us a lot of smart people that we otherwise wouldn't have gotten. Yeah.
00:32:14
Speaker
And we're competing in a very, very small pool of other companies for these developers, right? If you hire for Java, then you're competing with everyone. Yeah. And of course, the business context makes sense as well. For some business context, obviously, Clojure is not going to be suitable.
00:32:34
Speaker
depending on where you are and depending on what type of problem that you're solving. Obviously, we want to close it everywhere, but there are some domains that they're not there yet or there is not enough libraries or whatever. It's always a tricky balance. That's also something that I try to stress when I present my views on closure and my experiences is that I work in web development.
00:33:05
Speaker
I have continuous integration. I have continuous deployments. I'm a rebel away from production. I have my build pipeline so I can get a fix from like commit to being in production is two minutes. So there's a total difference from that and shipping CDs to, I don't know, Mars or something. Yeah, sure.
00:33:32
Speaker
That's a, that's so speaking of, um, because you said, you know, closed script, uh, tooling and everything, you know, it's a, it's a bit of a difference between audit or a gap between closure tooling and closure script tooling. So, uh, Emacs or some other shit? Uh, Emacs. Okay. And, uh, there was sort of, there was a dark period in my life. I started out, Emacs was my first editor. That was what we were taught at the university.
00:34:01
Speaker
And the coding Perl in Emacs is obvious. Yeah. Um, coding Java in Emacs is not so obvious, even though there were some efforts. So at some point in time, I said, I will never, uh, work in a language where there was no decent ID. Yeah. Right. So I switched to, I used Eclipse for a long time. And then,
00:34:26
Speaker
Coming back to closure, it's like, yes, now I have Emacs again. And it's like, I will never work in a language where I have to have an IDE to work. The funny thing is actually I've got completely the opposite experience because maybe it's because I don't know Emacs very well.
00:34:45
Speaker
Um, I used, I used, um, I think that's the problem. Yeah, but I, yeah, it was like left and right for me. It was like VI or Emacs and I went by because, but you know, that Emacs is the superior one there. Yeah. Well, I think to be honest, I was, it was a practicality. I mean, for me, it was, uh, I could always use VI even when I logged into any system that I logged into, I could use VI.
00:35:12
Speaker
didn't have to install a toolchain. Whereas that's the problem with Emacs. I think Emacs is like for people who want to sit in their own space and program their own environment. But if you're doing admin tasks for system admin, it costs a hundred boxes, well, Emacs is not a good place. There's no point in learning. That's how I learned BI. Yeah, exactly. Yeah.
00:35:37
Speaker
So you say that's the kind of, that's where I learned VI as well. And once you've kind of like put a year into VI or something, well, I could learn Emacs, but again, it's like one of these like complacency things, you know, why should I unlearn all this stuff? And, and.
00:35:55
Speaker
from everyone that tells me it's pretty fucking awesome. But, you know, fine. I mean, there is there is a difference between drive by editing and Formula One editing, you know, certainly a difference. So if you want to do drive by editing, like, I'm going to just jump onto the server and then remove a couple of lines and then restart the service and then go home. And then that's a drive by shift. So that's fine. The thing with with Emacs is that it makes perfect sense when you're used to REPL driven development, right? Because Emacs is a REPL. Yeah.
00:36:25
Speaker
So I was listening to Bajidhar on the REPL podcast here the other day, and it's like, how do you develop stuff in Emacs? Well, you just go into where the source is and you evaluate the new function. It's instant feedback. Then you can say that the Emacs Lisp is probably not the most beautiful language, but it's Lisp.
00:36:49
Speaker
I mean, it held up for 30 odd years, so, you know, why not? But even more, I don't know, 60s, first one. What I was going to say to you though, was that like from an exploratory perspective, IDEs are very nice. Like for instance, recently I've been doing some Go programming and C programming and also some Closure programming altogether. And I've got like three IDEs open, like all from JetBrains, like the Sea Lion, Go Land, and the IntelliJ.
00:37:19
Speaker
And it's really nice because you've got all these similar things to explore the functions, to explore the code, find the usages. There's perfect debuggers on all of these IDEs so you can trace what's going on in all languages. And I've got to say, for me, that's been really a perfect experience. But I think you get some of that. I'm not saying you get it as good. I will admit that.
00:37:45
Speaker
but the language modes for Emacs are quite, they're quite similar. Now, I must admit that find usages in cursive is really, really good. And even though Emacs has or CIDR has now something similar, I don't trust it. So when I want to figure out where a symbol is used, I can either grep or I can use IntelliJ.
00:38:15
Speaker
Recursive orking. I still do that occasionally, you know.
00:38:25
Speaker
Because I think cursive and intelligent has the MPI thing, like there is semantic model behind it, which makes it easier to walk through the code. I mean, it's very nice across these different languages to have a very similar experience. And it's very powerful. So I agree. I think if you're very familiar with Emacs, it's great. But I would just say that, you know, fuck you. But on that note, though,
00:38:53
Speaker
I think that one thing that's really interesting is the work that, uh, uh, Petter Stromberg has done on Kalva for, for reach. Uh, and also I, I'm really happy to see the, the work that, uh, Bojidar is putting into the org orchard. So, and he, and the way that he's sort of taken the custom code that is.
00:39:19
Speaker
Specific for emacs and he pulls it back into these libraries that are usable for for the whole Community is just that's software development as it should have been done. Yeah, definitely Yeah, and I remember Stuart Halloway was saying that you know, you don't write lining in plugins Write libraries and then write plugins for those libraries. Hmm
00:39:48
Speaker
And that's basically what, uh, budget R is doing now is pulling these specific things and then making libraries out of them. Yeah. So that the N REPL middleware becomes really, really thin and it's just a connector into, um, into the interesting bits.
00:40:04
Speaker
Yeah, I've used the completions library from Orchard in a repel that I wrote. And it's fantastic. It's great that you can do completions in a bespoke repel. Yeah.
00:40:21
Speaker
So it's been, I mean, because we are talking about different libraries and people, you know, contributing to different stuff. So it's been almost seven plus years in closure for you already, right, Eric?
Appreciation for Clojure Community
00:40:33
Speaker
2013? Yeah. So what is your experience with the community or the good and not so good things in the closure world? The good and not so good things is that I'm trapped.
00:40:51
Speaker
Um, I have a really hard time seeing myself working outside of this community and outside of this language because I sort of feel at home and I feel it's possible to contribute. Um, whereas in Java, it's too big in JavaScript. It's also too big. It's like you're just, I can have a conversation on Slack or on Twitter with Alex Miller, right? Uh, yeah.
00:41:21
Speaker
Uh, that's harder to do that with Brian guts. I don't know where his lack is. Um, and I think that there's a couple of years ago when in the closure community, there was like almost an uprising that cognitive tech is not listening to us and, um, all that stuff. But I think they brought their point across.
00:41:48
Speaker
Um, they do the core of the language and unlike, uh, other languages in closure, you are, you're, you're, um, it's possible to write your stuff on top of what core gives. And that's sort of one of the value propositions of, of a list. And I think one of the reasons, one of the things that I sort of created was, uh, the speculative thing. Yeah.
00:42:16
Speaker
So someone was creating or complaining on Twitter that, oh, there should be specs for, for the closure of core comp function. Right. Yeah. Yeah. And then, you know, why don't, well, if you want that, why don't we just set up and make it. And the interesting bit was that I think there's a handful of contributors to that. Yeah. So people like to complain about stuff not being there, but they're not so eager to contribute maybe.
00:42:45
Speaker
Yeah. Maybe it's a good idea to just tell us what spec is and what speculative is. Yeah. So ClosureSpec is, what is that? It's something that replaces schema. I think you don't need to tell us what spec is. I think most of the people listening will know what spec is. Maybe it's not speculative. So speculative was just a collection or is a collection of specs for the core functions in Closure. Yeah.
00:43:15
Speaker
Uh, so that now, um, Michelle Bortent has, uh, I mangled his name, I guess, uh, he's taken over that project. Uh, but it's basically just specs for map for filter for the most used, uh, core functions. So now you can basically run your program or your tests with spec and you can get to know if you call the core functions wrongly.
00:43:42
Speaker
Yeah. But do you spec in your production code base or your company code? Yeah, we do. We have spec, we have schema, and we have CLJ schema. So we have like three generations of spec tools. Okay. So you're on spec two or spec one? Spec one. Oh, okay. Spec two even out yet? Yeah, it's out. You saw that on 1st of April on Slack, didn't you?
00:44:12
Speaker
There was like three, I think. Yeah, it's like three. Yeah. Yeah. That was hilarious. So for, we also used, um, spec tools from a Tosin quite a bit. Um, but we've moved a little bit away from that now. And we wrote at our doc, we wrote our own little.
00:44:38
Speaker
piece of spec tools to do swagger generation for, uh, for composure. Yeah. Where the spec tools thing did too much for us. Yeah. So your backend is mostly API. So it really has more synergy there. I think. Yeah. Okay. Nice. So, uh, yeah, go ahead. No, no, go ahead. Sorry.
00:45:02
Speaker
So one of the things that we kind of like and don't like about closure or about spec is that it's open. So I like to think of it that spec is sort of data interface, whereas schema is more like data classes, right? Because in schema, if you try to pass more data than the schema says, then it blows up. Yeah. That's really annoying until it isn't. Yeah.
00:45:33
Speaker
because it stops you from storing the whole of Wikipedia in your database. But when you want to add one more key, you have to update the schemas, and that's also annoying. Yeah, this is the thing about required, like a kind of a view into the data that you're processing in that function in specs, right? You can do optional, only part of the data. The thing is that if you have a spec that says that you have a required key,
00:46:02
Speaker
which is an int and you have an optional key, another optional key, which is a string. Then if you pass those two, then they have to perform to the spec, right? Yeah. But nothing stops you from sending a bunch of other keys that nobody talks about. Yeah. Yeah. So it will, it will accept the data that doesn't have specs. Yeah. Yeah. Which is nice. Uh, but it also means you can't use it to sort of stop getting data into your database that you don't want there. Yeah.
00:46:32
Speaker
Oh, I mean, if you have a database, then obviously a database will have some sort of a schema, right? That is going to... Well, you could think so. Kind of block you. But MongoDB doesn't have... MongoDB. Oh, you have. Yeah. I mean, I said database. I mean... Sorry, my fault. Yeah.
00:46:50
Speaker
No, but I think, I think what you're saying is, I mean, uh, clearly you can, you could, you could write, um, maybe see you, you've even done this, write something yourself to, to police that interface. But what you're saying is that you can't leverage spec for that. And that's a shame. Yeah. Or that's not what spec was designed to do. Yeah. Sure. Yeah. I mean, it's designed for a certain reason, but I think as far as I know, like if you were a closure trailer, Alex was saying that, um,
00:47:22
Speaker
Although they want open by default, they're going to provide some tooling in the upcoming version of spec that will, that will offer you the ability to say only a certain set of keys must be passed. And so I think they have listened to people in that respect because they know that.
00:47:39
Speaker
You know, there are some APIs, for example, that will only accept the limited range of keys. So even if the maybes don't want that in their closure interfaces, they accept that there are some existing interfaces out there that will not tolerate that kind of open key space. Yeah, but I think it's interesting from like, if you look at how your code base, your internal code base becomes when you use spec, it's
00:48:07
Speaker
you program against interfaces, which is really nice, right? You say that, oh, the thing that I'm passing here has these keys, but it might have a lot of other stuff that I don't care about. And I think that makes it possible to evolve the code base over time so that not everyone has to know about all the data that's passing through the system. It's like with
00:48:34
Speaker
If the internet had to know, like the protocols had to know about every little bit and piece of data that's passing through it doesn't, it wouldn't have worked. But you have a protocol that says that, you know, a TCP thing is this and a payload. But it depends on the domain as well, right? Because the keys are probably representative of the domain. And if the domain doesn't change that much, then you can actually
00:48:59
Speaker
restrict what you're passing or pre-design. This is how it is going to be. Yeah, but there is a function called select keys, you know. Yeah, I know. But it exists and it's existed for quite a long time. So if that's what you really want, just do that, you know. Yeah.
Dynamic Typing Debate
00:49:20
Speaker
And that's a thing that I've seen in sort of in a, there's a conference here in Oslo called a flat map, which is basically a statically typed, um, functional programming, uh, conference. And what I see is that they argue for functional or for static typing. And they're saying that, Oh, I changed this one thing here. And I see like, I get a ton of red things over there. And my compiler says that, um, this is not going to work. Right.
00:49:48
Speaker
But to me, that indicates that there's a design problem because you shouldn't like changing one thing over here shouldn't give you a hundred errors over there. Yeah. Yeah. I mean, it makes it very brittle. I mean, that, that, that is the, the fundamental problem with these very kind of complicated type systems is that they're sort of magical and they do, they can do great things, but you're right.
00:50:16
Speaker
They constrain you and concretize your implementation. Quite kind of. And I think, again, maybe in certain domains, that's really important. In medical equipment or something, or certain types of environments where you want to be 100% sure, or you want to have mathematical proof that this thing is correct, then maybe that's OK.
00:50:46
Speaker
Yeah. And I think that's one of the things that one of my problems with functional or with, with the dynamic languages is that I feel that I have to defend the usage of dynamic language or dynamic types, right? Because I'm choosing away some sort of security measure. I was thinking about it from, from a climbing perspective. It's like I'm choosing to climb without a rope because I don't fall.
00:51:18
Speaker
Such climbers exist, I think. Oh, they do. They do. Not many, probably. Free climbing is quite popular, I think. Since I'm a climber myself, free climbing is climbing with a rope, but not using other things than the rocks to get yourself up. Oh, right. OK. In comparison to aid climbing. What's the other one, sorry? Aid climbing.
00:51:45
Speaker
when you put stuff into the rock and you pull yourself up on those things. What's the one where you don't have any ropes then? That's free solo. Okay. Okay. Yeah. Now we know. Now you know. So there's this movie free solo. Oh yeah. Isn't the guy got into an accident and then he died, right? No, no, no, no. I think that's a different guy.
00:52:14
Speaker
Okay, yeah. And I think none of the guys that really been on film actually fell down. Oh, okay. Yeah. Is this the guy who was going through the Catalina or something that the big super flat things in the US? Yeah, El Capitan. Yeah, sorry, El Capitan. I'm just picking some Mac operating system. Probably now, I don't know. Is this the guy who claimed Mountain Leopard? Oh, maybe.
00:52:45
Speaker
It has a mountain in it. So when did you start climbing a long time ago? Yeah, before I started programming. So I started climbing when I was 17 or 18, which is late now, but that was sort of halfway early at that point.
00:53:09
Speaker
Okay. And what is the, I don't know, levels, grades, whatever that you crossed already? Is it like skiing? Like the black ones are difficult and... Well, and outside there's grades and they normally we use sport climbing grades or at least what I do. And they go from three to, I think we're up to 9B or something now. And I stopped at 8B.
00:53:39
Speaker
Wow. So you can do that Tom Cruise move in the Mission Impossible thing. I would think so. Yes. Yeah. Nice. You could be a chimney sweep. I probably could be. It's not all else. You know, if the closure thing doesn't work out. Exactly.
00:54:03
Speaker
Anyway, back, can we just go back to your, your talking closure? Yeah. What's wrong with climbing? I'm completely unqualified to talk about climbing and neither are you. Well, I'm completely unqualified to talk about closure as well. So, you know, I have equal. Fair enough. Yeah. Okay. So, so climbing and closure, because they're all, they're starting with CL, I guess. Yes, exactly.
00:54:33
Speaker
You plan this thing since the 90s. 80s, actually. Oh, sorry. 80s, yeah. All right. So, Ray, you're talking about ClosureD. Yeah, you asked the question right at the beginning about the topic of the talk at ClosureD. And I don't know if you've already covered it or whether we should now bring that round to it. Yeah, so we can bring that back.
00:55:02
Speaker
Basically, it was a list of things that I think are important if you want to write maintainable closure. OK. Well, let's have an argument about that then. Yeah. Yeah. I always like these manifestos that people make, you know? So let's get it going. Yeah. So I started out with an article from Eric Raymond.
00:55:32
Speaker
took up on his podcast, which was stratified design by Abelson assessment and where they go about and they talk about how if you want to write maintainable software, it has to be somewhat more general than what the specs are saying because things are going to involve. So you're going to have to make sure that you have room to evolve. And they say that you do this by doing a stratified design.
00:56:00
Speaker
And so what is stratified design? And I think that the thing that I brought up in the talk is that, and that Eric Raymond also brought up is that we use hat maps to, to model our domains, right? Um, but as you walk down through the layers in your stratified design up at the top, you talk about a user and then you should do operations that are
00:56:29
Speaker
um, sort of relevant to the user. So if, if you're working on a user, then you can do change password, right? Uh, whereas when you go down into the layers, you're operating on maps, then a soc or dis soc are nice things. Yeah. But you shouldn't, uh, soc and dis soc on a user, like at the top level, maybe you do that inside a function, but the operations that you do on a user should be.
00:56:57
Speaker
at the user level and not at the map or seek level. Does that make sense? Of course, yeah, absolutely. I mean, you know, you kind of have different, what should we say, different degrees of, different degrees of, abstractions. Yeah, abstractions, but also I'm thinking of like, generalities, I would say, because at top, you're very specific.
00:57:26
Speaker
Yeah, it's like parochialism, isn't it? You know, at a certain point, there are parochial concerns, you know? That's a very difficult word for me. Oh, I mean, they're like local concerns. They're concerns to you in the local place that you are. Yeah. And so the next thing that I think I brought up was be careful to name things.
00:57:51
Speaker
Closure is a language where you don't have to create a user class. We have a map for that, but it might be useful still to have this user thing in your program if your program is about users. I think even more important is to name your anonymous functions.
00:58:14
Speaker
Because both in Clojure and in JavaScript, I think I see a lot of maps, some sort of anonymous function over some collection. And unless you're building like Clojure Core, then your application is probably not about mapping, filtering and reducing, but it's about the things that you map with or you reduce with or you filter with, right? So those are the things that you should name.
00:58:41
Speaker
Yeah, but this is probably similar to your first point as well, right? Because the math and filtering become like a sort of a implementation or a lower level things. Where do you draw the line there though, Eric, because, you know, one of the nice things about, you know, about functional programming is that it can be anonymous. So there, there is a kind of like,
00:59:03
Speaker
And I think Zach Telman said this, you know, that in his book, which is that if you don't have to name something, then you shouldn't name it because actually naming thing is a pain in the ass. You're kind of stuck with a name. So names can be nice sort of for debugging purposes. If you're, if you're doing like partial functions or whatever, but generally kind of naming things is a burden. So, yeah, but I would maybe as I'm missing your, your point there.
00:59:31
Speaker
Well, this point was brought up after the talk as well, I think, that in Elements of Closure, Zach Tillman says that avoid naming at all costs. No, he doesn't say that. But I would argue that if at your application layer you have problems with naming stuff, naming the operations that you do on your users, then
00:59:56
Speaker
then you don't understand your domain. No, no, that's fair enough. Yeah, that's fair. But what I really like is when you have like a threading pipeline that you don't have to say that, oh, on the one side of this thing, I take a user and then I, on the other side, I have this slightly modified user, which I have to call something because it's a class and then, you know, through the pipeline you have to call. Yeah. Yeah. Yeah. No, I think, I think everyone can kind of get on board with those, those distinctions. Yeah.
01:00:25
Speaker
But do you mainly use maps or do you reach out to some other things like records? We use maps. OK. Yeah. I mean, we have Mongo, right? Oh, yeah. So basically, it's JSON in and then as little as possible transformation and then JSON out. OK. Yeah. Because I think designing the domain. It's like the programming equivalent of the human centipede.
01:00:59
Speaker
But I think that's interesting. I mean, we have 70,000 lines of code, including tests, right? And basically all we do is we take Jason and we store Jason and we deliver Jason. Yeah. Why do you have so much code then? Um, I can tell you a couple of reasons. I think, uh, one is that we, in my sort of humble opinion, we use Mongo the wrong way.
01:01:27
Speaker
I don't think there is any right way to use Mongo. That's what I heard on the internet. I think there is. But if you try to use a document database as a relational database, you're asking for trouble. So instead of having our data sort of stored in documents, we have a bunch of relations. And then we have to do all the constraints management ourselves.
01:01:57
Speaker
And Mongo has schemas, but we're not using them. So we have to make sure that the data is correct in the application layer. At the time when we started using Mongo, Mongo didn't have aggregates, which they have today, which means that they didn't have joins. So we have to do joins in the application layer as well. Yeah, that's a lot of data moving around.
01:02:25
Speaker
Yes. So you adopted Mongo in the same way as you adopted Java basically before it was ready. Yeah, I think so. And the problem with Mongo is that it keeps getting slightly better. Yeah. So, so you're not really pushed over the edge. Exactly. It's like, Oh, now they have transactions too, right? Yeah. Yeah. So you don't have that argument either. But that means that it's really interesting how they took over the whole,
01:02:55
Speaker
kick-starting a project phase like Ruby on Rails. It's so easy to get started. So just type Mongo D and then you're ready and then you can just show whatever the thing that you like and then build the stuff up from that one. Yeah, I think Bodil's talk from Urdav there that she used Mongo as well, right? And that sort of, it's
01:03:16
Speaker
It saves you a lot of time in the beginning because you don't have to define the schema. You can just hammer stuff into the database and it's happy, which is great. But then when you sort of mature, you start paying for this because you don't know what's in the database and it just becomes a mess to clean up.
01:03:39
Speaker
Yeah. So you would say just, just, just, just so I understand it back to your point, then you've got these 70,000 lines and it's basically because you're essentially doing the work of Mongo, the work that a database should be doing or that a relational database would be doing. You're doing that in your application. Yeah. I'm not saying that we would get rid of all the code, but a lot of the code could have been done in, in the database. Yeah. Yeah.
01:04:09
Speaker
Of course, we could have written the whole thing in PL SQL as well, you know, and everything would have been in the database. Oh yeah, of course. I think one of the Oracle nine had PL SQL HTTP server. Yeah. Yeah. So you could write. Yes. Oh yeah. Like come in, you know, keep, keep, keep showing shit into, into the database itself, you know, like. Yeah. But it's also, you know, why would you want to write HTML in SQL? Well,
01:04:41
Speaker
If you're from Oracle, you really want people to do everything in the database. So you can charge, but I don't know, key-typed, whatever. They have amazing licensing policies. But to circle back to the talk a little bit, another thing that I've, so I've used a lot of examples from our code base, which is interesting because our CTO started using Clojure when he didn't really know it. So we have a lot of gems.
01:05:10
Speaker
you know, good examples of what not to do. I guess you got to be a little bit like, oh, dude, you know, I'm going to talk about this amongst the whole Closure community. I'm going to shame the shit out of you. You know, are you okay with that? I'm fine. And no, no, you are. What about him? No, he's fine. He's okay. He's given up coding. He's not coding anymore. But but that that's,
01:05:37
Speaker
That's an important thing though. Uh, he did whatever he did in best effort and they got this company off the ground and it's actually viable. Yeah. So, you know, that's, that's the thing when you do sort of retrospectives and I brought this up a little bit in the talk as well as that assume good intent. I mean, yeah, he didn't sit there and write this and I'll write this like really convoluted code because I can know he did it because that was.
01:06:05
Speaker
you know, how he thought closure was supposed to be written. Yeah. Or whatever. Sure. Yeah. Yeah. I think, you know, always, always consider the context. I think that was the key, you know, understand in which context has been written and yeah. And that's also when you do, um, you know, PRs and everything is that people generally do stuff in good, good intent and, uh, you know, be nice to each other. It's as much nicer than that one. But, but another thing that we have,
01:06:35
Speaker
in our code base is overly general functions. So functions that handle anything that you throw at it. And also overly defensive functions which check for everything. So you don't know if they're just checking for everything because they want to or because it's actually something that we can expect to happen. And that as, as a developer coming afterwards, it makes me insecure of the code. Like,
01:07:04
Speaker
When can the user be null? Can it be that at this point? Yeah. And that's where you sort of need to create boundaries within your architecture that you say, you know, on the outside here, the user can't be a null. On the inside, no, it can't be. But isn't that the one that type systems are supposed to help you with? Well, no, because what you see people do, at least in the beginning with types, so say you have something like a maybe thing, right?
01:07:34
Speaker
Yeah. And then, yeah, option type. So when people start out, it's like, Oh, if option dot has whatever it's supposed to have, then you do what you're supposed to do. Otherwise you say, uh, I don't have that. Yeah. Uh, but what you see, uh, after a while is that you should do this checking at some boundary and then all the functions inside, uh, should be, you know, I know that I have the user here.
01:08:02
Speaker
You don't send the maybe user around. Isn't that a nice thing for spec though, because like these required keys and stuff like that, um, you know, we use, we use that so we can have like, we can have confidence that yeah, these keys are required. We don't have to check things because we just do a valid on them. Just check. There is a check, but it's very little from our coding. You know, we just say, well, there has to be a valid user at this point. Otherwise we're just throwing an exception. And, you know, obviously we're assuming that.
01:08:33
Speaker
99.999 recurring percent is going to be fine. Yeah. But the thing is that, you know, down at the base, uh, say three levels down where you persist the database, you shouldn't be wondering if there is a user or not. Yeah, exactly. That should have been handled somewhat about it. But I don't think there's a problem with having a spec to say there must be, for example. No, no.
01:08:54
Speaker
I think that's the difference between Clojure and other languages because in other languages, you're forcing this at every level. So in Clojure, you have a bit of a freedom to say the outer layer because you want to be accepting everything when you're accepting, but when you're producing something, you want to be very clear on what you're producing. So I think the inner layer we can tighten up a bit. Yeah. I mean, the classic case on the outside is you might have some defaults that you'll fill in. Yeah.
01:09:22
Speaker
But you'd only be doing that every fucking way. Yeah, exactly. Yeah. But I think the thing that I brought up in the talk there is that there's a thing about protocols that you should be lenient in what you accept and strict in what you send, right? Yeah. But I think that's really nice for APIs, for external APIs, but for inside your code.
01:09:42
Speaker
inside your application, you should be fairly strict on what you accept as well. Yeah, but that's still under your control, right? Because API is suddenly an interface that you don't have any control over. For the internal API, of course, what you said makes complete sense, because you're part of the system. So you know what is happening there. Yeah. But I do find that, I mean, you know, I mean, this is one of, to me, by the way, this is one of the things where spec really, really earns its corn, is that if you, on your own internal,
01:10:12
Speaker
sort of APIs, if you spec there, you can be quite rigid with what you enforce because you know that, okay, well, you know, I'm not going to put nothing there because I don't want to completely trust that I can't be called with shit, but I can be quite rigid in what I spec and what I say must be there because I'm controlling it. So I don't need to be too fussy about, could be, couldn't be, you know, whereas I am more like that on the outside.
01:10:41
Speaker
Yeah, because I see we find that a lot from our tests. We run those either with schemas on or specs on and they catch quite a bit of things. So like you say that I'm expecting something that has this shape and it suddenly doesn't. No, we had this guy Jay on recently. We had lots of arguments with him. He was a very funny guy. I remember that. That was a great episode. Yeah.
01:11:11
Speaker
But what he said, and I really liked, I mean, I love orchestra and the sort of stuff he's doing with spec. And, you know, I've definitely adopted this approach in my own code as well. Maybe it's not at work yet, but this notion of just instrumenting everything and just taking the hit is, I think, a really good idea, actually. I think he made a really good point there that although this instrumentation is meant to be expensive, it turns out in reality,
01:11:40
Speaker
It's not that expensive. We actually had a point, like really far. So when we fetch stuff out of the database, I did spec checks on the stuff coming out of the database to see that it was actually, because we don't have a schema, right? So you have to be certain of what's there. So you have like both sides, because of MongoDB being external act of your system. Yes. So you have specs when you store stuff and specs when you pull it out.
01:12:09
Speaker
Yeah. Uh, but that was actually turning out to be quite costful for us. So on the, uh, on the sort of entities where we pull a lot of stuff from the database. You're kind of like on sitting on way on the extreme there, Eric, you know, every database access, you know? Okay. Yeah. Yeah. Yeah. And that was, that was too much.
01:12:34
Speaker
Yeah, that's fair. That's fair. Yeah. I mean, there are limits to everything, you know, you definitely found it there. Almost like, you know, harder of magnitude, more checks happening every time. Yeah. It's like, okay, I'm going to insert something into the database. I'm reading, but wait a minute. Did I get the data properly back or not? Yeah. But the thing is that we have old data as well, right? So yeah, exactly. Because you're the schema. Yeah.
01:13:04
Speaker
No, I mean we had the same, we had the similar kind of thing, but I think at that time I was writing Akka and Scala and MongoDB. It was because we didn't need any joins or anything. So we did use MongoDB, but eventually you keep evolving the document version to next versions and everything.
01:13:25
Speaker
So that made all the case classes go fucking haywire because everything is an option because when you read from the database and you know that it's not gonna be there because you fucked up, well, it was not there before in the domain before. So it was fun. So I can relate to it. But okay, so any other points?
01:13:52
Speaker
No, I think I've gotten most of the things that I wanted to talk about, but I wanted also to mention that I'm fairly lucky and privileged, working in this domain for so long. And I live in a country where you basically cannot get fired, even if you're making funny your boss's code.
01:14:18
Speaker
And, uh, even if you get fired, you're sort of on social security. And so I have like a security network around me, which is, uh, which is super important, which lets you be grumpy at work, lets you ask questions. Cause you know, question, why are we doing this? So that is, uh, I understand for other people, that is not so easy, you know? Yeah.
01:14:47
Speaker
That's an interesting point. I mean, I don't think, uh, well, I got fired as well. So I know, uh, how it feels like asking some questions and then they're like, pack your shit and then go home. And yeah, I think that's code. And I think everyone at a certain point, you do get fired. I mean, I've been fired for asking questions, but you know, I think the, um, you're, you're right in general, that it is a kind of privilege space. Really. You know, if you're a programmer these days,
01:15:17
Speaker
Um, in any country, I think, and I think you're in a kind of privileged environment. Yeah. And I think another thing that I've learned sort of over the last couple of years, and especially working in our doc with, um, uh, with our CTO is that a disagreement is basically just a thing, which means that you're not seeing where the other person is standing.
01:15:47
Speaker
So, uh, if, if I am the CTO, if we disagree, it's not because the CTO is stupid, it's because he has some other considerations. Yeah. And, uh, I feel again, there I'm privileged working with really smart people and I, people that I respect and that I know that I've thought things through, um, which is really great because then we can have disagreements and you know that when you come through these that you've actually learned something, both of us. Yeah.
01:16:17
Speaker
Yeah, I've got to say, one of the things that I do find a little bit annoying in some of the discussions we have with programmers is that they say, oh, these these fucking idiots have done this. They've done that. They're all man. They're so dumb. They've done this and this and that.
01:16:32
Speaker
You know, I often push back and say, well, you know, people often take shortcuts for good reasons. You know, you might not like that shortcut. It might not be the most perfect answer, but think about why these people have making these shortcuts. They're making their shortcuts because it's probably the only way they can actually deliver something or get something done because they're getting pressure from their bosses to, you know, to make something work.
01:16:58
Speaker
they're storing passwords in a database, they're not salting it or whatever, but that doesn't matter to them. They've been told they have to deliver something and they don't have to have everything completely finished in a perfect way. That's a bad example, but it does happen. Some people are all about just delivering things.
01:17:23
Speaker
because that's what their project managers want. That's what that's what they need. That's what the deadlines are. That's maybe it's their wages depend on it. So people are under pressure to do these things, you know, even if it's not the smartest thing in the world. So you have to sometimes understand why people are doing things not necessarily. And I don't think I don't think they're always good intentioned either. I think sometimes people just do it because they have to. Yeah. Yeah. But I think it's also like,
01:17:52
Speaker
Again, I'm not scared of losing my job, right? So I can argue that we have to spend some more time and we have to solve these passwords. Whereas if you're scared shitless of losing your job and that's the only way that you get health insurance, then, you know, you store those passwords.
01:18:12
Speaker
I think that's a really good point because, as you said, I mean, you live in a, in a, in a, in a environment and context in a country where you have this safety net around you that gives you a little bit more opportunity to, to actually show your courage or, you know, be
01:18:32
Speaker
more inquisitive or be asked questions or because in the other places, I'm in both sides. I manage a team and then this so-called psychological safety that you can just say, fuck you Vijay, it's pretty okay in my team. You can say that and you can complain about my code, there's no problem. But even though you say so many things, if I work with a group of people who are coming from
01:19:00
Speaker
a country like India, for example, where I'm from. And there is no fucking way you can say no to anything, to your boss. And there is this stereotypical idea of Indian programmers just do this, waving their heads and saying yes to everything. That is because there is no other fucking way. If you say, no, you're going to lose your job. But here, because I've been living in the Netherlands for 10 years now,
01:19:28
Speaker
that touch being direct and everything because there is a certain safety net and equality among people once you step out of the office. So that gives you way more freedom to say what you want to say. So I totally get your point. Yeah. But I think also it's important there to be tactful, you know, and I think it's like there's stuff at work that I might not agree to.
01:19:54
Speaker
Yeah, like go implement this thing here and I say why would I want to implement that and then It's on me to sort of it's both on me and my manager if you will to to get the understanding of why this is important because Nobody's asking me to do this feature because they think it's fun. It is because we have like an idea of this being important Yeah, yeah, and that's both on me as a programmer to understand or just to get that understanding But also on my manager to give me that understanding I think Yeah, yeah
01:20:25
Speaker
I think it all brings down to like a code should most of the time have a purpose that is serving some sort of a problem, solving a problem or having a purpose. And sometimes, yeah, code is just code. You just have fun and then do whatever you like. There is time for those kind of things as well. Yeah, that's a really nice start. So I was thinking, you know, what do you think that is,
01:20:52
Speaker
not so good stuff, but I think it feels like I don't want to end on that one. Because you've been so kind and then you explain some of the nice things that I want to leave it at the
01:21:08
Speaker
at a higher note rather than, I mean, we are pretty much used to complaining about shit all the time. That's what we do. So you're breaking the tradition at deaf end. But I think these are trying times for people around the world anyway. And the kindness should be at every level, at work, at life and everything.
01:21:37
Speaker
And I hope everybody is staying safe. And I mean, luckily all three of us are in a pretty decent countries. Yeah. And I think it's important. We're, as we started out, Ray and I were talking a little bit prior to the show and a lot of people are now starting to work from home, right? Yeah.
01:21:58
Speaker
And we have to realize that this, this is not normal distributed work. I have three extremely well-behaved kids running around the house. So I get to work, um, eight hours a day, even so their home, but other people are living in smaller apartments with, uh, I don't know, uh, more busy kids. Yeah.
01:22:21
Speaker
Um, and do you have to realize that your productivity is going to drop in these, uh, in these situations? And I hope as companies that we can see past like these couple of weeks, um, and give people some benefit of, of doubt when the productivity drops a little bit. Yeah. I think there's also, like you say, Rick, I mean, you know, there is, there's stress external externalities, what you want to call it, um, but stressful kind of aspects to this thing.
01:22:52
Speaker
in Europe where, you know, where we tend to have like more safety nets than they have in, in places like India, even places like the US, which is, you know, a shocking place really. I mean, you know, the world is becoming revealed as the sort of, you know, either kind of a nice place to survive a pandemic or not a nice place to survive a pandemic. We're lucky to be in a relatively safe place, you know, all three of us. So, um,
01:23:22
Speaker
So yeah, definitely we, you know, my heart goes out to people that are feeling stress, um, cause they have to work at home. Maybe it's in, maybe it's even in bigger houses or, you know, big or small apartments, but if they're suddenly feeling like, wow, you know, this whole economy is just grinding to a halt. Um, and what do I do? You know, if I get ill.
01:23:45
Speaker
Yeah. This is the thing that really worries me about, um, about countries where there's none of these kinds of, um, privileges. Cause they, they're even scared to go out and call that doctor or go to the hospital because they can't, they can't even afford it. Yeah. And you can't even afford staying away from work if you're sick because then you get fired.
01:24:09
Speaker
And if that is not a good context for productive work, you know, anyway, um, on that happy note, let's, but I think you're right. I think what Eric said was right, which is like, we have to be kind to each other and think you echoed it as well. Vijay, you know, let's be sympathetic to our colleagues and, um, and kind to each other in these difficult moments. Um, understanding of the stress that we're all in.
01:24:40
Speaker
Yeah, so I think all is well when it ends well. And everything that has a beginning has an
Returning to Normality and Podcast Reflection
01:24:49
Speaker
end. So obviously, things will get normal, or whatever normality is, I think, and better. So everybody who is listening to the podcast, I think you're staying safe, washing your hands, and taking care of each other as much as you can.
01:25:06
Speaker
And for the people who are affected by it, our sympathies and our heart goes out to you. And so be kind and try to use more closure and try to have as much fun as you can. And we hope to bring back the normal times where we can have more
01:25:32
Speaker
of our stupidity delivered to you in our podcast. I think there's been a decent portion of stupidity this time. You know, obviously Eric's brought the good stuff, but we've brought the stupidity. We tried, we tried, yeah. We tried to deliver on our stupidity direct to your podcasting. It's been a good talk. And I think that, as I said, my biggest problem with Closure is that I'm stuck with it.
01:26:03
Speaker
Which is a good thing. There are worse things to be stuck in, like awkward programming. I mean, you know, the ultimate first world problem. Yeah, exactly.
Farewell and Listener Engagement
01:26:18
Speaker
Okay, on that bombshell, we'd like to say goodbye and we'll be back soon, hopefully in a couple of weeks again. Stay safe and enjoy.
01:26:31
Speaker
Thank you for listening to this episode of DeafN and the awesome vegetarian music on the track is Melon Hamburger by Pizzeri and the show's audio is mixed by Wouter Dalert. I'm pretty sure I butchered his name. Umm maybe you should insert your own name here Dalert.
01:26:49
Speaker
If you'd like to support us, please do check out our Patreon page and you can show your appreciation to all the hard work or the lack of hard work that we're doing. And you can also catch up with either Ray with me for some unexplainable reason you want to interact with us, then do check us out on Slack, Closureion Slack or Closureverse or on Zulep or just at us at Deafened Podcast on Twitter.
01:27:18
Speaker
Enjoy your day and see you in the next episode.
01:27:56
Speaker
Okay, Deaf and Credits fucking take 27 or something.