Vadym Kostiuk (00:01)

Hello, Kalle. We are pleased to have you on our podcast.

Kalle Korhonen (00:08)

Well, thanks for having me. Hello, Vadym. Hello, Artem.

Artem Barmin (00:12)

Hello.

Vadym Kostiuk (00:13)

Yeah, so to our audience, I just want to tell a bit about Kalle. Kalle is a chief product officer at a well-known company called Quuppa. And yeah, Kalle, we would be pleased if you could tell a bit about Quuppa and what Quuppa does and where the Clojure fits in it.

Kalle Korhonen (00:37)

Sure, alright. Yeah, Quuppa does indoor positioning. Super interesting company. We are based in Finland in Espoo. I joined from, I had a long career in California, in Silicon Valley, but then I moved back. I'm originally Finnish but yeah. So indoor processing. So what does that mean - we track these tags about coin size a little thicker with these locators that we put on the ceiling and then this is based on angle of arrival sort of a computationally heavy problem where we track the the ag gives a signal and then, you know, the locator measures the angle, but then that's all fed into this positioning system that computes the position. But for me what makes Quuppa like so interesting is that we do it all. That we do the firmware for the locators and the tags as well as the algorithmic development for this Quuppa position engine and then sort of the enterprise side where we manage systems and multiple sides for for different large customers, whether they are in logistics, or manufacturing or sports or there's a whole lot of lots of very very different use cases for the technology.

Vadym Kostiuk (02:18)

Yeah, nice. I knew a lot about Quuppa before this meeting, but I believe a lot of our audience will find it interesting and will Google Quuppa afterwards to see more what it does. Yes, Kalle. So as far as we know, when you joined Quuppa, it was a primarily Java development team. And you mentioned...

Kalle Korhonen (02:46)

Yes.

Vadym Kostiuk (02:47)

...that you were the one who brought Clojure into this ecosystem.

Kalle Korhonen (02:51)

Yes, I mean, you know, Quuppa is not a new company that started as a spin-off from Nokia. The founders had already developed this. They are R engineers. They had already developed that technology. But when I joined, Quuppa was still a much like a research project. We did side by side, whether it was again a sports arena or one warehouse at the time. But then when we started, we had a little bit of more funding as well when I shortly after I joined, even though this was, always been kind of, we've always had sort of revenue base. But yeah, so we started working on this enterprise system, very much like solving the problem of remotely managing these systems. The position engine is typically deployed on the site, but it needs to be managed by us or a partner from outside. And we wanted to make the whole solution closer to Software as a Service, even though this has a very heavy physical hardware component. And then... No, had been kind of for different projects. I have quite some background with Clojure and Java, but Clojure was like, you know, there was like two problems that we could immediately solve. That we were doing a lot of stuff over the wire, sending instructions back and forth, the network, and then collecting the position data. So the serialization was one of the aspects that was really lucrative to me in Clojure. And then...

Kalle Korhonen (04:49)

I knew that we had a very small team so I was like Clojure is the one tool that does it all, both the front end and back end. I've always liked the idea that I can kind of freely move from the back end to the front end and back again using more or less, it's of course not the same but very similar ideas in the whole technology stack.

Vadym Kostiuk (05:17)

Yeah, and I believe it was not easy to onboard the new technology.

Kalle Korhonen (05:23)

Yeah, mean, I mean I could say that. That was very interesting. So one of the core tenets was that, OK, we need to solve this problem for managing multiple sites. We have this kind of the architecture is like multiple monoliths. We have servers all around and they manage from a single interface. And so how do we even communicate to that server on the site. One of them is like okay there's a firewall in between and then we use a WebSocket but typically of course a WebSocket is from a browser to a server but then and if you guys know Sente, Sente is this little abstraction layer over web sockets enclosure. My little contribution to that library was doing server to server or Java to server web sockets instead of browser to a JVM server. And that's how we get past or we get through the customer's firewall. Obviously they are always in sort of enterprise systems and there's firewalls in between but that's how we kind of establish the connection to the system that we try to manage.

Artem Barmin (06:34)

