When I have to write something computationally complex in the language my employer wants me to write it in, I first write it in Clojure because it's easier to think about the problem in that language. Then I translate that.
I'm willing to bet that any dev who has learned Clojure does the same thing. If I'm right, that's a huge indictment of what we've been doing for the last 60 years in programming.
You'd lose that bet. I think it's easier to reason about problems in languages you are familiar with and that fit how you think, which can change through continued use. A lot of the other stuff is just post hoc rationalization about why we like these languages and why they are better.
The opposite of my experience. I have many more years of experience and am far more familiar with in the target language than Clojure. But for the really difficult computational problems, say, for example, particular performance analysis of a sensor network for a given time series, I reach for Clojure.
Same. Clojure is very, very good at expressing data and data transformations in a simple, concise way. Once I learned to reason in Clojure, it quickly became the language I prefer for playing with a fuzzy problem.
Surely the argument being made here is for the best prototyping language, not the most familiar. If familiarity was the only yardstick nothing beyond C would even exist.
The argument being made is if it's necessarily efficient to prototype in a different language than the one that will be actually used, especially if one is more familiar with the target language.
In a world of options where an experienced programmer has had a chance to experiment with different languages the most familiar language is the best prototyping language. In a world where C is the only option programmers think about what other options they could imagine.
I haven't tried closure but I can believe so. I observe the same phenomenon with Python. Whatever I have to do is just easier to first express in Python then translate for me. I guess there are just some languages that are closer than others to the way we think.
It's quite probable that this language changes from dev to dev, depending of habits, type of problems and skills with said language. However I suspect some languages are just better at it by nature as well.
I know Clojure and have used it for some projects, and I don't do that. If I need to sketch an algorithm, I'll do it in pseudocode, and if I need to test the design I do it in a verifiable pseudocode, like PlusCal. For sketching/testing numerical algorithms, I use Matlab/Julia.
Why does the language matter when reasoning about the problem?
It seems to me you're conflating "how to solve this problem" with "how to use a particular tool to implement a particular solution to a given problem."
Troll: a person who makes a deliberately offensive or provocative online post.
You don't have to be wrong to be a troll, you just have to unhelpful and provocative. Which is what your comment was. You just said "its useless" without even providing the smallest effort in terms of an argument.
Two wrongs don't make a right. If you thought that OP was making bad arguments then make good ones.
Personally, i know 4 languages rather well and i do write everything in clojure first and then translate it.
OP's article is called "Why i'm more productive in clojure" This sets a tone that doesn't require evidence because its a very personal. If readers choose to interoperate that as "clojure is better" then i can't blame them, but the author at least had the decor to not state their opinions as evidence.
In terms of evidence for anything Programming language related, even if you had read every study, your still going to consider your projects needs. So even if Clojure showed a reduction in bugs over java (https://news.ycombinator.com/item?id=8558740) you should still consider other factors.
So many libraries in Clojure that lead to serious productivity benefits rely on macros, which in turn are possible because of homoiconicity. It's more than useful, it's a key ingredient in the power of the language. You can extend and embed the language or sub-languages or quickly write a particularly potent DSL in just a few lines of code in Clojure thanks to this feature.
Compare this to language that offer macros but without homoiconicity and the benefits are clear. The two different ways to write macros in C and C++ involve language semantics and syntax that are quite different from the regular syntax. In Clojure, the language is identical, you can actually control the compilation process using the same regular Clojure code that you use everywhere else. It's really quite amazing how far this gets you.
I also think macros are what keeps the language clean long term. Since most things can be expressed in user space using libraries, you don't have to bolt them onto the core language.
As time goes on, usage patterns change and something that might've seemed like a good idea at one time can become an anti-pattern later. Clojure has stayed remarkably small and focused over the years while the way it's used has changed significantly.
I'm willing to bet that any dev who has learned Clojure does the same thing. If I'm right, that's a huge indictment of what we've been doing for the last 60 years in programming.