Re: [External] : A peek to the other side

[Arthur Miller <arthur.miller@live.com>]

Drew Adams <drew.adams@oracle.com> writes:

>> If you didn't you don't know how lucky you are with the integrated
>> Elisp manual. It doesn't have an integrated manual, you have to browse
>> a huge HTML file to find some API call...
>
> The built-in help and thorough-going introspection of
> Emacs and Elisp are in fact outgrowths from Lisp and
> the Lisp community.  Lisp has had this strength from
> the outset.
>
> And RMS has always had a strong will to keep Emacs
> open and self-aware/self-documenting.  "Doc", in
> multiple senses, has always been important to Emacs.
> And Eli has continued this practice and direction.
> We've all been lucky for such attention to doc/help.

+1 Yes, thanks guys!

>> And as usual with APIs (unlike Emacs' open system) you can only access
>> what the developers expose via the API which is very limiting compared
>> to Emacs.
>
> Yep, free, open code, down to the bit-level.  It's
> free turtles all the way down.
>
> IMO, even the notion of "internal" variable, function,
> or other Lisp construct is a misnomer in Emacs.  (I'm
> in a minority on this.)
>
> That "internal" label can/should never mean more than
> a _relative_ and rough indication of some imagined
> probability that the thing might change.  Everything
> might change, and nothing is really "internal".
>
> Unfortunately, there's been more of a tendency in
> recent years to "name-claim" more things to be
> "internal", as if that somehow protected something or
> someone (Emacs development/developers? Elisp users?).
>
> As always (esp. with Lisp), some things whose creator
> never thought of as possibly useful or needed outside
> the initial context do find useful uses by _users_.
>
> By using something thought/intended to be "internal",
> users can discover real uses and put to the lie the
> notion that the thing should be considered internal
> or in some way restricted.
>
> The tendency to think in strong black-&-white,
> internal/external, baked/fluid, closed/open terms
> comes also (I think) from the fact that developers
> come to Emacs and Elisp from working with other, more
> static/structured languages and environments - worlds
> where there really can be a strong use and need for
> an inside/outside separation and protecting coders
> from themselves and code from itself (beyond purposes
> of abstraction).

I don't think it is so white or black. It is more like, here is an API, we
promise it will stay stable, we won't change it, we make commitment to keep
those same in the future to keep your applicaiton stable too and minimize your
effort as an application writer. But for "private", of which "internal" is Elisp
version, there are no such compatibility guarantee. It can be that some code
bases are not so dedicated to keeping public APIs very stable, while others are
more rigorous in that regard. But yes, everything changes, nothing is written in
stone. 

>> You can't change everything, so you don't shoot yourself in the foot. I
>> prefer Emacs' approach where I can even break the system, which is a
>> great learning experience.

Yepp, indeed, I love doing this myself :-). 

> Indeed.  Not only learning for an individual, but
> discovering and inventing for everyone.

Yes, and that is great thing not just with Emacs or GNU/FSF software, but with
all open source software. It empowers everyone interested to become part of
development, not just those with money to invest in shiny new tchnologies
launched in recent years by big tech companies. Even those in poor contries
running on cheaper hardware can take the software, adapt it and use it, instead
of being marginalized by companies who don't see profit and thus reason to adapt
new shiny tech for such community of cheap old hardware.