If you’re doing browser/selenium testing, you could definitely write all that in Clojure since it would be a totally different app for those tests. It’s probably possible to use Clojure to do testing of Java functions, but I’ve not seen it done.

https://github.com/lacuna/bifurcan

Source in Java. Tests in clojure. Could be a good example for you

I hear people suggest this a lot but tbh it has never made sense to me. I think you’re better off defining the interfaces for a component in Java and just implementing that component in Clojure.

I suggest the easiest approach is to write the app in Clojure as a separate project, especially if the Web app is providing an API. This is also a clear way of showing the difference between Java and Clojure. There are some nice templates to help create an API web app, like https://kit-clj.github.io/ or https://practical.li/clojure/clojure-cli/projects/templates/practicalli/ The practicalli/service template creates a working APi with a few endpoints, swagger, logging, etc. Optionally with Donut or Integrant for component management

thank you! there is an API alright. I might just try this approach

Sounds like a good question for ask.clojure

There's a jira ticket for this, https://clojure.atlassian.net/browse/CLJ-1179, but I couldn't find an https://ask.clojure.org/, which is usually how the community interacts with clojure development.

Strange. Seems like a vacuous truth. Which clojure does support via every? and others.

> Rich declined it, implying that it was not a change he wanted. Not sure of the reason. [2014] 😬 Seems worth an ask, it's been 10 years

Is there maybe a good alternative to (apply distinct? coll) ?

I doubt you'll do better than

(defn my-distinct?
  ([] true)
  ([& xs] (apply distinct? xs)))

I asked an AI whether this is trivially true: > Given the description of the distinct? function, if it is provided an empty sequence [], it should return true. This is because, in an empty sequence, there are no elements to repeat, so by definition, every element (of which there are none) is unique. Hence, the condition for distinctness is trivially satisfied. Sounds reasonable that there should be no ambiguity here.

More generally, as clojure has fnil I wonder if the presence of an f0 hof would be useful:

(defn f0 [f x]
  (fn
    ([] x)
    ([& xs] (apply f xs))))

(apply (f0 distinct? true) [])
;; => true

there are a number of "please add 0-arity to function N" asks. https://ask.clojure.org/index.php/3348/juxt-should-have-a-0-arity, https://ask.clojure.org/index.php/2780/add-support-for-0-arity-comparisons-in-clojure-core-etc>, https://ask.clojure.org/index.php/12441/should-clojure-core-have-a-zero-arity, https://ask.clojure.org/index.php/12045/expected-difference-in-clj-cljs-behavior-with-apply-max, probably others i can't find in a cursory search. none have made any progress

Except for juxt , there isn't an obvious trivial value to return for those, is there?

maybe also ask in #CBE668G4R?

What is the current language that's used at that workplace?

They use TypeScript, Java and C++. Probably some others as well. It's a big company, and I don't know them very well yet.

Cursive will probably be a better bet since it has the best support for Java given that it's a plugin for IntellIJ IDEA.

in that case I'd start with the Java side of things... they are already familiar with the JVM etc.

Yes, perhaps Cursive is the best place to start. I'm also personally somewhat more familiar with JetBrains IDEs than with VS code, which might be another practical advantage.

Calva uses clojure-lsp and cider-nrepl, among other tech. It's all OSS Cursive is based on proprietary implementations (Cursive itself, and IntelliJ) While I don't believe in 'proprietary' being a negative, most practically, when you have a problem with Calva or the like, one has support from a wider variety of developers, and you can always take a look at the source yourself

Those are valid points, but my impression is that both alternatives are so mature and stable that few people encounter serious issues with either of them?

And those points are hardly selling when it comes to showcasing a new language.

Things are always changing (see Clojure 1.12) and also it's not rare for projects to have unique intricacies https://github.com/cursive-ide/cursive/issues isn't exactly encouraging to me But yes, in the end one can pick anything - tooling is rarely the bottleneck

> isn't exactly encouraging to me Unfortunately, that list itself isn't maintained all that well. Of course, not saying that there are no real issues - I encounter them myself, even beside desired feature requests. But there are a lot of duplicate issues, questions, outdated issues.

As the creator of Calva, I am biased of course. Still think there’s a strong case for Cursive if people come from Java. Cursive is very strong with the Java intersection of things. Ultimately for your colleagues it will come down to which editor they are comfortable with. Calva has a Getting Started REPL, that you could spend some 15 minutes to check out, just to get an idea about what the colleagues choosing Calva will encounter.

They're both great. I'd probably try to understand which one between VS Code and Intellij is more popular in your audience and be driven by the result of this independent survey. I'd keep in the equation also is it smooth or a pain to get software licenses in this workplace?; if there's the risk of getting Cursive licences becoming another tedious task, I'd personally pick VS Code and move on

Which eve one you decide on there are some key things you should let them know about - repls obviously and some key shortcuts, like send to repl, and the one I use most the Slurp and Barf.

Java is ok with VS Code! There are Java plugins from, I think, Red Hat. And I seem to remember seeing a Java LSP start up. I do not know how the VS Code Java support compares on the basis of exotic features like refactorings, but if the plan is to transition away from Java anyway, the only refactoring you really need is "Convert to Clojure", which will, I believe, be announced for Calva in the very near future, maybe April 1.

