<div class="heading_h4" style="grid-column: span 2; margin:15px 0">Introduction</div>

Adam Tornhill

Because to me it's always been important to eat your own dog food, right? Why are you using this strange language? So I started to learn Common Lisp and you know, once you learn Lisp you can never really go back.

Artem Barmin

For me that's something about Clojure itself. Because it's fun, pleasant experience. And sometimes people just don't know how to choose the simple and straightforward way to do things.

Vadym Kostiuk

What could be the main factors that could drive other teams actually to move from closure?

Adam Tornhill

That's a good question. I mean, a year ago I could probably have answered that. Now the answer is I don't really know. I expect this to be a no-brainer. I mean, of course we choose the best tool for the job. It's going to save the company a massive amount of money.

Artem Barmin

I heard the story when two Erlang engineers support a part of the system and other part of the system supported by 40 Java engineers. And they're doing basically the same amount of job. Can you make some forecast for three, five years? Where will be closure after?

Adam Tornhill

Python to me, it's probably my second favorite language.

Vadym Kostiuk

Documentation. Really? Well, that's unexpected.

<div class="heading_h4" style="grid-column: span 2; margin:60px 0 15px 0">Full Version</div>

Artem Barmin

Hey guys, welcome to the second episode of the podcast, "Clojure in products. Would you do it again?"

Vadym Kostiuk

And today we're meeting a very special guest, Adam Thornhill, who is a founder and chief technical officer at Codescene. Codescene is a next generation code analysis tool that help companies not to drown in a technical debt, but also improve their development experience.

Artem Barmin

Adam also is the author of multiple technical books, including the best-selling "Your Code as a Crime Scene" and a keynote speaker at various conferences. For more info, check the links down below.

Vadym Kostiuk

And also, we have a question passed from our previous guest, Kalle Korhonen, who is a chief product officer at Quuppa. And he passed the question to Adam about the AI enclosure. The question as it follows, "What is your experience with AI in Clojure? Have you used any AI with Clojure in a production? And is there any tool support for Clojure to bring AI to your product?"

Artem Barmin

And luckily for us, Adam really has experience with AI. So you should check the answer in our podcast. And let's begin. Map our questions and macro expand them into real life Clojure experience.

Vadym Kostiuk

Hello Adam, hello Artem.

Adam Tornhill

Hello, good afternoon, good to be here.

Vadym Kostiuk

Yeah, thanks for joining us, Adam, on our actually second episode of the podcast, "Clojure and Product. Would you do it again?" And I'm sure that most of our listeners, they have heard about CodeScene and about you and about your book, but it would be great to hear firsthand about your experience and about CodeScene. So could you please tell a bit to the audience?

like more details about CodeScene and about yourself.

Adam Tornhill

Sure, I'd be delighted to. So I've been a programmer for almost 30 years, been working in lots of different product companies. And one thing I noticed that seems to be a common trend in the industry is that software development is extremely hard to do right and to do effectively. I've seen so many projects fail, and even the ones that succeed are probably not living up to their potential.

So I started to think about that many years ago. How can we improve what we do? How can we get better at what we're doing? And one thing that I found really important was to shine a light on technical debt and code quality in a way that's accessible, not only to us as engineers, but also to managers and other non-technical stakeholders. So I started to work on something I call behavioral code analysis, which involves both analyzing the source code, finding code that could be better or code that's overly complicated and combining that with patterns from how we as developers work with the code. And these patterns I typically collect from version control history. So when I put these two together, we can start to visualize technical depth in a meaningful way and we can start to prioritize it based on impact and our return on investment, both for us as engineers, a more pleasant code base, but also for the business allowing them to iterate faster.

And I've written a book about it called "Your Code as a Crime Scene". It's just out in its second edition. And back in 2015, I started a company to automate all the analysis from "Your Code as a Crime Scene". You can just kind of point the tool to your code base and you get all this information up front, including automated code views and stuff like that. And that tool is called CodeScene. And we're based in Sweden and we are heavy Clojure users. The whole backend and analysis engine in Clojure is built.

it encodes in this built in Clojure. So that's like the very, very short story.

Vadym Kostiuk

Yeah, and it's really interesting. And I know that you've been actually using Clojure from the very beginning at CodeScene, I guess since 2015, probably. So can you please tell us a bit why actually have you decided to start off the product with Clojure?

Adam Tornhill

Yeah. So I started to learn Lisp back in 2005. At that time, I had mostly struggled around with procedural languages like C and these classics, but also a lot of object-oriented languages like Java and C++ and some C#. And I kind of found that I didn't really get the productivity boost I was expecting. And then more or less by accident, I came across Common Lisp.

So I started to learn Common Lisp and you know, once you learn Lisp, can never really go back, right? It completely changes the way you view programming. So I became a Common Lisp advocate. I wrote a short book about it called "Lisp for the Web". And I looked for opportunities to use it in my day job. And that was really, really challenging, really hard. A couple of years later, the first versions of Clojure came out.

