16 ms·

Common Lisp has bad marketing (even OCaml has Twitch streamers and "influencers" now), and bad support for general editors, both of which make it a non-starter

Common Lisp has bad marketing (even OCaml has Twitch streamers and "influencers" now), and bad support for general editors, both of which make it a non-starter for most curious people who have an afternoon to try something. But behind all that is magnificent activity for those who got over the initial potential energy barrier. Just to give some examples: 1. SBCL, the most popular open source implementation of Lisp, is seeing potentially two new garbage collectors, one of which is merged and open to beta testing. One of them is a parallel collector written by a university student (!!) which blows my mind. 2. SBCL has better and better support for deploying Lisp as a C-compatible shared library, using SBCL-LIBRARIAN. It makes it play nicer with other applications in C and Python, without the baggage of process wrangling and thick RPC (IPC/servers, serialization, ...). 3. Coalton is another exciting development that allows a Haskell type system and "Lisp-1" functional programming in Common Lisp. That means type classes (or traits), something Lisp hasn't really had a proper notion of, and full type inference. Persistent sequences based off of RRB-trees were recently merged [1], and interestingly, they're implemented purely in Coalton [2]. That means Clojure-like seqs. It's interesting to see users of Lisp generating the above ideas and libraries, not a special in-group of committees, "official" developers, etc. [1] https://coalton-lang.github.io/reference/#seq-type https://coalton-lang.github.io/reference/#seq-type [2] https://github.com/coalton-lang/coalton/blob/main/library/seq.lisp https://github.com/coalton-lang/coalton/blob/main/library/se...

posix_monad 3y ago
Isn't Clojure the most mainstream Lisp at this point?
- reikonomusha 3y ago
  I'd say so, but for many, it's "dead on arrival" for a variety of reasons: Java-centric, unabashedly dynamically typed (favoring instead a slightly more eccentric way of enforcing contracts), etc. Unfortunately, a lot of Scheme and Common Lisp people don't like Clojure a whole lot because it gave up on a variety of things that group has treasured.
  - 7thaccount 3y ago
    It also assumes significant Java knowledge, so I kept finding myself at a dead end where it assumes I know the Java library way to do something and can just call it. I tried Clojure for the Brave and True and Living Clojure. I kept thinking that I wasn't getting anything I couldn't already do in Python (at least for my uses), but there's a lot of baggage like emacs + cider...etc.
    - ryanobjc 3y ago
      The gap between the clojure libs and the java libs and actually calling java is a jarring experience and really isn't a plus. While in theory the java interop is a selling point, if you don't need that it ends up being extra syntactical complexity. Now I haven't coded extensively in clojure, so a lot of it stylistic unfamiliarity. It does hold back people from adopting clojure. One reason why I'm excited never to use the JVM again is the huge memory footprint it uses. The best practices for production java is to figure out how much ram your process will need max under normal (not leaking) usage... and set both max and min ram to that (Xmx and Xms). It's a real hog on ram, and when running under clustered tools like k8 with can do memory overcommits it really reduces your flexibilty. I'm super psyched for all these tiny go and rust programs that run and use like 50 mb ram or even less. Running a cluster of 50 containers is really no heavier than a single Xmx1g java process!
      - deleted 3y ago
        [deleted]
      - pjmlp 3y ago
        GraalVM and OpenJ9 are the answer to that, before one would need to shell out to commercial AOT compilers like Excelsior JET. If you want to see Java going into where Go and Rust hardly matter, see real time Java used in embedded deployments by US and French militar, in battleship weapons control systems, and missile tracking systems.
    - koito17 3y ago
      > It also assumes significant Java knowledge For interop? Yes. For debugging a JVM in production? That, too. But the same can be said about ClojureScript and ${JAVASCRIPT_HOST}. I picked up Clojure after a few years of using Common Lisp. Everything I know about Java and the JVM is thanks to using Clojure and deciding to make use of Java libraries when the ecosystem lacks a good library for something I need (e.g. WebAuthn). My complaints about Clojure usually boil down to lack of performance (when writing idiomatic Clojure as opposed to "Clo-java") and lack of static typing (most Common Lisp compilers do a way better job here). Although I complain a lot about performance, it's ironic many Clojure users will point out to me that Clojure is still faster than Python, Ruby, etc., because I never use those languages and beating them in performance IMO is a very low bar to clear, unless you consider alternative implementations like Truffle Ruby (but then most of the Python/Ruby/etc. ecosystem is incompatible with your implementation). With that said, Clojure is the only language I know with something like clojure.spec out of the box, and every time I use other languages, I miss being able to treat schemas as data and run transformations on them, especially when dealing with data that has a lot of optional fields (but they are optional only subject to specific conditions). Avoids a lot of repeated subtypes and keeps code concise. I also have an easier time testing Clojure code compared to other languages, in the sense that I rarely have to maintain intricate hierarchies of mock objects and state. Most of my Clojure code tends to be small, pure functions, and stateful things happen at the boundary between e.g. backend and database. So the most complex fixtures I usually have to write is setting up a database. > there's a lot of baggage like emacs + cider...etc. I think you were trying to use Clojure in its very early days, when people were still hacking atop of inferior-lisp-mode in order to provide basic Emacs support. While Emacs is still the majority of editor usage in Clojure, the next significant chunk is VS Code users with the Calva plugin. There is also an IntelliJ plugin and it offers (IMO) the best experience for Java interop.
