Something makes me think they'll notice all the parens during a code review...

Write a reader macro that treats all [ ], { } and < > as if they were ( ), and the only thing they'll notice is that there's less parens/brackets than there should be in regular Java code...

There have been efforts to do something similar to create more "readable" S-expressions. I did work in Common Lisp for a number of years and didn't have any issues with the syntax but I rather like this idea:

http://readable.sourceforge.net/

why would one do that instead of using clojure?

Because as 'klibertp wrote, they're two vastly different languages, with different design decisions.

The whole thread is about primarily Common Lisp; people who enjoy the design choices made by the CL standardization committee and subsequent evolution of the language's ecosystem would most likely want to know that there exists a proper CL implementation for JVM.

but the person i replied to replied to a commenter lamenting the fact that there was nothing but java and c style development jobs instead of lisp inspired jobs. they weren't lamenting the lack of jobs specific to just common lisp. and to me, it doesn't make sense to "sneak in" an esoteric implementation of lisp on the jvm when clojure already exists. what makes people think that would be easier to sell at a place using java heavily?

I wouldn't call ABCL esoteric; it's as rightful JVM citizen as Clojure or Scala. That said, I agree it's much, much less popular in the JVM world, so it could be a harder sell.

Because, despite both being Lisps, Clojure and Common Lisp are vastly different languages, with different pros and cons.

of course they're different. i didn't say or imply otherwise. the original parent mentioned both racket and common lisp, again different languages, so it was clear they weren't looking just for common lisp and were more generally wanting for some lisp or scheme type of job. and i was asking a legitimate and honest question, as i see ABCL to be a much more esoteric and hard sell than clojure to a place heavy on java development.

You asked, "why would one use [ABCL]?" What I implied in my response (sorry for not stating it directly) was that one may prefer the particular feature set of CL over Clojure's.

As for being a hard sell - my personal experience is that if you're in a position that allows you to choose your implementation language, in most cases you can choose Brainfuck and nobody will care. As an example, I introduced F#, Erlang, Elixir and a bit of Prolog to a Python shop that way: all that mattered in these cases was whether the code worked, and it did, so no one complained. The Erlang microservice actually outlived the project it was written for by a year and a half.

On the other hand (still, in my experience) if you're not in a position where you can choose your language you're basically screwed, and should stop trying to convince your team to switch to something else. You have almost no chance of succeeding and a high chance of disrupting teamwork by pushing your opinions on others.

So I was thinking about the former situation, where you have some degree of freedom of choice and can decide the language on technical merits alone.

Common Lisp is vastly more powerful and better implemented.

Seems dead

> Seems dead

The latest release (1.5) was earlier this month.

plus:

it's common lisp. if the language spec hasn't changed, and your code works, you don't really need to change the interpreter.

ABCL's interoperability with Java is not part of the CL spec, but an add-on. This can make it easy to quickly get things done in a situation where Java libraries are the best tool for the task, but at the cost of portability between CL implementations.