• 2 Posts
  • 41 Comments
Joined 1 year ago
cake
Cake day: October 3rd, 2023

help-circle


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



  • Hm, yeah, imagine some kind of service that takes a question from a user and posts it on Reddit, then feeds the answers into its own ML model and gives something back to the user (with a significant delay, obviously, so maybe more for training purposes).

    There was a post here within the past couple of months that, when I looked at its account history, seemed to be obviously some kind of bot, but its writing was coherent enough to seem authentic in isolation.

    Seems like a dark time for the Web is coming. :/










  • It might seem like a subtle improvement to you but I really think it actually achieves the goal of making it so that you can kind of get the structure of the code just from glancing at the colors.

    Structure, from colors. I don’t know, I have never tried to infer structure from colors in the code.

    This is what prism.el provides: color reflects logical depth, which signifies the primary aspect of structure. IMHO it is generally more useful than making function names stand out (their position makes them stand out anyway), variable declarations a certain color (though helpful, I don’t need to see that constantly), etc. A well-written piece of code communicates a lot by its shape, which logical colorization helps to reveal.