Mm...

Kalle Korhonen (06:42)

And many other problems of course as well but that's one of the of the core architectural ideas in this.

Artem Barmin (06:50)

Thank you. And what was the size of a team of Java developers when you started to adopt Clojure?

Kalle Korhonen (06:57)

Little by little. Because I you know we started with the idea and then it was first me and then I was like okay somehow I was able to convince sort of the board and the management that this is the right architecture but then we hired a few guys I always want to have sort of experience in-house. But at the same time, especially after we got the funding, were like, then there's pressure to kind of to start delivering. So we were lucky enough, we had a couple of consultants from Metosin, which is this Finnish, Clojure-focused consulting company. They were really good.

Artem Barmin (07:36)

Mm..

Kalle Korhonen (07:45)

It was fun to work with them but you know nobody can kind of or I don't know at least we couldn't afford to keep them a long time but they were crucial in that period when we built a whole lot of software sort of greenfield development.

Artem Barmin (07:52)

Mm...

Artem Barmin (08:00)

And what kind of work did they do? So did they do training of a Java team or just technical and architecture parts?

Kalle Korhonen (08:10)

All kinds really, really, you know, sometimes of course training, but also just sort of just, you know, even UI development, of course, many of the architectural parts. And there's always this other part, it's not quite enough to just develop the software, it's all like, okay, so how do we deliver it? What's the kind of the whole deployment pipeline? They did many of those parts as well.

Artem Barmin (08:16)

Mm -hmm.

Artem Barmin (08:41)

And how the team, internal team reacted to your suggestion. So how this happened actually? You came out and say, hey guys, now we are writing in Clojure or...

Kalle Korhonen (08:54)

Yeah, I mean, I don't know. So that's interesting. So like the core of it and or at least the algorithm core is in Java. But for the Clojure...

Artem Barmin (09:03)

Mm -hmm.

Kalle Korhonen (09:07)

...development, we hired new developers mostly. So that, I mean, we were also at the time when the team was expanding and I kind of, was lucky enough that I had sort of freedom to decide where are we going to expand. So it's interesting, but there's like, because overall Quuppa is sort of so complex, there's firmware, there's...

Artem Barmin (09:11)

Hmm.

Artem Barmin (09:20)

Mm -hmm.

Kalle Korhonen (09:35)

...there's the algorithm development, there's all these different parts and a lot of testing systems, there's Python, there's you know lots of Bash scripts and stuff so it was not you know introducing one more language that runs on the JVM, it's like well you know I don't know it but that's fine.

Artem Barmin (09:54)

Mm -hmm. I see, I see. Pretty interesting way of transferring. So right now, Java engineers are still working in Java or they kind of learning Clojure or doing some stuff.

Kalle Korhonen (10:09)

Java engineers are still, you know, they're very, kind of the hard core is still in Java. And of course, could it have been written, rewritten, in Clojure? Yes, probably. But really, any sort of sufficiently large architecture, like you've got to be careful that you don't break everything because of course it's like, ah, if we could, if we had known, we would have made it better, but you never know. And then you have to be careful that you don't...

Artem Barmin (10:14)

-huh.

Artem Barmin (10:28)

huh. Yeah.

Kalle Korhonen (10:39)

...you don't introduce different kinds of bugs or problems. Like we get a whole lot with Clojure, but we tried to kind of build it sort of honoring the existing code base.

Artem Barmin (10:51)

I see, thank you. And would you take Clojure as one of the main technologies of the project right now in 2024?

Kalle Korhonen (11:03)

Any day, yeah. Absolutely.

Artem Barmin (11:05)

Yeah.

Kalle Korhonen (11:05)

I mean, know, for us it was easy because the sort of the web parts were like undeveloped or old. They were like very based on very old sort of Servlet technology, you know, not necessarily even Spring or anything. So it was easy for me to just rip off the sort of the Servlets, replace that part with Clojure. But that's a small thing. You know, I think the benefit really is more about the, especially now.

Artem Barmin (11:16)

Mm -hmm.

Artem Barmin (11:24)

Hmm.

