Kotlin, Pamela Hill, South Africa discussed on Talking Kotlin

Talking Kotlin


Talking Kotlin on this episode. I'm sitting down with Pamela hill, discussing coat kindness. Hi, Pamela, welcome to the show. I had he thank you. So we were just speaking before the show that you're based in South Africa. Right. So you were you work in South Africa or you work remotely or how does that work? I work in southern forgotten yuno a cryptocurrency, we have app, and we have a website, and sunsets, ticker and see company. Oh, nice. So you actually work in something that, you know what it's about as opposed to the rest of the did just talks about something they have no idea about, right? Well, I pretend that would occurrences about in it seems to be looking quite well, that's cool. Does does it involve blockchain as well? Okay, an does it involve Kotlin, so act is a Java Khatun hybrid. But our blockchain staff is out in written a gun and our website in anger, sir. It's not it's not footed, the raccoons on Clifton. But we are keeping going to question. And they have been some discussions as well. Because as a really big open source project. I think it's the largest open source project, outside of cotton itself, or the stuff from Jap rains, which is called Korda, which is an open source blockchain, framework to, I don't know. I'm like, I'm totally out of blockchain I have how to even call that. But it's blockchain something something. That coordinator. Not at all. I'm. Completely android. Sir, Ivan, Judy whipped in that, right? Okay. So the blockchain is also something, I know very little about apparently my supermarket local supermarket knows more about blockchain because they have advertising on how they're using blockchain to verify where food is coming from, which is ridiculous. But anyway, but we're not going to talk about blockchain, although if I had a show that was called talking blockchain, I bet that would be successful. But will we're going to do talking Kotlin and you and I were speaking offline and one of the topics that you brought up was the concept of code kindness. Can you kind of like give a brief idea of what you meant by that? So can this is really kindness yourself more team? It's, it's mostly about readability and making a new sort of into about inter between. John cotton, making your job occurred. If you have control over, it's a little bit easier to, to work with in Cutler and the other way around while because you want to have the delicate balance between. You know, not messing up your Cortlandt too much with an attentions in things, but also making Java really easy to work with so good kindness would really be for me. Mostly about, you know, readability in harm nicely cutting support street ability. So that's sexually quite a few points. You've brought up and I think we should dive into each of them a little bit. But the first one, I want to focus on is, is something that I don't know if you're familiar with a with a gentleman called Kevin Henny. Have you heard of him? So he's written a bunch of books. He saw on the plus plus committee. I think it he put together authored or something, the ninety seven things or program should know or something. And it talks a lot about code readability in how you stuff how you write things. And one of the topics that he brings up is that there's a difference between readability and comprehension and comprehensibility a word right? Comprehensive. And, you know, a lot of times when we are talking about this, and even, like, for example, as you mentioned, you know, in keynotes, Andre was also talking about how cotton is readable, and Kevin talks about that. It's not so much that it's readable. But that is comprehensible right in that anything is readable. But it's, it's mostly about comprehending. So would you agree with this posture? I think so because I think credibility has to do with parsing. It's a let's stick before comprehension. It's you know being able able to car. The lines of curd in kind of process in your mind before getting into your brain before you actually get to the point. We understand. I mean things like. Winstons regular expressions. I mean it's difficult to read so it tends to be difficult to understand. Whereas with Caughlin it's, it's Barth, it's easy to to read, and it's nice. It, it doesn't have a lot of synthetic noise or things contracts. That might you know that are difficult to read. So it makes it easier to comprehend what the actual in taints off of the card is in the end on a gun. That's a very good point. And also kind of what, you know, Martin Fowler were used to say or said was, you know, some paraphrasing writing code that a machine can understand this, anyone can do. Right. That the big challenges writing code that a person can en- read the understand, but you bring up, yet another interesting point. Which you talk about being able to parse. Right. And this is something that I've been thinking of especially off to, you know, we talked about discussing this topic, which is, and then try and see if I can express this correctly. But how much do we have to focus on the parsing and is the parsing very important? Because you say that it's, you know, it's fundamental for me to understand the code. In order to be able to comprehend it like be able to read and parse the construct so to speak. In in order to be able to comprehend it. And what I'm asking is all we putting too much emphasis in this, and how much of that is actually kind of inherent to the language. That is being used. I mean probably a lot. But I would like to know your opinion on that. Yeah. So I think that's I mean, we grow up reading natural rang, which, so we're kind of used to parsing natural language. So when we used things like infix operators, infants. The infix modifier and so on. And we kind of construct DS Elza easy to parse easy to kind of get your head around that just makes it easier to read. Mr. Wien, sub them. I was mispronouncing. I'm sorry, I think is Subramaniam, if I'm not then he's Anki. Sorry. mR. Vinca. I think he'll be fine with it. I think like ninety percent of the people mispronounce his name. I have the most respect for him. Are he is teacher and such a Jane? Human being just a really great person anyway. So he took Subodh fluency nine richness, and how I think he talks about the fluency being it's so concise, so doesn't have the craft that, that actually takes away takes away that parsing ability that have actually read slack, natural language. So I think, you know, the car so we can get in a way that makes sense in having the change in between. You know, not making, it's so complex language designers that it actually doesn't make sense and so easy to read for developers and read right for the birds that it would actually kind of be a really good way of making card more. Both readable end compensable. Yep. So that now comes to specific construction, for example. Right. And for instance, let's, let's take this just focused now on the standard library of Kotla n-, you know, there's a lot of functions in there that are re- relatively easy to on the stunned. I mean you read the name of the functioning, you know what it does. Right. So it you could say that it's a very aligned with the English language, so to speak. Right. And so if I read filter, a list on a on a series of conditions then I know essentially, I know what that does. Right. Because I comprehend the concept of filtering. And if you give me a collection, and you give me a condition, I can kind of put, you know, one on one on one together because there's three things are so not to into, but very, very, very, very lame joke, but no mind, put all of those together and pretty. Deduce. What exactly is happening? Right. And that is based on, you know, having functions that are easy to understand and easy to follow. So from that perspective, I completely agree that it's like it's important to have very little barriers in the language and try and make it as simple as possible. So that is comprehensible, right. But then take the standard library again. And you have a whole bunch of other functions that a lot of people are using such as let apply Ron with etc. And you know I've seen endless discussions on should I use let or should I use apply. Should I use Ronald should I use what and is this because we are using non. I mean I'm big terms or not very well, defined terms for these, you know functions. That supposedly in a language that is meant to get rid of all of this, additional syntax and barriers for people to actually on understand what's happening. I'm honest, I was looking at, you know, Nate supply use them on a regular basis. Especially in apply. But sometimes, I think you, you because you don't know us some of them, like run will so on the often you'd actually NAR. So I agree with you in full ter-. And I agree with you that perhaps the Senate live Landry. That the any clause. Mitha names would perhaps not that well-named icon really think of anything bits but I they is a lot of confusion about those, those Mason names differently, and they're super useful in. It's actually sad. When people done on the standing would don't use them probably. But as you know, there's a lot of documentation out there that eases it a little bit. But you actually want to, to have things be so obvious in a way that, that you don't need the documentation on is that there's a line of obvious rights, and because this is related to to something else that I wanna talk about, which is, you know, the comprehension, I guess readability is a little bit subjective. But focusing back on this, what is obvious? Like yes, as most of us that are writing code. I guess the majority of us have certain level of dominance of English so anything that we align. With English language. It kind of feels obvious. Right. Because we all know what a filter does, right? We, we pull Water Filter and it filters out the particles. So you get a collection and you, you tell it to filter out something, and it's gonna fill to those things out. But then apply run map. Okay. If you're familiar with it. If you've used it, this makes you code very comprehensible. But if you haven't, then it's not so comprehensible. Right. And you start to end up a little bit trying to understand or decipher what the function is doing in autonomous down. What exactly is going on? Right. So now you have to dive into the function to figure out what function is doing. I'm say, okay. Well, this is badly named but then, you know I've been talking a lot about functional programming. And I talk about things like you know, beyond filter, you have flabby have map, you have either you have option. You have try you have all of these data types that the majority of people that haven't done functional programming may not be familiar with and the keyword there being familiar. So do we? Do we use these constructs? I mean, is it just a question of, you know, because a lot of people come back to me, and they said, this looks really cool. But if I start to use his constructs in my code people don't understand it very well. Right. They need to now on the stand. What all of these functions do once they doggedly they get it. But where did you draw that line of, of what is obvious? And what is not just juicy what I'm saying? Yeah. So I was like she thinking yesterday on, I did a course in two thousand twelve on functional program with professor Martineau Dashti was a it was Christine goose, and I remember struggling struggling with with understanding functional programming. I mean, I think they comes appoint week. We kind of all been away where we. We learn what full-timer and fled map and so on is just becomes part of a regular programmers vocabulary, sir. Maybe you know, it's, it's something that we kind of learn girl the late apply with him, so on. It's just it's a needs to become part of the caulking programmers vocabulary, rather than, you know, having to token, change the language too much that yet dozen. But sold the then goes back to the whole of phase of like, then we should move away from doing things that are very much aligned with English will the natural language, and move towards more domain specific languages, which you could say that functional programming is a domain specific language for. Functional programs in a way. Right. So if I talk about friends since, you know, in Kotlin, I have the concept of infix now if used the infix operator you can very much, right? Something that looks like English. Yeah. Or if you start to do DSL's, you can start to write things that are very like commenting leash. Yes. Very split, and you could even describe your domain in, in a in a language that would feel at times that you're just basically constructing English sentences. You know. Ignoring the Carly braces that you have here and there. So what do we do? Like, you know, should someone, take Kotlin and say, okay, I'm gonna make this comprehensible as possible, and I'm going to try and write out everything as a DSL, right?.

Coming up next