And what initially attracted me to Clojure was that it lives in the JVM ecosystem, which means I can integrate it more seamlessly into all the Java shops I've been working with. And it also meant I had access to all these powerful libraries in the Java ecosystem. So to me, that was a big personal selling point. So started to play around with Clojure. I did a couple of open source projects myself in Clojure.

And in 2015, when I decided to start CodeScene, I mean, CodeScene today, we're a slightly larger company. We are like 30, 40 people, right? But back then it was only me as a programmer. So I kind of knew I have to do something different compared to all these other companies that are trying to do code analysis tool. I have to be more, I have to value my time more. And I knew that using Clojure could be a competitive advantage. We could implement new features quicker. We could iterate on them much, much faster.

So that was like the efficiency, financial motivation, but there's another super important aspect to it as well. And it has nothing at all to do with efficiency or technology. It simply is that Clojure is really, really fun. And I knew that doing a startup means I'm going to spend like 12, 14 hours a day looking at that code. And I want that code that I look at to be motivating, beautiful and engaging. So that was my second motivation for picking up Clojure.

Artem Barmin

Thank you for sharing. That's really fun  that such focus on the process of development is important. And have you had any things to worry about when you started your company and you choose Clojure as a main technical stack? So did you have some possible drawbacks in your mind that can came out?

Adam Tornhill

So I had like two possible drawbacks. The first was that, you know, I had used Clojure on my own for small open source projects. I hadn't been to anything at scale. So I was worried about a couple of things technically, like will it perform? Will it be fast enough? Will it be able to sustain a larger code base once we get there? Because for me, CodeScene was always a long game. I knew I'm going to do that for the rest of my life.

The other thing that was interesting that I ran into that pretty early on, I had some conversations with some investors and I remember at least two of them told me stuff like, I'm paraphrasing a bit, but they basically told me that, why are you using this strange language? You know, switch to Java and you can get 10 developers tomorrow. And I tried to explain that maybe I don't want 10 developers at this point. Maybe I want two or three that really, really know what they're doing and are really, really efficient. Because a smaller team is always going to be much, much cheaper to coordinate and manage. Right? So I had like these both technical concerns and the potential outside of concerns.

Artem Barmin

I see. And looking back, what were real drawbacks of starting Clojure as a main technical stack? Does your worry came true?

Adam Tornhill

Not really. mean, what really fascinated me was that I was pretty convinced early on that there are parts that we do in Clojure that we will have to rewrite in a different language to be more performant. And in 10 years, we had to do that exactly once.

In all other situations, it turned out that the Clojure was more than performant enough. And I think it's largely because we have such an excellent fit between the domain we work in with CodeScene and what Clojure is really good at. So what we do with CodeScene is basically that we process a lot of data, a lot of development data, source code, Git data, data from JIRA and other tools. And we basically, you know, took in large amounts of data, we analyze it and we transform it to an outcome. And that's exactly what Clojure is so good at. So we could mostly optimize our algorithm and get the desired performance. The other thing that I worried about, or maybe the people I talked earlier worried about that I wouldn't be able to get enough developers turned out to be completely false.

Instead, turned out that in my experience, Clojure has such a great community. There are so many skilled people there that are really passionate about the technology. So I've been fortunate to work with some extremely good developers over the past 10 years, and I've learned a lot from them. So I'm very grateful that I picked Clojure. The only potential drawback I see, Clojure being dynamically typed, I kind of find it challenging when you want to make larger sweeping changes to the design. I'm not talking about the smaller refactorings, they're very straightforward, but when you want to make larger design changes, you really wish that, hey, couldn't I have a type system on top of this that kind of helps keeping me sane.

Artem Barmin

But Clojure does have type systems, Clojure typed. Have you tried to use it?

Adam Tornhill

We tried to adopt a Clojure spec. We were still using it. And somehow we never really got the benefit out of it that we expected. That's probably the one thing I wish could have been slightly different. It might be something in how we do it. I don't know. But I always thought that dynamically typed languages are really, good early on because they let you iterate so fast.

But then once you get to a point where you start to kind of stabilize the design, that's when you want to go in and kind of sprinkle types on top of it, right? And I thought Clojure spec could help us out with that, but that's the challenging part. We compensate by using good tools. We use codes on its own code base, of course. And we also are very heavy on automated testing. So we have all these tests at different levels as guardrails.

Artem Barmin

And can you tell a bit more about early days of CodeScene? So how long would it take to run the first version? As I understand, you made it by your own without external team, without any help from outside. So it's pretty interesting, you know. We talked about drawbacks and right now I want to ask about benefits that you gained by choosing Clojure.

Adam Tornhill

