all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Community is About Addition
@ 2024-12-10  9:30 Psionic K
  0 siblings, 0 replies; only message in thread
From: Psionic K @ 2024-12-10  9:30 UTC (permalink / raw)
  To: Emacs developers

Reflecting on Emacs conf, I expect much of the exploratory work will
capture the interest of intersections of communities.  Intersections
of sets are smaller than either original set.

Union strategies are stronger.  Even if I am adding only an
intersection of two sets to a set, the resulting set is strictly
larger.

Who wants to write dynamic modules in X language?  As there is no
exclusion of any existing users who may even ignore such development,
expanding the dynamic module interface is purely additive from the
perspective of attracting hackers.

There are perhaps a few ways that I find Elisp subtractive.  We all
know what they are.  However, I find adoption of another lisp, even if
better, to be an intersection.  If it were required, then it is
attractive for some users, but if a way were found to be purely
additive, it would be better than an intersection.

Users of Emacs would likely enjoy controlling or augmenting Emacs from
a number of languages, including all Lisps.  The common denominators
of interoperation live in the dynamic module support, between programs
that can speak to Elisp to exchange data and call each other.  The
existence of excellent support for other Lisps to live at the boundary
would be additive.

Rust is perhaps a better language for implementing asynchronous things
in Elisp.  While running Emacs built entirely in Rust may not be
viable without a degree of effort that is difficult to attract, using
Rust to provide language extensions to shoehorn more useful
asynchronous expressions into Elisp, especially for it to farm out
work to user code in other languages, would be purely additive.

There is a likely skepticism of some of the "additive" approaches I
have described.  They are not directly beneficial to all Emacs users.
It may be viewed as advocating for dispersion among usage patterns.
Such a concern is framed on the implicit belief that there is a fixed
amount of community or that community can be coerced into a unified
effort.  Community is about addition, and strong addition overcomes
dispersion.

It is true that the promise of some intersections is to overcome an
activation energy and then zoom down into a lower energy state,
releasing tremendous potential.  If only these things were done
tomorrow, users who were so compelled by a newly available
overwhelming value would join the new set.  It is true.  It would be
more likely to happen if net users of the destination set were working
on such things today, compelled by value that is available sooner in
smaller amounts.

I wish all of the various efforts to do different things success.  My
main point is to encourage reflection on how such efforts can create
immediate net addition to community and sub-community as a means of
attracting mass of users, which has robust dividends to any ecosystem
and to any individual project.



^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-12-10  9:30 UTC | newest]

Thread overview: (only message) (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-10  9:30 Community is About Addition Psionic K

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.