[atdixon]

A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..."

The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure.

What I mean by this:

I was a Java programmer for years and increasingly started writing code in a more functional, immutable, dynamic style with the occasional need for meta-programming -- for the sheer need of being more productive and writing more robust code.

Yes, you can write functional, immutable, dynamic, code in Java and do meta-programming in Java!

It's just somewhat cumbersome and prickly.

Enter: Clojure.

I've seen many an 'unwise' programmer make just as much a mess of Java systems as people are suggesting they've seen in Clojure projects. It may be simply that Java slows you/your team down enough so that the messes of unwise programmers are just made more slowly.

But one wonders if this is really a win: you're probably also delivering your business value more slowly, as well.

:thinking-face:

[throwaway92938]

> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure.

HN seems to blindly accept the idea that developers using niche languages are good but I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure.

Great developers have to be working on hard problems and almost all of the hard problems in our industry, outside of language/chip design and correctness proofs, are being worked on in relatively boring languages (C, C++, Java etc.). Most of the niche language users I've met are working on basic CRUD web applications.

[bambataa]

I suppose the argument would be that only developers with a modicum of interest in their craft will gravitate towards niche languages such as Clojure. But you are correct that doing so doesn't necessarily mean they are good.

However, I don't think it follows that great developers work on hard problems. Why can't you be a great developer working on CRUD apps and occasionally finding ways to do them better?

[indymike]

There was a time when Java was a niche language for web applets. There was a time when Python was a niche language you tossed into your "real" program so users could extend it. There was a time when C was a niche language for Unix development. Likewise C++ was this niche object oriented thing that didn't even compile to object code... it compled to C.

And developers would look at the niche language devs and go, why write in C? I have my COBOL and most production code is written with it. Java? Why? I have Powerbuilder and Delphi. Most of the developers with any new language are creating CRUD apps, because well, that's what most computer programs do.

[jjav]

Agreed. I went through my phase of geeking out on Lisp and playing with programming languages for the sake of the language itself. But in the end it wasn't very satisfactory. I prefer building things.

At a later job my views got reinforced by a team who were so excited about Scala (many years ago when it was particularly bad, not sure if it is better now) and all the language tricks they could do in it. So we spent tons of time on "stupid programmer tricks" (Letterman-style) and debugging obscure language constructs, less time on the actual working product.

So I don't want clever programmers on my teams nor clever languages. Give me mature ecosystem, great tooling and simple code. Java and C remain the gold standard for getting things done.

[oftenwrong]

I prefer functional programming, and have a background in functional programming, but I still primarily work with Java, and it is currently my go-to for any project. In my opinion, Java as a language is gross and unlovable, but the runtime, the development tooling, and selection of libraries and other integrations is about as good as it gets.

I feel like I am continuously looking for a better alternative, but it's hard to overcome the practicality of using something with such immense buy-in. For example, nearly all major SaaS offer a Java SDK, or have Java-specific docs. They want the big companies to be their customers, and they know they use Java. I am all too happy to benefit from that.

It should also be noted that Java the language is rapidly being enhanced with features inspired by functional programming. For example, sum types (in the form of sealed classes) have been added to the language, and ML-style pattern matching with compile-time exhaustiveness checking is in the pipeline. More on the platform side, Java now has a REPL (JShell).

Of course, Java codebases you encounter in the wild are very likely to make you want to cry. The world of Java development has a lot of bad taste and questionable practices enshrined as best practices. That said, the Java community is slowly shifting toward a better style.

[huahaiy]

I think the ratio of people using functional language that work on "hard" problems should be a lot higher than the mainstream language users.

From my personal experience, before I become a Clojure user, I wouldn't dare to write "hard" software such as compiler, database, and such, all by myself. Now I have done all that, I would credit part of that to the productivity of the language. That's why with such a small community, Clojure ecosystem has produced so many first of its kind innovative systems, e.g. Storm, Datomic, etc.

[keymone]

> I certainly haven't seen any proof of that and I haven't seen anything to even remotely suggest that good developers gravitate towards Clojure

What about stackoverflow survey? Clojure is the most paid language (evidence that businesses value Clojure programmers) and Clojure has the most mature user base (evidence that users stay or flock to Clojure after many years in the industry).

Sure, not the best kind of evidence and depending on your biases you can read it in many different ways, but it’s a datapoint.

[juskrey]

Not that developers using niche languages are good, but rather it is very easy to figure out if they are good.

[puredanger]

I use Clojure because I am not a particularly wise programmer (I have been fortunate to work with many actually wise programmers).

