we need *modularity* [last problem] (was: Re: as for Calc and the math library)

[Emanuel Berg <incal@dataswamp.org>]

arthur miller wrote:

> I have seen your previous answers to others, and I do
> understand the point you make, but I think the argument
> fails because a module can be just a proxy to
> a non-free library.

Emacs is notoriously not modular. Everything is everywhere,
you seem to have everything but if fact you have nothing.
There is so much stuff you can't find the basics stuff that
isn't there.

Here take a look: what does this name say?

  cl--defalias

Ah, that's a local function in the Common Lisp package, right?

Well, YES, but ...

It is actually an Elisp defun. And that prefix isn't really
a package qualifier, it is just a convention, part of
the name. And the double dash, likewise just a convention, we
don't have package modularity or any of that kind of data
hiding, abstraction, encapsulation ... what is it more called?
Well, modularity!

In Emacs everything is intermixed, Elisp-Emacs,
non-interactive/interactive, data/data processing/the
interface (buffer, buffer, and buffer), what is a file, what
is a package, what is a library, and what is a program - no
one can tell.

Emacs Lisp isn't is fun, but absolutely not any kind
of powerhouse. It is inconsistent in itself and on top of that
all those zillion interfaces, cl-, seq-, slime- (yes, had to
use that today, for `slime-transpose-lists').

It is pretty fast to get something going but complexity
skyrockets.

What we should do, in general: modularity! clear divisions, in
particular, libraries for everything, including those that provide basic
stuff in a complete and consistent way.

We should get real package modularity, transform the prefixes
into real package qualifiers, and throw away the ugly
local ones.

With Elisp, optimize everything for development speed and
convenience, have consistent interfaces as much as possible,
acknowledge that Elisp was underpowered, which is why all the
interfaces came, now, core Elisp and the interfaces should
make peace, one should identify what it is exactly, what are
the to 10 things that people use with cl-, pcase-, seq- etc,
and bring them into a new core Elisp, and the few CL experts
can still use all the rest.

Now, with native compilation we have speed - we have power
with the interfaces if one could harvest it, which one
currently - well, it is very slow and difficult, anyway - the
very, very last spet into maturity and getting out of the
Elisp ghetto (and getting visitors!) are modularity, modern
software principles - by modularity I mean real modularity,
based on technology - not silly conventions - I forgot where
I was - the last step is modularity in general, and libraries
in particular.

Clear cut interfaces. Get away with the ugly prefixes and
error--prone conventions that don't even do anything.

Elisp 3.0! \o/

PS. This is the problem. This series is completed, I said
    I would write 10, I wrote 4. Here are the other parts.
    It is all based on the same theme. Modularity,
    consistency, libraries, modern software practises.
    
    https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00154.html
    https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00380.html
    https://lists.gnu.org/archive/html/emacs-devel/2024-08/msg00388.html

PPS. So who is working on real modularity based on the package
     with real public and local functions as we speak? I know
     there are always some guy - at least - working on such
     a basic idea. I know some way. And I know some day.

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