10 ms·

Hy 1.0 – Lisp dialect for Python

448 points by Kodiologist 2y ago

steeeeeve 2y ago
To resolve the issue of Python not having enough parentheses.
blumomo 2y ago
Congratulations! I once bought your eBook on Hy, and still today I regularly receive notifications about your book having been updated. Thank you for your steady contributions. I really want to use Hy in one my production apps one day.
- Kodiologist 2y ago
  The author of the e-book is a different guy, Mark Watson. He isn't involved in the development of the language.
  - blumomo 2y ago
    Oh, thanks. He seemed so enthusiastic about Hy :-) I just read through the author list on the Hy repo and had a glimpse into their blog posts. Cool stuff, great work.
marmaduke 2y ago
I enjoyed the less serious part a lot. I wish more programming related projects could embrace the whimsical. That might the best way to honor the python tradition in any case :)
- Kodiologist 2y ago
  I eliminated a lot of whimsy from Hy and its documentation years ago because it was distracting and created noisy test failures, but I did go too far at some point, and have tried to reintroduce a little whimsy more recently.
paultopia 2y ago
EXCITING! Can't wait to give it a spin! (Does `let` work? I remember that being a barrier for a while.)
- Kodiologist 2y ago
  Remarkably enough, yes, we got it to work, on our 3rd or 4th try.
  - rcarmo 2y ago
    Yep. I use it a lot.
anovick 2y ago
Congrats! Could you compare the language with Clojure?
- Kodiologist 2y ago
  Well, this is a little embarrassing: Clojure was one of the biggest influences on Hy in its youth, but that was mostly before I got involved in 2016. I never actually learned Clojure. So hopefully somebody who knows both Hy and Clojure well can answer. I can tell you that at run-time, Hy is essentially Python code, so Hy is more tightly coupled to Python than Clojure is to Java; a better analogy is CoffeeScript's relationship with JavaScript. I get the impression that Clojure tries to convince the programmer to avoid side-effects a lot more strenuously than Hy does, but it's still not a purely functional language, so I don't know how consequential that is in practice.
  - a57721 2y ago
    Clojure has a good collection library with immutable/persistent data structures, but as a language it allows side effects and has some mechanisms to manage them. It is also possible to call any Java method from Clojure. Clojure does not work with Java ASTs, it translates into JVM bytecode directly.
- chrisrink10 2y ago
  I haven't used Hy, but I am the maintainer of a Basilisp which also compiles to Python and aims for reasonably close compatibility with Clojure if you're interested. https://github.com/basilisp-lang/basilisp https://github.com/basilisp-lang/basilisp
  - anovick 2y ago
    Cool project! Wondering how custom immutable data structures fit in with the Python ecosystem. Particularly, I know that NumPy arrays and Pandas Series/DataFrames are the popular data structures used in research computing in Python (for Statistics, Data Science, Machine Learning etc.). These data structures afaik are mutable, however (for performance reasons), so at least the aspect of immutability from Clojure cannot be easily integrated with the Python ecosystem.
kayo_20211030 2y ago
Very exciting. I'm in awe of the long-term commitment (over 10 years) that was required to get this to 1.0.0. It renews my faith. Well done.
tosh 2y ago
Does Hy also work with Mojo?
- Kodiologist 2y ago
  I'm not sure. I was going to say that Mojo is proprietary software and so I've never tried it, but I just checked and apparently it's free now. If nothing else, you can probably get a lot of Hy code to run on Mojo via `hy2py`, if Mojo supports a lot of Python as it claims to. Edit: actually, confusingly, the GitHub repository for Mojo doesn't have an interpreter. The language is still proprietary.
  - tosh 2y ago
    Thank you for the hy2py pointer and kudos @ 1.0.0!
- rcarmo 2y ago
  Not sure either, but it should. I do test it every year or so with pypy.
knlb 2y ago
Congratulations -- and thank you! I've been playing with Hy on and off (tried to do transformers with it, and then released https://github.com/kunalb/orphism https://github.com/kunalb/orphism written in hy). Time to pick it up again and take it for a spin
chrisrink10 2y ago
Congrats on the release! Very impressive.
instig007 2y ago
You can get FP compositions without throwing away Python syntax (as Hy does): https://github.com/thyeem/foc https://github.com/thyeem/foc
- benrutter 2y ago
  That library looks like some seriously cool wizardry! I'm excited to play around with it later
agentultra 2y ago
Wow! It has come such a long way since its early, humble beginnings. I saw the original lightning talk that introduced Hy to the world at Pycon those ages ago. Soon after I met Paul and started contributing to the early versions of Hy. I was responsible for the CL-style kwargs (you’re welcome), some minor innards, and a library or two. Whimsy is useful, especially to keep enthusiasm up. It’s nice when hackers can be hackers and not every thing is business. While I haven’t been involved in years it brings a smile to me face to see the project continues apace. What a great milestone!
agumonkey 2y ago
Congrats. It's been a great pleasure to watch it evolve. :)
HexDecOctBin 2y ago
Congrats! Two questions: 1. Does it support REPL-driven development? (condition system, breakloop, etc.) 2. Is there a standalone distribution? Distributing python in itself is a hassle, ideal situation would be to simply distribute a single Hy binary that contains all dependencies within it (either statically linked or as a zip file extracted in tmp directory).
- rcarmo 2y ago
  I managed to do 2, sort of, with py2app and judicious hacking. You can compile everything to byte code and use Python "single file" deployment tools.