Yeah, sure. So right now the development team is larger. We're like 15 people working on developing it, right? So the context now is very different compared to the early days. For the first six months, I was the only programmer and I bootstrapped codes and I never had any external capital for the first year. So I had to do really everything. There wasn't anyone else.

And this was a very interesting period in terms of learning. I learned a lot because you really have to do everything. But it was also challenging because there were many aspects of like software delivery that I haven't really worked on before, right? Like how do I deploy this thing or how do I package it? So the first version of CodeScene, took, I think it took four months until we had like the first version that someone external could try out.

And I had some pretty good contacts with a couple of larger enterprises. I had been doing services to them before. So what I did was that before CodeScene, the product was good enough to stand on its own. I used the tool to do services on top of it, right? Because I can get all the data, I can repackage it and kind of present it manually. And then it took six months until we sold the first enterprise version of CodeScene.

And then I brought in the next developer. So we doubled the team after that.

Artem Barmin

Was it hard to bring the new developer in existing code base?

Adam Tornhill

No, it wasn't. The onboarding was very straightforward. And this was a person that had played around a little bit - a lot - with functional programming. Not Clojure specifically, but, you know, had a mindset and was pretty straightforward. And I found again over the years that onboarding, even if you don't have prior Clojure experience, is quite straightforward because the syntax is so ridiculously simple in Clojure. I mean, you can learn it in an afternoon. So it's more about learning to think in a functional way. And if you have that mindset, I think it's very straightforward in my experience.

Vadym Kostiuk

Yeah, that's interesting that you said it. So you started off the CodeScene actually all by yourself. But now, past nine years, you have a large team supporting and developing the product. Can you please tell us more about... what is the current structure of the team? And how do you organize the process of development between different team members? Is it  hard, in your opinion, do when the team size becomes larger and larger?

Adam Tornhill

Yeah, I think that scaling a team is always hard. And a lot of things kind of shift over time. I mean, when we started out, and I mean, even back when we were just three, four people working on CodeScene in the holidays, the thing is that at that scale, you don't really need any processes, right? You can just talk to each other. So you can get really, really far and you can move very, very fast.

But then there is some kind of cutoff point. And I think that cutoff point is quite early, maybe already around six, seven people. Or you start to need a bit more structure, right? You need to start to use a bit more process. And you always kind of want to keep this in balance because you don't want to put an unnecessary administrative burden on people, right? So what we focused on a lot over, let's say, the past four or five years is to formalize the things that have been working well for us in terms of principles and processes that we follow.

And I don't think you ever get done with that work, right? So this is something you continuously want to refine. And last year we made another big shift. I brought in an engineering manager that it's a person I've been working with in the past. And so I knew this is a super skilled person.

And the reason for that was that I simply found that the team has gotten a bit too large for me to manage on my own. And I think the team deserves someone that can really be there for them all the time. So that has been another personal shift for me to take a little bit of a step back from the day-to-day development. So a lot of the things I'm saying now, I probably take credit for work I haven't done myself. But... The team has done a fantastic job, I would say, on being able to scale.

And one key to the success, in my experience, is to always have a very straightforward mapping between the features you work on or the capabilities you work on and the software architecture. Because the worst thing that can ever happen is when you have different teams working on different aspects of the product and kind of have to coordinate in the same parts of the code, will create a mess. And so that is something that we continuously had to think about. Okay, how can we kind of restructure the product and to fit the way we want to work with it?

Artem Barmin

So it's more about architectural thing, yeah? How to separate different teams, code bases.

Adam Tornhill

Yeah, architecture is definitely one part of it. we were actually, as we speak, I know that one of the teams is working on re-architecting parts of Jolensin to allow one more team to work in parallel on that part. So it doesn't have to be big things always, right? But I think it's important to never kind of settle with what you already have. I think you constantly need to re-evaluate it.

The other thing that we had to do was to, I mean, as the tool has grown, it has also grown in capability. So CodeScene today integrates with, you know, not only GitHub like in the early days, but BitBucket GitLab, Azure, and all these different providers, as well as a ton of different product management tools like Azure DevOps, JIRA, Trello, and so on. And that means that we have lots of fairly complicated integrations because not all of these APIs are well documented, not all of them are super stable. So we also had to develop a lot of practices around how do we make sure that nothing breaks if one of these tools change their API, right? Or that at least we find out about it. So all this observability stuff is also things that we had to build in over time.

Artem Barmin

I want to ask you a bit controversial question. And one thing that I noticed by supporting different projects and Clojure that's run for 10 years is tendency to overthink and to overengineer things.

And I especially noticed this with the teams that didn't have prior experience with Lisp family. Yeah, they maybe had experience with functional programming, but Lisp and Clojure gives so much opportunities, macroses, you can build DSLs, you can create your own language and write your program in your own language inside the ecosystem. So everything is possible. And sometimes people just don't know how to choose the simple and straightforward way to do things. So have you ever met such problem in your project overengineering?

