I don’t know what is the problem with cl-lib been loaded in Emacs core. RAM is cheap nowadays. I am loading the entire cl-lib in my Emacs when I build Emacs, no problems noted (been doing this for a while):

In my loadup.el I do this:

;; This file doesn't exist when building a development version of Emacs
;; from the repository.  It is generated just after temacs is built.
(load "leim/leim-list.el" t)

(load "emacs-lisp/gv")
(load "emacs-lisp/pcase")
(load "emacs-lisp/easy-mmode")
(load "emacs-lisp/cl-lib")
(load "emacs-lisp/cl-seq")
(load "emacs-lisp/cl-macs")
(load "help-mode")
(load "emacs-lisp/cl-extra")

In conjunction with this, I have also patched cl-lib.el to remove some unnecessary loading when bootstrapping:

(provide 'cl-lib)

;; (unless (load "cl-loaddefs" 'noerror 'quiet)
;;   ;; When bootstrapping, cl-loaddefs hasn't been built yet!
;;   (require 'cl-macs)
;;   (require 'cl-seq)
;;   ;; FIXME: Arguably we should also load `cl-extra', except that this
;;   ;; currently causes more bootstrap troubles, and `cl-extra' is
;;   ;; rarely used, so instead we explicitly (require 'cl-extra) at
;;   ;; those rare places where we do need it.
;;   )

The reason is I just prefer to have it in loadup.el explicitly so I can see it and comment/uncomment if need be, instead of perhaps forgetting cl-lib.el does it on the bootstrap.

You can make those as patches and apply patches automatically when building Emacs.

You know the discussion’s gone off the rails when LWN picks it up. I’ve been biting my tongue at times while reading it (and now glad that I kept silent…but then, look at me now).

I can’t fathom the objections to using cl-lib, especially since something as basic as the built-in debugger already uses it. Elisp is a very pleasant language to work in, but without cl-lib it would be missing basic functionality.

It boggles my mind to see how some people seem to want to write Lisp as if it were C. As an experienced CL hacker I’ve seen often asks, “Is that the level of abstraction you want to be working at?” These forms from CL allow working at higher levels, treating the lower levels as solved problems that need not be re-engineered at each invocation. They don’t increase the cognitive burden–they significantly reduce it, especially when it comes to reading others’ code. By using those standard solutions, we stand on the shoulders of giants.

And pcase is, as far as I’m concerned, a masterpiece of programming, a tool I sorely miss when working in any other environment. I really hate to see this incredibly useful contribution of Stefan Monnier’s disparaged, especially when much of the criticism merely comes from unfamiliarity and NIHism. (The use of backquote patterns with unquoting to destructure patterns, the same way they’re used to construct the same values, is brilliant and naturally Lispy. And the extensibility and modularity of pcase is excellent–compare to, e.g. cl-loop’s implementation (another macro I like to use, but it’s not easily extended).)

Some of the worst has been to see the disingenuous argumentation presented in these threads on emacs-devel. I’ve seen a lot of hypocrisy and insulting, passive-aggressive attitudes, blaming one person for what the other is himself doing. It wasn’t but a few weeks ago that I noted in another thread how off-putting the discussions can seem to newcomers, only to be told that such impressions are incorrect and invalid–and now to see such awful behavior between people who have effectively been colleagues for years. Is this how we will keep Emacs alive for another 40 years–by artificially holding back the language and viciously attacking those who object?

I think the fundamental question is, is all this worth it? Of all the things to spend the very limited programmer time available, to spend it on rewriting working code to use more awkward and verbose constructs because ideas from Common Lisp have cooties? (Forgive me, but that seems to be what it boils down to.) It’s disappointing.