- natrys 3y ago
  You have to define mainstream, and it's hard to quantify things when there is no data. If you use statistics from Github[1], there is a strong argument to be made that the most mainstream Lisp is actually .... Emacs Lisp. [1] https://madnight.github.io/githut/#/pushes/2023/4 https://madnight.github.io/githut/#/pushes/2023/4
  - aidenn0 3y ago
    That's going to be biased a bit by people putting their dotfiles in github. It shows Clojure with 4x the share of CL though. Lisp-1's hurt my brain though, so I haven't dabbled in it much.
    - koito17 3y ago
      > Lisp-1's hurt my brain though No worries! (defn cl-funcall [function & args] (apply function args)) Jokes aside, I've written a significant amount of software in Common Lisp and Clojure. The Lisp-1 vs Lisp-2 distinction isn't something that bothers me. It used to, as a beginner with strong opinions on everything. But nowadays? I don't even remember the last time I've heard Lisp-n before reading this comment.
      - aidenn0 3y ago
        I'm just too used to naming variables things like "list" Having variables that shadow functions, that are later used somewhere causes rather inscrutable jvm backtraces to appear in Clojure.
        koito17 3y ago
        If you use the CIDER debugger then this doesn't appear to be a big issue. Try step debugging the following function. I get an IFn related exception right as the call to (list name) is made. (defn f [name list] #dbg (concat list (list name))) (f 'alice '(bob))
    - natrys 3y ago
- behnamoh 3y ago
  > Isn't Clojure the most mainstream Lisp at this point? Calling Clojure a Lisp triggers some people.
  - pharmakom 3y ago
    How would they define lisp? To me Lisp means programs in list syntax with prefix notation.
    - lispm 3y ago
      Typically a programming language (& family) is a bit more than token syntax. You could write any programming language in prefix notation. C is more than foo{bar}. A programming language has dimensions like: syntax, semantics, pragmatics, implementations, standards, practice, tools, social/community, libraries, code, ...
- bsdpufferfish 3y ago
  If Clojure is a lisp, so is JavaScript.
- lispm 3y ago
  It may be a prominent, active language in the "market", but among Lisps it's not very mainstream, given that it lacks a lot of things that define a Lisp (which are more interactive, more dynamic, full languages, ...). I would consider it as "a Lisp" not so "mainstream", given that it is has very little backwards compatibility to earlier Lisps, is mostly a hosted language, is a blend of a not so functional language&platform (platform JVM is object-oriented) with functional datastructures, is very opinionated, is BFDL controlled, ... Clojure has also successfully spawned in the last years enough variants/tools/libraries/practice, ... , that it is now a diverse language family on its own.
