Karim Galil: Welcome to the Patientless Podcast. We discuss the good, the bad and the ugly about real world data and AI in clinical research. This is your host, Karim Galil, Cofounder and CEO of Mendel AI. I invite key thought leaders across the broad spectrum of believers and descenders of AI to share their experiences with actual AI and real world data initiatives.
Karim Galil: Hi everyone, welcome for another episode of our podcast. Today we have a technical guest. We were just chatting before the podcast, he actually teaches programming languages, specifically Scala. I was like a lot of our audiences never wrote code and he said okay, I’ll do my best. So we’ll try but before we get started, Daniel can you please start by introducing yourself?
Daniel Ciocîrlan: Thank you for having me first, I'm honored to be here. My name is Daniel Ciocîrlan. I am a developer software engineer and a teacher. I teach in esoteric programming language called Scala and a variety of tools and technologies based on Scala that are widely used for distributed computing and functional programming and high load systems.
And I also teach kids to code. So I am an software engineer and a teacher at heart. This is what occupies pretty much all my time now.
Karim Galil: But I see a guitar in the background. So it seems like there is also some music
Daniel Ciocîrlan: Yes
Karim Galil: in your day to day.
Daniel Ciocîrlan: I do play some guitar. I play an absurd amount of Ed Sheeran on, on guitar. I have a training platform called rock the JVM, which teaches everything in the Scala ecosystem and the naming is not coincidental. So it has some, it has something to do with with music. Yeah.
Karim Galil: with the guitar. sweet. So first of all, I'm interested, like I was looking at your profile and usually like someone who writes Scala today is, is, is a rare commodity, like hiring scholar. Engineers is super hard, like hiring good Scala engineers. Someone who teaches Scala becomes even a more rare commodity. You probably would be making a lot of money in the industry and yet you chose to go down the route of teaching kids and teaching others how to write Scala. So where's the inspiration coming from?
Daniel Ciocîrlan: Well, first of all, I started Scala where I started my journey with scholar and functional programming out of pure intellectual curiosity. I was writing mostly Java or even other front-end bits while I was employed. But in my spare time, I used to dive and play with this concepts with these concepts in functional programming and in the scholar language, which I found pretty. Pretty damn beautiful. It's the closest thing to a beautiful language that I've seen in my programming experience and the fact that it's also so powerful and that it allows you to encapsulate very abstract mathematical concepts. This just was pure intellectual pleasure for me. So I spent most of my time, most of my free time studying this and playing with it. And I also have a passion for teaching, which dates are almost 10 years now. And I wanted to combine the two because I was so passionate about this Scala and functional programming thing. And I was also passionate for teaching and for the kind of feeling that I can create in my students, when I explain a complex thing, I wanted to merge these two into what became rock the JVM. And apparently people like my work and they like my teaching style. And so I've been doing this for a while.
Karim Galil: So you said that you're teaching kids, Scala
Daniel Ciocîrlan: I'm teaching kids something else. No, not Scala
Karim Galil: so, so, what are you teaching kids?
Daniel Ciocîrlan: I am teaching kids to code with a programming tool called scratch. I'm pretty sure you've heard of it. It's this tool created by MIT, which is completely free and this allows kids to, or pretty much anyone, but it's targeted at kids and young adults to create the sort of games and applications and stories and interactions based on tools that look like legal pieces that you stitch together and you create these scripts that do something and you learn core programming concepts by putting these together and creating ever complex animations or games or applications or drawing things. So, kids learn by intuition and this is how I like to teach kids to code. And they have a lot of fun playing with the games that they made with their own two hands, which is by far, the most meaningful.
Karim Galil: Historically we, we had to learn like a language or two in school. Like two, like spoken languages, right? Like say English and French or English and German. Do you think it's like, we're heading in a future where everyone will have to have to understand some basics of coding actually as, as a way of expressing thoughts and ideas.
Daniel Ciocîrlan: I don't think computers are gonna go away anytime soon and quite the opposite. I think we are going to merge more and more with technology and technology is gonna get ever closer to our lives. And it's crucial to understand what technology is, what technology can and cannot do and how it works under the hood and I think the more people at least understand if not produce something with it. The better it is for all of us, because we have a deep understanding of the tools that we use instead of them using us without having any sort of awareness about him. them.
Karim Galil: That's an awesome point. Now that's the whole point of the podcast is like, you don't have to write code. You don't have to be an AI scientist, but you should have some sort of an understanding of how those things work at a very high level. So you're able to make like judgment calls, whether it's a good use case for, for whatever you have or whether it's a good vendor or whether it's a good path to take. So who's harder to teach kids or adults. I mean, I'm assuming you're teaching on different age groups.
Daniel Ciocîrlan: There's no one group that is easier, or harder to teach than the others. They're so different that they're almost world apart. I mean, kids learn by intuition and kids learn by immediate feedback. So if they stick a new code block in, into their scripts and they see the cat moving 10 times in a, in a circle, that's something that immediate feedback that. That they produce. And they now learn that the repeat block does something 10 times. And when you click on it, it programs the cat to do a certain thing. Whereas the experienced engineers that I teach scholar and functional programming, they learn a completely different style. So I have to deconstruct a very complex topic into its constituent parts and then select the most important bits and then sequence them along the way so that the learning curve is as sequential as possible, as smooth as possible because complex software requires complex understanding and therefore the kind of material that I produce needs to lower that barrier as much as possible and this is what I, this is what I wanna do in my R the JVM classes with that's to teach this sort of complexity that a language like scholar and technology is based on scholar can involve and make them accessible so that every developer simply can write. Three lines of code and everything happens by magic, but they deeply understand what those, those three lines do.
Karim Galil: Got it. So let's take let's use this methodology to explain to our audience like the methodology of breaking things into small components and assembling them together again, what is the difference in programming languages? Like why is it different thing to use Java versus scholar versus call versus any other type of programming language aren't at the end? Like the question folks usually have at the end of the day, when I click a button, the same action will happen. So why does it matter what programming language we're using? So I think that's the first question, like why it matters. And the second is like, what are the types of, of programming languages out there? You talked about functional programming, but what are the others and what are the differences between these things?
Daniel Ciocîrlan: Yeah. So what is a programming language? A programming language is a way to translate human thought into something that computers can execute and programming languages were invented so that we can write programs more easily because computers are essentially machines that you can plug in some bits, which are essentially currents and a processor. And the processor does something as a result it's completely predictable and it will be completely feasible to build the kind of application for podcasting that we're using right now, just by that, by putting bits in processor as manually one by one. But it would take us a million years. And so we invented some more intricate tools that allow us to build more complex applications faster and above machine code that there's assembly code, which is then broken down into the sort of instructions that computer can execute. And based on that on top of that assembly language, then we have some other more complex programming languages that compile to the sort of bites that the computer can execute. But it's easier for us as programmers to write a few lines of code instead of millions of assembly line code to do the same thing. And so languages like C or recently, C++ with its never ending stream of improvements was needed because complex software requires complex thought and the kind of approach that our thoughts needed to be broken down into bits that the computer can execute is just too tedious for us humans to accept. And so we wrote ever more complex programs to be able to express our thoughts into something that the computer can execute. Then we have these higher level languages. So on top of assembly we have compiled languages like C, then we have interpreted languages like Python. Then we have Java, which is a completely different paradigm. And then we have these higher level languages like Scala or Haskel or things of that nature. So one classification or one difference between programming languages is whether they they're compiled or they're interpreted. What does that mean? A compiled language means that you write a piece of text, which is the programming code. What is code is just text you write you type it on a keyboard. It's nothing but text, but there is a, a very smart program known as a compiler. To turn that piece of text into the stream of bits that the computer can understand and execute. And the compiler is what does most of the work and that compiler is built by years of iteration and so on and so forth. So that we as programmers, just write the, the text described by the syntax of the programming language, which is the easy part. And the compiler does the heavy work of turning that into something that the computer can understand. So that's the compiled, the compiled stuff. Then there's the interpreted languages such as Python, whereby you write some code that is not turned into computer bits by taking the source file and then turning that into an executable. But rather there's another smart program known as an interpreter that traverses the lines of code that you've written and executes those one by one. It just parses them incrementally. So for a language like Python, you can have a syntax error line, let's say 54, but in the first 53 lines of code. The Python interpreter just executes everything until it gets into some sort of error.
Karim Galil: Error
Daniel Ciocîrlan: Right.
Karim Galil: Versus in the compiled languages. If you have an error, you have an error. It's not gonna compile.
Daniel Ciocîrlan: Exactly. So in a compiled language, the executable cannot be created until the program is correctly written, following the exact rules of the programming language. So that's the one difference. Another difference is more philosophically. And I think this is the bigger, fundamental difference between programming languages. And that is the style of thinking that is applied to those programming languages. This is why we have imperative languages, such as instruction based things like C or C++, or Python or C# or Java. And there are obviously differences between all of them. After that we have other styles of thinking such as functional programming, which is like Haskel or Lisp or Closure or Scala or other programming languages that think differently. They allow you the programmer to think in different terms that is approach or translate your thoughts into code in a different way. It's like speaking another language and there are other paradigms. There are very esoteric languages, for example, Prolog or CLIPS or other programming languages that think completely differently. Like you write three lines of code and the computer tries to validate all possible solutions to a constraint satisfaction problem. So for example, if you write five lines of Prolog, the computer will try all possible solutions to the kind of restrictions that you specify. So Prolog is a language where you just write restrictions and the compiler just works around those restrictions. And the answer to those restrictions is the solution to your problem, for instance. So the style of thinking is completely different, and this is why Scala is such an amazing thing for me because the style of thinking was very much resembling my own in terms of a mathematical approach. So Scala and functional programming in general is very mathematical in nature. And because I have a background in physics right before I started learning computer science this was so fit for me because I only think in terms of expressions that needed to be evaluated. And then the run time just does its job to, compute those for me. And in three lines of code, as you've probably seen in your, company you can do a lot and this makes language like Scala extremely powerful.
Karim Galil: Let's dig into that a little bit. First of all, super helpful classification of how things work. So the story I was sharing with you before we started the podcast was like we had something written into Java into like hundreds of lines of code. And then we hire an engineer who loves Scala and he spends few weeks comes back, shows me like, hey, you see those three lines. They can do exactly what those hundreds of lines of code can do, this is Scala. This was my introduction to what Scala is right. Is like, it's the language where you can write in three lines, something that requires hundreds. The question that I don't understand till today is why, like, for example, right, in my mind, if I'm speaking, let's say English and I wanna write an essay or something around the weather and I write it in 10 lines and then I choose to write it in French, I'll probably still use 10 lines, but the idea of trimming down hundreds of lines into three is, is something that I still cannot conceive or understand.
Daniel Ciocîrlan: Yeah, that's a, that's a really good point. And this is where the, the analogy between programing languages and human languages start starts to break down because human languages are more or less equivalent. And there are fundamentally different languages, for example, Japanese versus English or European languages versus Chinese or Japanese. In the realm of European languages, you have more or less the same kind of structure. The words are different. Grammar are slightly different. You get the same kind of conceptual approach to how you can express your thoughts? Well, in programming languages, there is a possibility that you can express in a programming language, an extremely short code, what you can do in another programming language isn't like 10 times as much. And the reason is not just the structure of the language itself, but rather how you can organize your thoughts so that at the end of the day, you as programmer, you can write in a few lines, some functions or some values, or some expressions that behind the scenes involve a lot of code that do involve a lot of code. So there's no way around it. The computer will do the same thing when the computer starts to evaluate that instruction by instruction.
Karim Galil: Are you basically abstracting code into functions?
Daniel Ciocîrlan: Yes. Yeah. So you abstract complexity away into a variety of concepts, not just functions. Maybe you abstract them away in like, I dunno, operators or interfaces of various types, depending on the kind of language that you use. But the concept of a abstraction is possible in programming to almost an unlimited amount, which is what allows us to write in such short code. What, in other languages like Java, for instance, you would need to write a lot to accomplish the same thing. So it's this abstraction thing that makes programming languages in general very, very powerful. Now, obviously people can probably abstract away those hundreds of lines of Java into let's say 10 lines of Java. There's always that possibility, but the way that Scala approaches the problems, the first place makes it more susceptible or more has higher chances of having this sort of compaction that you describe
Karim Galil: So why is it called functional programming? Like what, where does that come from the functionality in, in description of Scala.
Daniel Ciocîrlan: Before programming languages were invented Alan Turing and Alonzo Church were the pioneers of the mathematical description of a computation. So these folks formally described what it meant to be computable. What means to have something that can be calculated is two plus three computable. Yes, it is. Well, how do you compute two plus three? Well, you can evaluate it at five, which is how math arithmetic works, but you can also compute two plus three by starting from two and counting by one, three times. So the fundamental difference of what it means to be computable or rather the equivalence of that is that the same expression or the same result can be computed in two ways in multiple ways. But for these folks in two different ways, Alan Turing came with a description of an algorithm, which is the sequence of steps that you need to reach your result. For example, two plus three is counting from 2, 3, 4, and 5. So you follow an algorithm like a process, like a step by step thing in order to get to your result. And Alonzo Church had a completely different approach, which is reduced expressions with their values. And this is fundamentally different mathematics. And these folks demonstrated about a hundred years ago that these two forms of computations are equivalent. So mathematically they're equivalent in the sense that a fictitious computer or a fictitious machine that would evaluate such an algorithm would take roughly the same amount of time as a fictitious computer evaluating expressions in Alonzo Church definition. So we say that in mathematical terms, these two have equivalent complexities and the mathematical models of computations are equivalent because any computation described as an algorithm can be expressed as an expression and vice versa. And Alan Turing's approach was more geared towards machines that could program step by step. So that compute numerical things step by step in algorithms. That's what his mathematical model was about. And it just turned out that computers are easier to build that way, but theoretically, at least Alonzo Church's model is just as powerful. Because it allows us to build expressions, like mathematical structures that can be evaluated to a value. And from a Alonzo Church's theory, functional programming evolved. So from Turing's approach, we have imperative programming, like step by step things from which our regular computers are built. And then from Church's approach, we have functional programming, which is thinking in terms of expressions and functions that you can pass around as the function in functional programming.
Karim Galil: Interesting. So do you need to be good in math? I mean, you need to be good in math or have some math competency to be an efficient programmer, but do you need to be relatively good at math compared to others to be a good Scala engineer?
Daniel Ciocîrlan: It's an interesting question. I think just to clear any doubt, having good skills in math doesn't hurt anyway. So. The, the more skills in math, you have the, the better usually in scholar, depending on the kind of abstractions that you want to use, certain mathematical things are probably needed or helpful. If you are a heavy functional user, which Scala is very well known for, you need a good understanding of what those abstractions mean in order to navigate around them just as you need some good algorithmic preparation to study any kind of regular code, like in Java or C or Python. We learned algorithms in school before we before we released in the world as engineers. In Scala especially if you want to do some heavier functional programming or very high level abstractions a decent, at least an interest in kind of abstractions that functional programming involves will be very, very useful.
Karim Galil: So why is it that Scala is not as predominant as Java or Python? That's one question, but the other is like, why is it the higher density of Scala engineers are Europe based compared to the US or at least that's the myth that I've heard. It's like, there is more Scala engineers in Europe per capita, basically compared to in the us.
Daniel Ciocîrlan: Okay. Let me take this, take this in turn. The popularity of Scala I think the popularity of Scala is quite minor in the JVM world and in the programming sphere in general because of its apparent complexity. Scala can be intimidated to beginners, especially if you have the kind of hacker mentality. That you wanna get something done very quickly, like you can do in Python. Scott's not very friendly with that because in order to write a good Scala program, you need a bunch of foundations in place and you need some sort of patience to understand what Scala concepts can do. Now, once you've crossed that barrier, everything is easy. And then you can write three lines of code that do the same thing as hundreds of lines as you described. But there's a, there's a mental barrier that you need to cross in order to become a productive Scala developer. And I'm pretty sure, or this is my hunch at least judging by my students is that Scala can seem quite intimidating for this reason. And this is why I think people come to me to teach them because in my, in the learning curve that I try to create. They find that Scala is not that intimidating. If you take it the right way. So just like regular programming. If you read a hundred lines of Python, if you've never heard Python before, of course, those are intimidating as well. So you need a bunch of foundations, but the trouble is that once you've learned a programming language like Java or Python, I don't know why, but I find that many people, I, I don't even wanna say most people, but many people get into the mindset of, oh, I know how to code. I don't need anything else. I know how to think code, but then you see something like Scala and it looks on a little bit alien and you go like, I don't wanna learn this thing. This doesn't look like code, or this is too hard. I know how to code. I'll use my own tool. I think one of the reasons why Scala has a pretty minor proportion of programmers. Now to answer your second question, I have no idea about stats. I don't even know how well those are distributed among the US or Europe. So I, I can't really answer that one cause I don't have the data.
Karim Galil: We have an interesting social experiment in, in, in Mandel. So as I told you, like, we, we weren't a scholarship early on and we, we basically build a lot of AI. So we have a couple of teams, an R&D team that basically is in the business of getting the model right. And then we have an engineering team that's in the business of taking that good model and actually making it a product that's scalable, repeatable and so on. And the engineering team, like the AI team is heavy on Python as every other AI team and is heavy on Java. And the engineering team was all converted into Scala and then they had this like interesting meeting where like, engineering was preaching. Like you guys need to start using Scala. Your life is gonna be easier. Our life would be easier. And they offered to teach them out of 18 engineers, only two opted into the Scala like course, and now they don't want to go back Java. They don't wanna do any other thing except Scala but to your point about the barrier of entry, it wasn't that hard. It's just like the decision to get, to know how to do it was the hard one, two out of like 18 did it. And when they did it, it became more efficient, faster. And I think it's not only about writing lesser lines of code, it's just easier to debug your code. Like whenever there is a something that's not working as, as you want it to work, rather than looking in a hundred lines, you know, you have only three that, that, that you need to to debug. Cool. So let's switch gears here. One other thing, why people who are heavy on the AI side prefer Python and kind of sway away from Scala. There seems to be like a strong disagreement or a, strong lack of desire to use specifically in the AI community.
Daniel Ciocîrlan: I can see a couple of reasons. When, when you start working in AI, you look. Not necessarily a programming language, but you look for tools that could implement what the theories that you want to bring into the world. And the programming language is not that important. At least in my case, I also played with a bit with, with some AI models. And when I looked for tools, all of them were in Python. The most popular ones were in Python. They were very well maintained. They had good documentation. They got results really quickly. So the incentive is very small to use another programming language and have whole bunch of barriers to the kind of things that you want to build. Because when you're an AI programmer, you're not the regular software engineer that builds a web application, but rather you wanna test a model into the world. So you want, you're more mathematically inclined. You want something that could embody that math into something that computer can execute. And the Python tools that we have that we currently have are the most appealing because they seem to do the job. The quickest and Python is an easy language to learn. And the barrier to entry, as we described as probably double in the field of AI or for the purpose of AI compared to regular software engineering, because the, at least the, the AI programmers that I know I can, I cannot speak for, for the entire field as I'm not that intimately familiar with it. The AI programmers that I know just want their models out. So as an AI program, or you're interested in a model more than just the more than the code itself, so you don't need high level functional abstractions or, or, or things of that nature you'd want, you want the model plug it in, hit play. Just let the, let the GPU learn the, learn the weights of your model and then just have it run predictions. So I think the the kind of habits that a language like Python would involve make it easy for Python to be the, the language of choice for, for AI. I think in terms of James Clear's Atomic Habits I think the kind of make it obvious and make it easy bits are very easily enabled by Python
Karim Galil: Yeah. The downstream of that from a business perspective, like from my position, what I look at is at the end of the day it's all about making sure that my clients are happy by getting a product that is high quality, repeatable and scalable. And even though when you have the mentality of like, I want my model to work, which I agree, like you're in, you're in experimentation. You wanna focus on things to work, not how to scale them, but as a business, you start suffering downstream. And what we have done here. We started this team of rewriting things from Python into Scala or Java, but mainly Scala after that R&D mode. The challenge we're facing though is like, to your point about abstraction, the one who thought of the model is the one who most well positioned to abstract his thoughts into code. But now you're getting an engineer who haven't have spent as much time thinking about the model and is required to abstract those from Python lines. And, and, and talking to other like folks, it seems like it's a, it's an industry wide problem. And one I don't know, happy to see, to hear your thoughts about that, if any. But one thing that we're trying here is to have an engineer shadow the AI scientist early on in the experimentation, just from like, Hey, what's going on here? How are you thinking of the model? So when the time comes and they have to do a switch, it becomes an easier thing. But I don't know if you have seen other practices or, or other ways of doing it.
Daniel Ciocîrlan: I was just about to suggest something similar. I think across skilling of your AI modeling team versus your software engineering team would probably do wonders for both because the AI team will now understand software engineering and product, and the software engineers will understand models and the closer they can understand each other's business, the higher quality code you'll push. Less friction and probably more scalable and with more productivity in the end, because if one side of the development team or of the R&D is thinking a certain way, and another side is thinking differently and side number two, which is the software engineering part has to push the product. There is certain degree of friction or, or at least this is how I anticipated it. There is a certain degree of friction to rethink what the first site has written into something that's more scalable and works well from a software engineering perspective.
Karim Galil: So, as I. told you earlier, like last couple of weeks ago we interviewed Leslie Lampert. And we, we asked him a lot of questions around AI and his answer was always I don't comment on things I don't know. And the levels, the level of humbleness there was pretty impressive because in healthcare we see the opposite. People who have like very little experience are making bold claims and comments around AI in general. And now talking to you, you, I'm, I'm seeing the same theme. Like you're like, I don't know a lot about AI. I have some friends and I played with some models, but I'm not as intrigued as into the community as others. So I'm seeing a theme where like true engineers tend to make the, the, the differentiation or the, the, the, the distinction between engineering and AI research that's happening these days. But here's the thing in healthcare. It's not the case in healthcare. If you are a software engineer, it means you can write AI or you can, you're qualified to be an AI engineer. Those two terms are used simultaneously basically. In your experience or in the way that you break down things, what is it that the difference like what is the difference between AI and engineering, even though they're very closed fields? Two, what is. the difference in the engineer? Like the R&D engineer versus the production or product ready kind of engineers.
Daniel Ciocîrlan: I would like to, to ask you some clarifying questions about the second bit, but let me take a stab at the first. So you're asking about what the difference is between an AI engineer and a software engineer or a product engineer.
Karim Galil: a software, like writing a piece of software, right? Like, let's say writing whatever, a piece of software that allows you to do trading, market trading versus building a model that can predict that next prize for that same stock trading. Those are two different sets of skills and two different schools of thinking. Right. So what, what, what is the distinction between those two things? And what's the distinction between the engineers or the scientists working like from a qualities perspective? In each one of them.
Daniel Ciocîrlan: well, I think it pointed out quite well. I have a, to give another another analogy here. I have a, a very good friend working in astrophysics and she's a very well respected astrophysicist now in university of Toronto. And she does research on dark matter and cosmic dust and she pretty much does mathematical models, but she also needs to know how to code because she needs to validate those models on data. And so essential software engineering skills. I shouldn't say software engineering skills, but at least programming skills to know what works and what doesn't, how to structure your code, how to think properly so that you don't refer to your code and just make a mess, a mental mess out of your code. At least those are essential skills for her to do a good job. And I think you've pointed out just right. I think that an, an AI developer would be equivalent to somebody building a model for just about any other kind of business where trading, like you said, I also have some friends working from the old days in the physics Olympias that are now mathematical modelers for, for trading companies. But they're not software engineers. They just know basic code just to put proof of concept, but then the software engineers have to then understand what they've done. Push a product that could scale that could sustain high loads, that would be fall tolerant that would minimize failures and impact for, for the company and so on and so forth. So I think the analogy is pretty similar in this case.
Karim Galil: Sweet. Now one other term that's being used lately a lot. Akka so what is Akka and why it's always within the Scala community, a more frequent thing to talk about.
Daniel Ciocîrlan: Akka, Akka is a toolkit that is a set of libraries used for distributed systems. Akka allows building a distributed system in very few lines of code compared to other tools or equivalent things in other programming languages with a high degree of fall tolerance, scalability, resistance to errors, elasticity in terms of high and low load and so on and so forth. And Akka solves a bunch of distributed systems problems, very, very well. And the Scala API, which is the language that Akka has built in allows you to write very few lines of code that could do all those automatically. The way that Akka is structured is by thinking your code or thinking your product or software in terms of independent entities known as actors that could work not just by. Using their internal state or using their internal data or mechanism like you would do in regular programming languages. For example, in Java, there is this concept of encapsulation. For example, if you have a piece of data, a data structure, which has some fields and some functionality you would call or invoke those fields, or some function that functionality by calling their methods. For instance, in Akka that's not possible because these actors are completely encapsulated in the sense that you can only send messages to them and they will reply, or they will act upon those messages asynchronously at a later point, you don't, you don't control when those messages will be treated pretty much like human interaction, because just to give an analogy. Let's say that I'm interested in going to a concert. I play at an absurd amount of it, cheering on the guitar. And so I'm interested in learning when the next Ed Sheeran concert is gonna be in Brucharest, Romania, which is where I'm talking from right now. And assume that I don't know that, but I have a friend who's more of a fan of Ed Sheeran than I am. And so I'm going to go ask my friend, Hey Alex, when is Ed Sheeran going to play next in Brucharest and Alex might reply to me back. If, if we're talking and Alex might say it's going to be on November 17 or, or something like that. Notice the interaction. I'm asking a question. It takes a little bit of time for that question to be registered. She'll have to fetch the memory and then reply back. This is the normal human interaction. I can't poke into the brain of my friend to fetch that information and retrieve it back into my own. This is what regular programs do, by the way. So. takes physical time for a message to travel. And this is the, the kind of normal interaction that would happen in between independent entities. This is what object oriented programming was meant to be by the way, spending several decades back by its original creator. So objects were intended to be these dependent entities with whom you can only communicate by sending messages. And just to keep the analogy with my friend, answering my question, it takes physical time for a message to travel, to be registered, and then a reply to be sent back. And my friend, Alex might not even reply in the same at the same time, or even in the same context. For example, I call her, hey, Alex when is Ed Sheeran gonna play next in Brucharest? And she'll say, I don't know, I'm gonna get back to you. And it takes like three hours and then she'll send me a text message instead. So notice that the, the, the scenario, the, the context was different. She didn't reply back by the same means, but she sent me a text message instead. So notice that this message exchange might be in a different context or in different style than the the original request. So this is how Akka works, and there's a bunch of software that was built on this principle. And Akka is one of the most powerful toolkits in the Scala ecosystem. Now recently Lightben, the company behind Akka has decided to change its licensing model for Akka to something that's not open source anymore. This cause a stir in the Scala community and time will tell if this move was worth it. But there is some discussion happening about the future of Akka.
Karim Galil: Interesting. Ah, I didn't know. So basically means we're probably gonna get a bill pretty soon. Interesting. So on, on, on the open source piece before we go to that and, and I know we're coming into the end of the hour and I wanna be conscious of your time, but our engineering team, I ask them like, Hey, what, what do you want me to ask Daniel? So this question is not for me. This is from our engineering team. It's like Scala 3. Everyone wanted to hear your comments around Scala 3.
Daniel Ciocîrlan: Okay. How much time do you have?
Karim Galil: As much as you want.
Daniel Ciocîrlan: Yeah, I
Karim Galil: It was Scala 3 and they also wanted to hear about Scalameta which by the way, when I heard Scalameta, I was like thinking of like the Facebook Meta kind of stuff. But then did my own research and was completely like, oh, I'm off from what I thought it is.
Daniel Ciocîrlan: Yeah, it's a, it's a, it's a tool. Scala 3 is the next iteration in the Scala world. And I think it's going in the right direction because one of the gripes with Scala in general was that with every, the Scala is a research language. It started almost 20 years ago. Oh my God. It's been a while. It started in 2004, something like that as a research language. So it started in Switzerland as a Ph.D or something research and it's become this production language, but at heart Scala is constantly evolving. So features are constantly being added into the Scala language and have been for the longest time. But this created gripes with the Scala language because in between versions, Scala was not compatible with the older versions, unlike Java, which moved very, very slowly, but it maintained the trust of programmers using Java because they knew for sure that subsequent versions of Java will still run their code. But with Scala, that wasn't, that wasn't the case. And this would, this was probably a, another reason for the lack of adoption in Scala early on, but they've fixed this in Scala 3 with monumental effort. They've rewritten the Scala compiler from scratch with a bunch of guarantees, for example, in between new versions, from example for 3.2 to 3.3, like minor versions, they are now compatible and major versions are only going to occur with a cadence of once per 10 years or something like that. So this is what, this is the kind of intention that now backs Scala as a research language. So Scala 3 is this new age in the Scala world where we hope that by guaranteeing compatibility, between versions, things will be more stable in the Scala world and with the libraries that we as software engineers use. And therefore, because things are more stable, people will have more confidence to use Scala and associated tools for large scale projects. So this is the, I think the main benefit of using Scala 3 plus the language itself has changed of course, to make it easier for programmers to write it correctly.
Karim Galil: Interesting. Alright, so that was very helpful. And specifically the area where you were explaining the differences between different programming language I thought that was very easy to understand I have to say so are you, are, are you living in, in Romania.
Daniel Ciocîrlan: I, I, am in Romania Brucharest. Brucharest is my home. I yeah, I plan to spend quite a bit of time here.
Karim Galil: There is a big, like. Really great movement from an engineering perspective in Eastern Europe it's picking up really fast, like Ukrainian, Romanian, Polish kind of developer community is, is growing fast. And it's a lot of Silicon valley companies now are, are, are trying to hire and, and build there. It used to be India for quite a bit. Then it became Ireland, Holland for some time. But now it seems to be moving more towards Eastern Europe.
Daniel Ciocîrlan: Yep. This is what I've noticed as well. Eastern Europeans are generally well prepared software engineers, and because of the pandemic software engineers now are working remotely. So US companies now have access to global talent and Eastern European software engineers being quite competent. It's quite an attractive offer for such companies like Silicon valley to invest, in hiring Romanian Bulgarian, Polish software engineer.
Karim Galil: All right. So I was thinking what's the best way to end our podcast. And as I told you early on, we, our mission is to make medicine objective, and we believe that this is a mission where we would be saving lives. Like some folks go through suffering that they don't have to go through because they either got a treatment that's not gonna work. So they better focus on quality of living or missed on a treatment that should have. Most of our stack is built on Scala and a lot of our engineers have got to learn a lot about Scala from your work and videos and, and website. So in a very indirect way you are, saving lives and that's I, I, I think I have to say I was very impressed by the fact that he decided to teach specifically a language like this. So thank you for, for, for the good work and thank you for coming into the podcast on like without a lot of context about what the company is, is doing. I really appreciate it.
Daniel Ciocîrlan: Thank you so much. I really appreciate you taking the time. I'm honored that you had me for the podcast. I wanted to thank you for your insightful questions. And I am really, really happy that you like my work and that I've helped you in any way that I can.
Karim Galil: Definitely. And just for the audience, the website is rockJVM, correct?
Daniel Ciocîrlan: It's rocktheJVM.com.
Karim Galil: rocktheJVM. So, and we know the rock now is coming in from the guitar in, in the background. so now we know like where this came from. Awesome. Hey, thank you so much for, taking the time.
Daniel Ciocîrlan: Thank you so much. I really appreciate.
