Intro
Vadym Kostiuk
It gave you an opportunity to develop their own product with a small team. Just because you don't need like 20 Java engineers, you can have like three to five Clojure engineers.
Artem Barmin
Is it moving forward or it's stagnating?
Marten Sytema
Yeah, so three answers to that. You can have a monkey and a logo and who doesn't want a monkey and a logo, you know?
Vadym Kostiuk
So for the early startups, the overengineering might not be a problem. The problem might be, is actually under-engineering.
Artem Barmin
Guerrilla tactics, yeah. I met this on my previous job 12 years ago when I brought Clojure into QA department.
Marten Sytema
I'm not really risk-shy on that. I'm always like, well, I kind of figured out, probably.
Vadym Kostiuk
So once you try Clojure, there is no way back.
Marten Sytema
It's just my de facto language until the day I quit or die.
Artem Barmin
And right now, how do you evaluate the state of ecosystem? Is it getting better from year to year, or anything else?
Marten Sytema
I can rant about this forever. I think that's the whole problem with Clojure adoption. It's not that everyone tried it and then went away. It's like most people don't even try it.
Artem Barmin
Hey guys, welcome to the third episode of the podcast, “Clojure in Products. Would you do it again?”
Vadym Costiuk
And today we're meeting with Marten Sytema, the co-founder and chief technology officer at Catermonkey, based in the Netherlands. Catermonkey is a cutting-edge web platform designed to simplify daily operations and drive sales for catering businesses.
Artem Barmin
And today more than 200 event venues, food trucks, and other catering companies across the Netherlands and Belgium are benefiting from using this product to optimize their workflows and grow their businesses.
Vadym Kostiuk
Yeah, and we will also hear a response to the very interesting question passed from our previous guest, Adam Tornhill, Chief Technology Officer at CodeScene. And the question is, if you could fly back in time 15 years and have a conversation with Rich Hickey, what would you convince him to change in Clojure?
Artem Barmin
So let's begin to map over questions and macro-expand them into real-life Clojure experience.
Full Text
Vadym Kostiuk
Hello, everyone. Hello, Marten. Thanks for joining us on our third episode, “Clojure in Product. Would you do it again?” Today, we'll talk a lot about your personal story with Clojure and your experience in building your own product as a solo engineer. But to start, I would like to ask you about how the idea of creating your own product came about and what is actually Catermonkey?
Marten Sytema
So, Catermonkey is a niche product for catering businesses. It's a web app where a catering business can organize themselves. So it helps with estimates, price quotes, and invoicing, as well as everything kitchen-related, like prep lists, all kinds of know, overviews, and reports.
And also there's like a calendar in it where you can just see what you need to do. Basically, it's basically a to-do list app, but then way more than that. It's like an ERP, but then really focused towards catering businesses. So with a lot of kitchen stuff.
So, having said that, the idea came about when I basically from in 2011, which is a long time ago, but then already someone, a catering business, asked me to develop, as a freelance developer, a system specifically for them to organize themselves. And I was kind of looking for a good idea to make a SaaS web app because that was kind of my ambition and dream to work on a product rather than work on services, which in the service mode, which I was doing most of the time. This felt like a good idea. And I saw in, at least in the Netherlands where we're based, there was no competition in this actually, or not much. So I thought, well, this is worth pursuing.
And then I grew it small, bootstrapped it basically as a side project for a few years, got like, I don't know, 15 or so customers. So it was all right, but it never really took off. But I knew that I solved the problem.
And then, at some point, one of my customers, which is now the co-founder, said like - he's from Belgium, which is bordering the Netherlands and we speak the same language, which is Dutch. And he asked me like, can I sell this software in Belgium? And I was like, yeah, but I have a 2.0 version in my head because the 1.0 version was made in Java and Google Web Toolkit with Spring. I got more and more frustrated by Java in this year.
So we're now like 2017, 18-ish. And I already dabbled with Clojure, like with one of the freelance projects, and like a lot of hobby and I was determined like the new 2.0 version will be in Clojure, ClojureScript like all in on the tech stack basically because I loved like things like the reframe and then you know all the good stuff like on the front end as well and Figwheel back then and now Shadow and I was like okay we should make a 2.0 version and then join team because I'm a I would say I'm, I'm decent as a CTO, but I'm not a really good entrepreneur in like the commercial marketing kind of stuff. And he was very good or is very good at it.
So in 2018, we really made the Clojure version and launched it in 2019, January 1st.
Vadym Kostiuk
Nice. And back then, in 2018, why have you decided actually to have this, like the 2.0 version of the application in Clojure?
Marten Sytema
Three answers to that. So I had one big project for another SaaS system in the Netherlands for recruitment that I built in Clojure from 2016 onwards, like just as a freelancer. Basically, I built it for someone else, basically, not like my own product, but I just, as a sole developer. And I could choose the stack on that point.
It was 2016 and I went for Clojure because I had some hobby projects in it. And I was like, okay, the next web app will be in Clojure and ClojureScript. I did that and I loved it. Actually loved it. So every time there was like another freelance gig or something or a little project for existing customer, they wanted some customer of mine wanted a very different, they wanted like a portal for something and I built it in Clojure. So I already got some smaller projects going on. It just fit like a glove, like the ergonomics about it, everything about it, I kind of loved.
So, and I wanted my own product. still wanted, I still had one, but it was not really successful at that point. So I was like, okay, this 2.0 version will be built in Clojure. I've learned a few things now in the two years that I'm doing this. So yeah, so I couldn't wait basically. And then we basically just went for it.
And the idea of like the business idea of the app and what the app should do, that was already very clear. I had a lot of experience in the years of 2012 until 2016, what works and what didn't work, for instance, and what was good about the app and what was not good about the app. So I had a lot of domain knowledge at that point. Yeah, I was just ready to make it really a nice-looking product, a product with a better name. So we, well, better name, it's subjective, but...
You know, we went to Firefox, serving monkey kind of route. So I'm not sure if that's a good idea, but at least it's catchy. You can have a monkey in your logo and who doesn't want a monkey in the logo, you know? So yeah, so that was, that was really, and then the fun began. So that's, that's basically why I went this route. Yeah.
Artem Barmin
Interesting. Thank you. You know, moving from a hobby project to a real production business that you are, depend on is a big step. So have you worried about something when you started this second version of a project?
Marten Sytema
Well, I did some spiking, would say, like just like seeing, okay, you know, okay, line Uber jar. Okay, now I have a jar. Okay, I know jars because I deployed jars before, you know? So I kind of felt, and the database was still SQL, what I was using. So I felt that I had enough stuff that I knew and to basically say, I can do this.
There's a lot of resources also available. Well, if you look for it for like how to host it. So that also gave like blog posts and stuff that gave me confidence as well. I'm not really risk-shy on that part. I'm always like, well, I kind of figured it out. It worked kind of, and sometimes something doesn't work and then I just have to make sure it does. So yeah.
Artem Barmin
And aside from deployment parts, have you some worries about Clojure as a main technical stack? You know, if it's a business, it's more about organization, people and maybe such kind of stuff. Have you thought about such things?
Marten Sytema
It's funny. I actually saw it as an opportunity rather than as a risk. Well, it's my psyche, I guess. I could move very fast because I know and there was confirmed when I worked on his recruitment app in 2016 to 2018 that I could get stuff done having way more fun, which is an important aspect I think.
Like the ergonomics of it was it was so fun to like to craft with Clojure as opposed to typing a new hash map and then the little thing sign and in Java because that was so it felt so shoe horny in a way.
And also the object-oriented stuff, I got less and less in favor of it as the years went by. And then I thought back about my one class I took in university in 2008 in functional programming, the elegance of it, and that kind of stuff really came back. But it still was very pragmatic. And I'm kind of in a pragmatic kind of way. Because I tried Haskell as well, which is nothing bad about Haskell. I kind of like it.
But at some point it's, I would say it doesn't fit the way I think basically, not as well as Clojure. Clojure is like, it does not get in the way, it doesn't get in the way, it works for you, and you have this short feedback loop, and it's the way I think. And this is like the programming language that fits really into the way my brain works. So yeah, I love it. So I saw it as an opportunity actually, rather than like a risk.
Because I was the sole developer at that point anyway. The one thing I thought, because I have a good friend, Python developer here in town, a good friend of mine who asked you, but when you hire people at some point, aren't you worried you can't find anybody? And I had a little bit of worry, but then it turned out it wasn't that hard actually, because there's not a big pool of developers.
That was the one risk I saw basically, but it turned out not to be a big of a problem because there's maybe a small pool of developers relatively, but the quality of them is very high. That was amazing to me, as always. And also people who get it and like think like me, they basically want jobs like this. So we do have remote, a team of remote developers now. So that's maybe one trade-off.
So it's an illusion to say, like in this rural part of the Netherlands where I'm at, there might be two or three Clojure developers, if at all. But if you go a little bit further, like Amsterdam, Paris and all that, well, it doesn't really matter, right?
Artem Barmin
Yeah, yeah, yeah. I heard the idea that Clojure works as a filter for developers.
Marten Sytema
It's actually what I was saying to this mate of mine who asked this. Another friend of mine was also a co-founder who works with PHP. And.. well, it sounds arrogant, but he said, like the PHP founder, big company now, and all that. He said, like, there's a lot of programmers or people who apply for our jobs, who aren't really good for lack of a better word.
But whenever we had interviews, In general, I was kind of impressed always like, I can learn a lot from you. From you, know, so like stuff like that. And also, I had one Clojure gig in 2017, like as a freelancer, I joined a very big corporation, and in the Netherlands, like an energy company, we worked with a small R&D team in 2017. Basically, I joined it just to see if I can work in a Clojure team and just...
It wasn't really my career goal or something like that because I already had the idea of this, building my own app and all that. But I learned a lot of stuff, also about the practical day-to-day stuff like the tooling and the editor and Cider. I'm kind of a FIM user, but I also loved Cider. And then someone told me about Space Max. And that was, again, was like, this is like, for me, that was like this. That was pretty fun as well.
Vadym Kostiuk
On our recent episode, we talked with Adam Tornhill from CodeScene. And he told us that at the very beginning, when he only started the company, he had to compete with large companies. It's probably fair for every startup nowadays. And he mentioned that Clojure actually gave him competitive advantages in terms of developing their own company.
He was talking about moving efficiently, faster, and most importantly, it gave him an opportunity to develop their own product with a small team. Just because you don't need 20 Java engineers, you can have three to five Clojure engineers. Thinking of the early days of Catermonkey, do you think that Clojure gave you some competitive advantages or opportunities to overcome the competitors?
Marten Sytema
Yeah, well… The good thing about this product is there wasn't really much competition. There was like one system that was like a desktop app in the Netherlands and Belgium where we were at first going. Most of our potential customers just use Word and Excel and then they do it in a way that they're not tech savvy. So just leave it at that.
So there's still a big opportunity for us in this, even in our countries, but also we get requests now from Germany and from the UK and from France, like, hey, when will your app be translated? Because it's such a vertical, it's such a niche product. So the competition aspect wasn't really a problem. Say a friend of mine that I just told to the PHP, he had a product; there were way more apps in competition with it. So for them, it was more of an issue, I would say.
But for me, it wasn't kind of. But I had the competition kind of with myself. Like I could see that I was developing so much faster when I switched to Clojure, even before Catermonkey, like with the recruitment app I was building. I knew what I, how fast I was like before. And then I could basically compare it. Like I was like, this is way better, way less friction, way more to the point, way less code.
And it's kind of funny, like it's now 2024 and it was 2016, so it's eight years of code. If I look back at eight-year-old Java code of mine, not that I became so much better at Java, I didn't, but it's just like, how was this class structure working again, all that? And now if I look back at eight-year-old Clojure code, all right, maybe I used a little too many lead bindings by then instead of trying, you know, kind of those things, but in general, it's really like, okay, I can touch this again, and it doesn't feel like old code. Like, remember this? This is how we do it.
But with JavaScript, it's even worse. I mean, I don't even know like JavaScript nowadays. Like all the syntax is going on. I always have to kind of look it up because I'm abstracted away from it, like through ClojureScript and just everything is the same toolbox again.
So I knew that it was a better way to do things. And I knew that I never needed 50 developers in the foreseeable future or something like that. So that wasn't; it was strategic for me to use it basically, just for my own.
The thing is, if things go fast, there's, there's this secondary effect. If things go fast, you love what you're doing. And the short feedback loops give you this little rush all the time. I knew when Figwheel came out, you know, that was like, this is, this was what I needed, you know, and now, of course, you can choose between Shadow, GLAS or, but the thing is that like you're editing something and it's in the screen, it auto updates. That feels so fast. It is fast. And, and you kind of feel you have superpowers in a way. Yeah. So it's cool.
Which is only a tiny aspect, by the way, of what the benefits of Clojure are. It's just like the front-end part and the feedback loop in that. There's so much more like there's data going over the wire, and you have code that is just CLJC files, and they both on server side and client side operate on it. And there's not even, like, any friction or conversion or almost, which is amazing as well.
Artem Barmin
So you mentioned the early days of a product and it's really interesting for me. So how the newcomers in Clojure start building the products? Have you noticed sometimes that the flexibility and ability to do anything in Clojure leads to over-engineering, and you need to refactor things afterward? Because your project has a pretty big lifespan. So maybe you met some bad decisions that you've made before, and you need to somehow to refactor them.
Marten Sytema
Yeah, the funny thing is, I think actually it is less than compared to what I used to do in Java, like way less.
I'm not really using like those interfaces a lot and the dev types, but I'm basically just using functions, like just functions. If you're squint, right? In general, you know, multi-methods and stuff I do and all that. The macros kind of like don't, really, I'm a power user of macros; I use it here and there. But then...
What happens is you have functions, and you have data, and you know, that's it. So, in general, if you can do any kind of pattern like that in Java that has a special name, there's one that I think that in 2016 or something, there was a blog post about it like, is the adapter visitor pattern adapter, well, a lot of patterns. And then it's like, it's just in Clojure equivalent. It was just like functions.
And that's basically the burden that fell off my shoulders because I knew all these patterns. I have a degree in software engineering, and I learned all these things, and it's so cumbersome, actually, if you think about it. And now it's so much simpler in the rich, shaky sense of the word. My code is kind of okay all the time in general.
Of course, sometimes, as I said, like, you grow a function too big and you get these big lead bindings and stuff. But at some point you can kind of easily, quite easily refactor it because you kind of use pure functions anyway. And at some point, you get better at the specific part. So you do that like from the start rather than refactor it after the fact. So that is what I would say experience gave me, at least. Yeah. So.
No, big refactorings we didn't really need to do. But on the other hand, must maybe put it in perspective a bit. We have a web app where the structure is kind of very in a way straightforward. It's like one jar deploys; there are no microservices. And the server side, there's like a database layer and a service layer. So it's kind of, in a way, run of the mill, architecturally speaking.
And also, on the client side, we have sort of like… We use Reframe, so with Reframe, it kind of tells you like, this is how you structure your code. And then we use names for the same name for every like domain aspect of the code, like invoices, price quotes, orders, you know, the things that are living in our app, in our domain. We use files in namespaces there. And then you basically can find everything. So the one thing is that maybe some files get really big with a lot of functions in it.
But even that is not, I never felt like that as a big problem, like big files with code, because you navigate using decider tools and all that to navigate from function to function. It's not in the way, it isn't in the, and then you can easily factor it out in new namespaces anyway. So I kind of feel I can keep my complexity of code under control to answer your question way better than I did with PHP in the past and with Java.
Artem Barmin
And do you use some techniques like test-driven development or generational testing?
Marten Sytema
Yeah, not really test-driven, like religiously, but we do use unit tests. Yes, sure. And that might be a thing that if you put things in pure functions, it invites you to unit test it so that works hand in hand.
On the other hand, sometimes you're going really fast in your head and you're on your screen with the outer, like in the front end and maybe unit test fuel at that point, like a burden. So I would say in the front end, we don't really use it a lot, but we just try to use, well, clean structures and that, but that's actually…
We don't have a lot of orchestration in structure, like with classes and class hierarchies, that you first need to understand to get going. It's just components, it's Reagent components. So, it's, everybody knows within our company, least, or who knows Reagent, kind of knows how they look. So you can just follow the code basically, and there's no, there's no, yeah, class castle in the sky with sort of interfaces and. Yeah.
Artem Barmin
As a person coming from a Java background, I can understand what you're saying. Factory, factories.
Marten Sytema
Yeah, factory facade. Yeah, abstracts.
Artem Barmin
Yeah. And all this stuff.
Marten Sytema
And not only that, you also need so much code, like to type it, to declare that you have a factory of adapters of interface. There's this one slide, like, where he, in a simple made easy, where he shows like, the Java equivalent of HTTP, where like get requests, set requests, get headers. And then he shows like just Eden data of, it's just a map.
And that's the thing that I can relate to Rich Hickey's charisma; he was one of the sellers as well to me because when I heard him speak in these talks, I was like, yes, this is what I mean.
And then that was basically a good selling point for me for Clojure. Like basically just watching his talks. And also Stuart Holloway, some other guys and girls as well. Those two, for me, they really struck a chord, you know? So he'll do. yeah.
Artem Barmin
We've seen the pattern from the guests of our podcast and from the projects that we've managed in FreshCode that technical founders in Clojure projects are usually tend to continue development. So do you do programming right now?
Marten Sytema
Yeah. Me too. Yeah. Yeah. Yeah. I'm not stopping, either. No, I love that. Because like...
We were discussing our dreams and goals in 2018 with my co-founder, Maty. I was like, I will continue to build. I'm not going to be a manager. I'm a bad manager. And I just want a small, focused development team at some point, that not all the burden is on my shoulders because in the beginning, there was downtime or there was something going on.
I was a sole developer in the beginning. So now we have a team, but like in the 2019 and stuff, it was kind of, it's nice that you can kind of share that burden, well - responsibility. And yeah, but I will be programming. But even if this will be a major success and someone buys the company or whatever, or I leave the company, I will be programming anyway.
Artem Barmin
For me, it's interesting how the technical, pure technical decision of taking Clojure, influences the culture of a development team. So how do you make architectural decisions? What kind of people are you hiring in your team? So it's a senior level or it's a middle or junior? So can you tell a bit more about culture of technical processes?
Marten Sytema
Yeah. And I will refer back to your word where you said filter. Yeah. Because that's basically what it does. Like, okay, we have a Clojure app. We wrote a job listing for Clojure development on functional works or something. We put it, we published it there.
There's already a filter like in the hiring process. Senior, junior and stuff is already a little bit less relevant. If this was to be done in the Lavarel PHP framework, one of the most popular ones. And then I put a job listing. I feel there's less of a filter.
So a lot of people apply because they know PHP, but you don't know how good they know it. But with Clojure, there's always sort of a, they get it, and they look for jobs like that. And so there's a filter, an intrinsic filter already. Like people get it and with it, mean like function composition, pure functions, composability, all these things that we like, like REPL Driven and all that stuff.
They get it. There's no one coming in here. I just want to learn Clojure. You hire me and then I can learn it. Those people didn't really apply. Most people who applied to the job, we hired two developers at once in 2022, 23, yeah, 23, year, beginning of last year. There were like 40 applicants, which was a lot. And like quality, like...
And basically, at some point we were like, okay, the first is nice if he can speak Dutch. And there were two Dutch applicants who had a good resume, you know, but in the future, if you hire more developers, it's probably not even a requirement to speak Dutch. But we only are in the Dutch market still, but next year we go, we’ve already translated the app and stuff. So going forward, English speaking will not be a problem at all and probably will happen when we grow our team. Yeah.
Vadym Kostiuk
I just have a question. So you've been talking about over-engineering, and when we asked Adam about over-engineering in our recent episode, he - actually surprisingly - answered with a very interesting thought. So for the early startups, over-engineering might not be a problem. The problem might be is actually under-engineering.
He mentioned there were some cases when he had to settle for a less elegant technical solution in terms of achieving the business goal, actually to promote the business. Have you had such cases building Catermonkey or not?
Marten Sytema
So, yeah, I was the sole developer at the beginning, and I am not really an over-engineering type of person who gold plates. Because that's like also a personality trait, if you are, if you aren't.
Go fast and break things is not really that, but it's more towards that end of the spectrum for me. And it's for me with everything. Like if you see my house, like at some point, it is kind of feels good enough and then I don't see anymore that I still have to fix that light bulb or paint this wall or paint, you know, because I can live in it. It's kind of, it's not explicitly mentioned that I don't have to do it, but at some point, I forgot to paint that wall. So that is my trait.
So I am prone to underengineering, I would say. Well, under, I'm not sure if it's engineering, but it's like finishing it properly, like finishing the details. But luckily, we have a nice team where there is kind of a balance in that now.
And also that I learn daily from them as well. Like we discussed these kinds of things, like, okay, maybe I'm too shortcut-y and too pragmatic. And maybe some other folks are, they polish too much and get bogged over. Should I use a treading macro or should I make a higher-order function? I think that's a balancing act for me. So, yeah, but I have under-engineering cases, yeah, yeah, where...
Well, unser-engineering is more like you haven't thought of everything for me. Like that's all right. I think I'm all right with that part, but like really finishing it like, like it's really finished. That's something maybe I should, I'm working on like say, so to speak. Yeah. Yeah.
Vadym Kostiuk
Yeah. That's interesting. I'm not saying about, you know, some delivering some bad quality features or something like that. But yeah, you answered the question. So it's, it's about actually finding the right balance between over-engineering and under-engineering and delivering the quality that is just needed in terms of having a good product.
Marten Sytema
Because you always have perfectionism. Maybe that's the word. Over-engineering is something else is perfectionism, but perfecting things is not always perfect. Because then often the time scale is ignored in perfecting something. By not meeting time goals because you're perfecting.
You're technically you're failing in a way you're not failing maybe in the quality of the code, but in the time when it was delivered. So there's always like an economic aspect as well. Being that in mind that aspect that like I'm not polishing everything also because there's it costs a lot of time. But of course, it's a spectrum. Do you do you do enough or not?
And also the fact that our application, I mean, a lot of people made way more complex stuff with Clojure than I am doing right now from an architectural standpoint. Like if you have a lot of microservices that work together and the performance of it and all that, by choice, keep it very simple. Like, the structure of a web app, like the architecture of a web app is really simple in a way that most web frameworks are kind of simple. We basically cobbled together a lot of libraries to build a framework.
But we value simplicity in just using basic building blocks and that also makes... But that's not under-engineering, that's just making sure you don't get too complex because that's the enemy of everything, I think.
Artem Barmin
As I said, the project lifespan is pretty big and I've seen several times when such long-lived projects in Clojure do need some refactor and maybe you can name some parts that were refactored or rebuilt from scratch or something like this for 8 years. Yeah.
Marten Sytema
Catermonkey is now launched in 2019. So 18, there was development already. So that's a little bit less time span. And the other one, the project I did before that basically, which was my gateway to professional Clojure, which was the recruitment app, which is still going strong. Actually, the funny thing, the hiring of our team went through the system.
And still, still again, if you go to our careers page on the Catermonkey site, you see a little forms thing, which is an integrated, you know, plugin for the website, which is built in Clojure, which was that thing. So that's kind of funny.
What did we refactor? Well, not really Clojure-specific stuff, more like, okay, we shouldn't store files on disk, but we should store it in like S3 buckets, more that kind of thing. Was it refactoring? Honestly, not really big things.
Well, function level, we do a lot of refactoring. I do. I have these things that grow. So we have one component or module in our system, which is by far the most complex, which is kind of an edge case for most caterers. Most catering businesses don't even do it. It's like daily meals for senior folks, you know, elderly homes, and also school meals and stuff, where the menu changes daily and is bundled up in weekly menus. It's like all kinds of complexity going on there, like dietary wishes. It's way more complex than just throwing a party with a buffet like most catering businesses do.
So in that, there's a lot of stuff going on, like calculating the right price, the right amount, which diets, all that. And in that, it grew small. It started small and then we had these really big lead bindings where all kinds of intermediate stuff is going on. And at some point, I was like, okay, this is too heavy for everyone, for anyone.
I never used that word, but like a pattern, like a higher order function kind of sort of threading, it wasn't with macro, but just with a function, I actually get this whole lead bindings gloss into nice little functions. And then there's like one threading stack of applying things in order and saving the intermediate results in a map that gets passed through. It's sort of a pattern. And that helped a lot. And now we use it on other stuff in the code where we see, here is it creeping as well, and use the same thing. Basically, that's a refactoring we do lately. And that would have saved me a lot of headaches if I had done that way earlier.
So, because at some point if it's in production and there's a request with a deadline on it, whatever, and or an issue, and you kind of put a little lead in the lead binding, you put a little binding, and then it grows and grows. And also, in the beginning, I had functions with two arguments, and now they have more arguments. That's actually a burden on, well, we'll get a little bit technical now, but it's a burden on two levels, of course. You can…
Because we refactor it now to pass in a map with options and then destructure it. And we should have done that earlier and more often or from the start more often. Because sometimes downstream, you split stuff up again in functions and again in function, and then you keep passing these five arguments through everything and everything gets a mess. Well, if it's a map, you can only destructure what you want.
It's way more clean. You cannot get the order wrong and all that stuff. So those kinds of effects we do. But in general, nowadays, we just do that right from the start, basically. So if we kind of say, like, if you have too many arguments, but you can, it's easy to fall in that trap if you're like not really experienced and you start with a function with two arguments, and then you add one and you, well, maybe you recognize this, but that happened with us.
Artem Barmin
Imagine in five or ten years, so your product became really successful, and you decided maybe to sell it to gain some investments or something like this. And imagine the situation in that you decided to move away from Clojure. Within such situations in our practice, can you name the reasons why do you think such decisions can be made in the future?
So moving away from Clojure to some...
Marten Sytema
The new big thing. Yeah. It's funny because I was asking myself this like up until 2016, that was what I was doing. I went from JavaScript framework one, two, three, PHP, web framework, X, Y, Z, Java's sort of the same thing, which kind of language construct was now. It was always more functional in the trend, but that was exhausting also for me.
But if I refer back to a little bit earlier, what I said, like old code, it's still kind of all right. It's called the Lindy effect when if something stays for long, the chance of it staying for much longer increases. And for me, I hope the Lindy effect applies to Clojure, meaning that it is just my de facto language until the day I quit or die.
And that sounds like a bit religious or whatever, but it is a genuine feeling. Like if there's something domain-specific thing that you, that there's not like AI or something, and you need to leverage all the Python stuff, maybe one of them, that could be one of the reasons that it already demotivates me to, to think about it. I kind of feel like I like my real language because it does feel like that.
I mean, for since 2000, I'm programming Clojure on a daily basis, and less and less in other languages. I mean, CSS is one of the only ones left. Even HTML is edited structurally now rather than... So yeah, I'm not seeing myself getting away from that.
Artem Barmin
Speaking about this linear pattern, I don't know how we should name it. Yeah, it's a very good explanation for me. Thank you.
The amount of code base and domain knowledge captured in this code base are growing, and it would be okay. Okay. Thank you.
Vadym Kostiuk
And you partially answered this question, but still, I meet a lot of engineers who are using Clojure day to day. And even we had a few podcasts before this one, this episode, and I hear the same words from them. So once you try Clojure, there is no way back.
And in your opinion, why do you think engineers just don't want to try or leave Clojure and stay with it after they actually tried Clojure?
Marten Sytema
Yeah. So you have to just list the things that you have now and then say, okay, you can't use it anymore. In any piece of the code, I can do a little hotkey and I see a prettyprinted situation of this far, the symbol, this whatever. I have scope capture, which is also a really nice plugin.
Condo and all that stuff. You have this REPL driven. You have this Shadow JLJS with the... Everything is a quick feedback loop. The REPL is so powerful. It's way more than just evaluating something. It's like a Swiss Army Knife that you can just inspect everything and save the intermediate state. Marten Sytemaaybe, I mean, I don't follow the other languages as much. I would almost say at all anymore. So maybe Python has a story like this, and for this, maybe JavaScript. But I doubt it.
And also the fact that it's, we don't talk about it that much, but like the structural editing, like the S expressions, like the concept of it, like the fundamental concept of it and the ergonomics of it, like with editing and racing and you know, I don't really know the names, but I know the hotkeys by muscle memory. Then you can forget like, what was it, racing?
It's this hotkey, you know. That would all be gone if I would go to most other languages. I'm not sure if there's any other language.
But if you haven't ever tried it, you don't know what you're missing. And I think that's the whole problem with Clojure adoption. It's not that everyone tried it and then went away. It's like most people don't even try it because in the most lists, in a big corporation, there's always one of the other Java dialects that has more users, and it doesn't matter if it's better, but it has more users, which seems like one of the most important requirements for people. But it's of course, it's silly. It's really silly.
But if you look fundamentally, like, and what do people do when they are lobbying, then they don't have a boss and the manager and the company policies, and they just choose whatever. And then there's a chance they drink the Kool-Aid of using Clojure and really get it because you do need a little bit of time with it to really get the benefits of it. You can get the conceptual benefit pretty quickly, but then like the day-to-day grinding of writing code, the ergonomics of it, I keep using that word because I think it's very important at some point when you get all the hotkeys in your editor right and it's almost like playing the piano where you know the song really well and you don't have to think about playing the notes and it's all by feel, that kind of excitement that takes a little bit of time, but then you cannot go back.
Unless there's a different language that has all the same traits. Like.. that's how I feel about it. I'm not saying it's for everyone like this, but that's how I feel about like using Clojure.
Artem Barmin
Let's move to our last blog. It's your thoughts about the ecosystem of Clojure. How it's for your opinion. Is it moving forward, or it's stagnating or…
What problems can you see right now in the ecosystem, in the community? What can you change, or what would you change if you can? And such kind of questions, you know, more about the overall scope of the Clojure, not about the project itself, but…
Marten Sytema
Yeah, I see. Like in the landscape of things. I'm not sure we're doing anything wrong. Like, it's just the...
In a way, it feels too foreign for a lot of people. So, the adoption question is like always the question. We don't necessarily need to strive that we are the biggest language in the world because you lose your filter. And I think that everything that we're doing, like people who don't get it, is not that they tried and don't get it; they just haven't tried. So there is the key to growing is that more people get to really try it.
If we can somehow make that appealing or normal, exotic, feels Haskell-like, it's only for, I don't know, academics, whatever, but it isn't. I mean, but that's maybe how it's viewed because of simply the, it's like the number of users, it's like below a certain level. So it must be niche and Haskell or exotic or esoteric or whatever sort of solve that. Then, we can get the adoption up.
But within the community, I think it's really nice. Also like old code still works if you can still compile and all that. That's a quality. That's not like stagnation. That's the opposite of stagnation. A lot of stagnation is by the fact that stuff gets changed all the time, and then old stuff doesn't work anymore. That's stagnation. But it feels like you're getting to use new tools. Yeah, but why? I can rant about it forever.
Artem Barmin
You know, that's interesting, but how we can explain this to other people in the industry that a library that doesn't have commits for three years, it's not that. It's a good thing. Yeah, it's really kind of an unusual phenomenon for the industry.
Marten Sytema
This is kind of hard to in bigger companies to make a Clojure happen just because it's not on way to not enough people's radar. It's not really a problem like the language is bad. It's like, it's just, you need some sort of tipping point or numbers if you really want to get to Python levels or whatever. But I mean, it's kind of sad. I mean, still, like on my university, the girl next door is going to the university now where I went to, like, and she asked me, can you help me with my programming exercise? I'm stuck, and I know you're a programmer. And it was still like, your Java, that's what it was.
Of course. Yeah. And then she said, no, no, next year the university quits Java and we go to Python. It's not that like they consider Clojure as well, you know, it's not, they didn't. That's sad a little bit. So the good thing is that everyone who works with Clojure is like intrinsically enthusiastic about it from the first principles because of the first principle of the language.
Artem Barmin
And you know, comparing the time when you started the product, it was six years ago. And right now, how do you evaluate the state of ecosystem? Is it getting better from year to year, or anything else?
Marten Sytema
Nice tools come up now and then. I'm always amazed with, amongst a lot of others, but I like what Borgdu, my fellow countryman, Borghendt always comes up with. It's always interesting to kind of follow that. But also, yeah.
Well, I lost, like, at some point a few years ago, told me about scope capture. Like, was like, this is like magic, you know? So it's like the tool that I use now so often to fix issues, you know? So that is innovation, I think, even though I'm not even sure how old it is, but maybe it's around for a bit.
To be honest, I don't really follow the cutting edge of the of the ecosystem that much. I am way too preoccupied by just developing every day. So I'm using Clojure like a gazillion times a week, hours a week. And my team does as well. But I'm not really like on the forums a lot. But that's me just basically I'm basically too, well, don't want to start out again, but I'm too busy like writing Clojure.
Artem Barmin
And the last question on this block from me. Would you take Clojure as the main technical stack for your product right now? If you would start today?
Martem Sytema
100%. Yeah. Absolutely. really, like no doubt at all.
Artem Barmin
I think everything else is covered before. Yeah, the reasons. Okay.
Vadym Kostiuk
One last, I guess, question is, is rather a question for advice. So as a person who wants to like choose Clojure for his own product, what would you say to others about the advantages of Clojure, maybe drawbacks that it brings to the business, actual business today that makes it a compelling choice for a new product?
Marten Sytema
The quickest way to develop and to... It's like prototyping. You can do very rapid prototyping, but it is seamless into product developing as a whole. It's like... It's so to the point, pragmatic, ergonomic, it's like short feedback loops, that's the best. If you have a, think about a slow feedback loop somewhere in your life, maybe, I don't know, your Windows laptop updating, know, whenever you, I mean, you don't have time for that anymore. I mean, your brain is disconnected. You think about other things.
People shouldn't underestimate, like, if the feedback loop is slow or if you don't feel like you're making progress, how demoralizing that can be in productiveness. Your productiveness can drop. And with Clojure, that's one of the main things that it is really quick. Yeah. But of course, you need to have a little bit of a basic. So yeah, you need to try it out for a little bit, maybe, but then, I think it's a fast way of developing. Yeah.
Artem Barmin
So, REPL-based development, fast feedback loop, and a lot of other things as well.
Marten Sytema
So I don't want to sound like just saying that I don't want to sound like this is the one thing and other things are there's like, I think there's like ten things. I'm not naming the other that we all know that are very important and are lacking in a lot of tools. People don't even realize that that's what they actually want. Like the non-Clojure people.
That's why people like us are like so... I don't like the word, like so... are always like fanatic or religious about it, outspoken about it. That's one of the reasons, because it's just so good, yeah.
Vadym Kostiuk
An interesting point of view. And we've been talking for almost an hour now. We've discussed a great number of different topics, I believe. But when you were invited to this podcast, I'm sure you had some... you've been imagining what topics you will be discussing, and perhaps there is a topic or maybe topics that we haven't covered yet, but you really, really wanted to talk about it.
Marten Sytema
You did all right, actually, because I kind of like the premise of it being in the context of a business sense. It's worth it and all that stuff. So that was what I was in.
And that was what I liked as well. A lot of stuff in conference and all that is sometimes it's a lot about libraries and it's about open source and which is all great. I mean, it's kind of nice to also have like more of the commercial side of things, like the business side of things, the startup side of things, to put Clojure in that light as well, which by the way, I also think could help adoption depending on, you know, these kinds of stories, what I was expecting, that's what you asked.
Artem Barmin
Okay. We're asking this because it's interesting to gather questions from the guests also for our podcast because sometimes we can have blind spots, we can kind of notice something and it's really interesting to hear. And we have this chain of questions from guest to guest and we have questions for you from our previous guest. And I will read it.
If you could fly back in time 15 years, and have a conversation with Rich Hickey, what would you convince him to change in Clojure?
Marten Sytema
I could convince him. I would probably be inside like in awe, probably. Then I would start Clojure, would have started Clojure earlier. I think, I don't know, actually. I'm not really sure. We're missing a lot of stuff or anything, actually. It kind of ticks all my boxes all the time.
It's the most boring answer, but everything he writes about it and talks about it and all that stuff in general, he shows the world how things can be. And he has given an awful lot of thought about all this stuff. Also, from his experience, like from C++. That's why I don't really have anything or a lot to argue with him actually. No, no.
Artem Barmin
Okay, okay.
Marten Sytema
That's an honest answer. I'm not going to make something up just because it's really how I think about it, actually.
Artem Barmin
Great. Okay. Okay. Thank you.
Vadym Kostiuk
Adam Turnhill, who initially asked us this question. We were curious because we never thought about this question in general. And we asked him as well, what would you change, actually? And he said, I'm actually not sure, but it's really interesting to hear what others will say.
So your answer is practically like nothing, that you would change nothing. It's also a great response, in my opinion.
Marten Sytema
Yeah, but it is true. I don't really...
Artem Barmin
Actually, I had an answer and you can check it when the episode will be out. Cool. If we keep it, I don't know.
Marten Sytema
Yeah, sure.
Vadym Kostiuk
Yeah, so this is the part where we also would like to ask you to leave the question to another guest who will be after you.
Marten Sytema
So I thought about this, and it's the topic of adoption again. As I said, like before the podcast, I've kind of like happy now in a place that I've created a few Clojure jobs now, both in Catermonkey and in the previous project I worked on. There's now other developers working on that. So I kind of passed the baton, is that the word? So, and my question would be like, what would be a good way to create Clojure jobs, like real paying, money-paying Clojure jobs? How would you go about like doing this?
Vadym Kostiuk
Interesting.
Artem Barmin
Nice question. It's interesting for me because, you know, one of the main goals of Fresh Code is creating Clojure jobs. And we have a team of 30 people doing Clojure.
And I would answer if you're interested. We should focus on making Clojure popular and more widespread among the industry. And in this way, we will encourage other CTOs, technical leaders, or technical founders that will leave their company to start businesses in Clojure.
So the main and the easiest way is to spread the word about the Clojure on other conferences, not only inside the community, but in other contexts.
Marten Sytema
I think the best way that Clojure is that projects in companies are started with it. I heard Rich Hickey say some people said they snuck Clojure into our company, that kind of thing. And I think planting seeds like that. So if you're like a...
So for you, like what Freshcode is probably doing, now and again, there's greenfield project. I did like six or so in like Catermonkey, in this recruitment app, and then four others, like some internal tools, most of some like a little portal for something or for some educational institute, kind of those things.
But these are now projects that run and need maintenance, or they're qrowing, or that's creating jobs now. If there is a code base going on and the code base provides value, then there's not much choice than to either rewrite something else or continue doing so. And often that is, the last part is the way the easiest because it's kind of funny actually, like I had these projects and I was kind of willing to pass the baton because Catermonkey is consuming all my time. And on the Clojure Slack and all that, I was pretty quickly in finding other people, you know, either a freelancer or who could take over the project. So that's pretty interesting as well. It was with not much effort. So that was cool. Yeah. So now they are getting paid for doing their work. So.
Artem Barmin
Gorilla tactics, yeah. I met this on my previous job 12 years ago when I brought Clojure into QA department. I created a DSL for them to write automation tests, and it's still in process actually. I don't know how they support it, but they're still using this.
Marten Sytema
Yeah, but that's the thing. It does work. Yeah. Yeah. There's some factory in the Netherlands that uses an internal monitoring tool for the production. They're depending more and more on it. And never was it like, did you write it in Clojure? Now you're, you're saying to us, you want to pass the baton? No, I kind of...
I kind of found someone who takes the baton pretty easily and he was pretty quickly up to speed and is improving it like as we speak. That's the thing as well. A lot of projects that I started as a greenfield project wasn't in a software company where the software company was an end user. It was like in an educational institute, in a recruitment agency, in a factory. So they have very different core businesses, and we are supporting them with IT tools, software tools.
So they're not really interested in it should be written in Python or whatever. They just want a problem solved. Realize that. I mean, if you're a freelance consultant or something, and someone asks, can you automate something for it and you build it in Clojure that company isn't like a software company with some sort of policy around it, you can just do it. And it's not even unfair or something. You just deliver value and…
And you make it work, and no one will bet an eyelid. It's not even, that sounds like it's like you committed the crime. You don't, you didn't. And in a way it's better because Clojure codes kind of stay stable. If you used one of the JavaScript projects or Node projects for it, and then five years later, it's not the Node framework anymore, and no one wants to touch it. That happens. That is more criminal.
Artem Barmin
Thank you for a very pleasant and insightful conversation.
Marten Sytema
You too.
Artem Barmin
About its future and about your perspective of how it's actually been doing business in Clojure. Because it's not a very common thing in our world.
Marten Sytema
It would be cool if that would be more promoted, but it's hard. I get it why it's not, but that would be a cool topic, too, more for me, at least. And I think for you guys as well.
Artem Barmin
Definitely.
Vadym Kostiuk
Yeah, and in addition, I'd like to say also thank you, Marten, and to our audience. If you'd like to learn more about Catermonkey or connect with Marten Sytemaartin, we will be sharing the links below this video to access the website and social profile. So yeah, right before below this episode, please check out the links. Yeah. And yeah, learn more about Cutting Marten Sytemaonkey.
Marten Sytema
Thank you. Thanks for having me. Very much fun.
Artem Barmin
Very much fun. Thank you.
Vadym Kostiuk
Thank you very much. Alright, bye-bye.
Artem Barmin
See you soon.