Adam Tornhill

Wow, yeah, that's an interesting area.

I don't think it's a problem I have seen often. I know exactly what you mean because I kind of, it's Clojure, it's a very flexible design space. And quite often it's tempting to build in this extra level of engineering. Maybe we do this DSL using macros or whatever, right? And in 99% of the cases, you probably don't need it. So I know, I haven't seen that become a problem.

What might have happened is that the parts of the code base where I felt that maybe we under-engineered it. And I think that's a better problem to have if you know about it, right? Because in the old days, I mean, when we were a small team, we always paid a night to code quality. We know that this is going to be our advantage. But we also settled for some very simple solutions.

So to give you one example on what I mean with under-engineering, in the first days of CodeScene, we decided that we wanted to be very simple to get started with the tool. I don't want you as a potential user to start to install databases left and right. So we choose an embedded database. So it was really, really simple. You just basically downloaded a .jar file and spun it up and everything just worked.

But then we found later as we scaled up and start to take on large enterprise accounts that we simply couldn't meet their needs with an embedded database because it's really hard to do a backup of it. It's really hard to do a restore of it and all that. So we kind of have to rethink that space and make sure we could support external databases that you connect to and all of that. So I think that the right design decision today might be under-engineering two years from now, when the situation changes. So I think constantly paying attention to that is important.

Artem Barmin

Can you share a bit the culture of technical decisions in your team? So how do you choose the new tool, new library, new approach? So how do you try to manage all this complexity of the software?

Adam Tornhill

So one key to success there has been our tech leads. So we have four tech leads. And they have a large, large responsibility in making sure that everything kind of fits together. And so they are doing a lot of heavy lifting. The team in general has a very large freedom in choosing whatever tools are best for the job.

And quite often it's not big decisions, right? You have a particular task, you need a particular library, you're free to use that library as long as you meet some principles that we have set up. So for example, we need to have principles that protects our IP. We don't want to drag in any GPL licenses in our code, for example. And we try to automate as many of these things as possible. So we have gates in our build pipeline that kind of check for various aspects of these. So we take away that cognitive load from developers. I think the technical decisions are best made by the people that know the area best and that is the developers with guidance from the tech leads.

Artem Barmin

Can you share also a bit your process about keeping the code base clean, managing technical depth? As I understand you use your own product on your own code base. Do you use other Clojure available tools like CLGCondo?

Adam Tornhill

That's a good question. mean, a year ago, I could probably have answered that. Now the answer is, I don't really know. I know that the team are constantly evaluating other tools too that might catch a different aspect that we don't look at with codes in. One example is scanning third party dependencies for known vulnerabilities, right? We use tools for stuff like that.

If you want to call it a success of raw, we kept the company alive for nine years. We've been constantly growing and expanding. I'm super personally, super proud of that because it's, it's been hard. But one key to that is that we never allowed technical debt to grow. We never allowed our code to deteriorate because if we would have, then it would be virtually impossible to, you know, stand up to the needs we have today. We constantly need to evolve the product and you know, adjust to changes in the environment, in the integrations we have, but also develop better and new capabilities.

So what we did was that we always use CodeScene on CodeScene itself. And the way it works today in practice is that we have an integration with pull requests. We're using pull requests, super shortly branches, but we find it a useful communication point. So in pull request, CodeScene automatically goes in and reviews my code for code officials. And if there are any issues, then I'm expected to fix them.

However, since last year, we built a new tool. It's called CodeScene CLI. It's basically a command line tool that you integrate via pre-commit hook in Git.

So the moment I try to commit some code, CodeScene is doing the review locally, right? And if I introduce some code officials, I know about it there and I can fix it and I can push clean code to the PR. So we find that we identify less and less in the PR and more and more when we write the code. So this has been one success factor. Another success factor has been that CodeScene is not only an analysis tool, right? It's also a visualization tool. So it visualizes code.

And that has been super useful for me now that the team has grown. There's no way I can keep all of that in my head anymore. So to me, it's very, very useful to sit down, look at the code-based visualization, and have a mental model of what the code looks like. It makes it so much easier to have technical conversations with the team. It saves me a lot of time.

Artem Barmin

And is it hard to add support to CodeScene for Clojure language? As I understand, as I can imagine, your main clients are not using Clojure in their production databases. So it's probably Java, C#, something like this. And you still need to manage the pretty large Clojure plugin to do this analysis.

Adam Tornhill

So Codescene supports, I think, 28 different programming languages now. So we have a massive list of programming languages that we support. Some have been more painful to support than others. Clojure was actually quite straightforward. So we decided to support Clojure very early on. I think, in fact, it was the first language we did, even if we didn't announce it, because to me, it's always been important to eat your own dog food, right? So if we couldn't analyze our own code base, it's very hard to recommend someone else to do something you don't do yourself, right? So, so yeah, it wasn't that hard.

