Hacker News Reader

Comment by reikonomusha | Hacker News Reader

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

[2] https://github.com/coalton-lang/coalton/blob/main/library/se...

View on HN

> 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.

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

> 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.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)…

> 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.

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?

+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-)

Lem is cool! But doesn't address what I consider a fundamental problem for Common Lisp adoption: lack of no-nonsense support for a familiar IDE. Lem feels like an Emacs, so the same people that won't use Emacs also won't use Lem... which is a lot of potential users.

Lem (and sbcl) is still broken on macOS Sonoma, sadly.

Broken how? I've had no issues with sbcl for quite a while.

I use sbcl on Sonoma every day

C-c ~ isn't defined in any of my emacsen ... do you happen to know the command name it binds to?

edit never mind ... it's bound when invoked from a .lisp source file ... very cool! I think I will use this a lot! Thank you for sharing it ...

I’ve tried SBCL in Atom/Pulsar and Emacs. I found the debugger confusing as hell. The whole thing felt super janky compared to a properly integrated debugger.

What I want — what I really really want — is an Allegro CL experience. Unfortunately, nothing provides it, nor does it look like anyone has any interest in providing such an experience.

This isn’t just a CL problem. Janky debugger integration is widespread. It’s the pathetic that only commercial developers provide a polished debugging experience. Everyone else is satisfied with a basically a CLI tool running separately in a window. That’s like. 80% solution. We can do better. We should do better.

There is an exception to only commercial developers provide a polished debugging environment and that is the various non GNU open source Smalltalks.

Eclipse can also produce reasonable debugging for Java at least.

But yes other than that poor debuggers do limit the choice of languages.

Unfortunately PHP is better served than most interesting languages.

Squeak is basically a port of the original Xerox PARC Smalltalk-80 image into a more portable implementation from Xerox folks themselves, Pharo was originally a Squeak fork.

Eclipe was born as a rewrite from Visual Age for Smalltalk into Java.

See the difference?

interesting that you say this. have you also tried out Franz Lisp? it is another commercial one.

Franz was too expensive :) Allegro had an academic license.

Okay. I think both you and I may have made a mistake about the product names.

(I just corrected mine, which was in this same comment. Corrected info below.)

I had tried out Allegro Common Lisp (which is from Franz, Inc.) and LispWorks Common Lisp, some years ago.

Maybe sometime after Peter Seibel's book Practical Common Lisp came out.

I had also tried out GNU Lisp at some point.

Yeah. There are two. I definitely used Allegro, which apparently is from Franz. I remember that the other commercial one was very expensive.

It’s been like 20 years ago. :)

There are two companies: Franz Inc. and LispWorks Ltd.

The Lisp development product of Franz Inc. is Allegro CL. https://franz.com/products/allegro-common-lisp/

The Lisp development product of LispWorks Ltd. is LispWorks. https://www.lispworks.com/products/lispworks.html

Both are kind of expensive. Both offer also academic licenses.

"Franz Lisp" does not exist as a product since the 80s.

Both Allegro CL and LispWorks are sold since the mid/end 80s and are still being maintained and sold.

Do you say so for Emacs and Slime's debugger too? It's certainly weird at first, but powerful and integrated. Although it isn't graphical like LispWorks' (and probably Allegro's), so I agree it could be even better. (for readers: Slime's debugger is not a separate CLI tool running in a window)