Kalle Korhonen (11:34)

or environment in this kind network-based development.

Artem Barmin (11:39)

And I'm kind of curious, you know, I would say that I know technology not only when I know how to do some stuff in it, but when I know the limitations of the technology or drawbacks of technology. So can you name some problems or drawbacks that you faced during this adoption?

Kalle Korhonen (12:01)

Yeah, I mean the nature of like a sort of network developed that you have, you're managing state in multiple places. That makes it difficult. And then of course...

Artem Barmin (12:09)

Mmm.

Kalle Korhonen (12:15)

Clojure that you gotta know like Clojure maybe it is still difficult to start with, and there's a lot of different ways and new ways of like okay well this was done then we've already moved on to CLJ-new or whatever like from leiningen and there's a lot of stuff. And then then sort of the REPL-based development you know, I don't know, I think it's not for everybody.

Artem Barmin (12:32)

huh.

Artem Barmin (12:44.44)

Hmm.

Kalle Korhonen (12:44)

Sometimes it's like, you know, so like hey like you can actually how do you debug a system that's running and that's... That's okay. You just hook up your REPL to it and start doing it. But it's like for others. It's like wait a minute. I can't do that or there's like, you know, but unused to doing this or that Yeah, I don't know.

Artem Barmin (13:01)

Yeah. This part is really interesting because REPL is the first thing when I say about something about Clojure.

Kalle Korhonen (13:17)

Yes, absolutely. Yes, totally. I tend to agree with you. But then of course, debugging and knowing how to read, especially ours, like, you know, still there's a lot of like, okay, where was the bug? Was it in the Java code, in the core, or was it in the Clojure code?

Artem Barmin (13:34)

Mm -hmm. Mm -hmm.

Kalle Korhonen (13:38)

...and that's not always immediately obvious. That makes it of course, because this is not a pure Clojure system, that makes it perhaps at times more complex.

Artem Barmin (13:42.146)

Mm -hmm.

Artem Barmin (13:51.294)

Interesting. Okay, yeah, Vadim. Thank you.

Vadym Kostiuk (13:57.262)

Yeah, thank you, Kalle. And you know, I talk a lot with different projects and teams who use Clojure. And nowadays I see that some organizations, they are moving towards from Clojure because of different reasons. And I wanted to ask you, have you ever seen the moves within your organizations in Quuppa? And maybe someone pushed the decision to move forward from Clojure or even maybe ever considered this.

Kalle Korhonen (14:33)

Yeah, I mean, I'm... Current developers are Clojure developers. I picked them so like, know, so which one, which language do you prefer? If you prefer Clojure, then you're good. But, but yes, I mean, we had one guy at least who was like, you know, he was from the, and you know, maybe everybody has a favorite language, and his favorite language was Go. And so, okay, maybe we should, we should develop this with Go. I'm like, no, we're not going to do that because we already picked the language and you can't like, you know, for different things.

Artem Barmin (14:56)

Hmm.

Kalle Korhonen (15:04.912)

You that's like you gotta move forward, you make that decision and then move on with that. It's not that we like I'm even trying to hammer Clojure everywhere. But for this technology, there was like, you know, no room to just, okay, change to something else. I know, see it of course, and Clojure as a sort of industry, there's always people that's like, well maybe there should be even better languages, but those who, I'm quite happy with the ones who are sort experienced with Clojure, oftentimes you hear from them that like hey, Clojure has spoiled all these other languages, because it is consistent and... And works nicely and there's like not a whole lot of new things or new syntax coming in.

Artem Barmin (15:56.078)

I'm a bit curious about, you know, culture of doing technical decisions in your company. So, have you arranged architect committee, discuss everything? How usually you said one guy suggested to move to another language, but you rejected this, but how Clojure ended up in being implemented?

Kalle Korhonen (16:24.946)

Yeah, I mean, I can say that it was not a democratic decision. It was just a decision that I pretty much took and sort of convinced those that needed to be convinced.

Artem Barmin (16:29.112)

Hmm.

Kalle Korhonen (16:40)

