Hacker News Reader

Comment by cnbland | Hacker News Reader

I feel inspired to start with Lisp after being disappointed with the "open" source scene of 2021. I'd rather pay LispWorks a yearly fee and be left alone than dealing with unbalanced people in the Python space. The free Lisp implementations also look somewhat isolated from the ideological wars.

However, a C interface is required. Is this one the recommended solution? Is it really portable?

https://common-lisp.net/project/cffi/

What is the speed compared to a Python C extension? Are implementation-specific C interfaces faster (I guess they are)?

Sorry for so many questions, but these can usually only be answered by people who have actually used the interface.

View on HN

Comparing python's C extensions to CFFI is non-trivial because they work very differently. With Python, you implement the Python API in C, but with CFFI you implement the C API in lisp.

Re: CFFI vs. built-in API

The main difference is what features you have. For example, if you need errno, you will need to do something implementation specific (I'm currently working on a wrapper for that functionality though).

Another example: ECL let's you inline C code in the middle of a lisp program. Most other implementations don't.

As far as performance goes, the actual overhead of calling C is minimal, but if you need to copy large amounts of data, that can kill performance.

There is another library called static-vectors that let's you allocate buffers that can be used natively in both lisp and C, on the implementations that allow doing so.

If you're interested in FFI, then yeah CFFI is the standard. The other comments addressed speed, I also wanted to point out https://github.com/rpav/cl-autowrap which is built on top of CFFI and can help get a wrapper up and running faster. After using autowrap's c-include you can then use CFFI basically like normal or some useful autowrap/plus-c's helper functions -- e.g. in one project, I have an SDL_Event (https://wiki.libsdl.org/SDL_Event) and to access event.key.keysym.scancode I have a helper function that's just (plus-c:c-ref event sdl2-ffi:sdl-event :key :keysym :scancode). Last year I wanted to try out using FMOD, and even though it's closed source and has a (to me) "interesting" API things worked easily: https://gist.github.com/Jach/dc2ec7b9402d0ec5836a935384cacdc... More work would be needed to make a nice wrapper, type things more fully, etc. but depending on the C library you might find someone's already done that (or made a start) and made it available from quicklisp.

I would give the Emacs/Slime/SBCL combo a try, it's definitely an acquired taste but pretty cool and more Lispy than anything else you will find.

The most friendly and welcoming open source communities in my experience are Ruby, Elixir and Clojure. I'm sorry you had bad experiences, but don't let that stop your projects.

"Unbalanced" python people? Do you have examples? I don't do python and have no basis of experience with python, besides the fact that I have never installed a python program successfully with their package manager.

Is python the language that has spread furthest from programming circles? It probably used to be VB mostly due to Office, but with Python at #2 in Tiobe ahead of Java and behind only C, I'd guess yes.

Here's a good example of unbalanced people: https://github.com/pypa/pipenv/issues/2228#issuecomment-3926...

Yes, CFFI is the defacto standard, and has support for practically all implementations in use today. Nobody (but CFFI) uses the implementation-specific interfaces.

Reply on news.ycombinator.com