(ps: see slime-breakpoints for a nice graphical addition: https://github.com/mmontone/slime-breakpoints)

I don't understand this. Are you saying that SLIME/SLY debugging of SBCL in Emacs is "basically a CLI tool running separately in a window"? It is arguably the most powerful debugging experience available for any programming language. There is ton of documentation and tutorials available and it is as far from janky as you can possibly get.

It’s a janky 80% solution.

Saying that you just have to watch a bunch of tutorials betrays just how janky it is.

It what way is it janky exactly? I mean what normal debugger functionality is missing/broken? Or do you find it hard to discover?

I mostly have experience with C/C++ but have done some CL, and I agree with GP. Check out the debugging UX (not the performance :) of Visual Studio. More specifically, see how intuitive and discoverable it is for beginners.

For example, in CL debugging, how would I reliably set a breakpoint at some nested expression in a function body, run to it, and step through the code "expr-by-expr" while verifying a bunch of values in a watch window? In VS, it's one click to set breatpoint, one keypress or two clicks to run to it, one click to step to next line, and one double click and typing an expression to set up a watch that would show updated value of that expression every time execution pauses while taking care of scoping, etc.

In CL/SLIME, you add `(break)` to the code where you want it to stop and hit `C-u C-c C-c`. Then you run the code you care about and you should be able to step from the break.

This is a common complaint about CL, but my experience is that the utility of debuggers is vastly over-stated. It’s a nice trick in Java or C/C++ or JS (in Chrome), but I've never found a debugger to significantly improve my workflow and the “repl-driven development” paradigm of CL solves the problem differently by increasing iteration speed.

> In CL/SLIME, you add `(break)` to the code

Having to modify code to add/remove breakpoints is pretty much the definition of jankiness. Can Emacs+SBCL show a list of all breakpoints, for example?

> This is a common complaint about CL, but my experience is that the utility of debuggers is vastly over-stated.

I disagree. A debugger gives you insight into the state of the program. It makes no sense to burn neural cycles trying to track program's state manually when a debugger can visualise it in multiple views and forms. Frankly, during development, I always run my code in a debugger, just to be able to confirm my assumptions on a granular level whenever I want to.

> the “repl-driven development” paradigm of CL

In my experience, trying to substitute a proper debugger with REPL leads to unnecessarily small functions, which then lead to very deep call stacks and undocumented assumptions about pre- and post-conditions of all those tiny functions. However, CL is specially bad about this anyway, since every `let` binding adds a new nesting, making long linear functions unreadable (either due to deep nesting, or due to predeclaring all variable as in ANSI C). Scheme with its `define` is much better in this regard.

Since I dont use VS Code I'm not sure if I follow but most of these things you describe are in fact available, at least with Emacs+SLY (Common Lispers either use Emacs+SLIME or Emacs+SLY). What you call "non-janky" break points are referred to as Stickers in SLY, which on the whole seem to me a far more advanced idea than what you say VS offers.

See https://joaotavora.github.io/sly/#Debugger

I am not talking about VS Code, but Visual Studio (or any other visual debugger from the last 30 years).

Sly's UI seems to be similar to that of GDB, which is exactly what I am talking about. I would suggest trying out and comparing GDB and one of its numerous GUI frontends to understand why a GUI with multiple views displayed simultaneously (i.e., you can keep track of different parts of state on different parts of screen) and automatically (i.e., display doesn't require interaction) improves debugging experience.

The point I was making was that Emacs+SLY solution has nonintrusive debugging annotations.

As regards windows and gui, I also dont understand. I can certainly have multiple windows displayed in Emacs, even in a tty terminal. What buffer each of those windows serves is up to me. Certainly I can have each state sent to a different buffer. One of the things I personally value about Emacs is that I don't have to run it in some Windowing gui system to get any of the supposed benefits. Heck I can even use a mouse to adjust window sizes in just my tty. I dont get what GUI gives you except a higher overhead

You should sit this one out. You already said you aren't familiar with the systems being discussed.

Lol no worries hero :) I am unfamiliar in the sense that I cant be bothered to actually try it. However everything I said applies to what is being described herein

https://learn.microsoft.com/en-us/visualstudio/debugger/debu...

There is no feature here that is not available for debugging Common Lisp in Emacs, which has much more powerful debugging tools, and with less overhead

https://lispcookbook.github.io/cl-cookbook/debugging.html

For starters: GNU Emacs is not providing a Command Line Interface, CLI.

Exactly. The following demonstration on GDB in Emacs looks pretty good to me. In fact, it can do this even in tty, no GUI required.

https://m.youtube.com/watch?v=aNTFDq3e2Qo

Even in terminal one can have menus, menubars, tree navigation, folding views, scrolling lists, dialogs, windows, frames, textual buttons, editor buffers with specialized functionality, etc. That means one can have backtrace frames, steppers, data inspectors, configuration menus, preference dialogs, class browser, call graphs, restart menus, read-eval-print loops, refactoring dialogs, ...

