Right, the more idiomatic approach in java would be

- define the class

- let the framework fully handle serializing/deserializing it from your file to the neat in-memory object

That’s great if your dealing exclusively with CSV files and a fixed set of data types, but the point is that this approach in Clojure is universal regardless of where the data is coming from, or going to.

Everything comes in as a map, gets manipulated with the powerful set of core Clojure core functions, and spit back out as a different shaped map.

It’s a very flexible approach to dealing with data, and that is one of the main appeals of Clojure.

Yup, Java in its current incarnation is definitely a better fit for larger companies that can present more standardized workloads. You want to give each team clean and explicit interfaces that they have to work with, and not have to worry about different shaped maps. Flexibility and power just lets junior developers shoot themselves in the foot.

I agree, I wouldn’t suggest Clojure for a large company with lots of junior developers.

I wouldn’t suggest Java either, though. Go would be a better fit for that situation these days.

I look at Clojure and Go as different sides of a coin.

One is a powerful language the let’s a small team of experienced developers get a lot done with a small amount of code.

The other is a simple language that lets a lot of less experienced developers get a lot done with a lot of code.

I want to stress in this comparison though, that I don’t view one as better than the other.

Go was designed for development at scale, where you have lots of developers, all at different levels, all needing to contribute large amounts of code. In this respect, it does a great job at removing most of the rope that people can use to hang themselves. If I needed to pick one language to use at a large enterprise, it would probably be Go.

Clojure gives you a (different) set of limited functionality, but what it gives you is very powerful, and very foreign to most developers, so you can definitely hang yourself trying to force everyone into using it. If I got to choose one language for myself to use, it would be Clojure.

Go reminds me a lot of the old days of Java, that lead it to its current dominance. It used to be explicit and wordy, but there was usually just one way to do things, so a code base would stay very consistent, leading to much better portability even as code constantly changed hands between developers.

For people coming from a java background, I've had good results with other java+syntactic sugar languages as well, like Groovy and Kotlin, that have accelerated the growth of java to try to pick up some of the best parts of other more modern languages.

I would tend to disagree with the idea of "only choose one language for myself". You want to pick the right language for the job, you want to consider the business needs at hand, you want to consider the team that you have, you want to consider the experience that your team has. Even a company that would prefer to use as few languages as possible could easily end up with javascript for the frontend, ruby for the backend, go for infrastructure, python for ML. And at the end of the day, it's just code, it's just a tool to express your own skills as an engineer.

And then as an engineer personally, you need to get exposed to a range of languages, because each language teaches you a different mindset, and brings with it a different community with different priorities. Not referring to you specifically, but I've seen a lot of junior developers get into Clojure and all of a sudden it's the most amazing language because their life as a Java engineer before was horrible. But it's not Clojure specifically, it's the idea of learning new languages that is itself powerful.

A counter point is that most large companies these days operate with lots of small teams, not one big team. And most systems are composed through a service oriented architecture of some sort, not a single giant monolith worked on by all teams.

So in practice, even at a large company, you find yourself with lots of small teams.

And no such small team at a large company would be composed exclusively of junior developers. There's at minimum going to be a team lead of some sort, and most often you'll have a spectrum from senior to junior.

So in reality, Clojure can be quite a good fit even at large companies. In fact, it might be a better fit at bigger companies, because I think small startup might actually be where you could find a small team of only juniors, and a "deliver at all cost no matter the quality" business need (due to not being profitable yet).

I can't help but feel that all arguments defending how this Clojure solution supposedly can't be done as elegantly in other languages, use "idiomatic Clojure" as the judging criteria. Of course the conclusion writes itself.

Well, you can write code a lot like this in JavaScript using a library like Ramda, and get a lot of the benefits.

But then everyone that you on-board to that project has to be up to speed with how the code is being written and why.

With Clojure, that understanding is table-stakes.

So in that respect, the conclusion does write itself.

I've actually tried that: https://github.com/enumatech/sprites/blob/master/lib/__tests...

reads quite like Clojure, but looks foreign to JavaScript programmers...

I even made extensions to Ramda, so you can thread a mixture of async and non-async code with it: https://github.com/enumatech/sprites/blob/master/lib/fp.js#L...

At the end the friction was just annoying and no one else really understood the greatness of this approach, since they didn't know Clojure...

In my experience, it's not that you can't do these things in some other languages, it's that you won't, and if you try too, there will be more ceremony and friction.

That said, this is where a lot of people who took a detour through Clojure, come out of it saying when they went back to their prior language or some other language, they felt like they had suddenly become better programmers, and it helped them even in other languages to write better programs. Clojure showed them the way, and now they can recognize it and think of doing it as such in other languages as well.

Maybe a different way to think of it is that you can do OOP in Clojure if you really want, but you won't. Similarly, in Java, you could try and do FP with immutable collections and value semantics, but most likely you're not going too.

And I'm using Java here because in theory, Java and Clojure have the exact same set of available features, they run on the same JVM, same runtime, compile to the same bytecode, can share libraries, etc. So it goes to show that the language itself does influence the style that is most convenient for writing your programs in.