One in which Mary steps out of her room, sees a rose, and absolutely nothing new is added to her understandings.

She already had it all sorted out in her study. In many people’s understanding of “naturalism” that wouldn’t be any surprise.

But that’s not this world.

And indeed had she that knowledge, nothing new would be added by seeing one in person.

The implausible part is presupposing any person could ever have a complete enough understanding of all physical knowledge to achieve that.

I think you’re missing the argument.

We can easily assign words to things we know exist. That’s not the issue.

When we define things (like “naturalism”) we are invoking symbols and their semantics, all the stuff Mary presumably has access to in her room.

In her room, Mary already understands subjective experience, the brain mechanics behind it, etc.

The realization that there is more outside of Mary’s room suggests that our conceptualizations are limited / not accurate.

If that’s the agreed case how can anyone cling to a universal “naturalism” with a straight face?

With Mary’s room, haven’t we already accepted that formal statements are incomplete - and therefore would be silly to call universal?

Personal tasks with estimates and focused on “local first”/desktop usage.

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:

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.

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?

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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

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.

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

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.

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.

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.

It sounds like Clojure is perfect for you then. You have all the upsides of Java you mention here with Clojure because it's hosted on the JVM (among other platforms). You can use Java libraries and SDKs seamlessly from Clojure, but the language itself was designed specifically for a functional style from the beginning.

This is a great feature of Clojure, being able to access all of the benefits of the Java ecosystem and the zillions of hours invested into it.

There may not always be a ready-made Clojure wrapper over libraries, but the java interop tools are excellent and writing your own interface into a library is usually quite straightforward.

I've never seen a "best practice" that wasn't horrible dogma parroted by developers that can't do their own thinking.

As I get older I care less and less about FP, OOP, imperative, and language fads. Or Martin Fowler. Especially Martin Fowler. What I really crave and value over anything else: consistency. I don't want to look at the code base like an archaeologist, digging through layers of fads. "And this code is when James and Adam were going through an ORM phase with such-and-such library" Please no. I don't have enough remaining time in my life for this shit.

If Oracle, IBM, Microsoft, Azul, Amazon bring a KVM written in Kotlin, then I might consider it.

In the meantime it is just the language Android team is pushing to get rid of Android Java, while the offices next door are pushing ChromeOS/PWAs and Fuchsia.

"final var" anyone? Non-monadic, non-applicative "Optional"? No? Ok.

The guest languages require additional tooling, duplicated libraries (because just using the platform libs isn't idiomatic, whatever), and then as the platform moves on the seamless FFI stops being so seamless, specially when the guest language decides being a guest language in just one platform isn't enough for its life achievements.

Eventually the platform language acquires enough features, which remove the spotlight from the guest languages, and projects start to migrate back, ah then the "Why X in Y" blog posts, with reference to "Why Y in X" start to appear.

As for Arrow, if you want Haskell, it already exists.

For what it's worth, in case I come off as a die-hard Kotlin fan, I'm really not. I strongly disagree with many choices the designers make with Kotlin - there's too many to list, but the common theme is basically, as good as Kotlin is at discouraging the worst of Java, it still caters far too much to nonsensical Java practices IMO.

Eventually Kotlin needs to decide which master it wants to follow.

Java only needs to bother with keep being Java, everything else in terms of OS and AOT/JIT/GC support is just a matter of picking the respective implementation with zero code changes.

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.

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.

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.

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

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.

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

It's not a necessity in the same way XPath wasn't a necessity to interrogate XML.

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

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.

Because this in HN: Yes, some people are writing operating systems, video games, database engines. Most people are not.

They also don't want to throw away all their other valuable techniques.

Programming with mutation is not just efficient, it is also highly expressive and easy to verify, for the right kinds of problems.

Just because it's useful for writing operating systems, video games and database engines, don't be mistaken in assuming that it's only useful for operating systems, video games and database engines.

Yes, it is also absolutely necessary for expressive A* pathfinding.

This is unnecessary for someone connecting two web APIs. Correctness in most domains is totally worth not having to worry about pass-by-reference defaults.

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.

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

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.

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

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.

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