Keeping up with Clojure has been a bit easier because one of the challenge with supporting so many languages is that a lot of them are not stable. If you look at Java, how much it has changed over the past 15 years, it's ridiculous. It's like a completely different language now than it was 10 or 15 years ago. But Clojure has been, and I think that's the beauty of the language. It's been very, very stable at its core. There hasn't been any large changes. And that's something I really, really appreciate.

Artem Barmin

I'm curious, do you have commercial installations of Clojure part of CodeScene?

Adam Tornhill

Yes, we do. I know that for a fact that we have a couple of them. I know some are startups, maybe of our size, so like 15, 20 developers. And I know at least one other is a much, much larger client. But I don't know exactly how much Clojure code they have.

Vadym Kostiuk

I have a question. While you were speaking, it reminded me of a few conversations I had with our partners from different companies and where they had some discussions about whether it was to move from Clojure to some other language.

So, for instance, we had at least about three partners that moved from ClojureScript to TypeScript. And some of our partners also removed even a certain functionality written in Clojure to Golang, to Erlang, I believe, and even moved to Node.js. For different reasons. Sometimes it's hard to find a skilled engineer, sometimes it's just hard to maintain it or just want it to move to a more  mainstream technology.

So the question is, have you had any, at any point, have you had an internal push to move from Clojure? Maybe not entirely, I understand it, but at least some parts.

Adam Tornhill

No, never. I we are, I think it's the perfect fit for what we do in our analysis engine and backend. What we have done is that we are not doing, most of our user interface isn't done in Clojure. There we decided to use, we use mostly TypeScript. And I think that that's pretty fair because you don't have, you don't really have that complex calculation needs there, right? The algorithms are much, much simpler. The challenges are very different at the front end, right? There are other parts that are hard.

So we have a hybrid code base in that sense, but the whole back end is Clojure and we don't plan to move away. We didn't have any desire to do so. What we did was that a couple of years ago, we implemented a Jenkins plugin for CodeScene and it's open source.

What we did was that we decided to do it in Java, not because we are big fans of Java, but simply because we wanted to encourage third party contributions to it. And I think there more people that know Java simply in that ecosystem.

And I personally struggle with moving between the Clojure code and Java code because it's, you know, once you're used to Clojure and how expressive it is, it feels challenging to move back to, you know, mutating state all over the place. There's simply a lot of accidental complexity in mainstream languages that I don't have to care about in my Clojure day job. I think mentally for a Clojure developer, it's probably hard to move back to mainstream technology.

Vadym Kostiuk

Yeah, definitely. And, in your opinion, based on your experience, I mean, you've been in Clojure for over a decade now. What could be the main factors that could drive other teams actually to move from Clojure? I just want to explore a bit this area to understand better: what currently locks in in Clojure environment that could potentially drive out some of Clojure products from Clojure.

Adam Tornhill

I think there are a couple of things. So as much as I love Clojure, there are certain domains and problems where I wouldn't use it. So one obvious is I used to work a lot on real-time systems, systems with soft real-time constraints. And there I would probably not use Clojure. I would go for something like Erlang or maybe Elixir these days, right?

And also at CodeScene, I'm also part of CodeScene's research team. We do a lot of research around code quality and try to correlate it with the business impact and velocity and all of that. And as part of that, we obviously do a lot of scientific calculations. We also do lots of machine learning for our AI. And for these domains, I simply found that there are better choices.

So we always use Python for that. And it's not because Python is so better language. I mean, Python to me, it's probably my second favorite language. Right? If there wasn't a Clojure, I would probably go for Python as my default. But the main strength with Python is that it has this extremely rich ecosystem, right? So everything you need, it's there and it's up to date. And there are so many large corporations that invest in that ecosystem. And we simply don't have that on the Clojure side.

There's nothing technically preventing Clojure from being great at say, machine learning. But in practice, I found that it's always much, much easier to do this stuff in Python.

So I think the type of domain is an important factor. And then I know, of course, from back in my consulting days, that there's also the political dimension that can push teams out of Clojure. Where, you know, company gets on your new leadership, they want to streamline the technologies, they want to optimize for ease of hire and yeah, these factors do come into play. Was that what you had in mind, Vadim?

Vadym Kostiuk

Yeah, definitely. And by the way, the very last thought that you just mentioned is when the political change, when the, let's say that the tech leadership changes within the company. We've seen it ourselves a few times and even we have a partner. So they've been bought by a much larger organizations and...

It was initially a small startup, like 10 people, two engineers that had been with this startup for over seven years, I mean, from the very beginning. And after the acquisition, there were a lot of conversations, whether they actually need Clojure and ClojureScript for the product. Just because then the main company, like they are heavily Java users. So it was much easier for them just to rewrite everything in Java and keep it up as a Java product.

However, it's interesting how Clojure stood the time within the company because for over a year there were different discussions about how it will be rewritten in Java or whether they need it or not.

