While modern JVM languages leverage Java to overcome the 'library problem', the traffic tends to be one-way. So while there are 'clojurely' ways to call Java libraries, calling Clojure from Java is ugly and non-idiomatic, despite what the article claims. How does one even call Scala from Clojure?
Presuming that, for the most part, developers migrate from Java to a different JVM language, then inevitably these languages will fragment code written for the JVM, devaluing the very foundation used to hoist the languages into usefulness in the first place. The tower of Babel will rise higher with competing idiomatic implementations of various libraries. This is not a bad thing--rather it has to be this way because introducing new language features (such as STM in Clojure's case) demands it. We're living in a gold rush on Java to mine it for its libraries. After this will come a period of settlement as each JVM language builds its own community, with civic structures that perform the same duties, but look different, in every town square.
Calling Clojure from Java is ugly, but calling Clojure from JRuby is quite pleasant, and I'm pretty sure a nice Clojure library could be written for calling JRuby from Clojure.
Calling Clojure from Java is difficult because Java is inflexible more than some inherent weakness in the "bootstrap on a host VM" strategy.
I've written a library to call Clojure from JRuby. It's about 100 lines, and took me an afternoon. I assume the situation is similar all high level JVM languages.
Given all the above, I agree that the JVM languages will fragment somewhat, but to a lesser degree than you seem to think. If there are any really killer app libraries in one language, it won't be too hard to integrate them into the other languages.
Clojure and Java interop works and that's great. What's really interesting about this situation is that there's one guy committing code in a completely different language from everyone else. Not only that, but it's a language that most would consider "weird". How well is that received by the rest of the team?
Is anyone else picking up Clojure or is it "that one guy's crazy code that no one can understand"? I think we've all seen latter situation even when everyone's coding in the same language and it's a huge red flag.
I'm all for new and different languages seeing business use, but doing it this way seems potentially harmful. But maybe it was a huge success here; I'd love to hear more about it.
There's only 2 of us, and the other guy also wanted to learn Clojure. His response to my statement was: "That's part of the reason I want you on the team, we need to advance some of the tech on the project."
Also, Clojure has been in use at DRW for over 3 years, so adding it to another project wasn't actually that big of a deal.
I know all that context wasn't in the article, so I think your questions are on point - but, I think that info isn't really on topic for the article, which is why I left it out.
You are missing a lot of context. The DRW tech team has a lot of ex ThoughtWorkers - many of the best got tired of traveling around for consulting assignments and were snapped up by DRW. Jay was a very respected dev when he was at TW (we worked on a project together- hi Jay!), and if I were trying to hire him I would be hiring him specifically so that he could raise the bar. Adding Clojure to a java code base is trivial, especially given the calibre of the DRW team. The idea at TW when I was there was that languages were expected to change and devs were supposed to "level up" as part of their job description.
TW had the policy that "technical decisions are made by technical people" and I wouldn't be surprised if DRW had something similiar. What mix of languages should be used on a project should (imo) be made by developers who work on that code base. If Jay insists on working in a language he knows (from experience, he is a great Java dev) to be better, then more power to him.
This is interesting, and in general Clojure interop with Java is really nice. For me the biggest pain point comes when you are working with a Java framework, where you generally have to extend Java classes (abstract classes, often), and that gets pretty unwieldy. In general, I think, Clojure often tries to be too dynamic for what you generally want in this case, or at least what I did. For programming Android or IntelliJ plugins (which is what I tried to do) I'd prefer a mechanism to write the code with Clojure but generate "normal" (i.e. non-dynamic) bytecode AOT, like Kawa does.
It's not exactly a "normal" class IIRC - I believe each method is actually a class and method calls from the gen-class'ed class are delegated to them. This is to maintain the ability to replace these methods dynamically but it would be nice to be able to state that I don't want that behaviour. gen-class is a little odd to use, too. Again, it works but is just a little funky compared to the rest of the interop.
While I completely agree that what I said would be a red-flag in the wrong context, this was more a case of - I believe Clojure is a better tool for the job and I don't want to join the team if we're going to be stuck with Java. My statement wasn't about wanting to do future development with a specific language, it was about wanting to use the best tool for the job. We actually use Clojure, Java, Bash, Ruby, web (HTML+JS+CSS), and C#...
Great writeup. I also prefer coding in Clojure and JRuby rather than in Java. While interop is important, I have just invested in a large effort in converting some of my existing Java (and bits of Common Lisp) code to Clojure. I am hoping to build a business around the new codebase and I decided that it was worth the effort doing a cleanup and standardize on one language so it will be easier to add new features.
Presuming that, for the most part, developers migrate from Java to a different JVM language, then inevitably these languages will fragment code written for the JVM, devaluing the very foundation used to hoist the languages into usefulness in the first place. The tower of Babel will rise higher with competing idiomatic implementations of various libraries. This is not a bad thing--rather it has to be this way because introducing new language features (such as STM in Clojure's case) demands it. We're living in a gold rush on Java to mine it for its libraries. After this will come a period of settlement as each JVM language builds its own community, with civic structures that perform the same duties, but look different, in every town square.