Often I see Clojure projects which talk about trying to make their libraries accessible to non-Clojure users (I can think of Juxt/Crux, and Cognitect, and others). I’m not criticizing that desire, but more curious: how much do other languages think about this? I have not seen C, C++, Perl, Python, Javascript, Java, etc. saying that their library is designed to allow people to use it without using the language it’s written in. Is this a common desire that I’ve just overlooked, or is there something peculiar about us or our language that seeks this… “diplomacy”? Is it related to our being a hosted language (in which case other JVM languages might exhibit this concern for foreign users)? To Lisp being “weird” (so Algol languages pretend they share syntax that doesn’t need compromise)? To something else?
Big piece of infrastructure often do target being usable from other languages, such as Spark, which is implemented in Scala, but works to be usable from outside Scala and even outside the JVM.
Similarly most databases don’t force their clients to use the same language they are built in, such as Oracle not forcing compatibility with only Java.
I think it makes similar sense for similar projects in Clojure to have that reach as well. I think the challenge with Clojure sometimes though is that bringing to other languages can hurt the benefits that Clojure brought. Like using EDN over JSON has benefits, but EDN isn’t well supported in other languages, so providing a JSON alternative does diminish the value proposition sometimes, like datalog queries are not as cleanly modeled in it for example.
For a database, stored functions where Clojure code is data and can be sent to the DB to run within the DB context is a benefit here too, supporting similar things for other languages are again trickier, maybe now you need some DSL instead and all that.
But the general idea of reach I think is a good one, and especially for projects like those which require investment to maintain and develop further, reaching out outside Clojure for it might be a good thing.
A related question, then, is whether a claim can be held that Clojure syntax is better in some way, and that it constitutes a loss to go to another language. I’m not ready to say that’s completely true just yet, but if ANY language is better than others, Clojure is at the better-end of that spectrum…
I think syntax differences in languages are one of the lesser compelling reasons to choose one language over another. More important to me are the big ideas that a language supports (e.g. CSP, immutable persistent data structures, etc).
True, yet,… in the specific case of Clojure, the lisp(y) syntax is actually a feature I miss when I return to (most) other languages.
in the specific case of Clojure, the lisp(y) syntax is actually a feature I miss when I return to (most) other languages.
For me it is the consistency. Having written a lot of TypeScript over the last couple of years, it always strikes me how inconsistent a language feels when it uses syntax to mix method calls and infix operators. As an example, I find it difficult to remember how to use the instance check in TypeScript: Why is it foo instanceof Bar and not foo.instanceOf(Bar) or instanceOf(foo, Bar)? That’s a rhetoric question of course. 
I think the value of consistent syntax is very high, and it feels like languages with reserved keywords are quicker to take the route of “let’s introduce a new keyword for this”. Given the macro system, Clojure is not without this pitfall, but it seems like the language designers have done a good job of communicating the data > functions > macros mantra, and the community has accepted it.
As to the original question, I think it is a matter of reach. If you have a product that is better built with one language yet is generally useful, making the product usable from more languages increases the potential return on investment. In the case of Clojure, the reach of a product limited to being used from Clojure is relatively small, compared to a product built to be used from Java or C.
I think it’s hard to make a profit building solutions for Clojure’s user base and nothing else. Database solutions like Crux, Datomic, etc. are expensive to develop and hard to monetize in the first place; you’re doing B2B sales competing not only with solutions like Oracle, Microsoft, etc. but also “free” open-source projects. Building a sustainable business means carving out a niche these industry titans aren’t servicing and ensuring that the niche is big enough to pay the salaries of the developers, salespeople, management, etc.
Secondly, there’s a risk assessment that development teams must do when adopting a product: how might our business and development practices change? Will this product meet our needs in the future? If a particular database only works with Clojure, and we want to build something new using Ruby on Rails, well, no we’re not- or we use Postgres with our RoR app and build a system that synchronizes the two systems, introducing a ton of complexity. Development happens within a business, and businesses change all the time; they pivot, get bought, buy other businesses, devs get hired and leave. Choosing a flexible solution allows us to ride those waves and keep the tech in line with what the business needs.
That is a well-put response. So is it the case that Clojure is one of many that work to accommodate other ecosystems? Or is it mostly a database thing? Or do many do it?
The first version of Storm was written in Clojure, but it had a Java-first API. I think the rationale behind that was to make for efficient and elegant development of the tool itself, but have it reach a much larger audience.
The reference Python implementation refuses to remove the GIL because removing it would break interop with C libraries.
I’ve seen the argument made that lower level libraries should be implemented in C, or at least expose C bindings, so they can be used by more languages.
The Wayland protocol specifies a binary interop instead of language apis specifically so that window managers can be written in any language.
.Net is designed so that any language can be compiled to it. C# is kind of the reference language, but any .Net language can use stuff compiled from any other .Net language. That’s by design to not force one language on everybody.
So, it’s not unheard of for cross language usage to be taken into account. I have no idea why the various Clojure libraries do it, though.
This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.