Re: seq.el and the complexity of Emacs Lisp.

[Harald Judt <h.judt@gmx.at>]

[-- Attachment #1.1: Type: text/plain, Size: 3179 bytes --]

Am 07.11.23 um 11:14 schrieb Emanuel Berg:
> Harald Judt wrote:
> 
>>>>>> Saying lets just drop these in a sec to all package
>>>>>> authors seems overreaching.
>>>>>
>>>>> Richard's question was about use of cl-lib in the Emacs
>>>>> tree, it will not (and cannot) affect
>>>>> third-party packages.
>>>>
>>>> He also mentioned about ELPA. Even if it's just the Emacs
>>>> tree it does seem overreaching unless there's
>>>> a direct benefit.
>>>
>>> On the whole, changing code that works, for that to make
>>> sense one must have a distinct improvement in mind, that is
>>> almost beyond discussion, otherwise it isn't worth the
>>> effort to do it, with everything negative and unexpected
>>> that can follow - in my experience.
>>
>> That seems to be a common but unfortunate practice nowadays,
>> that you should not touch code that is working, especially
>> rooted in corporate environments. Every improvement to the
>> code will make it easier to maintain in the long term,
>> fighting bit-rot and inconsistencies. If you touch it and it
>> fails, you simply fix it, there is nothing preventing you
>> from making changes to the code again.
> 
> Fighting bit-rot and inconsistencies is okay if those are
> small, easy and uniform to fix, and one can see a clear
> benefit of doing so (be it small in size as well).
> 
> But cl-lib is huge, any action to reduce its influence will be
> an equally huge effort - an effort that will seldom look the
> same twice - and, worse, can anyone tell for sure what the
> benefit would be again? Code that is easier to maintain?
> Why exactly, and how do we even know that?
> 
> What are we going to replace cl-1, cl-2, ..., cl-n with to get
> what kind of advantage-1, advantage-2, ..., advantage-n
> exactly? Can anyone tell, really?

My response was targeted more at the general denial to code changes, not about 
this discussion about cl-lib. Your assumption that every change needs to be 
driven by benefit seems a bit short-sighted to me. It is probably good enough 
when you want to build something fast without having to care about it much 
later. Maybe it holds when you lack time because then not wasting time is a 
priority. But if you want to build something for long-term use, it might not 
be an optimal solution. Having to depend on immediate benefits to change 
anything also loses importance when time is not that much of a priority.

If cl-lib is huge, then one should ask, why has it grown that huge? Is it just 
a badly documented one-pot of several ideas thrown together instead of someone 
doing a library using careful planning? Wouldn't it have been better then to 
replace those functions with something better? Could the situation be improved 
by revising the cl-lib documentation, or splitting up the library and 
progressively replacing it with something better?

 > No, this whole case against cl-lib doesn't add up, sorry.

Probably it is a bad idea to treat this as dragging someone to court?

Harald

-- 
`Experience is the best teacher.'

PGP Key ID: 4FFFAB21B8580ABD
Fingerprint: E073 6DD8 FF40 9CF2 0665 11D4 4FFF AB21 B858 0ABD


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 228 bytes --]