- tosh 2y ago
  not a standalone distribution but: uvx hy@1.0.0 gets you into the Hy REPL echo '(print "hi hn")' > hi.hy uvx hy@1.0.0 hi.hy prints "hi hn" https://docs.astral.sh/uv/guides/tools/#running-tools https://docs.astral.sh/uv/guides/tools/#running-tools (context: uv can install and manage python versions)
  - PaulHoule 2y ago
    Generally, uv answers the objection that ‘Python sux’ in that it (1) is correct, unlike pip, and (2) is freaky fast.
    - Snowfield9571 2y ago
      Except uv doesn’t support conda so there goes many of the niche scientific packages required for many users like me. Someone please prove me wrong because I do love uv when I can use it. I’ve found pixi to be an ok alternative but not nearly as fast.
- Kodiologist 2y ago
  1. I don't know what a breakloop is. Hy uses Python's exception system, which is more like a traditional exception system than Common Lisp's condition system. 2. No, sorry.
cooljoseph 2y ago
I was having some difficulty figuring out how Hy actually is translated to Python (and wasn't even sure if it was compiled or interpreted). Eventually I found on Wikipedia the following: > Hy is a dialect of the Lisp programming language designed to interact with Python by translating s-expressions into Python's abstract syntax tree (AST). Also, looking at the code on Github suggests this compiler is written in Python (see https://github.com/hylang/hy/blob/master/hy/compiler.py https://github.com/hylang/hy/blob/master/hy/compiler.py). I kind of wish this was made more clear on the main website. Perhaps, instead of introducing Hy as "a Lisp dialect that's embedded in Python", introduce it as "a Lisp dialect that compiles to Python's AST". The words "embedded in Python" don't make it very clear just how it's embedded into Python. The various ways you can embed a Lisp look very different and have very different tradeoffs. For example, off the top of my head, I could "embed" a Lisp by writing an interpreter (in C if I care about performance) and letting it be called from Python, perhaps passing in a Python list instead of a string to make it more "native". Or I could "embed" a Lisp by compiling to Python bytecode. Or I could "embed" a Lisp by translating it directly to Python source code. Etc. Regardless, interesting project!
- rcarmo 2y ago
  The "embed" part stems from the fact that you can mix Python and Hy in a project with bi-directional calling. Works great, because it is all Python byte code in the end.
- PuercoPop 2y ago
  The original hy annoucement makes it clear that they embed a Lisp by compiling with Python bytecode. You can see it in the following video about the 16:25 mark https://m.youtube.com/watch?v=1vui-LupKJI https://m.youtube.com/watch?v=1vui-LupKJI
  - Foxboron 2y ago
    and for those interested in history, Docker was first announced 10 minutes afterwards on the 26:24 mark.
rcarmo 2y ago
At long last! Now I can finally clean up https://github.com/rcarmo/sushy https://github.com/rcarmo/sushy (I've been poking at it over the years, but every time I upgraded hy portions of the syntax broke, or things would get moved in and out of the hyrule package, etc.) By the way, Hy works really well inside https://holzschu.github.io/a-Shell_iOS https://holzschu.github.io/a-Shell_iOS on the iPad, although the syntax highlighting in vim/neovim needs to catch up to the 0.29+ releases and async. Although I've tried using Fennel and Guile instead over the years, having access to Python libraries and ecosystem is preferable to me, and with async I can do some very nice, efficient API wrangling (doing HTTPS with fine-grained control over socket re-use and headers remains a pain in various Schemes, so I very much prefer using aiohttp)
BeetleB 2y ago
Any downsides to using Hy (over Python)? Other than my coworkers don't know Lisp? More concrete: Are there Python language features I can't use in Hy? Or performance penalties in using Hy?
- Kodiologist 2y ago
  > Are there Python language features I can't use in Hy? At the semantic level, no. I work to cover 100% of Python AST node types with Hy's core macros. It does take me a little bit to implement a new core macro after the CPython guys implement a new feature, but you can always use the `py` or `pys` macros to embed the Python you need, should it come to that. > Or performance penalties in using Hy? Compiling Hy (that is, translating it to Python AST) can be slow for large programs (I've seen it top out at about 3 seconds), but at runtime you shouldn't see a difference. Hy always produces bytecode, which can be used to skip the compilation step if the code is unchanged.
- rcarmo 2y ago
  You take a little performance hit upon initial startup (from a clean filesystem, while __pycache__ folders are created). Other than that, mostly everything is the same. I'm now figuring out how to pack images to OpenAI REST calls (using my own REST wrapper), and everything is peachy. Here's my test snippet (mostly to b64encode the file): (import aiohttp [ClientSession] base64 [b64encode] asyncio [run]) (defn :async pack-image [filename] (with [h (open filename "rb")] { "type" "image_url" "image_url" { "url" f"data:image/jpeg;base64,{(.decode (b64encode (.read h)) "utf-8")}" } })) (defn :async main[] (print (await (pack-image "request.hy")))) (run (main)) This shows you async, context managers, selective imports, f-strings... etc. All that you need, really.
- Qem 2y ago
  Lack of self-contained tooling. Idle doesn't work with Hy. You'll probably need to fiddle with Emacs to set your environment first, before being able to do anything beyond playing with the language in the REPL.
  - 2y ago
cab404 2y ago
Ну, молодцы.
deleted 2y ago
[deleted]
vintagedave 2y ago
I loved the HYPE POST.[0] I work with corporate software. It is absolutely brilliant. [0] https://github.com/hylang/hy/discussions/2609 https://github.com/hylang/hy/discussions/2609
- zoom6628 2y ago
  That post deserves its own star rating! Absolutely brilliant.
- Kodiologist 2y ago
  Thanks. I enjoyed compiling a huge list of buzzwords to use for it.
- __MatrixMan__ 2y ago
  > I guide the development of Hy as a morally ambiguous iconoclast not totally averse to indefinite nominal executive rule, or "MAINTAINER" for short. Hehe, clever.
qwerty456127 2y ago
Does PyCharm support it already?
- Kodiologist 2y ago
  I don't think so? https://youtrack.jetbrains.com/issue/PY-48754/Support-for-hy-language https://youtrack.jetbrains.com/issue/PY-48754/Support-for-hy...
celaleddin 2y ago
Great news, congratulations! Years ago, under the influence of Lisp romanticism late into my university years, I worked on a domain-specific language for designing and analyzing control systems as my senior design project, using Hy! Just checked, it's been five and a half years to be specific. Really, time flies. Here it is for anyone curious: https://github.com/celaleddin/gently https://github.com/celaleddin/gently Since then, I've been following Hy from a distance and it's amazing to see it's still active. Thank you everyone involved!
jedberg 2y ago
I looked the examples page, but it was a little disappointing. Every example was something that was easier (and sometimes shorter) in Python. It would be awesome if there were an example of something that can't be done in Python because it takes advantage of lisp's "functions are first class".
Foxboron 2y ago
Super happy Hy 1.0 has been released! It was the first proper open-source project I contributed towards and I don't think I would have been as engaged as I am in the community without it.
masijo 2y ago
Also related, for the Clojure fans among us: A Clojure-compatible(-ish) Lisp dialect targeting Python 3.8+ https://github.com/basilisp-lang/basilisp https://github.com/basilisp-lang/basilisp
librasteve 2y ago
(one) nice thing about Raku is it does a surprisingly good lisp impression out of the box… https://www.codesections.com/blog/raku-lisp-impression/ https://www.codesections.com/blog/raku-lisp-impression/ [thanks to Larry Wall’s penchant for collecting stuff]
- lispm 2y ago
  Strange, the Lisp example has a lot of syntax, even though the article claims it hasn't. letrec, lambda, or & and are not functions in Scheme.
ashton314 2y ago
Yay! The birth of a language is a beautiful thing. I’m curious about the macros: how are these implemented? They seem like pretty straightforward unhygienic Lisp macros, which is a little bit of a disappointment, but better some macros than none at all! Anything about the macro system that distinguishes it from the Common Lisp system? E.g. anything borrowed from Scheme or Racket? Docs are sparse here.
- kstrauser 2y ago
  It’s far from new. In 2012 I worked for a shop who used an internal package named “hy”, and the introduction of this Hy made our builds break in a novel and interesting way. (Also, use something to insure your own internal packages have a higher priority, alright? That’s a lesson I didn’t need to learn twice.)
  - ashton314 2y ago
    You're right—my bad. I'm sad I hadn't heard about Hy sooner! Update then: The first stable release of a language is a beautiful thing! :)
- Kodiologist 2y ago
  Sparse? I got a whole chapter for ya: https://hylang.org/hy/doc/v1.0.0/macros https://hylang.org/hy/doc/v1.0.0/macros
  - ashton314 2y ago
    Yes, and it's a very nice tutorial! I'm interested in implementation details. Maybe there's no hygiene (and no scope sets etc.) to worry about—that would probably make documentation a little shorter. I'm sure the documentation will grow as people run into edge cases. (I'm also probably a little spoiled with documentation coming from Racket which has like 4 big chapters dedicated to different aspects of macros scattered around the docs, plus some associated papers. Forgive me—I'm not trying to dunk on Hy; I just like reading docs.)
libbrfish 2y ago
I'm wondering, is it worth learning Hy if I don't know any python? (coming from a clojure background) Or is python knowledge a prerequisite?
- Kodiologist 2y ago
  Learning Python is not required to get started and do some simple stuff, but it is effectively required to master Hy.
nikisweeting 2y ago
I remember Hy! It blew my mind back in 2014 and is still cool today, it's great to see it still going and congrats on releasing 1.0.0! Also great timing after the recent Python Preprocessor post: https://pydong.org/posts/PythonsPreprocessor/ https://pydong.org/posts/PythonsPreprocessor/ Could Hy hypythetically be implemented as a preprocessor like https://github.com/tomasr8/pyjsx https://github.com/tomasr8/pyjsx?
- Kodiologist 2y ago
  Hy-pothetically, yes, you could take Hy code in and spit Python code out via `hy2py`. I think at one point I considered supporting this officially, but then decided there was really no advantage.
  - cfiggers 2y ago
    That's how I'm using Hy at my job—I write Hy then hy2py it into Python, lightly polish the compiled Python for human consumption, and then share that with my Python-fluent but Lisp-illiterate coworkers.
mark_l_watson 2y ago
Wonderfull! I wrote a book oh Hy, so now tomorrow I will update all the examples to version 1.0 Not counting work on my book, I don’t use Hy more than perhaps five hours a month, but it is a fun language, with good Emacs support. Thanks!
- Kodiologist 2y ago
  You're welcome. There are no actual breaking changes from 0.29.0, so you're already up to date if you got that far.
aidenn0 2y ago
Does Hy offer any features that Python lacks (e.g. dynamic binding)? I find the syntax of Lisp to be the least compelling of its many features.
- Kodiologist 2y ago
  Yes, such as: metaprogramming via macros and reader macros; arbitrary compile-time computation; removal of restrictions on mixing statements and expressions; and other arities for Python's binary operators. See http://hylang.org/hy/doc/v1.0.0/whyhy#hy-versus-python http://hylang.org/hy/doc/v1.0.0/whyhy#hy-versus-python Dynamically shadowing global variables is not built-in, but easy to write a macro for if you want it. See e.g. https://stackoverflow.com/a/71618732 https://stackoverflow.com/a/71618732
notepad0x90 2y ago
I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?
- ungamedplayer 2y ago
  I find non lisp harder. In blub lang based on c: Fn(Val Val Val) to f(1,2,3) or Val fn val 3 + 3 In blub lang based on lisp (Fn val val...)
- troad 2y ago
  I don't think (fn x y z) is all that different to fn(x, y, z). The lack of finicky operator order or other syntax footguns is nice. You're basically looking at the AST as you work. You're one fewer layer of abstraction removed from the logic you are composing. In real world Lisp, alignment conventions are used that make even a fairly nested function readable at a glance. You'd also generally work using something like paredit, so you're kind of shuffling the S-expressions around like legos. It's not a language that you'd want to write in something like Notepad. The most important thing about the syntax, though, is that since it's basically the AST, a Lisp macro can effectively manipulate the AST directly and on the fly. This is incredibly powerful, and would be hard to achieve in an Algolian language like Python.
  - notepad0x90 2y ago
    Because we're so used to thinking parenthesis provides an order of evaluation precedence, the fact that 'fn' is within the parenthesis is very confusing. even (fn(x y z)) would have been better. having the function name and it's arguments just next to each other with no syntactic separation is hard to follow. it's like doing arithmetic this way: "add x y z" , is it x+y = z or x=y+z? I'm sure I can get over this hurdle though. Thanks for suggesting paredit.
    - troad 2y ago
spit2wind 2y ago
Whoa, congrats! Been watching this project for years, seeing the steady progress toward a 1.0. It's been no small feat. Congrats! Excited for you!
aitchnyu 2y ago
Does it (or other lisps) interact with Python static typing?
- Kodiologist 2y ago
  You can add all the same type annotations as in Python, but from what I've seen, type-checkers expect Python source text and don't just use standard Python introspection, so you'll need to use `hy2py` first to actually check your program's types.
giessel 2y ago
Congrats!
fhchl 2y ago
Not a Lisp, but also an interesting take on a functional programming language that transpiles to Python is Coconut (https://coconut-lang.org/ https://coconut-lang.org/). I'd be seriously interested in hearing from people that have actually used any of these two and what their experience was.
- nerdponx 2y ago
  I played around with Coconut many years ago and my impression was that the compiler was not smart enough to be useful. The generated code had a big pile of helper functions hardcoded at the top, and the program was much slower than the equivalent plain Python. By contrast Hy generates Python code that is very close to what you might write by hand, apart from some indirection when it comes to scoping with `let` and some variations around returning values. Maybe Coconut has improved though, it's been a long time.
rogerallen 2y ago
Is there a wisp frontend? Seems like it would be appropriate. :-) https://github.com/stereobooster/wisp https://github.com/stereobooster/wisp
jollyjerry 2y ago
This reminds me of Berkeley's CS61A when it was taught with Scheme. One of the projects was writing a schema interpreter for scheme. It felt silly, but was a great small project to show case recursion, trees, and blurring the distinct between data and code.
mcejp 2y ago
I would like to make the observation that as Hy matured over the years, instead of accumulating syntactic sugar and special cases to grow more Lispy, less Pythony, it seems to have generally gone the opposite way. That is, becoming a thinner syntactic abstraction of Python's feature set, focusing on the essentials that cannot be emulated in any other way (macros) A few examples from recent releases: - "match" is just native Python "match" -- it doesn't even polyfill for pre-3.10 Python versions (in the TypeScript world this would be unthinkable) - "foo?" used to mangle to "is_foo" as a special case, but this has been removed - "hy.eval" has been overhauled to be more like Python's "eval" - nice-to-have but non-essential utilities ("unless") get often pushed out into the Hyrule package For me this direction was counter-intuitive at first, but it has some very nice outcomes; for one, it simplifies the learning curve when coming over to Hy from Python, and it makes it easier to consistently interact with Python packages (arguably the main reason to use Python in the first place!) Or maybe it's just a matter of simplyfing maintenance of the language; IIRC, "let" took like 4 attempts to get right :) In any case, congratulations on this great milestone!
- Kodiologist 2y ago
  Yeah, at a certain point I realized that both the maintenance and the use of the language became much slicker if unnecessary deviations from Python were minimized. After all, when I'm writing Hy code, I'm usually spending a lot more time referring to the documentation of Python or third-party Python libraries than the documentation of Hy. I felt there were a number of ways Python could be improved upon, but e.g. the old feature that let you spell `True` as `true` in deference to Clojure was just a needless complication.
  - mcejp 2y ago
    It is true that Hy really shines in those cases where it adopts an existing Python feature and adds meaningful quality-of-life improvements: anonymous functions without limitations; multiple iteration in for-loops; relaxed character set for identifiers. Things that seem completely obvious, once you have them. It also demonstrates that elegance in a Lisp-on-Python is reached in a very different way than elegance in a stand-alone language, since it becomes an art of making the best out of what is already there.

448 points by Kodiologist 2y ago

To resolve the issue of Python not having enough parentheses.

Congratulations! I once bought your eBook on Hy, and still today I regularly receive notifications about your book having been updated. Thank you for your steady contributions. I really want to use Hy in one my production apps one day.

Kodiologist 2y ago
The author of the e-book is a different guy, Mark Watson. He isn't involved in the development of the language.
- blumomo 2y ago
  Oh, thanks. He seemed so enthusiastic about Hy :-) I just read through the author list on the Hy repo and had a glimpse into their blog posts. Cool stuff, great work.

marmaduke 2y ago

I enjoyed the less serious part a lot. I wish more programming related projects could embrace the whimsical. That might the best way to honor the python tradition in any case :)

