RE: [External] : Re: Shrinking the C core

[Drew Adams]

> > I think you're missing the point I made about a "family"
> > of functions.
> >
> > Just having separate "many functions, all with few
> > arguments" can make it more difficult to understand which is
> > which, what's what, and when to use this one or that one.
> >
> > More generally, it's harder to see what the familial
> > relations are. You can't as easily see the forest because of
> > all the trees.
> 
> Indeed, you have to be familiar with the functions in order to
> use them. Just as you have to be familiar with the optional
> arguments and keywords to use them. So there is no difference
> in that regard.

There is a difference.  The doc of for the family,
i.e., all the variants of the function, is in one
place.  And that doc can, and typically does,
describe them together, i.e., it describes their
relationships.

And another, obvious, difference, for things like
apropos search and completion of commands.

> But I think the functions are easier to see than arguments and
> keywords which are inside functions, because when I use
> functions, I'm myself outside, not inside of them.

"The functions" can't be "easier to see" than the
single function, which encompasses the family.

Of course, you haven't made clear what you mean
by "to see" or your being "outside"/"inside"
functions.  So maybe you have some unsaid meanings
that fit your "easier to see" characterization.
 
> Or put it like this: If I have a computer that can do 100
> things, I prefer 100 functions to 2 functions, one with
> 50 optional arguments and the other with 50 keywords.

There's no need to exaggerate or deal with such
a level of abstraction.  The ability to have
&optional, &rest, and keyword arguments doesn't
prevent anyone from not making use of any of those
and instead defining 8000 separate functions (to
further the exaggeration).

Do you use &optional?  &rest?  Why, since you
apparently have a blanket rule that using
multiple separate functions is always better.