8 ms·

Common Lisp Community Survey 2024 Results

98 points by djha-skin 2y ago

smcn 2y ago
Favourite time of the year! I am, however, continually surprised that SLY doesn’t have more mindshare. Similarly jonathan. I guess cl-json and SLIME are _good enough_ for most people. …or maybe I need to revisit them?
- massysett 2y ago
  Sly is a derivative of Slime. I shy away from derivatives unless I understand exactly why the derivative is better than the original. In my view, derivatives often have poor documentation: they just copy the original docs, and I can’t tell when to do things the original way versus a special derivative way. Thus I used Debian and not Ubuntu, Vim and not Neovim, Emacs and not Spacemacs (though that’s not exactly a derivative), etc. I do use SBCL rather than CMUCL, as I do understand why SBCL is better for me: CMUCL won’t run on my platform. I look at the Sly page and I have no idea why I would want any of the stuff it does, so I stick with Slime.
  - tmtvl 2y ago
    Eh, I can see a use for stickers, they seem more convenient to work with than (break).
  - diogenesoft 2y ago
    Maybe TRY USING it and then you might understand. This mindset is the same reason people rarely try lisp because it is quite difficult to see somethings without actually using them.
    - massysett 2y ago
      I don’t have time to try everything. Sly may well be excellent. Plenty of folks might not try Lisp because they’re happy with the tools they have. And that’s ok.
- reikonomusha 2y ago
  Zulu-Inuoe's jzon blew everything else out of the water imho. It's a superlative example of a robust and comprehensive library to do a single job very well.
  - smcn 2y ago
    New to me! Will give it a bash.
  - BoingBoomTschak 2y ago
    The "cannot encode a dotted pair" issue still being open is the only thing worrying me, personally.
behnamoh 2y ago
[flagged]
- DavidSJ 2y ago
  I basically agree with you, but one answer to your challenge is Emacs. However, I’m sure it wouldn’t use anything like Elisp if written anew today.
- massysett 2y ago
  Emacs and Autocad.
  - behnamoh 2y ago
    > Emacs But that's a software made in Lisp for Lisp. The fact that it also works for other purposes doesn't change the fact that it's a "technology for the sake of technology" product, not "technology for the sake of goals".
    - diogenesoft 2y ago
      Not sure this makes any sense. Not sure what emacs does could have been as easily done in other languages.
    - lispm 2y ago
      GNU Emacs wasn't written for Lisp. It was developed as an extensible text editor. Its extension language was also the implementation language for a large part of the software. Much of the application domain of GNU Emacs has nothing to do with Lisp. People edit their files with it or integrate with tools.
  - tra3 2y ago
    Been writing elisp in Emacs for a couple of years now. Emacs is an amazing piece of software and its heyday lisp was revolutionary. These days though I don’t see what it offers over other general purpose languages.
  - fuzztester 2y ago
lkuty 2y ago
The "Steel Bank Common Lisp" link points to https://www.reddit.com/r/Common_Lisp/ https://www.reddit.com/r/Common_Lisp/ instead of http://www.sbcl.org/ http://www.sbcl.org/
- lkuty 2y ago
  The link https://edicl.github.io/Hutchentoot/ https://edicl.github.io/Hutchentoot/ should be with a lowercase h: http://edicl.github.io/hunchentoot/ http://edicl.github.io/hunchentoot/
- djha-skin 2y ago
  Oops. Will fix.
deleted 2y ago
[deleted]
rltuax 2y ago
> What libraries or tooling would you like to see written for Common Lisp next? I would like the entire Python scientific ecosystem be ported to Common Lisp instead of Python. Lisp is vastly superior for numerical work. What would be required for this to happen? I think empirically we can say that people who wrap Intel MKL, BLAS, etc. prefer a stable C-API with stable C functions that access the internals and do not want an FFI. The native FFI from SBCL is difficult to handle and performance is somewhat unpredictable due to garbage collection. I know this is a hard problem that alternative Python implementations like PyPy also fight with, but if SBCL somehow managed to publish a C-API that is as fast as CPython's (single threaded is good enough for the start) and retain the excellent speed for pure Lisp, I think it might be a great success. Even tricks like automatically activating some form of a GIL when loading a C module would be completely acceptable. In general, roughly copy the Python C-API, it is safe to say by now that people want this.
- deleted 2y ago
  [deleted]