Kodiologist 2y ago
I eliminated a lot of whimsy from Hy and its documentation years ago because it was distracting and created noisy test failures, but I did go too far at some point, and have tried to reintroduce a little whimsy more recently.

paultopia 2y ago

EXCITING! Can't wait to give it a spin! (Does `let` work? I remember that being a barrier for a while.)

Kodiologist 2y ago
Remarkably enough, yes, we got it to work, on our 3rd or 4th try.
- rcarmo 2y ago
  Yep. I use it a lot.

anovick 2y ago

Congrats! Could you compare the language with Clojure?

Kodiologist 2y ago
Well, this is a little embarrassing: Clojure was one of the biggest influences on Hy in its youth, but that was mostly before I got involved in 2016. I never actually learned Clojure. So hopefully somebody who knows both Hy and Clojure well can answer. I can tell you that at run-time, Hy is essentially Python code, so Hy is more tightly coupled to Python than Clojure is to Java; a better analogy is CoffeeScript's relationship with JavaScript. I get the impression that Clojure tries to convince the programmer to avoid side-effects a lot more strenuously than Hy does, but it's still not a purely functional language, so I don't know how consequential that is in practice.
- a57721 2y ago
  Clojure has a good collection library with immutable/persistent data structures, but as a language it allows side effects and has some mechanisms to manage them. It is also possible to call any Java method from Clojure. Clojure does not work with Java ASTs, it translates into JVM bytecode directly.