> Java is ok with VS Code! Can you go from e.g. (cons ...) in your code to (def ... cons ...) in the Clojure's code, and then, without interruption, directly to clojure.lang.RT.cons, then to clojure.lang.PersistentList and find usages of that specific constructor? List time I tried (albeit, more than a year ago), it was pretty much impossible without lots of interruptions like full-text search or manually entering a class name or manually navigating to a package. With IDEA, every single step in that chain is exactly one mouse click or one keyboard shortcut. Of course, different people have different workflows, but I personally find the ability to navigate the whole codebase, including the Java implementation, to be of immense help.

Oh, almost forgot - there's also built-in decompiler of Java classes. A fantastic tool that helps figuring out how some of your dependencies work. With all that smooth navigation built into it.

The choice is simple in my view. Use the editor that is already preferred amongst the developers for their current work (or is used by those most open to the idea of a new language). The capability of Clojure is largely irrelevant for early discussion. Lots of editors support Clojure sufficiently well. If the editor becomes a discussion point it's more likely the editor will become the focus of the discussion rather than the benefits of Clojure. If the developer team get hung up on the use of Emacs or use of parents, then not enough value of Clojure has been conveyed up front, or related to existing challenges they have. Or you've simple engaged with them at a bad time and they are too busy / stressed / exhausted from all the other work/deadlines. Honestly I wouldn't try and convince them all at once. I would build something that just works and is happily running in production. Or build something that solves a nasty problem that they have otherwise struggled with Or find one or two of the team that are open and you have a strong relationship with find out what will convince them to take a meaningful try. Then there are more of you to advocate Clojure. I see a lot of people fall flat trying to introduce a tool, language, etc because they haven't spent enough time considering the needs of those they are trying to advocate to. It is a significant challenge.

@U2FRKM4TW VS Code/Calva/LSP has a built-in Java decompiler now. You can go from cons to clojure.core/cons easily and then go to clojure.lang.RT but it doesn't currently navigate to the cons function in that (perhaps if I had a Java extension installed, that step would be easier).

@U04V70XH6 Just tried. The amount of friction is still insurmountable compared to IDEA. I won't list all the issues, but with the current state of affairs I myself, regretfully, still can't use Calva for my projects. Installing the MS Java pack affects nothing.

Good to know. Luckily, I don't do any Java so VS Code works great for my use cases. I've never liked IntelliJ (JetBrains kept giving me free licenses years ago, asking me to review it for them!) -- I was more of an Eclipse person (but I haven't used that for years now). I actually do have IntelliJ installed, because I've been trying to test Digma with Clojure and Digma doesn't support VS Code yet... but it feels painful every time I open it up 😞

Heh, my experience seems to be the exact opposite, including the Eclipse part. :) It's been a decade since the last time I tried it, but back then it used to choke on large projects (10e7 loc, GBs of deps) and it was incredibly easy for some mundane plugin to do something incorrect that would hang the whole IDE. You could hear regretful moans in the office every half an hour, which stopped the moment we switched to IDEA.

As the Cursive developer, I’d also recommend using whatever they’re familiar with. If they do a lot of Java that’s likely to be IntelliJ, if they’re doing a lot of Typescript it might be VS Code. It’s true that my issue tracker has gotten out of control, but I think Cursive is mostly a relatively problem-free experience for most users these days. If you need any help, feel free to ping me, either by DM or in #C0744GXCJ

Definitely I'd go slow judging the quality or reliability of a product measuring an issue tracker (and I'd double check what's exactly in it). Cursive is rock solid and its user base is usually very happy with it

loop + recur is not about recursion. But recur at the level of a function's body is. The technical aspects of the Erljang's implementation: https://github.com/trifork/erjang/wiki/How-Erjang-compiles-tail-recursion The linked article is 404'ed, but here's its copy in the Internet Archive: https://web.archive.org/web/20100110155216/https://www.javalimit.com/2009/12/tail-recursion-in-erjang.html

Nice find, thanks for the link!

A few thoughts from someone who's not involved in the development of Clojure at all: • recur is much more explicit - it fails if it's not a tail call • Vars can be changed in Clojure at run time: (defn f [x] (alter-var-root #'f (constantly inc)) (f x)) is syntactically a tail call but actually isn't • Non-self tail calls are also supported in Clojure with trampoline, which is also much more explicit than regular calls

Whoa, cool—I hadn't seen trampoline yet.

Um actually, it still is a tail call, just no longer a self tail call

A tail call is a tail call, changing the target doesn't change that

https://clojurians.slack.com/archives/C03S1KBA2/p1708631268989819?thread_ts=1708631268.989819&cid=C03S1KBA2 is another recent thread discussing tail calls and jvm langs

they've been promising us tail calls in the jvm for like 15 years, I'll believe it when I see it :)

Yeah, the questioner in that talk with Vriding also mentions some professor who made a pitch to Sun, which they rejected.

the main reason given was always stack based permissions checks, which was shown to be not an issue like a decade ago, and is now going away entirely

it also is one of those features that a vocal minority of users want but in reality we've been fine™ without.

like how every thread about Loom / Virtual Threads has someone saying "but why no full continuations?"

https://eighty-twenty.org/2011/10/01/oo-tail-calls "Why Object Oriented Languages Need Tail Calls" originally by guy steele when he was working on fortress back when it looked like maybe the davinci vm was going to bring tco to the jvm is very compelling

tail calls on the jvm would also fix things like concat's propensity to blow the stack

I can understand not exposing continuations (I think it is lame, but whatever), but no tail calls does cause real measurable problems