3 ms·
tl;dr three major pain points: (1) no native async (2) small library ecosystem (3) CL community NIH syndrome: > I think the straw that broke the camel’s bac
by throw10920 5y ago
tl;dr three major pain points:
(1) no native async
(2) small library ecosystem
(3) CL community NIH syndrome:
> I think the straw that broke the camel’s back was when a few people started making copycat projects that added no real value (other than benchmarking fast) but stole mindshare from all the work I had put in.
These are good points. (1) is a real, true problem with CL (as opposed to things that people commonly think of that aren't actually that bad e.g. syntax), and it's probably not going to be solved in a satisfactory way anytime soon - the design of the language is pretty nice, but seems to exclude first-class continuations (according to [1]), async, and coroutines. (yes, you can emulate these things using macros, but that often involves tree-walking, and results in non-orthogonal features that don't play great with the rest of the language - first-class is always better)
Common Lisp was designed for, and is very good at, representing algorithms under a very specific model of how the world works - that is, single-node and single-memory-space. Its design assumptions don't hold up very well in a multi-node, concurrent world. Yes, there's bordeaux-threads and lparallel, but they feel like hacks, and the presence of GC means that they won't be able to attain the performance of Rust or Erlang (which seems like Lisp for a distributed world - its model of the world seems to be fundamentally distributed, not a bunch of patches on top).
(2) is somewhat unavoidable when you have a small community, but (3) is not (and is highly undesirable). Ideally, the CL community would document all of their published code really well (from the library-author side), and then put some effort into learning how to use (and improve) someone else's code (from the library-user side) instead of rewriting their own 50%-complete version of an existing library, but that would require a significant shift in the attitude of the average CL user, and I'm not sure how to try to affect that.
[1] https://stackoverflow.com/questions/16651843/why-doesnt-a-primitive-call-with-current-continuations-exist-in-common-lisp https://stackoverflow.com/questions/16651843/why-doesnt-a-pr...
- math-dev 5y agoYeah the CL community likes to be lone warriors, I am definitely very guilty of that. Documentation in CL is pretty bad. Worst is when people say its well documented and its nothing but, all those manuals just listing all the functions are a complete nightmare and useless to me
- throw10920 5y agoI'm guilty of this too! Change begins with one's self, they say, heh. (I should learn to write good docs before castigating the community) And you're right - trivial docstrings for all the functions isn't documentation at all. Real documentation is the four-part system[1] of tutorials, howtos, examples, and reference material - I've found this mental framework to be enormously helpful for both (a) identifying when some other documentation is inadequate and (b) improving my own. [1] https://documentation.divio.com/ https://documentation.divio.com/
- svetlyak40wt 5y agoThat is why I've put about half of this year into the Common Lisp documentation generator for all of my libraries. If you are interested, please read it's docs and join the effort of making good documentation for CL projects: https://40ants.com/doc/ https://40ants.com/doc/
- math-dev 5y agoThanks, will check it out!
- math-dev 5y agoAgree 100%
- vindarel 5y agoI think (2) should be more "small ecosystem of ASYNC libraries", that's what he complains about.
- deleted 5y ago[deleted]