vindarel 3y ago
> bad support for general editors side note: only two years ago we were complaining about the lack of support for VSCode or the Jetbrains suite, now we have working plugins for them: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... in addition of Emacs, Vim, Atom/Pulsar (very decent support), Jupyter notebooks, Sublime, Eclipse (simple support), Geany, enhanced terminal REPLs, Lem (multi-language editor built in CL)…
- aidenn0 3y ago
  > Geany I wrote that support mostly over a weekend, and judging by the lack of bug reports, either my code is flawless (doubtful) or nobody uses it.
- reikonomusha 3y ago
  People like to cite supposed VS Code support. I tried it. It's buggy and easy to make crash/spin/not respond/etc. even under casual use. Like... single Lisp file development. This is not to mention the absence of necessities such as correct indentation and paredit-like support. The latter we can get by without, but the former has worked in other editors for 30+ years. Don't get me wrong, it's a great start, and I hope it gets polished. But as of 3 months ago, it still doesn't work well, so much so I'd never actually recommend it seriously to someone who wants to learn Lisp. Have you tried using VS Code (or any other editor you mentioned) for any "serious" full-cycle Lisp development before, and do you believe it passes the minimum bar of stable and recommendable to another professional programmer or enthusiastic hobbyist? Do I need to try again?
  - vindarel 3y ago
    +1. No, VS Code is an unusable resource hog for me, I don't think you would gain sthg in trying the plugin again, the last releases were not full of changes. Lem is remarkably featureful and usable for CL development though! Both its ncurses and SDL2 frontends. I only miss a couple keys from Slime: C-c C-y (print the function the cursor is on to the REPL), C-c ~ (sync the REPL with the current package (namespace)), then a better imenu, and that's it. Simple git support is available for power users too 8-)
Buttons840 3y ago
What's good about the new garbage collectors? You've only said they're new, but what makes them better? How do they compare to other languages?
- hayley-patton 3y ago
  One is parallel, using multiple cores to make collection happen faster, which increases GC throughput and shortens GC pauses. The other is concurrent and avoids pauses entirely, though it requires more bookkeeping from the application and might reduce throughput. I joke that the parallel GC is bringing SBCL to 2000s Java. It seems comparable enough to Java's Parallel, though SBCL aims for less space overhead by default, so you need to adjust either GC to have a fair comparison. The concurrent one is based off a collector for SML#, Haskell has a similar low latency "Alligator" collector too. (Disclaimer: I wrote the parallel collector, and I want to be clear that latency and throughput differ here, because someone didn't before.)
- aidenn0 3y ago
  SBCL's collector is inherited from cmucl, and it was an excellent collector at the turn of the century. However, it is very of-its-time in two major ways: 1. It is optimized for throughput over pause-times 2. It is non-parallel
medo-bear 3y ago
I think common lispers should just accept that they are lone wolf programmers and get on with our lonely lives. Jokes asside, I dont think energy should be spent on editor support. Too much work and little to gain. Instead what needs to be done is to study the so many great libraries and writing the damn documentation (and make it fun). Documentation problem is THE low hanging fruit toward improving the cl ecosystem and attracting new loners. I think once people get the confidence to read and write lisp codebases are much easier to digest than other languages. Which I think is partly responsible for the crap doc situation. But if you think about it this also makes lisp in some sense the perfect open source language. Kudos to things like the cookbook tho !
- tmtvl 3y ago
  Oh man, look up switch in the Alexandria docs, I really need to sit down and fix that. The documentation culture is the one thing I miss from Perl when I go to... well, any other language. Considering CL has DESCRIBE it's really something we need to get serious about.
- tnecniv 3y ago
  I used to hang out in an IRC channel, and the big CL proponent there was a Norwegian that would disappear for long periods and go boat / hang out in the woods on his own. Apparently those are common hobbies in Scandinavia but it also makes a lot of sense for a CL lover in hindsight.