> Frankly, during development, I always run my code in a debugger

For many Common Lisp implementations you don't need that. The debugger & source interpreter & compiler & break loops are always available. One also does not need to "instrument" code for a debugger.

> In my experience, trying to substitute a proper debugger with REPL leads to unnecessarily small functions

That makes no sense. The REPL includes a debugger and does not enforce a function size. You can call&debug functions of any size from a REPL. Stack traces can be detailed or overview. From within the REPL, which in case of break is a break-loop, which is a REPL with added debug commands.

> undocumented assumptions about pre- and post-conditions of all those tiny functions

The idea of tiny functions is made up by you. Common Lisp's debugging tools don't enforce tiny functions. Just the opposite, many CL code bases have large functions, which are also even larger after macro expansion.

pre- and post conditions can be explicit parts of Common Lisp code, since it has :before, :around and :after methods.

> every `let` binding adds a new nesting

Lisp uses nested lists. That's one thing to learn from day one when programming in Lisp. Nested code shows indented blocks.

> or due to predeclaring all variable as in ANSI C)

Not predeclaring variables is bad practice anyway.

> Scheme with its `define` is much better in this regard.

No, Scheme's "define" has to be at the top of a block, according to Scheme standards.

> This is a common complaint about CL, but my experience is that the utility of debuggers is vastly over-stated.

It is possible to patch a running CL system by simply setting a breakpoint and then revaluating a function.

I am unaware of any other language that is possible in. This Lisp feature is only made possible through a debugger.

I know, because I've done it.

> It is possible to patch a running CL system by simply setting a breakpoint and then revaluating a function.

It's also possible to change a running CL system without setting a breakpoint and/or re-evaluating a function.

> I am unaware of any other language that is possible in.

Start with Smalltalk and then search for more.

Yeah, although the debugger in lisp is also lacking a lot of features people tend to expect: stepping through code, in particular, is painful unless you recompile with DEBUG 3

There are even languages that can do more crazy things than CL or Smalltalk. For example, in Sinclair BASIC, if you put a breakpoint at some position on the line, you can even modify the rest of the line and continue with execution from the breakpoint without the need of restarting anything.

If we are using a Lisp interpreter, which executes s-expressions, we can do similar things, here an example using LispWorks, which has both a compiler and a source-level Lisp interpreter.

The function FOO has a BREAK.

    CL-USER 76 > (defun foo (a)
                   (+ (break) (sin a)))
    FOO

    CL-USER 77 > (foo 10)

    Break.
      1 (continue) Return from break.
      2 (abort) Return to top loop level 0.

    Type :b for backtrace or :c <option number> to proceed.
    Type :bug-form "<subject>" for a bug report template or :? for other options.

We are in the break lets get a quick backtrace and move to the right stack frame:

    CL-USER 78 : 1 > :bq

    INVOKE-DEBUGGER <- BREAK <- FOO <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP-LOOP <- MP::PROCESS-SG-FUNCTION

    CL-USER 79 : 1 > :n
    Call to INVOKE-DEBUGGER

    CL-USER 80 : 1 > :n
    Call to BREAK

    CL-USER 81 : 1 > :n
    Interpreted call to FOO