chrisrink10 2y ago
I haven't used Hy, but I am the maintainer of a Basilisp which also compiles to Python and aims for reasonably close compatibility with Clojure if you're interested. https://github.com/basilisp-lang/basilisp https://github.com/basilisp-lang/basilisp
- anovick 2y ago
  Cool project! Wondering how custom immutable data structures fit in with the Python ecosystem. Particularly, I know that NumPy arrays and Pandas Series/DataFrames are the popular data structures used in research computing in Python (for Statistics, Data Science, Machine Learning etc.). These data structures afaik are mutable, however (for performance reasons), so at least the aspect of immutability from Clojure cannot be easily integrated with the Python ecosystem.

kayo_20211030 2y ago

Very exciting. I'm in awe of the long-term commitment (over 10 years) that was required to get this to 1.0.0. It renews my faith. Well done.

tosh 2y ago

Does Hy also work with Mojo?

Kodiologist 2y ago
I'm not sure. I was going to say that Mojo is proprietary software and so I've never tried it, but I just checked and apparently it's free now. If nothing else, you can probably get a lot of Hy code to run on Mojo via `hy2py`, if Mojo supports a lot of Python as it claims to. Edit: actually, confusingly, the GitHub repository for Mojo doesn't have an interpreter. The language is still proprietary.
- tosh 2y ago
  Thank you for the hy2py pointer and kudos @ 1.0.0!
