Hacker News new | ask | show | jobs
by tom-thistime 2310 days ago
This doesn't scratch my itch at all. I love Lisp but boring old Python has the libraries I need.

EDIT: Based on a comment and downvote I suppose I didn't make my point clear above. I am saying that myths are not the only thing holding Lisp back. (I may be wrong. I hope I'm wrong. Big thank-you to people who are linking ways to get libraries in Lisp, especially Python libraries.)

I care 10x as much about libraries as about all these red herrings (EDIT: or myths, as you like) combined: " * Common Lisp does not have compile-time type checking. * Common Lisp is for imperative, object-oriented programming. * Common Lisp is too specialized, it’s not for general-purpose development. * Common Lisp applications are hard to deploy. "

5 comments

I'm always curious when this comes up: which libraries in particular do you have in mind? If you love Lisp and they're really absent, a short list would at least provide a data point for something that would be desirable and ambitious newcomers could cut their teeth on.

Anyway I don't think the library ecosystem is so dire... Lots of good libraries are distributed through quicklisp. It's pretty straightforward to wrap a C library. (You can even do C++ easily if you switch CL implementations to Clasp...) If you need Java libraries, you can switch CL implementations again and use ABCL. (But of course all your CL code and CL libraries still work.) Lastly, for Python there's https://github.com/pinterface/burgled-batteries (and https://github.com/snmsts/burgled-batteries3 for py3) that even in an incomplete state might suit your particular library needs.

Perhaps this capability isn't very compelling since Python can also access C without trouble (and Java via Jython, .NET via IronPython)? Well I guess all I have left to ask is whether you've considered there might be libraries (or features) in Lisp that would be needed that don't have equivalents in Python? What do you do then? One possible library for admittedly niche applications that came to mind was a hierarchical task planner (https://github.com/shop-planner/shop3) but I forgot someone did indeed make a Python library (https://github.com/oubiwann/pyhop) based on an older version (SHOP1) of the background work, so depending on if you need the v3 features it might suffice.

Thanks for the links! I'll check them out. I like the "higher level" of Python libraries better than C or even Java, because I tend to write what most people would call prototype code. Small user base, small applications, and the really harsh constraint is development time from concept through validation.

No-doubt-unnecessary boilerplate: I understand that people have language wars, and it's possible you may have identified me as belonging to one side or another, but I'll pass. That whole state of affairs is just unfortunate.

In addition, check out py4cl: https://github.com/bendudson/py4cl

(And a Numpy clone: https://numcl.github.io/numcl/)

If you're interested in lisps and python's ecosystem you might enjoy lib python from Clojure: http://gigasquidsoftware.com/blog/2020/01/24/clojure-interop...

https://run.nextjournalusercontent.com/kommen/parens-for-pol...

Thanks! Nothing would be more awesome than Lisp (or Scheme, I don't care) with easy transparent access to modern libraries.
I wonder if someone made an invert hylang.. a python->clojure transpiler
These four things are common myths. It says so in the very line above them. This article is literally about debunking these myths.
Yeah, I read it. Can you explain how "red herrings" differ from "myths"? Is the distinction really that important?

My point was that it is not just myths (or red herrings either) that are holding Lisp back. There are some issues based in reality as well.

I think the distinction is both easy to make and important.

Myths are widely held to be fundamental about a thing (but not necessarily true). Red herrings, on the other hand, are a distraction that draws your attention away from the actual matter at hand.

So that said, I think what you are trying to say is that contrary to the poster, you believe focusing on these myths is a red herring and there are other fundamental reasons that lisp popularity remains what it is. I suspect because you did not articulate the difference, your discussion got sidetracked into semantics because it sounded like you were saying they were "the same thing"

It's true that are many more for Python than for Common Lisp. Do you have some examples of libraries you are missing in Common Lisp?
Offhand, recently I've used NumPy, telnetlib, openpyxl, TkInter. I haven't used Lisp for a very long time, because of my (perhaps faulty) perception that some of these things (and the next one I will need) might not be there, or might be less usable than their Python counterparts.