I mean, Quuppa is still a small company with less than 50 people and much less engineers. So it's like, you know, the decision making is still very sort of agile. There's not a whole lot of committee meeting. And this, of course, because the technology stack is big, there's a lot of people who are specialized in different areas. So no, we didn't have any architectural board or anything.

Artem Barmin (16:43)

Mm -hmm.

Artem Barmin (17:05)

Mm

Artem Barmin (17:10)

I see, I see. Actually, we are running out of questions because we thought that it will be longer and longer, but let's proceed. It doesn't matter. We will figure out everything. And I want to ask you about over-engineering because I've seen this tendency in different Clojure projects, especially that were started by people that are not really into Clojure way of thinking. They were curious about Clojure. They decided to start the project in Clojure, but they are not really understand their own philosophy. And I've seen sometimes tendency to build, you know, domain specific languages. So we're not building the system. We're building domain specific language and then we build system in this language. Have you met something like this in your experience?

Kalle Korhonen (18:11)

Yeah, I mean I've seen a lot of libraries and maybe, maybe Clojure more that you have to have another domain-specific language. I think that happens all the time. I think partly, you know, it's the fun of creating and laziness to read other people's code and understanding, you know, how do the pieces fit together. I'm not sure that that's a of Clojure-specific problem.

Artem Barmin (18:32)

Mmm.

Kalle Korhonen (18:43)

But yeah, so overengineering of course at the architecture level can be fatal. I've always been sort of against that, that like you know, that this... Especially this thing that like I've seen microservices architectures gone really bad because you just... without thinking you split everything into different services and it really doesn't buy you anything, but added complexity.

Artem Barmin (19:15.31)

Yeah, so you don't connect this to Clojure specifically, This 10, this...

Kalle Korhonen (19:21.996)

I wouldn't, no, I would not say that. I've seen some libraries, but perhaps the beauty of the closure is still that like, know, many libraries tend to be very small.

Artem Barmin (19:34)

Mm -hmm.

Kalle Korhonen (19:34.95)

...and then you end up with lots and lots of different libraries but there are few, more perhaps on the Java side, you have these overarching frameworks that try to dictate like Spring, hey, this is it, and then you have a different Spring library for every little thing.

Artem Barmin (19:47)

That's all for you.

Artem Barmin (19:57)

So how do you use Clojure? As a set of functions and small libraries or do you use some frameworks that actually exist in Clojure world?

Kalle Korhonen (20:06)

Well, we do. So if you just talk about specific frameworks, it's at least Reframe. So we are React Reagent based and there are different alternatives, but I think like...

Artem Barmin (20:18)

Mm -hmm.

Kalle Korhonen (20:24)

At least Reagent is like, you know, it's like the better React or it feels more natural. But anyway, so Reframe and send their, even their API interfaces, like the method signature is very similar. So, and the program model is very similar if you kind of use them sort of, you have this inner loop of like a reframe events

Artem Barmin (20:26.53)

Yeah. Classic.

Artem Barmin (20:41.25)

Mm

Kalle Korhonen (20:53)

from your local backend to the frontend and then you can extend that to your WebSocket to your server. So that kind of pattern or program model we use extensively.

Artem Barmin (21:11)

Mm -hmm.

Kalle Korhonen (21:13)

We used, just to name some others, Intergrand to kind of boot up the systems. I think it's just quite nice, nothing to complain about it. I don't know, there's plenty of libraries but not sort of main frameworks, I guess.

Artem Barmin (21:21)

Mm

Artem Barmin (21:38)

You said used Integrand, so you are not using it right now?

Kalle Korhonen (21:41)

No, no, we use it, we use it. Yeah, I think we very early on I started with mount and then we moved on.

Artem Barmin (21:48.)

Mm -hmm. I see. And do you find it helpful for a team to use this kind of frameworks?

Kalle Korhonen (21:57)

Yeah, yes absolutely. Yeah, I mean I think that I don't know at least in this like everybody's like oh yeah, okay I'm good with that.

Artem Barmin (22:07)

Mm I see. Got it.

Vadym Kostiuk (22:11)