rcarmo 2y ago
Not sure either, but it should. I do test it every year or so with pypy.

knlb 2y ago

Congratulations -- and thank you! I've been playing with Hy on and off (tried to do transformers with it, and then released https://github.com/kunalb/orphism https://github.com/kunalb/orphism written in hy). Time to pick it up again and take it for a spin

chrisrink10 2y ago

Congrats on the release! Very impressive.

instig007 2y ago

You can get FP compositions without throwing away Python syntax (as Hy does): https://github.com/thyeem/foc https://github.com/thyeem/foc

benrutter 2y ago
That library looks like some seriously cool wizardry! I'm excited to play around with it later

agentultra 2y ago

Wow! It has come such a long way since its early, humble beginnings. I saw the original lightning talk that introduced Hy to the world at Pycon those ages ago. Soon after I met Paul and started contributing to the early versions of Hy. I was responsible for the CL-style kwargs (you’re welcome), some minor innards, and a library or two. Whimsy is useful, especially to keep enthusiasm up. It’s nice when hackers can be hackers and not every thing is business. While I haven’t been involved in years it brings a smile to me face to see the project continues apace. What a great milestone!

agumonkey 2y ago

Congrats. It's been a great pleasure to watch it evolve. :)

HexDecOctBin 2y ago

Congrats! Two questions: 1. Does it support REPL-driven development? (condition system, breakloop, etc.) 2. Is there a standalone distribution? Distributing python in itself is a hassle, ideal situation would be to simply distribute a single Hy binary that contains all dependencies within it (either statically linked or as a zip file extracted in tmp directory).