That during this period of time, these two engineers were able to achieve like a lot, a lot of tasks, everything been done, the integration to the main product being done during these discussions. So just, they were able to actually show that Clojure is more convenient, simple, and basically efficient for this certain product. So even after the acquisition, even though they have lots of Java engineers in-house, it is still a Clojure and ClojureScript-based product. Unfortunately, we also had different samples where Clojure had been just squeezed out because of this.

Adam Tornhill

I have a couple of examples myself that I think are related. So years ago, 10, 15 years ago, I tried to evangelize a lot of functional program languages because I simply think Fogtick could be a very good fit for the type of problems we were doing back then at other companies. And I more or less given up on that since then. And I feel a bit better about giving up after reading Paul Graham's "The Secret Weapon", right?

I think the essay is called "Beating the Averages", where some think that if people want to stick with other technologies, please do so. There might be good reasons for it.

And even if there aren't, Clojure is our advantage. But I remember something that really, really made me understand the political dimension of technical choices. That was maybe 15 years ago. At that time, I worked for a fairly large company. And they were doing a new product. They were investing in a completely new platform. And that platform was supposed to have soft real-time constraints. It was supposed to be massively distributed. And doing distributed systems 15 years ago wasn't as straightforward as it is today, right? So there was no concept of like microservices. No one even had heard that term. It wasn't invented yet, right?

The language of choice back then was Java. It was a Java shop. So we did one prototype in Java to kind of have a proof of concept and something to play around with. at the same time, I had started to get interested in Erlang. And I kind of thought that this sounds like a really, really good fit for Erlang, right? So I somehow managed to get a small budget to do a prototype in Erlang.

And I presented to management later that, with the Erlang solution, not only could we implement it in half the time it took us to do the Java version. And that is given that we were all experienced Java developers and no one knew Erlang before we started, right? Half the time. We had, I think, more features in the Erlang version. It was more stable, right? You could walk around and pull network cables and the system just kept recovering. It was amazing. It felt like magic. And finally, the amount of code was one fourth the code we had to write in Java.

And to me, being a technician, probably way too naive, I expected this to be a no-brainer. mean, of course, we choose the best tool for the job. It's going to save the company a massive amount of money.

And you can guess which technology that won, with the motivation that there are so many Java developers already, it's easy to hire them. And I think it's based on a very flawed idea that you learn a language and you never ever have to learn anything again, which we know is simply isn't true because if you haven't stayed up to date with Java over the past 15 years, you will write a very outdated form of Java today, right? You constantly have to learn new stuff. So yeah, that's one of the more stories.

Artem Barmin

Yeah, that's really fun. I heard the story when two Erlang engineers support the part of the system and other part of the system supported by 40 Java engineers. And they're doing basically the same amount of job.

So yeah, I'm really curious to ask you about the choice of TypeScript for frontend. So actually you already had experience with Clojure. You had experience probably with ClojureScript and you evaluated it, but why did you end it up with TypeScript?

Adam Tornhill

So TypeScript, in the early days of CodeScene, we tried to do as much as possible server side. So we used like Selmar templates and generated a lot of our HTML views that way. We used a bit of JavaScript, but it was mainly to drive the visualizations. So CodeScene is extremely heavy on visualizations.

But what we found was that, I think that's maybe the largest shift since 2015 that as consumers or technology users, we have come to expect much, more from a user interface. So we simply had to invest and focus a lot on improving the whole user experience. And it's something that we kinda keep working on a lot.

And I personally didn't really make that decision on, hey, let's use TypeScript. My tech leads came up with that idea. And I think it's a pretty good fit for us. I think it works well. I think TypeScript is a decent enough language. I don't feel that for that purpose and that domain, I don't feel that people are less productive than they would potentially have been in Clojure. But front end is not my experience, my expertise. So there might be others that have more insights.

Artem Barmin

I see. Yeah, actually I had troubles finding good fit for ClojureScript developers because that's not only the ClojureScript parts, but also a huge React, JS and all this modern front-end infrastructure and ecosystem. And the developer also should be knowledgeable, not only in Clojure, but both in this huge, huge, huge part.

So yeah, sometimes it's much easier to find people for front-end, especially with such expertise.

Adam Tornhill

I think so, and potentially the leverage you get from a power technology that Clojure is smaller on the front-end than on the back-end.

Artem Barmin

Yeah. Yeah, actually, this blog will be about Clojure as go-to tool for the new projects. And I have a personal story. So several months ago, we inside the Fresh Code started a product. It's deeply connected to what we are doing for our customers. So we are doing outsource, basically. We're doing project-based development.

And it was for me, it looks like a great idea to build some kind of low-code tool that will help us to do most repetitive tasks in almost no time. And I decided to choose Clojure and ClojureScript, by the way, for this project. And I was really curious to hear your opinion. So would you choose Clojure if you would start in 2024 the new product?