- Jach 3y ago
  JavaDoc has also traditionally been pretty good, and Java's idioms let there be rich doc in the source comments that gets turned into nice HTML. Every so often someone tries to make something similar for Lisp, with mixed results. (The one I remember most recently is https://quickref.common-lisp.net/index-per-library.html https://quickref.common-lisp.net/index-per-library.html but I pretty much never visit it, it's not helpful to me.) It also doesn't help that every project might do something different. (There's also multiple types of docs for different audiences in different contexts, but that's a separate common issue for any language and team.) For a lot of the commonly used libraries, the doc is sufficiently decent, though sometimes unintuitive to find. For core stuff I like the hyperspec as much as the next lisper (and opening it on a symbol is just ,h for me) but there's also http://clqr.boundp.org/ http://clqr.boundp.org/ that not everyone knows about, it's a great little reference to have printed out at my desk. And there's situations like how part of pretty much every Lisp, available through ASDF, is UIOP, a great little portability library. Its doc is at https://asdf.common-lisp.dev/uiop.html https://asdf.common-lisp.dev/uiop.html and it originates in the source repo from a Lisp script taking doc info from the source and applying a .texinfo template to it. Pretty bespoke. But this is also just part of the cost/benefit of CL: it's very unopinionated, unlike say Java or Clojure, and so lets individuals and teams do what they want which naturally isn't going to be the same worldwide. I like certain doc (especially at least one example of using the thing) in repo README files, others don't, nothing forces one way or the other. Once the confidence for Lisp is there though, you're right that it's not a big deal. It's very nice to jump-to-source for everything, including SBCL internals, and modify things even. I can fix some bugs in a dependency library, right now, without having to file an issue/pull request to the library maintainer and waiting for a new release, and that modification can even live in my source tree in the interim as just a bit of code that runs after loading the main library and then redefines one of its functions or whatever. I disagree that any effort needs to be made on attracting lone wolves, less even than trying to make editor support better for beginners; the loners will come on their own in time. Not because CL can only be used by loners (million+ lines of code projects made by teams demonstrate otherwise), but because it's a very good multiplier for that situation.
hayley-patton 3y ago
> One of them is a parallel collector written by a university student (!!) which blows my mind. I didn't let schooling interfere with my education.
- reikonomusha 3y ago
  (Non-obvious context: hayley-patton is the one who wrote the new parallel GC.)
ilc 3y ago
Do any of these come close to Genera? That is an amazing system, that even now, could probably hang with the best of them. :/
- pjmlp 3y ago
  If you want that kind of experience, only commercial Lisps come close to it.
leoh 3y ago
Off-topic, but OCaml’s reputation as being good for language design afaict is quite undeserved. I tried using it for a while for several language design exercises, and put it aside. Late last year I picked up Racket and it was radically better. Usage by a hedge fund does not for a impressive language make; nor do decades old accolades.
- pjmlp 3y ago
  Any ML[0] derived language really, not only OCaml. [0] - https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)
pjmlp 3y ago
Missed out Lisp Works and Allegro Common Lisp.

posix_monad 3y ago

Isn't Clojure the most mainstream Lisp at this point?