Speaking of technologies, I've been listening carefully to what you've been saying and I've been comparing it to what I've heard from other teams. And what I realized that each Clojure project is unique. Basically, there is no two projects that can be in a totally similar even stack. We're always talking about some differences because... On one project we have one technical lead that made his own decisions and there is another one. So I was wondering, is it something that you consider when you're looking for team members? So when you mentioned that you were looking for Clojure engineers, was it important for you that this Clojure engineer will be covering, let's say, 90 % of your technical stack? Oor you are primarily looking at the willingness to work with all the stack that you have.

Kalle Korhonen (23:15)

Yeah, mean, yeah, that's a good, interesting question. Yeah, and of course, the projects are very unique because they do very different things. And maybe if it's to sort of web development, perhaps the kind of the tools and choices tend to be sort of more similar. But... What I was looking for in engineers of course it was primarily first and foremost it was the interest in Clojure that like hey do you want to build it with this because I know that there's like this less that works for small companies works both for and against that it's difficult to find engineers but that I could find like at least in Clojure I can find people who are really interested in working with Clojure and they're looking for Clojure projects so it's was an easier sell in that respect. But then I mean overall I typically I sort of my screening is like I go to like I name libraries, hey do you know this, do you know that, so I to get sort of a picture of what you've done with Clojure because if you don't know the kind of the main libraries or the there's so many that like you I can immediately see that like hey you're interested in Clojure but you don't have the experience but it didn't really matter otherwise for me and then of course there's the other part of this is like hey have you ever like. To me, was interesting that not many people even like you always done web development, like you've never even used sort of UDP or like done any like sort of perhaps a little bit lower level network programming. This was specific to our system, but and then, know, it's...

Kalle Korhonen (25:15)

One other thing, especially, again, specific to Quuppa, not for many other companies, is like, hey, are you interested in hardware? Because like again, when I said in the beginning, that part is still fascinating to me, that there's so many things that we work with, and we work directly with hardware. Whereas many, if you work on software as a service,

Vadym Kostiuk (25:21)

Mm

Kalle Korhonen (25:41)

The company you may never see the hardware. It's just deployed to cloud but you never really like the hardware is never visible to you.

Vadym Kostiuk (25:50)

Yeah, that's an interesting point of view. I was asking because when we were talking with different partners from all over the globe, criteria for senior engineers, they were so different that we just couldn't match them. For some project, senior engineer is just someone who's been working with Clojure, let's say, for seven years, even though it was pure Clojure and ClojureScript, like no additional...

Artem Barmin (26:04)

Hmm.

Vadym Kostiuk (26:19)

...libs and frameworks and just some of the projects were considering such engineers junior because they don't know much about Reframe or Reagent or i don't know for someone molly is like let's say the the key point to know that's why it was interesting to hear what is your opinion on it

Kalle Korhonen (26:41)

Mm -hmm. Yeah, I mean, I always said that like it's very difficult to replace experience with anything but experience. So of course, if you worked with the multiple languages and you have sort of a deeper understanding, I think that leaves my view and I'm sure many, share that like that, that you you're much more well rounded. It's easier to like learn another language. It's like maybe in some ways like you get a, you become a better developer if you have... If you learn multiple languages the same way as it's easier for you to learn if you know already a few different languages It's easier for you to pick up a new language So just a spoken language the same way you can kind of learn but you know, like you said this there's lots of different kinds of skills and skilled engineers and they can all be good in very different ways.

Vadym Kostiuk (27:42)

Yeah, definitely.

Artem Barmin (27:42)

Thank you. Yeah. Can you tell me a bit more about structure of a team? So, how do you separate front end and backend engineering? So all you have, everyone is full stack and everyone can do both low level UDP packet inspection and both React with some hooks.

Kalle Korhonen (28:05.004)

I like to think that, but of course, and I think that's more that like people sort of are lazy and like to specialize quickly. So this, I encourage that, know, hey, if you're more into just like writing the front end and many of the back end, there's like, wait a minute, I said, like, you know, I don't know what to do. Then it's, you know, so then like, you know, it's like, need to know exactly how the UI looks like so that I could implement it. And it's not necessarily, if you've never worked on it, it's not that easy to, okay, so do I try to find a BootStrap component?

