[Shmebulock]

These Talebian references got me thinking. Couldn't you argue that it shows a certain arrogance and non-results oriented "falling in love with ideals and tools" detachment from reality to use Clojure instead of good ol' Java?

[TeMPOraL]

> Couldn't you argue that it shows a certain arrogance and non-results oriented "falling in love with ideals and tools" detachment from reality to use Clojure instead of good ol' Java?

Since when trying to do better than using a tool designed for mass-producing software with dumb and cheap labor is "falling in love with ideals and tools"? It's kind of like saying that using an excavator over a bunch of people with shovels is "falling in love with ideals and tools". No, it just allows a single person to get more work done faster and better.

Our industry is weird. When recruiting, companies claim they want "the best of the best" and will often test you on ridiculous stuff. But when it comes to actual work, on industry scale, learning, growing professionally, and doing things in a clean and efficient way is frowned upon. Best take the weakest tool available and compensate for its shortcomings with third party services.

[enlyth]

> trying to do better than using a tool designed for mass-producing software with dumb and cheap labor

This is completely disregarding the available developer pool of Java programmers, and the fact that a lot of them are really talented and can write efficient, production ready software.

The fact is, there is at least an order of magnitude more developers to choose from compared to Closure, and hiring and replacing people is hard. Ignoring business realities like this is bad, and akin to "falling in love with ideals and tools".

Also, someone using Java does not automatically make them dumb cheap programming labour, same as someone using Closure is not automatically going to be a 10xer who has memorised Knuth. It's possible to write bad FP code as well.

[TeMPOraL]

> Also, someone using Java does not automatically make them dumb cheap programming labour, same as someone using Closure is not automatically going to be a 10xer who has memorised Knuth.

I'm not claiming that. I'm claiming that Java has a long history of enabling factory-farming software development, whereas Clojure doesn't lend itself to this style. I mean that in the sense that an army of cheap labor with shovels can, in principle, do the same job as a few trained operators in construction machines. The physics of dirt is the same, and so the job done is essentially the same - just some tools let you do it faster with fewer people. And then, the quantity (or lack of it) has a quality of its own - the more people you engage doing smaller and smaller pieces of work, the more your work becomes about coordinating people than doing the actual job.

(I'm aware that since version 8, Java is growing to be a quite decent programming language. This somewhat weakens my criticism, but not all that much.)

But yeah, I'm also claiming that ceteris paribus, the pool of Clojure developers will yield you higher-skilled programmers on average than the pool of Java programmers - simply because everyone and their dog knows some Java nowadays, and some Java is enough to make some progress in factory-farming software development, whereas Clojure is somewhat atypical and requires expanding your competences beyond the very basics.

(Or, in other words, I'm claiming that the distribution of skill of Java programmers is wider than that of Clojure programmers, with the latter having higher minimum and mean values, and comparable max values.)

[pron]

> I'm claiming that Java has a long history of enabling factory-farming software development, whereas Clojure doesn't lend itself to this style.

Any hugely popular language would have a lot of crap written in it, and a non-popular language wouldn't have "factory-farming" simply because it's not at the needed scale. So any non-mainstream language would almost by definition not lend itself to "factory-farming" development. You could also say that a lot of good stuff has been written in Java, and not as much good stuff has been written in Clojure, and conclude that Clojure doesn't lend itself to writing good stuff.

Any comparison between languages with at least 100x difference in popularity is meaningless, especially as no large bottom-line effect of programming languages has been found.

> the pool of Clojure developers will yield you higher-skilled programmers on average than the pool of Java programmers

Which matters if you're picking people from the pool at random. If not, you want to have the pool with the greater number of higher-skilled developers, not higher average. It's like saying that it makes more sense to start software companies in Finland than in the US, because on average people there are much better educated.

[0815test]

Does Clojure lend itself idiomatically to any style other than quick-and-dirty prototyping, though? There are real benefits to many features of Java when it comes to long-term maintainability, even though it also has some very real pitfalls at the same time (no optional values, no variant records with pattern matching, no composition-plus-delegation-over-inheritance etc. etc.).

[yogthos]

Yes, it absolutely does. My team has projects that have been running for many years in production. They're far easier to maintain than equivalent Java projects we've done before. And there are plenty of companies, like Circle CI, who built there stack on Clojure out there. Here's a talk from Kira Systems who went from a quick and dirty startup to a 150 employee company in 8 years using Clojure: https://www.youtube.com/watch?v=u-4FiFpkPlQ

[cutler]

Considering Kira Systems had to resort to using Go for much of their heavy lifting, due to Clojure immutability memory overhead, I would hardly concur that this is a shining example of the benefits of using Clojure.

[krn]

> non-results oriented

I think Clojure's ecosystem is more results-oriented than almost any other currently available[1]. It just requires a completely different mindset to understand, which an average software developer lacks. Therefore, Java is a much better fit for an Apache project.

[1] https://news.ycombinator.com/item?id=19728502

[jrs95]

Oh I'm sure people make that argument all the time. I just don't think it holds up to reality. It's sort of just a dismissal of better options. The reality in my experience is that Java is just a poor choice for a lot of software. That's why you end up with frameworks built upon frameworks & AspectJ to basically make it behave like a dynamic language and try to hide some of the ugliness of the underlying APIs from you. And it's just because it's corporate approved and "everyone knows Java". I don't see how it can reasonably be considered the pragmatic choice. It's just not productive, and the final product isn't something that I would consider easy to understand or maintain most of the time either.