reikonomusha 3y ago
I'd say so, but for many, it's "dead on arrival" for a variety of reasons: Java-centric, unabashedly dynamically typed (favoring instead a slightly more eccentric way of enforcing contracts), etc. Unfortunately, a lot of Scheme and Common Lisp people don't like Clojure a whole lot because it gave up on a variety of things that group has treasured.
- 7thaccount 3y ago
  It also assumes significant Java knowledge, so I kept finding myself at a dead end where it assumes I know the Java library way to do something and can just call it. I tried Clojure for the Brave and True and Living Clojure. I kept thinking that I wasn't getting anything I couldn't already do in Python (at least for my uses), but there's a lot of baggage like emacs + cider...etc.
  - ryanobjc 3y ago
    The gap between the clojure libs and the java libs and actually calling java is a jarring experience and really isn't a plus. While in theory the java interop is a selling point, if you don't need that it ends up being extra syntactical complexity. Now I haven't coded extensively in clojure, so a lot of it stylistic unfamiliarity. It does hold back people from adopting clojure. One reason why I'm excited never to use the JVM again is the huge memory footprint it uses. The best practices for production java is to figure out how much ram your process will need max under normal (not leaking) usage... and set both max and min ram to that (Xmx and Xms). It's a real hog on ram, and when running under clustered tools like k8 with can do memory overcommits it really reduces your flexibilty. I'm super psyched for all these tiny go and rust programs that run and use like 50 mb ram or even less. Running a cluster of 50 containers is really no heavier than a single Xmx1g java process!
    - deleted 3y ago
      [deleted]
    - pjmlp 3y ago
      GraalVM and OpenJ9 are the answer to that, before one would need to shell out to commercial AOT compilers like Excelsior JET. If you want to see Java going into where Go and Rust hardly matter, see real time Java used in embedded deployments by US and French militar, in battleship weapons control systems, and missile tracking systems.
  - koito17 3y ago
    > It also assumes significant Java knowledge For interop? Yes. For debugging a JVM in production? That, too. But the same can be said about ClojureScript and ${JAVASCRIPT_HOST}. I picked up Clojure after a few years of using Common Lisp. Everything I know about Java and the JVM is thanks to using Clojure and deciding to make use of Java libraries when the ecosystem lacks a good library for something I need (e.g. WebAuthn). My complaints about Clojure usually boil down to lack of performance (when writing idiomatic Clojure as opposed to "Clo-java") and lack of static typing (most Common Lisp compilers do a way better job here). Although I complain a lot about performance, it's ironic many Clojure users will point out to me that Clojure is still faster than Python, Ruby, etc., because I never use those languages and beating them in performance IMO is a very low bar to clear, unless you consider alternative implementations like Truffle Ruby (but then most of the Python/Ruby/etc. ecosystem is incompatible with your implementation). With that said, Clojure is the only language I know with something like clojure.spec out of the box, and every time I use other languages, I miss being able to treat schemas as data and run transformations on them, especially when dealing with data that has a lot of optional fields (but they are optional only subject to specific conditions). Avoids a lot of repeated subtypes and keeps code concise. I also have an easier time testing Clojure code compared to other languages, in the sense that I rarely have to maintain intricate hierarchies of mock objects and state. Most of my Clojure code tends to be small, pure functions, and stateful things happen at the boundary between e.g. backend and database. So the most complex fixtures I usually have to write is setting up a database. > there's a lot of baggage like emacs + cider...etc. I think you were trying to use Clojure in its very early days, when people were still hacking atop of inferior-lisp-mode in order to provide basic Emacs support. While Emacs is still the majority of editor usage in Clojure, the next significant chunk is VS Code users with the Calva plugin. There is also an IntelliJ plugin and it offers (IMO) the best experience for Java interop.
natrys 3y ago
You have to define mainstream, and it's hard to quantify things when there is no data. If you use statistics from Github[1], there is a strong argument to be made that the most mainstream Lisp is actually .... Emacs Lisp. [1] https://madnight.github.io/githut/#/pushes/2023/4 https://madnight.github.io/githut/#/pushes/2023/4
- aidenn0 3y ago
  That's going to be biased a bit by people putting their dotfiles in github. It shows Clojure with 4x the share of CL though. Lisp-1's hurt my brain though, so I haven't dabbled in it much.
  - koito17 3y ago
    > Lisp-1's hurt my brain though No worries! (defn cl-funcall [function & args] (apply function args)) Jokes aside, I've written a significant amount of software in Common Lisp and Clojure. The Lisp-1 vs Lisp-2 distinction isn't something that bothers me. It used to, as a beginner with strong opinions on everything. But nowadays? I don't even remember the last time I've heard Lisp-n before reading this comment.
    - aidenn0 3y ago
      I'm just too used to naming variables things like "list" Having variables that shadow functions, that are later used somewhere causes rather inscrutable jvm backtraces to appear in Clojure.
      - koito17 3y ago
        If you use the CIDER debugger then this doesn't appear to be a big issue. Try step debugging the following function. I get an IFn related exception right as the call to (list name) is made. (defn f [name list] #dbg (concat list (list name))) (f 'alice '(bob))
  - natrys 3y ago
