4 ms·

I guess you were hoping for new cutting edge stuff, but I've been really enjoying Common Lisp. I've used it for a bunch of small projects the last year or so,

I guess you were hoping for new cutting edge stuff, but I've been really enjoying Common Lisp. I've used it for a bunch of small projects the last year or so, and just have a ton of fun. In particular, it has surprisingly good bindings to graphics libraries like Qt, SDL, and OpenGL, and it's super easy to get animations and graphical apps up and running quickly. The compilers are great for such a high level language, and it's significantly faster than Python, which was my preferred language before CL. It doesn't beat the raw speed of C, but I rarely need that anyway. As an example, I just wrote a cheesy, animated FFT visualization and full screen at 2560x1440 it gets 90+ fps with no attempt to optimize on my part, except turning up the default optimization level. https://github.com/jl2/qt-fft-viz https://github.com/jl2/qt-fft-viz The REPL and code reloading makes iterating on ideas really fast, and I find I experiment more in CL because it's just easier.

vram22 10y ago
What CL implementation are you using, on what OS?
- jlarocco 10y ago
  SBCL, mostly on Linux, but also a bit on OSX. Both platforms work really well, but the experience is a bit smoother on Linux. On both platforms I have a script that pulls from Git, rebuilds, and installs over the previous SBCL binary image, so I'm using the absolute bleeding edge of the compiler. One day this will bite me somehow and then I'll start using the most recent stable tag, but it's worked okay up to now. I use Emacs and Slime for development. I had used Emacs for a long time before using CL, so using Slime wasn't an issue for me at all. I know the commercial implementations have some neat IDEs, but I haven't tried them. I'm not sure there's many (or any) OSS alternatives to Slime. On both platforms I use QuickLisp to install all of the Lisp packages I use. Pure Lisp libraries always work great on both platforms. Libraries that wrap C/C++ libraries (like Qt or SDL) tend to work better on Linux, but in every case I can think of I've got them working on OSX also, with varying degrees of effort. On Debian I "apt-get install ..." the required lib* and sometimes lib*-dev packages, and then (ql:quickload ...) has always just worked. External libraries on OSX are where I've encountered the most problems. Qt was particularly tricky, and I'm not even 100% sure what I did that finally got it working. SDL has some hoops to jump through with a "cocoa helper library" that I had to build by hand, but it's pretty simple and a few minutes Googling turned up enough info to get it working. For the majority of the stuff I've needed (libpng, cairo2, mpg123, and a few others), I was able to install them with HomeBrew, and they just worked once I had my PATH and LD_LIBRARY_PATH setup correctly. OSX ships ancient versions of several libraries (like libpng), but installing the version in HomeBrew usually fixes the problem.
  - vram22 10y ago
    Thanks for the detailed answer, interesting. Hadn't known that Common Lisp had Qt bindings.
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.)

vram22 10y ago

What CL implementation are you using, on what OS?

jlarocco 10y ago
SBCL, mostly on Linux, but also a bit on OSX. Both platforms work really well, but the experience is a bit smoother on Linux. On both platforms I have a script that pulls from Git, rebuilds, and installs over the previous SBCL binary image, so I'm using the absolute bleeding edge of the compiler. One day this will bite me somehow and then I'll start using the most recent stable tag, but it's worked okay up to now. I use Emacs and Slime for development. I had used Emacs for a long time before using CL, so using Slime wasn't an issue for me at all. I know the commercial implementations have some neat IDEs, but I haven't tried them. I'm not sure there's many (or any) OSS alternatives to Slime. On both platforms I use QuickLisp to install all of the Lisp packages I use. Pure Lisp libraries always work great on both platforms. Libraries that wrap C/C++ libraries (like Qt or SDL) tend to work better on Linux, but in every case I can think of I've got them working on OSX also, with varying degrees of effort. On Debian I "apt-get install ..." the required lib* and sometimes lib*-dev packages, and then (ql:quickload ...) has always just worked. External libraries on OSX are where I've encountered the most problems. Qt was particularly tricky, and I'm not even 100% sure what I did that finally got it working. SDL has some hoops to jump through with a "cocoa helper library" that I had to build by hand, but it's pretty simple and a few minutes Googling turned up enough info to get it working. For the majority of the stuff I've needed (libpng, cairo2, mpg123, and a few others), I was able to install them with HomeBrew, and they just worked once I had my PATH and LD_LIBRARY_PATH setup correctly. OSX ships ancient versions of several libraries (like libpng), but installing the version in HomeBrew usually fixes the problem.
- vram22 10y ago
  Thanks for the detailed answer, interesting. Hadn't known that Common Lisp had Qt bindings.

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.)