I like to write dumb, obvious code. Most Clojure code is about taking your data, representing it a sequence of maps, and transforming them into different sequences of maps. The maps are open (easy to change over time), immutable (impossible to encounter data races, weird equality semantics, or concurrency issues), dynamic (no pre-definition or ceremony required), concise (thanks to a literal representation that does not even require commas between elements), and have a generic access api (no custom functions/accessors/etc).

Because I use the exact same transformation functions on EVERY PROBLEM, there is an enormous amount of reuse of generic operations both within and across Clojure code (even Clojure code that manipulates Clojure code, which is after all, just data).

Because the center of our code is open data, coupled with generic functions open to later extension (multimethods, protocols), Clojure is notably good at handling information systems that evolve over time in requirements (a feature of essentially all of them).

The core constructs are not hard, certainly they are easier to learn and use than complicated things like mutable classes and locking. The unlearning from other languages is often bigger than the learning. Nubank for example is certainly not hiring 100s of Clojure developers - in most cases they are hiring good people and teaching them Clojure. There are other successful companies doing the same.

Large Clojure programs can be hard to reason about because large programs are hard to reason about. One benefit of Clojure programs is that they are often 100x smaller than the equivalent program in a popular OO language. They are also trivial to interact with live in your REPL so that you can inspect the data flowing through them. I will happily take live data and interactive function execution over 1000 classes with custom methods. Both require time to learn but I'm much happier changing the smaller, simpler one.

The idea that "Clojure requires wise developers" is completely backwards. Enormous modern class/annotation based OO programs are the ones that require the smartest developers because that's what it takes to understand them. Clojure is accessible to all.

[ithrow]

All that is only true until you have to reach to Java interop because of Clojure's lack of ecosystem of libraries. Since this is a necessity and fairly common, now you are back to this enormous OOP world of over-engineered libraries, eradicating all the benefits and joy a doing a project in Clojure, it's unfortunate.

Clojure is also not making this easier(interop) by not keeping up with Java advancements. Ex: functional interfaces

[silver-arrow]

This is an excellent comment and it matches my experience with the language very closely. After a career with many languages and paradigms (C, C++, Java, javascript, Swift...), then pushed to do Clojure the past 3 years, all the points you make above became so obvious that is in now EXTREMELY painful to work in any of the other languages.

I think a couple pain points need to be remedied in the community so that Clojure is more inviting to the general programmer, who like you mentioned would ultimately have an easier time with Clojure once bootstrapped into the language.

The primary one for me was being met with Emacs out of the gate as the preferred and touted editor for Clojure. I dove into that for a good year, became proficient with it but sorely regretted it. It was a decision point and cognitive hurdle I wish wasn't even presented to me in the beginning. IntelliJ/Cursive or something like it is a better way for most newcomers.

Earlier books on Clojure were way to "intellectual" in my opinion and pretty offputting to the general programmer. Luckily that area has improved in recent years with books such as "Getting Clojure" and "Programming Clojure"

Also the newcomer could be confused about what a repl is and how it functions with the IDE or editor. It would be better if editors and plugins focused on raw Socket or prepl repls over middleware repls like nrepl.

I would hope actually that some resources in the community would make an awesome LSP Server for Clojure so that any editor that supports LSP would have a great Cursive like experience. "clojure-lsp" is a great start but needs more resources.

The points made above by puredanger are so very true in my experience and I am so lucky and joyful to be working on Clojure systems.

[randompwd]

I'm still salty about Specter[0] not being ~officially recognised as a necessity when using Clojure.

[0] https://github.com/redplanetlabs/specter

Data driven languages need simple & powerful transformation libraries. `get-in` is repetitive and tiresome to use.

Specter and it's ilk make transformations clear and simple.

No amount of planning or foresight negates the need for data transformation libraries.

[clusterhacks]

I think that the bigger problem is that developers just don't get taught any way to think about coding other than the object-oriented, use-Java-for-everything approach.

I sometimes think I could have massively accelerated my ability to produce decent code in any language if I had been forced to work through "The Little Schemer" and "How to Design Programs" before I saw anything else.

But that is probably just hindsight or personal bias. I found functional programming in Lisp and Clojure to simply click for me in a way that enterprise Java class hierarchies never did . . .

[kazinator]

When I'm coding in Lisp, I want objects with methods and mutable state.

I made myself a Lisp dialect with a nice little object system.

More precisely, I made it without that object system, but I eventually couldn't stand the situation.