rcarmo 2y ago
I managed to do 2, sort of, with py2app and judicious hacking. You can compile everything to byte code and use Python "single file" deployment tools.
tosh 2y ago
not a standalone distribution but: uvx hy@1.0.0 gets you into the Hy REPL echo '(print "hi hn")' > hi.hy uvx hy@1.0.0 hi.hy prints "hi hn" https://docs.astral.sh/uv/guides/tools/#running-tools https://docs.astral.sh/uv/guides/tools/#running-tools (context: uv can install and manage python versions)
- PaulHoule 2y ago
  Generally, uv answers the objection that ‘Python sux’ in that it (1) is correct, unlike pip, and (2) is freaky fast.
  - Snowfield9571 2y ago
    Except uv doesn’t support conda so there goes many of the niche scientific packages required for many users like me. Someone please prove me wrong because I do love uv when I can use it. I’ve found pixi to be an ok alternative but not nearly as fast.
Kodiologist 2y ago
1. I don't know what a breakloop is. Hy uses Python's exception system, which is more like a traditional exception system than Common Lisp's condition system. 2. No, sorry.

cooljoseph 2y ago

I was having some difficulty figuring out how Hy actually is translated to Python (and wasn't even sure if it was compiled or interpreted). Eventually I found on Wikipedia the following: > Hy is a dialect of the Lisp programming language designed to interact with Python by translating s-expressions into Python's abstract syntax tree (AST). Also, looking at the code on Github suggests this compiler is written in Python (see https://github.com/hylang/hy/blob/master/hy/compiler.py https://github.com/hylang/hy/blob/master/hy/compiler.py). I kind of wish this was made more clear on the main website. Perhaps, instead of introducing Hy as "a Lisp dialect that's embedded in Python", introduce it as "a Lisp dialect that compiles to Python's AST". The words "embedded in Python" don't make it very clear just how it's embedded into Python. The various ways you can embed a Lisp look very different and have very different tradeoffs. For example, off the top of my head, I could "embed" a Lisp by writing an interpreter (in C if I care about performance) and letting it be called from Python, perhaps passing in a Python list instead of a string to make it more "native". Or I could "embed" a Lisp by compiling to Python bytecode. Or I could "embed" a Lisp by translating it directly to Python source code. Etc. Regardless, interesting project!

rcarmo 2y ago
The "embed" part stems from the fact that you can mix Python and Hy in a project with bi-directional calling. Works great, because it is all Python byte code in the end.
PuercoPop 2y ago
The original hy annoucement makes it clear that they embed a Lisp by compiling with Python bytecode. You can see it in the following video about the 16:25 mark https://m.youtube.com/watch?v=1vui-LupKJI https://m.youtube.com/watch?v=1vui-LupKJI
- Foxboron 2y ago
  and for those interested in history, Docker was first announced 10 minutes afterwards on the 26:24 mark.

rcarmo 2y ago

At long last! Now I can finally clean up https://github.com/rcarmo/sushy https://github.com/rcarmo/sushy (I've been poking at it over the years, but every time I upgraded hy portions of the syntax broke, or things would get moved in and out of the hyrule package, etc.) By the way, Hy works really well inside https://holzschu.github.io/a-Shell_iOS https://holzschu.github.io/a-Shell_iOS on the iPad, although the syntax highlighting in vim/neovim needs to catch up to the 0.29+ releases and async. Although I've tried using Fennel and Guile instead over the years, having access to Python libraries and ecosystem is preferable to me, and with async I can do some very nice, efficient API wrangling (doing HTTPS with fine-grained control over socket re-use and headers remains a pain in various Schemes, so I very much prefer using aiohttp)

BeetleB 2y ago

Any downsides to using Hy (over Python)? Other than my coworkers don't know Lisp? More concrete: Are there Python language features I can't use in Hy? Or performance penalties in using Hy?

Kodiologist 2y ago
> Are there Python language features I can't use in Hy? At the semantic level, no. I work to cover 100% of Python AST node types with Hy's core macros. It does take me a little bit to implement a new core macro after the CPython guys implement a new feature, but you can always use the `py` or `pys` macros to embed the Python you need, should it come to that. > Or performance penalties in using Hy? Compiling Hy (that is, translating it to Python AST) can be slow for large programs (I've seen it top out at about 3 seconds), but at runtime you shouldn't see a difference. Hy always produces bytecode, which can be used to skip the compilation step if the code is unchanged.
rcarmo 2y ago
You take a little performance hit upon initial startup (from a clean filesystem, while __pycache__ folders are created). Other than that, mostly everything is the same. I'm now figuring out how to pack images to OpenAI REST calls (using my own REST wrapper), and everything is peachy. Here's my test snippet (mostly to b64encode the file): (import aiohttp [ClientSession] base64 [b64encode] asyncio [run]) (defn :async pack-image [filename] (with [h (open filename "rb")] { "type" "image_url" "image_url" { "url" f"data:image/jpeg;base64,{(.decode (b64encode (.read h)) "utf-8")}" } })) (defn :async main[] (print (await (pack-image "request.hy")))) (run (main)) This shows you async, context managers, selective imports, f-strings... etc. All that you need, really.
Qem 2y ago
Lack of self-contained tooling. Idle doesn't work with Hy. You'll probably need to fiddle with Emacs to set your environment first, before being able to do anything beyond playing with the language in the REPL.
- 2y ago

cab404 2y ago

Ну, молодцы.

deleted 2y ago

[deleted]

vintagedave 2y ago

I loved the HYPE POST.[0] I work with corporate software. It is absolutely brilliant. [0] https://github.com/hylang/hy/discussions/2609 https://github.com/hylang/hy/discussions/2609

zoom6628 2y ago
That post deserves its own star rating! Absolutely brilliant.
Kodiologist 2y ago
Thanks. I enjoyed compiling a huge list of buzzwords to use for it.
__MatrixMan__ 2y ago
> I guide the development of Hy as a morally ambiguous iconoclast not totally averse to indefinite nominal executive rule, or "MAINTAINER" for short. Hehe, clever.

qwerty456127 2y ago

Does PyCharm support it already?

Kodiologist 2y ago
I don't think so? https://youtrack.jetbrains.com/issue/PY-48754/Support-for-hy-language https://youtrack.jetbrains.com/issue/PY-48754/Support-for-hy...

celaleddin 2y ago

Great news, congratulations! Years ago, under the influence of Lisp romanticism late into my university years, I worked on a domain-specific language for designing and analyzing control systems as my senior design project, using Hy! Just checked, it's been five and a half years to be specific. Really, time flies. Here it is for anyone curious: https://github.com/celaleddin/gently https://github.com/celaleddin/gently Since then, I've been following Hy from a distance and it's amazing to see it's still active. Thank you everyone involved!

jedberg 2y ago

I looked the examples page, but it was a little disappointing. Every example was something that was easier (and sometimes shorter) in Python. It would be awesome if there were an example of something that can't be done in Python because it takes advantage of lisp's "functions are first class".

Foxboron 2y ago

Super happy Hy 1.0 has been released! It was the first proper open-source project I contributed towards and I don't think I would have been as engaged as I am in the community without it.

masijo 2y ago

Also related, for the Clojure fans among us: A Clojure-compatible(-ish) Lisp dialect targeting Python 3.8+ https://github.com/basilisp-lang/basilisp https://github.com/basilisp-lang/basilisp

librasteve 2y ago

(one) nice thing about Raku is it does a surprisingly good lisp impression out of the box… https://www.codesections.com/blog/raku-lisp-impression/ https://www.codesections.com/blog/raku-lisp-impression/ [thanks to Larry Wall’s penchant for collecting stuff]

lispm 2y ago
Strange, the Lisp example has a lot of syntax, even though the article claims it hasn't. letrec, lambda, or & and are not functions in Scheme.

ashton314 2y ago

Yay! The birth of a language is a beautiful thing. I’m curious about the macros: how are these implemented? They seem like pretty straightforward unhygienic Lisp macros, which is a little bit of a disappointment, but better some macros than none at all! Anything about the macro system that distinguishes it from the Common Lisp system? E.g. anything borrowed from Scheme or Racket? Docs are sparse here.

kstrauser 2y ago
It’s far from new. In 2012 I worked for a shop who used an internal package named “hy”, and the introduction of this Hy made our builds break in a novel and interesting way. (Also, use something to insure your own internal packages have a higher priority, alright? That’s a lesson I didn’t need to learn twice.)
- ashton314 2y ago
  You're right—my bad. I'm sad I hadn't heard about Hy sooner! Update then: The first stable release of a language is a beautiful thing! :)
Kodiologist 2y ago
Sparse? I got a whole chapter for ya: https://hylang.org/hy/doc/v1.0.0/macros https://hylang.org/hy/doc/v1.0.0/macros
- ashton314 2y ago
  Yes, and it's a very nice tutorial! I'm interested in implementation details. Maybe there's no hygiene (and no scope sets etc.) to worry about—that would probably make documentation a little shorter. I'm sure the documentation will grow as people run into edge cases. (I'm also probably a little spoiled with documentation coming from Racket which has like 4 big chapters dedicated to different aspects of macros scattered around the docs, plus some associated papers. Forgive me—I'm not trying to dunk on Hy; I just like reading docs.)

libbrfish 2y ago

I'm wondering, is it worth learning Hy if I don't know any python? (coming from a clojure background) Or is python knowledge a prerequisite?

Kodiologist 2y ago
Learning Python is not required to get started and do some simple stuff, but it is effectively required to master Hy.

nikisweeting 2y ago

I remember Hy! It blew my mind back in 2014 and is still cool today, it's great to see it still going and congrats on releasing 1.0.0! Also great timing after the recent Python Preprocessor post: https://pydong.org/posts/PythonsPreprocessor/ https://pydong.org/posts/PythonsPreprocessor/ Could Hy hypythetically be implemented as a preprocessor like https://github.com/tomasr8/pyjsx https://github.com/tomasr8/pyjsx?

Kodiologist 2y ago
Hy-pothetically, yes, you could take Hy code in and spit Python code out via `hy2py`. I think at one point I considered supporting this officially, but then decided there was really no advantage.
- cfiggers 2y ago
  That's how I'm using Hy at my job—I write Hy then hy2py it into Python, lightly polish the compiled Python for human consumption, and then share that with my Python-fluent but Lisp-illiterate coworkers.

mark_l_watson 2y ago

Wonderfull! I wrote a book oh Hy, so now tomorrow I will update all the examples to version 1.0 Not counting work on my book, I don’t use Hy more than perhaps five hours a month, but it is a fun language, with good Emacs support. Thanks!

Kodiologist 2y ago
You're welcome. There are no actual breaking changes from 0.29.0, so you're already up to date if you got that far.

aidenn0 2y ago

Does Hy offer any features that Python lacks (e.g. dynamic binding)? I find the syntax of Lisp to be the least compelling of its many features.

Kodiologist 2y ago
Yes, such as: metaprogramming via macros and reader macros; arbitrary compile-time computation; removal of restrictions on mixing statements and expressions; and other arities for Python's binary operators. See http://hylang.org/hy/doc/v1.0.0/whyhy#hy-versus-python http://hylang.org/hy/doc/v1.0.0/whyhy#hy-versus-python Dynamically shadowing global variables is not built-in, but easy to write a macro for if you want it. See e.g. https://stackoverflow.com/a/71618732 https://stackoverflow.com/a/71618732

notepad0x90 2y ago

I'm almost convinced people are pretending to like the Lisp syntax. I just don't get it. I looked at the Hy vs Python comparison, Hy is just as (if not more) verbose as Python and harder to read and reason about. Honest inquiry here, what is the appeal or benefit of the Lisp syntax? is it just that some people have a subjective preference for it?

ungamedplayer 2y ago
I find non lisp harder. In blub lang based on c: Fn(Val Val Val) to f(1,2,3) or Val fn val 3 + 3 In blub lang based on lisp (Fn val val...)
troad 2y ago
I don't think (fn x y z) is all that different to fn(x, y, z). The lack of finicky operator order or other syntax footguns is nice. You're basically looking at the AST as you work. You're one fewer layer of abstraction removed from the logic you are composing. In real world Lisp, alignment conventions are used that make even a fairly nested function readable at a glance. You'd also generally work using something like paredit, so you're kind of shuffling the S-expressions around like legos. It's not a language that you'd want to write in something like Notepad. The most important thing about the syntax, though, is that since it's basically the AST, a Lisp macro can effectively manipulate the AST directly and on the fly. This is incredibly powerful, and would be hard to achieve in an Algolian language like Python.
- notepad0x90 2y ago
  Because we're so used to thinking parenthesis provides an order of evaluation precedence, the fact that 'fn' is within the parenthesis is very confusing. even (fn(x y z)) would have been better. having the function name and it's arguments just next to each other with no syntactic separation is hard to follow. it's like doing arithmetic this way: "add x y z" , is it x+y = z or x=y+z? I'm sure I can get over this hurdle though. Thanks for suggesting paredit.
  - troad 2y ago

spit2wind 2y ago

Whoa, congrats! Been watching this project for years, seeing the steady progress toward a 1.0. It's been no small feat. Congrats! Excited for you!

aitchnyu 2y ago

Does it (or other lisps) interact with Python static typing?

Kodiologist 2y ago
You can add all the same type annotations as in Python, but from what I've seen, type-checkers expect Python source text and don't just use standard Python introspection, so you'll need to use `hy2py` first to actually check your program's types.

giessel 2y ago

Congrats!

fhchl 2y ago

Not a Lisp, but also an interesting take on a functional programming language that transpiles to Python is Coconut (https://coconut-lang.org/ https://coconut-lang.org/). I'd be seriously interested in hearing from people that have actually used any of these two and what their experience was.

nerdponx 2y ago
I played around with Coconut many years ago and my impression was that the compiler was not smart enough to be useful. The generated code had a big pile of helper functions hardcoded at the top, and the program was much slower than the equivalent plain Python. By contrast Hy generates Python code that is very close to what you might write by hand, apart from some indirection when it comes to scoping with `let` and some variations around returning values. Maybe Coconut has improved though, it's been a long time.

rogerallen 2y ago

Is there a wisp frontend? Seems like it would be appropriate. :-) https://github.com/stereobooster/wisp https://github.com/stereobooster/wisp

jollyjerry 2y ago

This reminds me of Berkeley's CS61A when it was taught with Scheme. One of the projects was writing a schema interpreter for scheme. It felt silly, but was a great small project to show case recursion, trees, and blurring the distinct between data and code.

mcejp 2y ago

I would like to make the observation that as Hy matured over the years, instead of accumulating syntactic sugar and special cases to grow more Lispy, less Pythony, it seems to have generally gone the opposite way. That is, becoming a thinner syntactic abstraction of Python's feature set, focusing on the essentials that cannot be emulated in any other way (macros) A few examples from recent releases: - "match" is just native Python "match" -- it doesn't even polyfill for pre-3.10 Python versions (in the TypeScript world this would be unthinkable) - "foo?" used to mangle to "is_foo" as a special case, but this has been removed - "hy.eval" has been overhauled to be more like Python's "eval" - nice-to-have but non-essential utilities ("unless") get often pushed out into the Hyrule package For me this direction was counter-intuitive at first, but it has some very nice outcomes; for one, it simplifies the learning curve when coming over to Hy from Python, and it makes it easier to consistently interact with Python packages (arguably the main reason to use Python in the first place!) Or maybe it's just a matter of simplyfing maintenance of the language; IIRC, "let" took like 4 attempts to get right :) In any case, congratulations on this great milestone!

Kodiologist 2y ago
Yeah, at a certain point I realized that both the maintenance and the use of the language became much slicker if unnecessary deviations from Python were minimized. After all, when I'm writing Hy code, I'm usually spending a lot more time referring to the documentation of Python or third-party Python libraries than the documentation of Hy. I felt there were a number of ways Python could be improved upon, but e.g. the old feature that let you spell `True` as `true` in deference to Clojure was just a needless complication.
- mcejp 2y ago
  It is true that Hy really shines in those cases where it adopts an existing Python feature and adds meaningful quality-of-life improvements: anonymous functions without limitations; multiple iteration in for-loops; relaxed character set for identifiers. Things that seem completely obvious, once you have them. It also demonstrates that elegance in a Lisp-on-Python is reached in a very different way than elegance in a stand-alone language, since it becomes an art of making the best out of what is already there.