I wonder if you might like "Burgled-Batteries" [0], which gives you access to Python objects from Common Lisp. I have not tried it myself, and it does not yet support CLOS integration, but it looks pretty interesting.
I suspect the problems of Hy are caused precisely by not compiling to bytecode, but to Python abstract syntax. I suspect that a Lisp that bypasses this syntax and goes right to bytecode could do things better: have a real let and such.
Re:Some thoughts on hylang (2017)
by mark_l_watson on Thursday March 21, 2019 @08:07AM
(#19451338)
I feel the same way. I found a nice Hy LSTM demo that uses TensorFlow and had fun playing with that. I did another night of hacking around with Hy and put it in the ‘really interesting, revisit later’ category.
Part of it is that it compiles to Python bytecode, and took the simplest route of adopting Python's not at all lisplike scope. With `let`, you have a visual clue of variable scope; Hy had a broken `let`, and then got rid of it completely. Now it looks like there's a new `let` that might make more sense. I haven't used it in a couple years.
But that's not the only problem. It has the same feeling I get from Clojure and the various lisps that compile to javascript; it just doesn't feel divorced enough from its parent language to be satisfying in itself. I'd rather write lisp than Python, sure, but except for a few libraries I'd like to be able to use, I don't see much reason to prefer Hy over Racket or some other similarly-mature Scheme, which would have somewhat fewer libraries, but would feel like a consistent and self-contained language.