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

[Emanuel Berg <incal@dataswamp.org>]

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?

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

-- 
underground experts united
https://dataswamp.org/~incal