In my experience they often prefer that scheme/etc ceased to exist at all. I've had conversations with CL fanatics who accuse Scheme/etc of diluting Lisp by merely existing, and thereby harming CL.
Others aren't so extreme and just want people to stop saying "scheme is type of lisp."
I don't mind that Scheme exists, but I do mind that enthusiasts naively use it to build production systems, because they end up wasting time & energy re-implementing things the Common Lisp standard already specifies rather than spending that time & energy on the problems that they're actually trying to solve.
Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things.
Meanwhile, the ecosystems of non-Lisp-family languages grow ever-larger, and hence ever-more-appealing, which is a problem because while Scheme-the-language is better than Python-the-language or Go-the-language, Scheme-the-fractured-ecosystem is worse than Python-the-healthy-ecosystem or Go-the-astoundingly-robust-ecosystem, which means more people use Python & Go, which means fewer people use Lisp-family languages … it's a vicious cycle.
Which means the world is a worse place, stuck in a local maximum of C-family languages and unable to break out to the Lispy global maximum.
> Scheme is another Blub: a Scheme user looks at Common Lisp and thinks, 'hey, I don't need generic functions; I don't need packages; I don't want separate namespaces for separate things; I don't want to extend my reader.' Meanwhile someone who's built large systems in both Lisp & Scheme realises how glad he is to have those things.
I find this list a little funny, because we do have generic functions, packages, and the ability to extend the reader. In Guix we use reader extensions for G-expressions, for example.
I grant you the separate namespaces thing, because, well, we really don't want to have a separate namespace for variables and procedures :)
> I find this list a little funny, because we do have generic functions, packages, and the ability to extend the reader.
But those are all non-standard, right? At least, I quickly skimmed through R7RS & don't see them in there. So they're either Guile-specific extensions, or your project implemented them, or they are a third-party library which has not undergone the same scrutiny as the standard itself.
FWIW, I find that having many namespaces (not just two!) rather than one is conducive to good program design.
