Hy may have changed since I last looked at it, but when I had looked at it, Hy was more of an s-expression syntax bolted onto python.

Some random thoughts on why this matters:

Clojure is very much not a thin s-expression layer for java; that would have been terrible (Python is more like lisp than java which is why Hy is tenable whatsoever).

In particular, CL style macros with out some first-class concept of symbols are a footgun[1], but I'm sure I could find other issues.

Another item that can't be ignored is that Hy selected the clojure syntax, which is going to be a turn-off for anyone coming from Lisp or Scheme.

Finally, there are hundreds of thin s-expression layers on top of existing languages, and most of them are terrible; Hy has done nothing to stand out from this crowd, so most lispers will not look closely at it.

1: See https://youtu.be/cPNkH-7PRTk?t=4786 for Rich's discussion of how he managed this issue in Clojure.

I'm actually interested in what other problems make Hy and similar languages infeasible. Even if a brief overview, as food for thought on the matter.

They aren't infeasible; a real lisp could target Python. However, just bolting on lisp syntax to python ends up in an uncanny valley of "not python" and also "not lisp."

I would actually recommend watching the entire youtube video I posted earlier (Clojure for Lisp programmers). Rich talks about a lot of the design decisions that went into Clojure. Some decisions I agree with, some I don't, but there was thought into creating a unified whole and he was clearly aware of work that had gone before, even when he chose to do things differently.

Note also that Clojure was his third attempt at doing a lisp/java interop, so there was a lot of previous experience backing many of those decisions.

Lastly, it's really easy to make a bad lisp-frontend for a language and a massive amount of work to make a good one. This is well known by anyone who has been in the lisp community for a while (if for no other reason than they themselves have made a bad one) so for better or worse, such frontends tend to be ignored.

A good way to target a Lisp to Python might be to forget the Python AST and target its virtual machine directly.

The compiler could itself be written in its own target dialect, and bootstrapped with some existing Lisp.

If I had to guess I would say the overlap is not as sizeable as you think, at least in the Common Lisp and Scheme camps.

Python really has very few things in common with Lisp and its philosophy is in many ways orthogonal to the philosophy of Lisp. From the idiotic moto "There should be one — and preferably only one — obvious way to do it" (which isn't even true in Python-land) to all the compromises that Python accepted to attract marketshare that would make any hardened Lisp user want to barf, it's crystal clear to me that Python makes an even worse platform than the JVM for Lisp.

Some examples of serious differences between Python and Common Lisp - that would make any serious CL user run away from Python/Hy - are:

+ CL (like Smalltalk) is a fully interactive language. Python's focus on interactivity is minimal if not entirely unproductive. Approaches like Jupyter come across as terrible hacks that lack most of the features that matter to people immersed in Lisp.

+ CL can be very performant. Implementations like SBCL can produce native code competitive with C compilers.

+ CL is truly multiparadigm (one can do imperative, functional, OOP, logic, aspect, nondeterministic, lazy, parallel/multicore and not feel as if the language is fighting him every step of the way). Python has too many limitations for that to be true.

+ Lisp feels conceptually clean and internally consistent. The metacircular evaluator is a thing of beauty. Python feels like a collection of gross hacks and adhoc rules thrown together by humans who didn't know better.

For me it is language instability. I was trying with Hy multiple times, but every new release they would break something, mostly by changing or removing core functionality (eg. removing let/cons).

To me, this looks like kids playground rather than serious project.

If Hy developers doesn't know how to evolve language properly, especially hosted one, which is challenging for itself, I'd suggest they look at Clojure or take some proper language development course.

It doesn't surprise me. It does not have a strong selling point.

I go on to the documentation page, and see that yes, it is nice clean lisp-like language, but I can't see what problem it solves that Clojure doesn't already solve. (And clojure has the existing library/community support to give it the edge.)

EDIT: That's not to say that there isn't one. I just am not immediately seeing it.

> which is a Lisp on the Python platform

'a Lisp' is a practically useless term, when you expect that usual Lisp code will run or even being able to be ported. It's incompatible with any other Lisp. Which makes it an island.

Played around with it a few months ago. The syntax is peculiar, clojure-inspired, but still very different. Breaking changes have been made, leaving most libraries unusable. The documentation didn't mention this (and is lacking in many other ways).

And btw. many of these changes weren't even features. Like core functions getting removed for philosophical reasons.

Feels like they broke and abandoned it

I imagine Clojure is more popular with Java programmers than it is with CL programmers. I did CL for over a decade and I've certainly never had a need to pick it up:

Java programmers on the other hand always seem to be looking for a reason to not use Java. But Python programmers? Always looking for a reason to use more Python.

FWIW: A lot of people also don't love Python. I particularly hate it, but the things (I perceive) it's bad at, Hy doesn't help with.

>- Plenty of people love Lisps, afaict with a sizeable overlap with the first group.

Not that many. And not that many are non-pragmatic enough to mess with a translation layer.

They removed "cons" in the latest version :(

Python can't use multiple cores, in contrast to the other lisps?

What does language have to do with "use multiple cores"? Python has both multiprocessing and threading libraries.

And the GIL on CPython, but yeah multiple process are also an option.