3 ms·
Hy feels all wrong to me, though I really wanted to like it, and I put some time in when I tried it. Part of it is that it compiles to Python bytecode, and too
by JasonFruit 8y ago
Hy feels all wrong to me, though I really wanted to like it, and I put some time in when I tried it.
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.
- nicklaf 8y agoI 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. [0] https://www.cliki.net/burgled-batteries https://www.cliki.net/burgled-batteries
- kazinator 8y agoI 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.
- mark_l_watson 8y agoI 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.