Adding a generic mathematical library

[Christopher Dimech <dimech@gmx.com>]

> Sent: Friday, July 26, 2024 at 2:24 AM
> From: "Emanuel Berg" <incal@dataswamp.org>
> To: emacs-devel@gnu.org
> Subject: Re: Adding a generic mathematical library
>
> Christopher Dimech wrote:
>
> >> Calc was brought into the discussion as a way of opposing
> >> the idea of a library. To say, we don't need it, because we
> >> already have it.
> >
> > Incorrect, we generally do not accept new packages that
> > substantially overlap with existing GNU packages.
>
> That means the more you do this "program as a library", the
> less you can have a common library for many programs.
>
> So the solution to the problem cannot be done, because of what
> is the result of not having it arranged soundly in the first
> place. When it would have been super-easy. "Here, here is
> math.el and string.el, use it and put new stuff in it!"
> Instead, that stuff has ended up all over Emacs.
>
> But it is what it is, anyone thinking that model is good, go
> ahead and think so.
>
> "We don't do generic libraries. We think it is normal that
> a program that has nothing to do with ERC, Gnus and Calc to do
> generic operations on strings and numbers require files that
> are part of all these programs."
>
> Instead of blaming why the problem cannot be fixed on others
> who have nothing to do with that idea.
>
> > The procedure is for GNU to have a given package to do
> > a given job, and people in that area to contribute to and
> > improve that package, working together, instead of having
> > many packages that each do different parts of a job, each
> > developed on its own.
>
> In practice "program as a library" means the opposite.
> Every program does a little of everything. Instead of adding
> to the common library, what is missing is added to the
> program. When something is needed by another program, instead
> of bringing it from library, it brings in the first program.
> Until there is something additionally needed, then that is
> added, again not to the library but to the second program.
> And so on.

What you are suggesting is to have an improved design where the functionality
of calc can be used elsewhere.  We can still have the tool and the foundational
code to be calc.  We do not need specifically a different name for a library.
Many people know about calc but would not be aware of some new library that
could be popping up.

The GNU Project, and by extension, the Emacs development community, has a
unique culture and set of practices that distinguish it from other software
development projects.  Understanding these nuances is crucial for anyone
involved, especially those considering taking on a maintainer role.

> > Is there a good reason why an association with them is
> > so terrible?
>
> Oh, absolutely not! Like I said, it is like this all over
> the place.
>
> Here, check out the string library! Only those files are all
> over Emacs.
>
> (shortdoc-display-group "string")
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>