Artem Barmin (28:15.117)

Mm. Yeah.

Kalle Korhonen (28:45.085)

Going to slap a little bit of ClojureScript on it. Or do I just write it from scratch or what should I do? But it's not that, but I like to kind of like at least sort of do kind of pair programming and code reviews so you have an understanding of like okay so when something fails you can at least start looking into it. I totally understand that people have a kind of different interest and specialty so it's not like I try to intensely force them to kind of move up and down the stack.

Artem Barmin (29:21)

Mm -hmm.

Artem Barmin (29:24)

Yeah, I'm asking because sometimes when we try to hire a Clojure person, ClojureScript person, the main thing he should know, they should know, is not ClojureScript, but React. And that's the main pain point actually, because sometimes person can know ClojureScript, Clojure, know everything.

Kalle Korhonen (29:31)

Yeah.

Artem Barmin (29:49)

But have very limited knowledge of React and life cycles and everything. So have you faced such problems?

Kalle Korhonen (29:54)

Yeah. Yes, absolutely. There can be very different closer engineers. If they come from a Java background, they often come with a more back end experience. But the front end engineers may not know anything about JVM, but they might know some other sort of more front end inclined technology Python or...

Artem Barmin (30:04)

No.

Kalle Korhonen (30:24)

Node.js or just JavaScript. And of course there's a huge difference on the front end. Again, if you know multiple languages and it's good to kind of know under the hood, like just plain JavaScript and how that works and how do the browsers work. Just picking up for backend engineering, again, just picking up something like, okay, so how does CSS work? It's completely new ballgame.

Artem Barmin (30:53)

So can we say that Clojure and ClojureScript are completely two different languages, ecosystems? I don't know.

Kalle Korhonen (31:03)

We can say that they're different ecosystems, but I mean, I don't know. We have a lot of crossover code and again, maybe it's because of the of the network nature of the development.

Artem Barmin (31:14)

Mm -hmm.

Kalle Korhonen (31:15)

But certainly that's another great benefit that we can have. It's the same language and now we use it on the front and now we use it on the back end. So certainly not exactly the same. There's a lot of tricks that you know, but it's not the language itself. But when you cross over to Java, so like, hey, this is how I'm gonna use the Java this and that, or the same way in JavaScript, like, hey, no, I will drop down.

Artem Barmin (31:31)

I'm sorry.

Artem Barmin (31:44)

Yeah.

Kalle Korhonen (31:45)

Because I know that you can do it in JavaScript in this or that way. So that's of course different, you know, yeah, so that's where the difference is we certainly come from.

Artem Barmin (31:59)

Mm -hmm. Mm -hmm.

Vadym Kostiuk (32:03)

And I'm wondering, like you said, ClojureScript is more tricky in terms of like you should have some background in React or at least some familiarity. And maybe it's obvious question, but still, is it harder for you to onboard people on the backend more or on the frontend more? And is it hard to even find someone, that is willing to work on the front end. I'm asking primarily because in my experience, most of Clojure engineers, tend to choose backend as their field of expertise just because they don't want to polish some buttons, like dealing with styling and this kind of stuff. And when we are looking for, let's say, full stack engineer, normally it's a person that is really, really good in backend, but... For the frontend, not that this person cannot do frontend, it's just this person doesn't want to do it. So is it hard for you to maintain basically the frontend on a ClojureScript from that perspective?

Kalle Korhonen (33:20)

I don't know. I mean, of course, there's always a lot of things to do in the front end. Once you get your algorithm done, it can just kind of keep working for years and you don't have to change it. But it's so different. There's a lot of... Typically, kind of back end, it's like if you write to a database and it has to be right, whereas on the frontend it's like, now I made the UI this way, but... You know, still make it that way or we can make a million other changes but like what's good enough. So they're very, very different because it's like it's like you know UI is like sometimes it's like you know you're painting a picture and then you know when is that picture complete. Is it harder to find? I don't know. At least right now we have such a great team. I'm super happy with them. They have their own strengths, some on the back and some on the front. But it's not like I've hired hundreds or even tens of Clojure engineers. So I don't know how it's statistically what's more difficult to find.

