>The objections to Lisp are not mere surface-level syntactic quibbles, it's deeper than that.
I am interested in the specifics; if you have the time to write details I'd love that, otherwise I welcome some links!
I am interested in the specifics; if you have the time to write details I'd love that, otherwise I welcome some links!
* Scheme is just too fragmented and lacking in arguments to seduce the current industry; its macros are unintuitive, continuations are hard to reason with (https://okmij.org/ftp/continuations/against-callcc.html), small stdlib, no concept of static typing, etc...
* CL is old, unfashionable and full of scary warts (function names, eq/eql/equal/equalp, etc...), and its typing story is also pretty janky even if better than the others (no recursive deftype meaning you can't statically type lists/trees, no parametric deftype, the only one you'll get is array). Few people value having such a solid ANSI standard when it doesn't include modern stuff like iterators/extensible sequences, regexps or threads/atomics.
* Clojure is the most likely to succeed, but the word Java scares a lot of people (for both good and bad reasons) in my experience. As does the "FP means immutable data structs" ML cult. And its current state for static typing is pretty dire, from what I understand.
All of these also don't work that well with VSCode and other popular IDEs (unless stuff like Alive and Calva has gotten way better and less dead than I remember, but even then, SLIME isn't the same as LSP). So, basically, that and static typing having a huge mindshare in the programming world.
>Few people value having such a solid ANSI standard when it doesn't include modern stuff like iterators/extensible sequences, regexps or threads/atomics.
For everyone: are there plans to include such topics in the Standard, or are there canonical extensions that people are using?
CL-PPCRE for regular expressions.
Bordeaux-threads for threads.
Alexandria for various miscellaneous stuff.
Trivia for pattern matching.
CFFI for, well, FFI.
And Series for functional iterative sequence-like data structures.
There's also ASDF and UIOP, but I'm not sure whether or not they're part of the Standard.
I would also add iterate to the "must haves". All noobs should constantly look at the CLHS (available for dash, zeal and emacs too!), https://lispcookbook.github.io/cl-cookbook/ and https://github.com/CodyReichert/awesome-cl, anyway.
Truly, someone could tie himself to SBCL and its extensions and get a much more modern environment, but I think it's worth targeting ECL and CCL in addition.
I do want to callout that while Racket started off from Scheme (and still maintains compatibility with a bunch of it), it should be considered a different platform at this point and solves a bunch of the problems you called out with Scheme - macros are apparently much better, continuations are usually delimited, has user-mode threads and generators, so you very rarely need to reach for raw continuations, a very nice concurrency system, large stdlib, and Typed Racket also adds static typing.
The DrRacket/SLIME experience is great for smaller projects. I do agree that the language server needs more love. However I still think it gets a lot of stuff right, and is much faster than Python/Ruby due to being powered by Chez Scheme.
The link is an argument against call/cc, not continuations themselves.
That entire website is an exploration into the shift/reset paradigm of delimited continuations, and explores in detail why continuations are incredibly useful and powerful idioms to build all sorts of control structures.
On the one hand, you can use that power to write elegant programs with great abstractions. One the other hand it's really really easy to create unmaintainable messes full of ad-hoc macros that no-one, not even you next month, will be able to understand.
Even if the program is well-written, it can be a really steep learning curve for junior hires unless it's very well documented and there's support from the original writers available.
Compare it to other languages that limit your ability to express yourself while writing code.
The truth is that most programs are not really interesting and having a code base that can be hacked-on easily by any random programmer that you can hire is a really valuable proposition from the business point of view, and using less powerful languages is a good way to prevent non-experts from making a mess.