[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?

[throwaway92938]

> 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.

There is an opportunity cost and there are plenty of motivated developers that instead of learning yet another niche language decide to work on algorithms, applications and generally more difficult problems. Few languages offer enough advantages to overcome the fact that the latter is almost always a far better use of your time. As someone that knows Clojure relatively well, I'd argue that it's certainly not one of those few languages. Also, the trade off continuously gets worse as the popular languages adopt the good ideas from the niche languages and as problems continue to get more difficult and rely on teams of developers with library support in a wide variety of domains.

[mto]

Good point. I have been playing with lots of niche languages but in the end I also find that focusing my learning elsewhere is usually a better idea. Even more, I don't know many of the features of the languages I use although I have been working on rather tricky topics - from 3D viz to medical computer vision, low power device soft-realtime streaming deep learning inference ;) etc. and in decades of C++ I still only know the basics of metaprogramming (means standard template functions and classes). I am pretty dogmatic about RAII and similar but try to keep things simple. Even dropped most of the abstractions over time - sometimes 3 else ifs that then never change again are probably better than polymorphism, command pattern, lambda etc. stuff - at least you know what will be called there just by looking at the code.

Similarly I feel my Python code is getting simpler and simpler over time.

I'd probably even gravitate towards Go at some point nur there I do muss a few things.

I usually find the pay off is just better when I rather learn more about deep learning, statistics, domain knowledge, security, visualization or stuff like AWS, Kubernetes, Unity etc.

The language ends up to be a very small piece and usually more important to have the ecosystem and community available. Like Julia also does not solve the 2 language problem for me but leads to a 3 language problem.

[hailwren]

I argue that Clojure née the functional programming community writ large capture a peculiar local maximum. I used to subscribe to the “functional = better” camp until going to MIT. I challenge anyone to find a cutting edge CS paper* that is written in their favorite functional language. If it were so effective — wouldn’t one academic have exploited this efficiency to catapult themselves ahead of their imperatively bound brethren?

Maybe there’s something peculiar about academic work that requires an imperative mind. This is why we see the highest paid practitioners programming exclusively in functional languages ... oh wait, the opposite is true.

My theory is that FP hits a nice sweet spot for someone who would like to casually improve their craft. Something akin to breaking out Popular Mechanics after work.

* - excluding, of course, papers about programming languages themselves

[didibus]

> This is why we see the highest paid practitioners programming exclusively in functional languages

Well I don't know how accurate this is, but in 2019 Stackoverflow survey, Clojure practitioners averaged the highest pay of any languages. (in 2020 they removed Clojure from the options so the data is missing).

> I challenge anyone to find a cutting edge CS paper* that is written in their favorite functional language

I rarely see papers written in any particular programming language to be honest, they tend to be pseudo-code and math like. And when you write a paper, you don't really need to be more productive or more reliable, since you write so little code. Plus any paper focused of low level or raw performance will obviously need something with semantics closer to the hardware.

> * - excluding, of course, papers about programming languages themselves

What about papers studying functional algorithms, type theory, automatic differentiation, parallel computing, and all that? Do you exclude those as well? Cause they're often written in a functional language.

[fractionalhare]

> Well I don't know how accurate this is, but in 2019 Stackoverflow survey, Clojure practitioners averaged the highest pay of any languages.

Well I didn't believe it, but wow: https://insights.stackoverflow.com/survey/2019#top-paying-te...

I'm not sure if I should conclude that I'm incredibly ignorant of the engineering market, or that Stack Overflow's survey is not representative.

It makes me suspicious that Clojure is shown as the most highly paid language at $90k. Basically any non-new grad developer in a high cost of living area earns more than that, regardless of the language. I'm also suspicious that only 1.4% of survey respondents use Clojure, which may show a bit of a base rate fallacy here.

What would be the explanatory thesis for Clojure programmers being the most highly paid? None of the most highly paid roles I'm personally familiar with in big tech or finance use Clojure, and people who work in those roles earn well into the six (and sometimes seven) figures.

[discreteevent]

>Basically any non-new grad developer in a high cost of living area earns more than that, regardless of the language.

SO is used by developers all over the world, not just in the US.

[deckard1]

> What would be the explanatory thesis for Clojure programmers being the most highly paid?

I couldn't find a breakdown of the stats by state or city, but here's my guess: Clojure is only used at companies that can take the risk. That is, SF, NYC, and a few other metros. There are businesses that probably run Java or something on their cash cow and want to throw a few bones to the developers for recruitment/resume-driven-development purposes. Whereas JavaScript/C++/Java developers exist at every company and in every tiny city with a much broader pay scale.

Anecdotal, my company does some Clojure. But it's limited to a handful of internal tools and we pretty much ended the experiment years ago. Nothing new is made in Clojure. To my knowledge, we've never hired specifically for Clojure. It's always some dev that knows another language.

[didibus]

It's interesting too that of the top 5, only Go is a non-functional language, the others all are: Clojure, F#, Scala, Elixir.

Right now my guess is that, if you also look at one of the other questions, it turns out Clojure has one of the highest ratio of senior to junior, like Clojure devs average a higher amount of experience as well. I haven't checked the others like F#, but my guess is that most dev using functional programming languages actively and professionally tend to be more senior and thus command a higher salary mostly. That means there isn't as many junior or mid-levels to skew the average salary down, where as my guess is other languages might have an even bigger number of new devs using them like JavaScript for example, which would skew the salary average towards their pay levels.

[huahaiy]

Cutting edge CS papers are written by Ph.D students who have not had any industrial experience yet. Of course, the code they wrote for those papers would certainly use languages that they learned in school, which would be C/C++/Java if the papers are system papers, python if the papers are ML/DL papers. That tells you nothing about the merit of functional programming language vs. other mainstream language.

If anything, as someone who has a Ph.D. and a career spanning both academia and industry, I can assure you that functional programming languages like Clojure is much more productive than the mainstream languages, even for implementing cutting edge CS research.

My experience of implementing algorithms from papers is that, in Clojure, the implementation is much more straightforward, always almost a direct translation from pseudo code in the paper to actual working code, even the pseudo code is inevitably written in an imperative style. However, the original author's code implemented in c/c++/java is always much more convoluted and bears no resemblance to their pseudo code in the paper. That should tell you one thing: that is functional languages often capture the bare essence of computer science, whereas mainstream language often have too much incidental complexity imposed by the languages themselves.

[rtpg]

I have something to tell you about CS researchers and whether they are actually good software engineers......

Seriously though, there are loads of papers out there that use ML variant programming languages (and not _about the language_) that I really wonder what papers you have been reading.

Let's not even get to all the older expert-system papers with stuff written in Prolog.

And yeah, loads of seminal CS papers are effectively just math.

[karamazov]

Academics are not, and don't need to be, good software engineers, because the tools and skills one person needs to build a proof-of-concept are different from the skills a large team needs to build production code.

Functional code and immutable data are fundamental ideas for managing complexity in big systems, irrespective of language. Even modern C++ tries to be functional until it has a good reason not to be.

(I also went to MIT, and I work on low-level systems at Google.)

[Barrin92]

>However, I don't think it follows that great developers work on hard problems.

Isn't that just the definition of what a great developer is? Mind you working on a boring CRUD app may very well surface hard problems, but it's difficult to see how one could be said to excel at their craft without doing hard and difficult work to prove it.

It's very easy to tell yourself that you're a great developer because you do some arcane thing that nobody else understands in an arcane language, but it's very easy to mistake esoteric behaviour for skill. Hard, real-world problems are a reality check. You either can tackle them or you don't, and if you can't do it in a fancy language it's no good to anyone.

[Twisol]

CRUD apps can be done well or poorly, just like any other product. In some ways, the difference might just be in tolerance for poor design in business outcomes. But it's not the case that every CRUD app must be god-awful.

Gread developers do great work, subject to the needs of the business, regardless of the difficulty of the problem.