behnamoh 3y ago
> Isn't Clojure the most mainstream Lisp at this point? Calling Clojure a Lisp triggers some people.
- pharmakom 3y ago
  How would they define lisp? To me Lisp means programs in list syntax with prefix notation.
  - lispm 3y ago
    Typically a programming language (& family) is a bit more than token syntax. You could write any programming language in prefix notation. C is more than foo{bar}. A programming language has dimensions like: syntax, semantics, pragmatics, implementations, standards, practice, tools, social/community, libraries, code, ...
bsdpufferfish 3y ago
If Clojure is a lisp, so is JavaScript.
lispm 3y ago
It may be a prominent, active language in the "market", but among Lisps it's not very mainstream, given that it lacks a lot of things that define a Lisp (which are more interactive, more dynamic, full languages, ...). I would consider it as "a Lisp" not so "mainstream", given that it is has very little backwards compatibility to earlier Lisps, is mostly a hosted language, is a blend of a not so functional language&platform (platform JVM is object-oriented) with functional datastructures, is very opinionated, is BFDL controlled, ... Clojure has also successfully spawned in the last years enough variants/tools/libraries/practice, ... , that it is now a diverse language family on its own.

vindarel 3y ago

> bad support for general editors side note: only two years ago we were complaining about the lack of support for VSCode or the Jetbrains suite, now we have working plugins for them: https://lispcookbook.github.io/cl-cookbook/editor-support.html https://lispcookbook.github.io/cl-cookbook/editor-support.ht... in addition of Emacs, Vim, Atom/Pulsar (very decent support), Jupyter notebooks, Sublime, Eclipse (simple support), Geany, enhanced terminal REPLs, Lem (multi-language editor built in CL)…

aidenn0 3y ago
> Geany I wrote that support mostly over a weekend, and judging by the lack of bug reports, either my code is flawless (doubtful) or nobody uses it.
reikonomusha 3y ago
People like to cite supposed VS Code support. I tried it. It's buggy and easy to make crash/spin/not respond/etc. even under casual use. Like... single Lisp file development. This is not to mention the absence of necessities such as correct indentation and paredit-like support. The latter we can get by without, but the former has worked in other editors for 30+ years. Don't get me wrong, it's a great start, and I hope it gets polished. But as of 3 months ago, it still doesn't work well, so much so I'd never actually recommend it seriously to someone who wants to learn Lisp. Have you tried using VS Code (or any other editor you mentioned) for any "serious" full-cycle Lisp development before, and do you believe it passes the minimum bar of stable and recommendable to another professional programmer or enthusiastic hobbyist? Do I need to try again?
- vindarel 3y ago
  +1. No, VS Code is an unusable resource hog for me, I don't think you would gain sthg in trying the plugin again, the last releases were not full of changes. Lem is remarkably featureful and usable for CL development though! Both its ncurses and SDL2 frontends. I only miss a couple keys from Slime: C-c C-y (print the function the cursor is on to the REPL), C-c ~ (sync the REPL with the current package (namespace)), then a better imenu, and that's it. Simple git support is available for power users too 8-)

Buttons840 3y ago

What's good about the new garbage collectors? You've only said they're new, but what makes them better? How do they compare to other languages?

hayley-patton 3y ago
One is parallel, using multiple cores to make collection happen faster, which increases GC throughput and shortens GC pauses. The other is concurrent and avoids pauses entirely, though it requires more bookkeeping from the application and might reduce throughput. I joke that the parallel GC is bringing SBCL to 2000s Java. It seems comparable enough to Java's Parallel, though SBCL aims for less space overhead by default, so you need to adjust either GC to have a fair comparison. The concurrent one is based off a collector for SML#, Haskell has a similar low latency "Alligator" collector too. (Disclaimer: I wrote the parallel collector, and I want to be clear that latency and throughput differ here, because someone didn't before.)
aidenn0 3y ago
SBCL's collector is inherited from cmucl, and it was an excellent collector at the turn of the century. However, it is very of-its-time in two major ways: 1. It is optimized for throughput over pause-times 2. It is non-parallel

medo-bear 3y ago

