I really appreciate Eli's ability to keep a cool head and reason, even if I don't agree where some of the decisions end up. Feels like a lot of folks could learn from that. Thanks for being a great maintainer, Eli. I know in my own professional life I've really flown off the handle on some requests that I saw as unreasonable or make-work.
this post was submitted on 30 Nov 2023
2 points (100.0% liked)
Emacs
313 readers
2 users here now
A community for the timeless and infinitely powerful editor. Want to see what Emacs is capable of?!
Get Emacs
Rules
- Posts should be emacs related
- Be kind please
- Yes, we already know: Google results for "emacs" and "vi" link to each other. We good.
Emacs Resources
Emacs Tutorials
- Beginner’s Guide to Emacs
- Absolute Beginner's Guide to Emacs
- How to Learn Emacs: A Hand-drawn One-pager for Beginners
Useful Emacs configuration files and distributions
Quick pain-saver tip
founded 1 year ago
MODERATORS
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.
Is this how we will keep Emacs alive for another 40 years--by artificially holding back the language and viciously attacking those who object?
Luckily Emacs and Emacs Lisp still have enough attraction that the package ecosystem will probably stay alive, at least there nobody needs to worry about copyright assignment (except for Elpa) and people's opinions on mailinglists.
But recently I saw that there is also a lot of value in contributions to the core with Eglot, tree-sitter, native-compilation, such improvements are important to keep Emacs attractive for newcomers. But it would be a shame if newcomers were discouraged from contributions to the core, ideally it should be a more inviting place.
But to be honest this is what I came to expect from free-software mailinglists, where everybody can voice their opinion and you can yourself be more heard just by being "louder" (posting more often), if you have the time. Especially if you add to that some level of historical authority. For mental health I find it best to just ignore the discussions or if I'm bored I take some popcorn and take a looks at what the drama is about 🍿. I think that's a social problem of group dynamics but I'm no expert and have no idea how to solve this.
My opinions regarding RMS are very mixed nowadays. I'm happy if he sticks to technical discussions, where he has at least some background knowledge, even if it might be dated. As long as his opinion is not held higher than others due to him being RMS, I think it might be time to pass on the baton in this regard. He already did officially as a maintainer long ago but his opinions still find a large audience). I think it would already help if everybody would agree he is just human. I'm also opinionated to some level and will probably be much more so when I get older 🤷.
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.
RAM is cheap nowadays.
Famous last words.
Seriously, though: RAM is cheap until you find your system filling all the RAM, and the OOM killer kicks in. then you will treasure every single byte of memory you can avoid using.
Treasure every single byte of memory? Who are you, Jeremiah?
I notice you often cite obscurities like the OOM killer to throw off your cross-examiners, a cheap courtroom ploy. The OOM killer code is utter garbage written during the Blandy days and never tested. Not that I mind as no non-trivial application recovers gracefully from OOM.
Interesting how you're a purist when it comes to cl-lib, and an absolute maniac when coding basic C.
Po Lu a week ago: less cl-lib please. Po Lu a couple days ago: What do you mean touchscreen.el shouldn't be loaded by default?
lol Not that I think it's a big deal (sorry for using you as an example, Po. I respect the work you're doing, but I'm calling it as I see it). It does highlight how unproductive this type of bikeshedding is, though. That email chain is beyond novel length now and it's still going. Almost makes me hope the "reply-to" button on the site stays broken.