- echoangle 2y ago
  Can you explain in what way Lisp is better than Python for numerical work? For someone who has never used Lisp?
  - g11479 2y ago
    smart common lisp compilers are orders of magnitude faster than cpython without annotations and can be in the same ballpark as c or fortran with annotations, which means that you can do your numeric work in lisp itself, without calling out to any kind of foreign libraries. it is not feasable to do numerical work in python itself, in reality python acts as a construction kit dsl for allocating and manipulating foreign (c and fortran) structures. this is usually sufficient as one can see by the massive success of libraries like numpy. when you are writing novel numeric code though, you have to figure out how to match it to the numpy's model. this is also not usually a problem, since matching it to numpy's model usually makes it architecturally performant. but one is still wearing a kind of straight jacket at the end of the day. when i was doing computation chemistry, i wrote a lot of code from scratch in fortran and lisp, and it was entirely feasable to do mainloops purely in lisp, implementing algorithms close to their paper versions. there are all kinds of aspects of lisp that make it pleasant to work with in computational science area, but this is already a tldr. i'll mention one, it's possible to rig your code in a way that a long running batch process will not lose its state without much code overhead. since lisp lets you recover from error without unwinding the stack, you can trust that after hours or days of computation an error is not going to cost you full progress loss. often times you can redefine the offending part of code, and continue processing.
guenthert 2y ago
[flagged]
- djha-skin 2y ago
  I tried to get it out to as many channels as possible, all the ones I knew about -- the common Lisp subreddit, discord, irc, the fediverse, telegram cl group, and matrix. I also sent two reminders in those places :) I'm sorry if I didn't reach you though. What channel did I miss?
  - g11479 2y ago
    http://planet.lisp.org/ http://planet.lisp.org/ is the canonical lisp revival place to announce lisp related things. a very small subset of lispers hang out on places like reddit, discord or telegram
  - shawn_w 2y ago
    Reddit-wise, you posted on /r/Common_Lisp but not /r/lisp, which has a lot more subscribers and activity.
  - rjsw 2y ago
    Add the mailing lists for the main implementations. You could even have posted to comp.lang.lisp.
  - guenthert 2y ago
    I was just curious, where the survey was posted. It seems I missed it, when a link to it was posted it here on HN. In any event, I thought it would be worth documenting such for any survey.

98 points by djha-skin 2y ago

smcn 2y ago

Favourite time of the year! I am, however, continually surprised that SLY doesn’t have more mindshare. Similarly jonathan. I guess cl-json and SLIME are _good enough_ for most people. …or maybe I need to revisit them?

massysett 2y ago
Sly is a derivative of Slime. I shy away from derivatives unless I understand exactly why the derivative is better than the original. In my view, derivatives often have poor documentation: they just copy the original docs, and I can’t tell when to do things the original way versus a special derivative way. Thus I used Debian and not Ubuntu, Vim and not Neovim, Emacs and not Spacemacs (though that’s not exactly a derivative), etc. I do use SBCL rather than CMUCL, as I do understand why SBCL is better for me: CMUCL won’t run on my platform. I look at the Sly page and I have no idea why I would want any of the stuff it does, so I stick with Slime.
- tmtvl 2y ago
  Eh, I can see a use for stickers, they seem more convenient to work with than (break).
- diogenesoft 2y ago
  Maybe TRY USING it and then you might understand. This mindset is the same reason people rarely try lisp because it is quite difficult to see somethings without actually using them.
  - massysett 2y ago
    I don’t have time to try everything. Sly may well be excellent. Plenty of folks might not try Lisp because they’re happy with the tools they have. And that’s ok.
reikonomusha 2y ago
Zulu-Inuoe's jzon blew everything else out of the water imho. It's a superlative example of a robust and comprehensive library to do a single job very well.
- smcn 2y ago
  New to me! Will give it a bash.
- BoingBoomTschak 2y ago
  The "cannot encode a dotted pair" issue still being open is the only thing worrying me, personally.

behnamoh 2y ago

[flagged]

DavidSJ 2y ago
I basically agree with you, but one answer to your challenge is Emacs. However, I’m sure it wouldn’t use anything like Elisp if written anew today.
massysett 2y ago
Emacs and Autocad.
- behnamoh 2y ago
  > Emacs But that's a software made in Lisp for Lisp. The fact that it also works for other purposes doesn't change the fact that it's a "technology for the sake of technology" product, not "technology for the sake of goals".
  - diogenesoft 2y ago
    Not sure this makes any sense. Not sure what emacs does could have been as easily done in other languages.
  - lispm 2y ago
    GNU Emacs wasn't written for Lisp. It was developed as an extensible text editor. Its extension language was also the implementation language for a large part of the software. Much of the application domain of GNU Emacs has nothing to do with Lisp. People edit their files with it or integrate with tools.
- tra3 2y ago
  Been writing elisp in Emacs for a couple of years now. Emacs is an amazing piece of software and its heyday lisp was revolutionary. These days though I don’t see what it offers over other general purpose languages.
- fuzztester 2y ago

lkuty 2y ago

The "Steel Bank Common Lisp" link points to https://www.reddit.com/r/Common_Lisp/ https://www.reddit.com/r/Common_Lisp/ instead of http://www.sbcl.org/ http://www.sbcl.org/

lkuty 2y ago
The link https://edicl.github.io/Hutchentoot/ https://edicl.github.io/Hutchentoot/ should be with a lowercase h: http://edicl.github.io/hunchentoot/ http://edicl.github.io/hunchentoot/
djha-skin 2y ago
Oops. Will fix.

deleted 2y ago

[deleted]

rltuax 2y ago

> What libraries or tooling would you like to see written for Common Lisp next? I would like the entire Python scientific ecosystem be ported to Common Lisp instead of Python. Lisp is vastly superior for numerical work. What would be required for this to happen? I think empirically we can say that people who wrap Intel MKL, BLAS, etc. prefer a stable C-API with stable C functions that access the internals and do not want an FFI. The native FFI from SBCL is difficult to handle and performance is somewhat unpredictable due to garbage collection. I know this is a hard problem that alternative Python implementations like PyPy also fight with, but if SBCL somehow managed to publish a C-API that is as fast as CPython's (single threaded is good enough for the start) and retain the excellent speed for pure Lisp, I think it might be a great success. Even tricks like automatically activating some form of a GIL when loading a C module would be completely acceptable. In general, roughly copy the Python C-API, it is safe to say by now that people want this.

deleted 2y ago
[deleted]
echoangle 2y ago
Can you explain in what way Lisp is better than Python for numerical work? For someone who has never used Lisp?
- g11479 2y ago
  smart common lisp compilers are orders of magnitude faster than cpython without annotations and can be in the same ballpark as c or fortran with annotations, which means that you can do your numeric work in lisp itself, without calling out to any kind of foreign libraries. it is not feasable to do numerical work in python itself, in reality python acts as a construction kit dsl for allocating and manipulating foreign (c and fortran) structures. this is usually sufficient as one can see by the massive success of libraries like numpy. when you are writing novel numeric code though, you have to figure out how to match it to the numpy's model. this is also not usually a problem, since matching it to numpy's model usually makes it architecturally performant. but one is still wearing a kind of straight jacket at the end of the day. when i was doing computation chemistry, i wrote a lot of code from scratch in fortran and lisp, and it was entirely feasable to do mainloops purely in lisp, implementing algorithms close to their paper versions. there are all kinds of aspects of lisp that make it pleasant to work with in computational science area, but this is already a tldr. i'll mention one, it's possible to rig your code in a way that a long running batch process will not lose its state without much code overhead. since lisp lets you recover from error without unwinding the stack, you can trust that after hours or days of computation an error is not going to cost you full progress loss. often times you can redefine the offending part of code, and continue processing.

guenthert 2y ago

[flagged]

djha-skin 2y ago
I tried to get it out to as many channels as possible, all the ones I knew about -- the common Lisp subreddit, discord, irc, the fediverse, telegram cl group, and matrix. I also sent two reminders in those places :) I'm sorry if I didn't reach you though. What channel did I miss?
- g11479 2y ago
  http://planet.lisp.org/ http://planet.lisp.org/ is the canonical lisp revival place to announce lisp related things. a very small subset of lispers hang out on places like reddit, discord or telegram
- shawn_w 2y ago
  Reddit-wise, you posted on /r/Common_Lisp but not /r/lisp, which has a lot more subscribers and activity.
- rjsw 2y ago
  Add the mailing lists for the main implementations. You could even have posted to comp.lang.lisp.
- guenthert 2y ago
  I was just curious, where the survey was posted. It seems I missed it, when a link to it was posted it here on HN. In any event, I thought it would be worth documenting such for any survey.