I think common lispers should just accept that they are lone wolf programmers and get on with our lonely lives. Jokes asside, I dont think energy should be spent on editor support. Too much work and little to gain. Instead what needs to be done is to study the so many great libraries and writing the damn documentation (and make it fun). Documentation problem is THE low hanging fruit toward improving the cl ecosystem and attracting new loners. I think once people get the confidence to read and write lisp codebases are much easier to digest than other languages. Which I think is partly responsible for the crap doc situation. But if you think about it this also makes lisp in some sense the perfect open source language. Kudos to things like the cookbook tho !

tmtvl 3y ago
Oh man, look up switch in the Alexandria docs, I really need to sit down and fix that. The documentation culture is the one thing I miss from Perl when I go to... well, any other language. Considering CL has DESCRIBE it's really something we need to get serious about.
tnecniv 3y ago
I used to hang out in an IRC channel, and the big CL proponent there was a Norwegian that would disappear for long periods and go boat / hang out in the woods on his own. Apparently those are common hobbies in Scandinavia but it also makes a lot of sense for a CL lover in hindsight.
Jach 3y ago
JavaDoc has also traditionally been pretty good, and Java's idioms let there be rich doc in the source comments that gets turned into nice HTML. Every so often someone tries to make something similar for Lisp, with mixed results. (The one I remember most recently is https://quickref.common-lisp.net/index-per-library.html https://quickref.common-lisp.net/index-per-library.html but I pretty much never visit it, it's not helpful to me.) It also doesn't help that every project might do something different. (There's also multiple types of docs for different audiences in different contexts, but that's a separate common issue for any language and team.) For a lot of the commonly used libraries, the doc is sufficiently decent, though sometimes unintuitive to find. For core stuff I like the hyperspec as much as the next lisper (and opening it on a symbol is just ,h for me) but there's also http://clqr.boundp.org/ http://clqr.boundp.org/ that not everyone knows about, it's a great little reference to have printed out at my desk. And there's situations like how part of pretty much every Lisp, available through ASDF, is UIOP, a great little portability library. Its doc is at https://asdf.common-lisp.dev/uiop.html https://asdf.common-lisp.dev/uiop.html and it originates in the source repo from a Lisp script taking doc info from the source and applying a .texinfo template to it. Pretty bespoke. But this is also just part of the cost/benefit of CL: it's very unopinionated, unlike say Java or Clojure, and so lets individuals and teams do what they want which naturally isn't going to be the same worldwide. I like certain doc (especially at least one example of using the thing) in repo README files, others don't, nothing forces one way or the other. Once the confidence for Lisp is there though, you're right that it's not a big deal. It's very nice to jump-to-source for everything, including SBCL internals, and modify things even. I can fix some bugs in a dependency library, right now, without having to file an issue/pull request to the library maintainer and waiting for a new release, and that modification can even live in my source tree in the interim as just a bit of code that runs after loading the main library and then redefines one of its functions or whatever. I disagree that any effort needs to be made on attracting lone wolves, less even than trying to make editor support better for beginners; the loners will come on their own in time. Not because CL can only be used by loners (million+ lines of code projects made by teams demonstrate otherwise), but because it's a very good multiplier for that situation.

hayley-patton 3y ago

> One of them is a parallel collector written by a university student (!!) which blows my mind. I didn't let schooling interfere with my education.

reikonomusha 3y ago
(Non-obvious context: hayley-patton is the one who wrote the new parallel GC.)

ilc 3y ago

Do any of these come close to Genera? That is an amazing system, that even now, could probably hang with the best of them. :/

pjmlp 3y ago
If you want that kind of experience, only commercial Lisps come close to it.

leoh 3y ago

Off-topic, but OCaml’s reputation as being good for language design afaict is quite undeserved. I tried using it for a while for several language design exercises, and put it aside. Late last year I picked up Racket and it was radically better. Usage by a hedge fund does not for a impressive language make; nor do decades old accolades.

pjmlp 3y ago
Any ML[0] derived language really, not only OCaml. [0] - https://en.wikipedia.org/wiki/ML_(programming_language) https://en.wikipedia.org/wiki/ML_(programming_language)

pjmlp 3y ago

Missed out Lisp Works and Allegro Common Lisp.