3 ms·

I love writing Lisp, it feels not so much like coding but like writing poetry... Unfortunately, it has lots of problems with interpreter interoperability, lack

by veddox 10y ago

I love writing Lisp, it feels not so much like coding but like writing poetry... Unfortunately, it has lots of problems with interpreter interoperability, lack of threading, etc. (unless I simply haven't found the solution to my problems yet). Therefore I often find myself forsaking it for Python, which has the added advantage that my friends will be able to read the code.

jlarocco 10y ago
All of the modern Common Lisp implementations support threading. I'd almost even say the situation is better than most other languages, because there is very good threading support at several levels of abstraction. First, all of the modern implementations include some kind of implementation specific, low level OS thread wrapper. It's unfortunate that these are all incompatible, but few people need to use them directly, so it's really not too bad. Next, the bordeaux-threads library provides a wrapper around all of the implementation specific libraries. Thanks to macros, the wrapper doesn't add much (if any) overhead. Finally, there are higher level libraries like lparallel and cl-cuda. I've used lparallel a few times, and much prefer it to writing my own low level threading. I'm not really sure what you mean by "interpreter interoperability". Common Lisp is standardized, and sticking to the standard and libraries in QuickLisp, I haven't run into many problems running my code across multiple platforms and multiple implementations of Common Lisp. All of the problems I've encountered have been related to foreign libraries, which, IME, are problematic in most languages.
- veddox 10y ago
  I wasn't aware of lparallel and cl-cuda, thank you for pointing those out! The only threading I knew of was the implementation-specific kind, which makes for some portability headaches. (Especially as I personally use CLISP instead of the more common SBCL.) Yes, the standardized definition is a Good Thing. What I meant by "interpreter interoperability" (I probably should have said implementation compatibility) are things like processing commandline arguments, which are not defined in the standard and vary wildly between operations. (Is there a library for that too? I haven't come across any yet, but that might just be me.)

by veddox 10y ago

jlarocco 10y ago

All of the modern Common Lisp implementations support threading. I'd almost even say the situation is better than most other languages, because there is very good threading support at several levels of abstraction. First, all of the modern implementations include some kind of implementation specific, low level OS thread wrapper. It's unfortunate that these are all incompatible, but few people need to use them directly, so it's really not too bad. Next, the bordeaux-threads library provides a wrapper around all of the implementation specific libraries. Thanks to macros, the wrapper doesn't add much (if any) overhead. Finally, there are higher level libraries like lparallel and cl-cuda. I've used lparallel a few times, and much prefer it to writing my own low level threading. I'm not really sure what you mean by "interpreter interoperability". Common Lisp is standardized, and sticking to the standard and libraries in QuickLisp, I haven't run into many problems running my code across multiple platforms and multiple implementations of Common Lisp. All of the problems I've encountered have been related to foreign libraries, which, IME, are problematic in most languages.

veddox 10y ago
I wasn't aware of lparallel and cl-cuda, thank you for pointing those out! The only threading I knew of was the implementation-specific kind, which makes for some portability headaches. (Especially as I personally use CLISP instead of the more common SBCL.) Yes, the standardized definition is a Good Thing. What I meant by "interpreter interoperability" (I probably should have said implementation compatibility) are things like processing commandline arguments, which are not defined in the standard and vary wildly between operations. (Is there a library for that too? I haven't come across any yet, but that might just be me.)