Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

What are the particular advantages of a Lisp on the python runtime?

Interop with existing programs could be good, as well as a potential trojan horse to convert a dev shop to Lispier languages if you care about that kind of thing.

Otherwise I'm not sure - what python libraries stand out as particularly useful in this situation? I haven't really interacted with the world of python that much so I'd love to hear.



If you are a lisp-enthusiast, Python comes with strong support for data science and web applications, if nothing else.

If you are a Python enthusiast, lisp-like languages can be used to write DSLs or cut down on boilerplate code in a way which isn't as easy in Python or similar languages.

But yes, in general, a lisp dialect on Python has the problem that Python itself is a great language.


Python has one of the biggest standard libraries there is, there is a lot of useful stuff in there already provided, plus there is a humongous amount of third-party packages available through pip. It also generally has a pretty good C FFI, so there's a lot more support of C-libs in Python.

It's not so much about any specific libraries as it is about the volume of support one gets 'for free,' and as well I think Python syntax and semantics alike really get along better with Lisp than some of the other dialects that rely on FFIs (like Clojure to Java/JavaScript, or the number of C FFIs available for Schemes).

Lisps in general don't tend to include much of a standard library, opting for a 'batteries not included' model, with Racket being perhaps the most prominent (and quite deliberate) exception. So the idea of getting the whole Python ecosystem 'free' is potentially very appealing, especially to someone with a Python background (and there are a lot of those someones around, especially with it increasingly being a more popular teaching language than anything else except JavaScript).


Racket (and precursor Scheme for academic reasons) is the Lisp I've interacted the most with besides Clojure, so I never really considered the perspective of a stdlib being so valuable. Clojure->Java and ClojureScript->Js have always seemed super awkward to me, and having a similar naming style could be a great feature.

Still, I'm reminded of Greenspun's tenth rule when reading about this project. Hopefully it will become a popular and well-supported option in its own right.


I find seeing a multipoint dotted Java name in front of an s-expression deeply unsettling somehow, and I never learned Java anyway, so Clojure was of limited utility to me since so much stuff seemed handed off to Java built-ins.

And I think there is an argument to be made against projects like this, because they're so dependent, but I guess in the case of Hy, that dependence is literally the point. I never felt like it was the case with Clojure, because the host language was so very different from the experimental FP playground Clojurists seem to want.


This comes with any Python, out of the box: https://docs.python.org/2/py-modindex.html

What stands out will be different for different people. I use the ftp and telnet libs a lot, I've used the imap and email libs.

Here's a repackaging of a large number of 3rd party libs, packaged as an alternative python distribution, which I use at work: http://docs.continuum.io/anaconda/pkg-docs.html

I've explored twisted (networking), numpy and scipy (math and scientific), and sympy (symbolic math).

IPython's shell and notebook are great work environment enhancers. http://ipython.org/

Here's Python's larger set of 3rd parties: https://pypi.python.org/pypi?%3Aaction=browse




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: