[HN Gopher] Common Lisp Community Survey 2024 Results
___________________________________________________________________
Common Lisp Community Survey 2024 Results
Author : djha-skin
Score : 83 points
Date : 2024-08-10 00:17 UTC (22 hours ago)
(HTM) web link (blog.djhaskin.com)
(TXT) w3m dump (blog.djhaskin.com)
| smcn wrote:
| 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 wrote:
| 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.
| diogenesoft wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| New to me! Will give it a bash.
| BoingBoomTschak wrote:
| The "cannot encode a dotted pair" issue still being open is
| the only thing worrying me, personally.
| lkuty wrote:
| The "Steel Bank Common Lisp" link points to
| https://www.reddit.com/r/Common_Lisp/ instead of
| http://www.sbcl.org/
| lkuty wrote:
| The link https://edicl.github.io/Hutchentoot/ should be with a
| lowercase h: http://edicl.github.io/hunchentoot/
| djha-skin wrote:
| Oops. Will fix.
| rltuax wrote:
| > 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.
| echoangle wrote:
| Can you explain in what way Lisp is better than Python for
| numerical work? For someone who has never used Lisp?
| g11479 wrote:
| 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 wrote:
| [flagged]
| djha-skin wrote:
| 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 wrote:
| 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 wrote:
| Reddit-wise, you posted on /r/Common_Lisp but not /r/lisp,
| which has a lot more subscribers and activity.
| rjsw wrote:
| Add the mailing lists for the main implementations.
|
| You could even have posted to comp.lang.lisp.
___________________________________________________________________
(page generated 2024-08-10 23:01 UTC)