Adam Tornhill

Yes, and I can answer that with confidence because we actually did. So we've been having the CodeScene tool, the core product on the market since 2016. But earlier this year, we launched a new product. It's called Codescene ACE and it's a tool that automatically fixes technical debt that CodeScene discovers, right?

And we built the whole service in Clojure. And then we integrated into IDEs like VS Code, where we obviously use TypeScript because that's the way you do it in VS Code. But the back end and business logic, everything is in Clojure again.

Artem Barmin

Interesting. So that's a fresh new product, yeah?

Adam Tornhill

Yes, it is. is something I wanted to do for many, years, but the technology simply wasn't ripe enough to take on that challenge. But now with the rise of all these powerful LLMs that are accessible, we thought that now we can finally pull it off.

Artem Barmin

Interesting. So did you use your prior experience and your existing team to run this product or did you create a new team for this?

Adam Tornhill

No, the whole team was like, you know, recruited from the core product. So it was people that already had a lot of experience with our domain and with Clojure.

Artem Barmin

And how do you assess the current state of Clojure itself as a language and its ecosystem? And can you make some forecasts for three, five years? Where will be Clojure after?

Adam Tornhill

Yeah, so I think my observation is that Clojure had much, much more hype behind it 10 years ago. There was a point, I think it kind of coincided with the rise of microservices, which was also like 10 years ago, that now people were free to kind of choose whatever the technology wanted for their services. And I kind of felt that Clojure is on the verge of becoming a mainstream language.

So, for some reason, that never really happened. I still think that many, many companies are using Clojure, but it just works so well that there's not much fuss about it. But to me at least it seems like the hype has died out a bit. Clojure doesn't have as much visibility in my opinion as it used to have.

My prediction for the future is that Clojure has been super stable for a long, long time. There is a strong community around it. It operates in one of the most powerful ecosystems there is with the JVM. So I think for the next 10 years Clojure is definitely here to stay and have a hard time seeing what should replace it.

Artem Barmin

Yeah, yeah, that's true. It's interesting to ask you the question in five years, would you start a new product in Clojure?

Adam Tornhill

Yeah, we'll see.

Vadym Kostiuk

Yes, I just wanted to ask, we've been asking you lot of questions basically and maybe you, I'm sure you had some expectations for this podcast, for this talk and maybe you can think of the question that we haven't asked you but you wanted to discuss.

Adam Tornhill

Oh, that's a good one. Yeah, maybe I was, I'm happy that you didn't ask more technical questions because I'm kind of feeling that I'm probably a worse programmer today than I was a couple of years ago, but...

Maybe you should have asked me if I still do coding or if I'm a full-time manager.

Artem Barmin

So are you doing coding?

Adam Tornhill

Yes, I am! And I'm not as much as I would like, but I make sure to get in five, ten percent of my time at least every single week. Because I found that if I don't, then these skills, they grow really stale. It's really hard to kind of have a technical discussion. It's really hard to coach the team. It's really hard to help them out if I can't lose the foundation. I think that's super important.

Artem Barmin

And what kind of technical tasks are your favorite?

Adam Tornhill

So my favorite, I kind of enjoy the analytical parts. I think what I do best is to work close to our core metrics, our code of metrics, hotspots, that type of stuff. I've also been doing a lot of hands-on work with AI product we're building now, the automated refactoring tool. That's also something I enjoy a lot. Basically, I like everything that has the potential to have an impact on our customers and how they value and use the product.

Vadym Kostiuk

That's interesting. And given to attention that you have, as you mentioned, not a complicated, but rather an efficient workflow within the team and even the engineering manager, how do you fit into this? Do you have someone assigning tasks to you or are you picking some tasks that you'd like to work on?

Adam Tornhill

So I tried to mix that up a little bit. What I try to avoid, I'm not always doing a good job at that, but I'm trying to stay out of the hot path. Because I know that my days can be a bit unpredictable. I might have to jump on a conversation with a client. I might have to travel somewhere. I do a lot of conference talks.

So I never want to be on the hot path where someone else is depending on me or I block someone else if I don't do my job on time. So at the same time, I think there are some things that I have a certain experience with and where I can contribute the most to the team. So I kind of try to do that. I also try to take some of the boring tasks or traditionally boring tasks. I actually enjoy them like documentation.

Vadym Kostiuk

Documentation, really? Wow, that's unexpected because everyone likes documentation, I mean, to have it on the project, but it's a rare case to meet someone who really likes to keep it up to date and actually write it. So it's interesting.

Adam Tornhill

Yeah, I just think it's a lovely challenge, right? To take something quite complicated and try to explain it in accessible terms. I kind of like that challenge and I think it helps a lot with my personal learning as well. So it's a task I enjoy.

Artem Barmin

I agree, I totally agree because documentation I can treat as a very good investment in the future of a project because every person that will come after me and will read my explanation will gain much better understanding than just reading the code base.