What is the current source?

    CL-USER 82 : 1 > :lambda
    (LAMBDA (A) (DECLARE (SYSTEM::SOURCE-LEVEL #<EQ Hash Table{0} 8220104A8B>)) (DECLARE (LAMBDA-NAME FOO)) (+ (BREAK) (SIN A)))

Let's change the code:

    CL-USER 83 : 1 > (setf (third (fifth *)) '(* a 4))
    (* A 4)

Let's see the new code.

    CL-USER 84 : 1 > :lambda
    (LAMBDA (A) (DECLARE (SYSTEM::SOURCE-LEVEL #<EQ Hash Table{0} 8220104A8B>)) (DECLARE (LAMBDA-NAME FOO)) (+ (BREAK) (* A 4)))

Move to the BREAK stack frame and return 2 from there:

    CL-USER 85 : 1 > :p
    Call to BREAK

    CL-USER 86 : 1 > :ret 2
    42

As you can see, we have changed the running source code, without the need to restart anything.

For background: I learned C 6 years before I first started learning Lisp; I used every version of Visual Studio starting with 6.0 through .net 200X (I'd have to pull out my CDs to see which the last version I used was). Prior to that I used Borland's C++ IDE.

> For example, in CL debugging, how would I reliably set a breakpoint at some nested expression in a function body, run to it, and step through the code "expr-by-expr" while verifying a bunch of values in a watch window?

I ... don't ever do this when debugging lisp? Sly has support for setting breakpoints, but I'm used to adding (break) expressions; the "breakdot on the side" doesn't work as well with Lisp as C (With idiomatic C you very rarely want to set a breakpoint in the middle of a line, and it's rare for a single statement to be more than 2-ish lines; I should also note that IIRC setting breakpoints in the middle of a line in VS was not the best UX).

Sly has a keyboard shortcut for stepping, but I don't have it memorized because I hardly ever use it. Conversely its F10/F11 in VS, which I still remember despite not having used Visual Studio for at least a decade, since I did it a lot!

Conversely, I have the shortcuts for recompile the single file I'm in and recompile the single function I'm in memorized, since I use those all the time when debugging. I believe VS added hot-patching functions at some point near the end of my usage, but it wasn't part of my workflow like it is with Lisp.

(The lack of) watch windows is a deficiency in Sly. While you can view all locals in the current stack-frame while debugging, it doesn't let you watch arbitrary expressions, and if you have too many locals it can be hard to focus on what you want.

I should point out stickers (C-c C-s C-s) let you trace evaluations of arbitrary subexpressions, and this has some overlap with how watchpoints are used in VS.

> it doesn't let you watch arbitrary expressions

You can't watch expressions, but when the debugger comes up, and I think if you're stepping through too, you can hit "e" for eval and do any expression you basically want. Any variables used would need to be in scope, etc ...

(this is with sbcl and slime ... I'd bet sly supports similar)

Right, but GPs comment about watchpoints in VS stands, they were accessible and easy to use, and could potentially provide value to the style of development that I use when working with CL.

I would think it's obvious. Look at any commercially developed debugger for any language. Xcode. Eclipse. IntelliJ, VSCode. AllegroCL. Now compare that Emacs + anything. Atom/Pulsar + anything. Vi + anything.

Just look at the screenshots. What's missing? Literally everything is missing, because it's just a CLI in a window. Want to add a breakpoint? Type in the window. Want to know how many threads are running? Type in the window. Want to pause a thread? Type in the window. Want to inspect a variable? Type in the window. Want to drill down through a complex data structure? Type that 50 character line correct in one go bitch. By god! Don't you dare complain!

The irony of course is that all of these commercial products are using the exact same debugging infrastructure of the OSS counterparts. It's just that one group finished the job, and the other doesn't bother to finish the job.

Obviously you have never used it.

> is arguably the most powerful debugging experience available for any programming language.

The sly debugger is better than most debuggers, but calling it the most powerful debugging experience is a stretch. Just try the debuger in a Smalltalk implementation (Squeak/Pharo/Cuis)

I mostly agree, though I find Allegro and LispWorks severely lacking in areas too. The companies themselves don't seem to care much about their IDEs. Certainly not in the way JetBrains cares about IntelliJ.

Tucked away in the McCLIM project is Clouseau, which you can quickload and use as a normal user: https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Cl... One small cool thing it does is if you inspect a complex number it will also draw a little x-y graph with its vector representation. (Though trying it out again just now it's overlapping with the text... maybe I should file a bug, but I've only now just learned they moved off github, and I'm not going to make a codeberg account. Friction wins this round.) It does take a while to first compile and load all the dependencies, especially 3bz, another weakness of at least our free Lisps; AFAIK there's still no equivalent of make -j for compiling systems.

I'm a happy vim user (though there is some jank with slimv, admittedly, but it's mostly prevalent around multiple thread situations) and setup the command ,ci to call my own clouseau-inspect function; it just inspects a symbol with clouseau instead of slimv's inspector. Also have a janky watch/unwatch pair of functions that just refreshes the inspector every second. (https://github.com/Jach/dots/blob/master/.sbclrc#L113 if curious, some other junk in .swank.lisp and .vimrc too, and there's https://github.com/dense-analysis/ale/issues/4061 to call sblint on your project...)

But more graphical tools like this are what I hope to one day see more of and are how the free Lisps can close the gap in this area with the commercial Lisps. I believe there's not much Allegro can do that poking around SBCL can't do, but for many things it's just nicer to have a GUI. Want to explore all the symbols and values in a package? Easy enough to script that, but not as nice as just having a table of symbols, and even nicer if you can set watches on some of them, or even set conditional breakpoints on value changes. None of the tools need to be tightly integrated with a single IDE either, because all the stuff necessary to debug Lisp is in the running Lisp itself. It's just that the GUI situation continues to suck.

LSP has gotten more popular with other languages and editors, sometimes I wonder if the acronym was made as an inside joke because it's basically how Lisp + Slime/Swank have worked...

Exactly. All the parts are there. Just no one goes beyond the bare minimum of polish.

I think the LispWorks Pro IDE is nice enough! When I am working on a smaller projects, I find that SBCL+Emacs+Slime are great, but when I am working with many files, often in different Quicklisp libraries I work on jointly, then I find the LispWorks Pro IDE works better for me.

I have been intending on trying the latest free IDE from Franz. Two days ago I was in a fun catch-up video call with Jans Aasman from Franz, but we were talking about AI more generally, not Common Lisp specifically.

I'm curious, what specifically works better about their IDE for you in the case of many files? Do they now have good global refactoring tools, like you can change a class name in library A and have it automatically be updated in library B and application C that depend on and use it? And without the actual files for such being open? Possibly not even the systems being loaded? (I'm reduced to what's essentially mass search-replace with https://github.com/mhinz/vim-grepper/ but it does the job and importantly helps update files I might not have open buffers for. Still a step down from what's available in JavaLand. I remember someone was working on a library to build some modern refactoring tools for Lisp but I don't know how far that's gotten.)

It has more to do with navigation and many tiled source code windows open. It is true that using treemacs + Emacs and opening multiple frames can get a similar experience.

It's also a question whether a Lisp IDE has tools on a system level. "system" means source code management for libraries and applications.

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 !

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.

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.

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 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/ 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 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.

I wasn't being full serious. Personally I take it for granted that CL can be used well in teams just like any other language. Teams are about leadership anyway, which is a seperate concern from choice of language. However, that CL gives you the power to be "lone wolf" (read effective solo programmer) instead of a lone sheep is a huge benefit. I also think that when people decide to learn a comp language, more often than not they do so in their own free time, without other distractions - ie when they are alone. Because of the at-best not so straight forward and dry state of documentation in common lisp libraries (the spec, while dry, is actually really good), common lisp is a bad starter for that type of learner. I mean just the dry style itself looks like it is either not maintained or poorly written. It is a shame because common lisp has great documentation protocols built into the bloody language. Again, I feel this is because seasoned lispers are so capable in reading the actual source code (with assistance of M-. and M-, from Slime) that they just skimp on the documentation.

Some things that I have in mind that would take alot of effort but WAAY less than making another editor competitive with Emacs+SLIME/SLY:

   * Rewrite the spec in org-mode and use babel for interactive learning
   * Integrate the above with the so called de facto standard libraries
   * Make excellent documentation for SBCL and ECL implementations (take CCL as an example)

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.

Any ML[0] derived language really, not only OCaml.

[0] - https://en.wikipedia.org/wiki/ML_(programming_language)

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

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.

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.

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!

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.

> 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.

(disclaimer: I develop Cursive, the IntelliJ option for Clojure).

In the recent 2023 survey, Cursive and Calva are pretty much neck and neck, and between them just edge out Emacs. So it's pretty much an even split these days between Emacs and more "modern" options.

https://www.surveymonkey.com/stories/SM-_2BH3b49f_2FXEkUlrb_...

It assumes knowledge of the host platform, which isn't necessarily the JVM.

I've been working on a library that targets the JVM, JS/TS, and the .NET CLR. Clojure has let me share about 85% of the code across the three, though to your point the remaining 15% required quite a bit of platform specific knowledge. I'm fortunate to have worked with all the over the years, so Clojure has been a nice power tool that has let me accomplish a lot while working solo. It's not the right tool for every person or every project, though.

Since you've worked with Python, you might enjoy Basilisp. It is essentially Clojure with Python as the host platform.

My chief recollection of the Clojure mailing list was countless explanations of what a stack trace is to countless people who had never worked with Java and who had no interest in learning about Java.

That was also around the time people had started hyping the JVM as a general language host. Seeing how people struggled on the Clojure mailing list made me rethink that proposition.

I personally never understood why Clojure stack traces alienate people.

I worked on python, ruby, Javascript and Perl before Clojure and I seem to recall they had stack traces too. Am I misremembering?

The Clojure stack traces are certainly longer. Which is because it’s a hosted language - the Java stack trace plus the Clojure stuff. I suppose the extreme indirection in Java might be part of the problem, where code passes through so many intermediate classes.

The traces were longer but also so much less helpful for finding the problem than stack traces in other languages, including pure Java. The one I remember getting irrationally angry over how much of a pain it was to track down the bug was where I mistakenly tried to call inc on a string. This was in 2012, I suspect (and hope) it's better now, but later I got more serious about Common Lisp and never looked back (except for occasional thoughts about taking a Clojure job). CL debugging is rather a joy because of its condition system and full live development support that Clojure emulates. (There's also compile-time warnings that tell you about things like incf on a symbol whose derived (or declared) type is not a number.)

People that think using guest languages saves them from the underlying platform are preparing for failure.

Doesn't matter if it is the browser, UNIX, Java, CLR, BEAM,.... eventually that underlying layer will catch one up.

You're absolutely right and it was a hard learned lesson for me with Clojure, Scala, Kotlin, and F#. I tried all four based on the hype and it kept hurting that I didn't know Java or C#. People would tell me that it wasn't relevant, but then I'd need to do something pretty basic like File I/O and in some cases there wasn't a whole lot out there as it assumed you knew the underlying platform and could just call the method from there. I read books on all of them and tried numerous times to build an app. I finally figured out I'd need to start with Java or C# first and then make the pivot, but frankly...those languages aren't for me and have too much boiler plate. F# too had a problem where there were several well praised books out there, but nearly all of them centered around making the shift from C# to F# or code architecture and practically nothing like the 100 intro to Python books, which is what I really needed. OCaml also has a platform issue, but it's that it mainly only runs on Unix and it also doesn't have what seemed like a great out of the box experience (e.g. https://ocaml.org/docs/file-manipulation).

"Clojure is the gutted and zombie-reanimated corpse of a dream" (:

Why so?

And where is this quote from?

The quote is from an old blog post: http://www.loper-os.org/?p=42#:~:text=Clojure%20is%20the%20g....

The blog post itself is not very informative, but the quote is poetic, memorable and perfectly captures the sentiment of some Common Lisp enthusiasts towards Clojure.

This is only partial true nowadays.

There are at least 4 different options for Clojure fans that dislike Java. BB, ClojureScript in node and browser, ClojureCLR (.NET), ClojurERL. (and a few more).

If you love static types, use TypedClojure.

It is like many things in Clojure a la carte.

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

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.

> 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.

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.

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))

That's true, although my 10k loc elisp config will be the last thing I will ever put on Github. Way too personal ;)

Incidentally elisp does a lot better in new Issue count too, although clojure narrowly beats it PR count. On the whole though, I think if you define mainstream to be number of people using it, then elisp probably edges clojure.

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

Calling Clojure a Lisp triggers some people.

How would they define lisp?

To me Lisp means programs in list syntax with prefix notation.

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, ...

If Clojure is a lisp, so is JavaScript.

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.

Do any of these come close to Genera?

That is an amazing system, that even now, could probably hang with the best of them. :/

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

Missed out Lisp Works and Allegro Common Lisp.

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?

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.)

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

Reply on news.ycombinator.com