Vadym Kostiuk (34:40)

Yeah, thanks for the input. It's interesting to hear.

Artem Barmin (34:46)

I'm curious from the list of questions that we've already asked you about Clojure and production, your experience. Maybe you can name some question that we should have asked but haven't actually. Maybe something important that we haven't asked you.

Kalle Korhonen (35:07)

You should totally ask about the IDE's. I'm surprised that they didn't even come up.

Artem Barmin (35:11)

Mmm

Artem Barmin (35:16)

Interesting. Can you elaborate a bit on this?

Kalle Korhonen (35:19)

Yeah, because I mean, I've been in this business for a long time and I've started with Eclipse. I still use Eclipse and now it's like I use as many IDEs as I use browsers. I have like different browser for everything. So now I also have different IDEs like I use Eclipse and IntelliJ and now VSCode as well. They all have like their different strengths, but I'm still not so sure like what's the sort of the best environment.

Kalle Korhonen (35:49)

I don't know if I even care about the best environment anymore. I'm always willing to try out and experiment and I'd be interested to also know what other people nowadays use. I haven't followed much of that.

Artem Barmin (35:52)

Mm -hmm.

Artem Barmin (36:04)

Interesting. And are you trying to manage these IDEs' culture in your team, or everyone just choose whatever he wants?

Kalle Korhonen (36:15)

Yeah, everybody chooses their own. Like I long ago let go of that. Like, you it's just like you pick your laptop, whatever you're comfortable with and we meet up to sort of like, as long as your comments are good. And then of course the review interface is normally then in GitLab or GitHub and then sort of that's the common denominator, not the IDE.

Artem Barmin (36:37)

And do you think that IDE or tooling support and Clojure lack some things that are required or very important?

Kalle Korhonen (36:48)

I don't know. A few years ago it was like all about the especially on the like what is your build system like you know there was like seem to be like the struggle between leiningen and boot and COJ and like now I think that's maybe that's more settled maybe we look sort of Clojure as a community also lost some because of that because it's like really? Yet another tool? Why do I need to pick up that?

Artem Barmin (37:01)

Mm -hmm.

Kalle Korhonen (37:20)

Yeah, but yeah, mean, I don't know, again, I'm happy to try out different things, even if I don't try to force it on. We are still sort of leiningen in base and I'm good with that. for me, it's like, you know, like I can do something on the side and maybe for the new project, I have at least one new good, very interesting project. But, you know, there are, I'm okay, like let's use the new tools. Yeah, sorry.

Artem Barmin (37:32)

Mm -hmm. I hear him.

Artem Barmin (37:48)

Do you have some plans to move in from leiningen in production?

Kalle Korhonen (37:58)

I'd be happy to use different tools for different projects. I would not go back, I mean, you now it's done this way. We also kind of the sort of the Java parts are, and Java still sort of in terms of lines of code is quite a bit bigger. It uses Maven, so Maven and leiningen maybe is sort of a...

Artem Barmin (38:02)

Mm -hmm.

Kalle Korhonen (38:22)

File -wise are closer, not pun intended. But, you know... So that's fine, those tools are okay, but I wouldn't resist if for a new project we would use CLJ.

Artem Barmin (38:24)

Mm -hmm. I don't know, Vadym. Do you want to ask about DSLs?

Vadym Kostiuk (38:57)

Yeah, I was wondering whether you use any within the Quuppa team, any domain-specific languages.

Kalle Korhonen (39:07)

Any DSL?

Kalle Korhonen (39:13)

No, not really. You should also know that my background, my history in especially university is in domain specific modeling and domain specific languages. And especially on the kind of the visual language is like, know, that part is always interesting to me. But for this thing, and that's maybe worth a different podcast, but that

Artem Barmin (39:22)

Yeah.

Kalle Korhonen (39:38)