So actually that's a pretty common way of managing projects. I've seen this a lot when founder of a Clojure company, still doing some programming in 10 years. And when team is pretty big and everything can be done on the team side, founders still love this part of doing things. And for me, that's something about Clojure itself. Because it's fun, because it's pleasant experience.

Vadym Kostiuk

So Adam, as you recall, I mentioned before, we had a first podcast with Kalle. He's a chief product officer at Quuppa, Finland company. And he asked you a question. And later on, I'll ask you to leave a question for the next guest.

So the question is, what is your experience with AI? Have you used any AI with Clojure? And if you know, what is the tool support for AI in Clojure? So this is a question from Kalle.

Adam Tornhill

Yeah, interesting. yes, have lots of experience with AI. As I told you, we're developing an AI product, right? So it's my job. And my experience with AI in general is that out of the box, on LLM has an extremely poor understanding of code. They will mess up your code more often than they will solve a problem for you.

With respect to Clojure, think what I see in our data is that it gets slightly worse because I think the LLMs simply don't have enough training data compared to the mainstream languages, right? If you look for, I don't know, JavaScript or Java, there's massive amount of training data on GitHub, but there's not so much Clojure code. So my experience is that the LLMs tend to do a worst job on Clojure.

We are not using any AI tools for our Clojure coding right now. What we do want to do is to use our own CodeScene Ace product on our own code base, but that has a different purpose. It's not so much about helping us solve a problem or generating more code. It's about, you know, fixing something, improving the internal structure in a predictable way. So I hope that serves as an answer?

Vadym Kostiuk

Yeah, definitely.

And if you can name it maybe from the top of your mind, where the person that is interested in learning more about Clojure with AI, where this person can find the information or where to look it, or it's totally distributed through different chats on Reddit and specialized, I don't know, communication in Slack. Yeah.

Can you give some advice for this person?

Adam Tornhill

I haven't seen much with respect to Clojure in that context. One starting point that I could recommend is we, me and my colleagues, wrote a paper a couple of months ago called "Refactoring vs. Refuctoring" on how we can use AI to improve code. And it's like, I think that might be a good entry point if you kind of want to explore AI coding in general, because it's so, really, really overhyped topic right now.

There is some substance in it. There's a lot of valuable stuff that an AI could help us with, but there's also a risk with like overselling it. So I think that paper kind of, you know, it's proper research and we try to write it in an accessible way. So I think that can shine a little bit of light on what you can expect from AI, whether it's Clojure or something else and what the possible pitfalls are.

Vadym Kostiuk

Yeah, thanks for that. Thanks for that. I'm sure that Kalle will be excited about hearing your response. Maybe a bit sad about the content, but still, it's nice to have a good advice from the one person who already explored the area. So yeah, thank you very much for that.

So coming to the next question, I would like you to ask to leave the question for the next guest. Anything you'd like Clojure related or running Clojure product related.

Adam Tornhill

Yeah, I actually have one question and the question would be:

If you could fly back in time 15 years, have a conversation with Rich Hickey, what would you convince him to do differently in Clojure?

Artem Barmin

Very interesting.

Vadym Kostiuk

That's a really interesting question. I even imagine how the next person will think about the answer carefully because it's hard to generate the response on the fly. But definitely an interesting question.

Artem Barmin

And what would you change? We can cut this off just to make it interesting for the next people, but I'm really curious.

Adam Tornhill

I honestly don't know, but I'm genuinely interested, right? There are some aspects of Clojure that I didn't like initially, like small, small stuff around the syntax. But now I've gotten so used to it that I cannot imagine being without it, right? So it would be super interesting to hear an answer to that question.

Artem Barmin

Personally, I probably would focus on tooling and onboarding new people from outside of Clojure ecosystem. Because, you know, we've made a research maybe a year ago of tracking metric time to hello world, what we call it.

And for common languages like Go, Rust even, it's very easy to get started. And for Clojure, people spend hours, know, install JVM, install Leiningen or not install Leiningen. How should I understand? What should I use? And all such different questions and people struggle to get started with Clojure. And if you have a person nearby that can coach you and teach you, it's very easy to get started. But otherwise... That's hard.

Vadym Kostiuk

As soon as we'll have a to this, a response to this question, I'll inform you immediately, Adam

Adam Tornhill

That's very good. I'm looking forward to that.

Artem Barmin

Yeah, great.

Vadym Kostiuk

Thank you very much for joining us, Adam. It was truly an interesting conversation to us. And thanks for telling more about CodeScene and about your vision of the Clojure and how it will evolve through the years. I wish you...

Adam Tornhill

Well, thanks a lot for the conversation. I really appreciate it. And thanks for all the interesting questions and insights.

Artem Barmin

Yeah, thank you for interesting answers. I really was really curious to hear all these stories.