I use objects even in small, throwaway programs used once. Sometimes it turns out that they aren't just used once, and the use of objects makes them easier to read later.

[juskrey]

In short, Clojure is far the best professionalism filter I have stumbled upon, in all of my 20 years of coding for money.

It takes around 5 minutes to figure out whom you are talking to, when you are talking about Clojure.

This worked perfectly for me on both sides: as a contractor on hire and as an employer for some project.

[Kalium]

I worked in a partially Clojure shop for a while. I found the Ruby on Rails developers to be more professional, overall. The Rails devs certainly did not have the habit of trying to compose together 75% of a framework anew for each project.

[majormajor]

> The converse of this is that good, wise developers are going to (ultimately) _demand_ Clojure.

Maybe the really wise developer is aware that not everyone thinks the same, even themselves now vs six months from now, and is very wary of dynamic behavior and cleverness...

I don't want Java or Clojure in a team environment, now that I've got Kotlin.

Or maybe I'm just not wise enough. ;)

[brundolf]

I'd be curious to see a survey of what background the average Clojure enthusiast has. If many of them come from Enterprise Java, it makes total sense to me why the enthusiasm for Clojure is so high (in fact, that's Rich Hickey's background). Java is: boilerplate-y, slow to iterate with, hard to express higher-level concepts in, requires lots of ceremony (in everything from type definitions to the build system). Clojure is a direct response to the cries of Java devs: the polar opposite of all the things they're sick of, without giving up the ecosystem that they're comfortable with.

Whereas for me: TypeScript is concise enough, functional enough, and has the added benefit of static types and multi-paradigm features for when you need them. The primitives aren't as good as Clojure's, and immutability requires a library, but I'm not so traumatized by Enterprise Java that I feel the need to seek out the exact opposite of it.

Not to invalidate that perspective; I'm just wondering if the Java background explains the discrepancy between different people's feelings about Clojure.

[grzm]

Anecdotal, but I don't think I ever programmed in Java before Clojure. I came to Clojure via Ruby, and was deciding between Clojure and SBCL, and Clojure won out. Being hosted on the JVM was part of that: extensive availability of the JVM and interop with existing Java libraries made it easier to get started.

[puredanger]

Lots of data on this from the annual survey: https://clojure.org/news/2020/02/20/state-of-clojure-2020

[maharajatever]

> A common point is being made in the threads here: "The downside of Clojure is that you need good, wise developers..."

A common situation is that a mediocre Java programmers reads the first page of a clojure tutorial, finds out about list comprehensions and map and filter (probably not even fold) and decides he (yes almost always he) is a genius. A “good, wise” “engineer”.

Reality usually disagrees.

The reality of actually having to write a complete working system in a language in which your knowledge is limited to the first page of a tutorial is even harsher.

When your “wisdom” and “goodness” are up against a hard deadline, or even an interview, you get the confused messages in this thread that blame companies for not hiring you, people for it understanding you, everyone else for being stupid, and the world for your unemployment.

May be learn what you started with first, but well, and thence to expand your knowledge in various directions.

But of this fancy stuff is available in almost every language. If you think clojure is special you’re in a bad place. Hickey wrote clojure in java.

For the record, I don’t write java or clojure anymore, and if you think clojure gives you an advantage without knowing at least five other languages to a professional level, then you’re not getting hired anywhere near me...

[higerordermap]

I find "great developers prefer clojure" narrative so infuriating. Clojure is just one paradigm. I am pretty sure there are as many great developers that don't prefer clojure to some other novel language.

[bitwize]

Hot take: Lisp (including Clojure) is for shitty programmers.

Great programmers can be great in any language, including C, COBOL, or BANCStar. Their brainpower alone can compensate for the language's lack of abstractive power.

Lisp is a mind prosthesis for the programmer; it extends the programmer's reach. Unless you are working in a complicated, abstruse line of work, you stand most to benefit from this if you are bad at programming.

Hence, the most clamorous Lisp zealots tend to be terrible programmers in their own right. The "wise" programmers jeep plugging along in Java, because it's well-supported by a bigcorp and has a HUGE candidate pool when you need to hire developers who work in it.

[sea6ear]

This might be the best advertisement for me picking up Clojure (or Lisp/Scheme) that I've seen so far.

[Scarbutt]

I was a Java programmer

Most Java programmers get enlightened and feel relieved as you did when they switched to language X from Java. Is a recurring theme, not specific to Clojure.

[aprdm]

> wise developers are going to (ultimately) _demand_ Clojure.

Lol. I guess your definition of wise developers is very different from mine.