[TeMPOraL]

Importantly to my original point, if I didn't like the message your little function printed, and you didn't design your "extension" to be extensible (e.g. by putting "hello world" in a defvar or defcustom), I can just... redefine your function - and everyone else using it will pick my new definition. Or I could defadvice it to modify its behavior without changing its definition.

As you say, Emacs has no special framework for extensions - it's all just functions and variables, plus a bunch of higher-level concepts (e.g. minor and major modes, customize, autoloads) to pick and choose from.

[meetups323]

The Emacs approach is a bit more closely followed by Atom, where extensions have full access to the window, are responsible for their own UI elements, and many "core" features are actually just extensions. Atom faced many of the same difficulties with this as Emacs -- when absolutely everything in the interface is "public", it becomes very hard to make changes without breaking userspace. But yes, it does allow for a much more diverse extension ecosystem.

Tradeoffs all the way down :) If we didn't have them we wouldn't be engineers...

[taeric]

The problem with Atom is that they didn't set a stable foundation for where to expose everything. That is, the window that they expose is itself under active development, if I understand correctly.

This is an odd shift of the word "stable" in software. For a long time, folks took stable to mean simply "doesn't crash." But, it also needs to mean "remains unchanged" if you want to use it as a foundation of other work.

Of course, I say that, and have to ack that the web itself has proven a major exception to this supposed rule. Nothing has been stable in that entire landscape, but it has continued to grow at an astonishing pace.