No, we don't really use any specific DSL and we haven't kind of stepped towards any of that direction. We don't have that sort of concise compact domain where we make variations or like you know we just need to make some part it's just sort of I don't know straight up organic development.

Artem Barmin (40:04)

Data driven.

Artem Barmin (40:09)

Okay.

Vadym Kostiuk (40:10)

Yeah, I guess we really ran out of the questions, Kalle. You answered everything we hoped for. And here's the part when I would like to ask you to leave the question for the next guest who'll be on our podcast. Can you please, you can ask anything you'd like to for the next guest.

Kalle Korhonen (40:34)

Alright, okay, so yes, I totally ask questions like, so what is your experience with AI and have you used sort of any of the AI with Clojure and whether it's, you know, tool support or anywhere else. I'm exploring that space as well, so it's very interesting to me.

Artem Barmin (40:38)

Mm

Artem Barmin (41:03)

Hmm, very interesting question. Okay.

Vadym Kostiuk (41:07)

It really is. really is. I believe this question actually requires another series of podcasts.

Artem Barmin (41:15)

Yeah.

Kalle Korhonen (41:16)

Yeah, totally. it's like I keep getting disappointed with the current versions, but I'm like, okay, maybe there is something there. But every time I, you know, try to use like current versions of the ChatGPT or Claude or like Monotone and it's like, that was not a good answer. But yeah, I remain hopeful.

Artem Barmin (41:23)

Mm -hmm.

Artem Barmin (41:44)

Yeah, if you're curious, I can tell you about my experience with AI and my research in this field. So actually, I found out that, you know, straight up usage of AI, like write a program that do stuff and earn money doesn't work. But it works pretty well if you supply a lot of context in it and, you know, providing a database schema,

Vadym Kostiuk (41:44)

Yeah.

Kalle Korhonen (41:48)

Of course. Hmm. Yeah.

Artem Barmin (42:13)

style of the code and a lot of other stuff and detailed specification and only after you ask a rather simple question. And in this way it can gather all this context information and produce some valuable result. I actually have a pretty good article about this. The guys who are building front end generation in React based on Figma. So they use them, ChatGPT a lot. They said that naive approach doesn't work well, but when they extract a lot, they build a structure kind of DSL for AI and they feed this DSL to AI and ask some questions. It works pretty well. So, it's, it's kind of, you know, I envision the next step of services that will use AI internally.

Kalle Korhonen (42:41)

Mm

Artem Barmin (43:10)

that they will not show anything at all to the end user, but they generate some stuff based on the context. And Apple is doing such thing because they're providing what is on the screen, what applications is opened, what's written in this application. And without this context, AI is not usable.

Kalle Korhonen (43:33)

Yeah, I mean, it mirrors my experience as well. Yes, that helps, of course, and then asking very specific questions. And sometimes, especially UI programming, can still kind of make it faster. But those are simple things. But the complex things are, of course, I'm interested in. And it just sort of falls flat on understanding what some code base is about, even.

Artem Barmin (43:41)

Yeah.

Kalle Korhonen (43:59)

And then, you know, I sometimes I end up spending more time explaining the problem where it's like, hey, I could have to solve this problem on my own.

Artem Barmin (44:04)

huh.

Artem Barmin (44:08)

That's true, that's true. Maybe, you know, combination of DSL, domain specific modeling and AI will be much better because it's limit this space of output for answering.

Kalle Korhonen (44:20)

Yes, I agree that could be very interesting, yes.

Artem Barmin (44:26)

Okay, we will think. I think it would be curious to ask another guy.

Kalle Korhonen (44:28)

Yes.

Vadym Kostiuk (44:34)

Yeah, thank you very much, Kalle. It was truly an amazing talk. I myself enjoyed it so much. Thank you very much.

Kalle Korhonen (44:42)

Great, yeah. Thanks for having me. It's great.

Vadym Kostiuk (44:46)

Yeah. Thank you. Have a nice day.

Artem Barmin (44:46)

Yeah, thank you. Thank you.

Kalle Korhonen (44:50)

Bye bye. Thank you.

Artem Barmin (44:50)

Bye bye.

‍