The Inner Platform Effect

[Delapouite]

Hello

Kakoune is often described as a “Better Unix Citizen” Why Kakoune — The quest for a better code editor meaning it tries very hard to not bundle features that can be done (better) by another program.

Good examples to illustrate this philosophy is how Kakoune relies on external windowing systems (x11, tmux, i3, kitty…) to display and organize multiple clients or how sorting stuffs is delegated to the sort command.

Today I stumbled upon on a related notion on Wikipedia, the Inner Platform Effect

The inner-platform effect is the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using. This is generally inefficient and such systems are often considered to be examples of an anti-pattern.

In the article, web browser are mentioned as such inner-platform. One could argue that the kitchen-sink approach of emacs also follows this trend while other could counter this by stating the all-text approach and consistency sublimes the underlying platform.

With the recent inclusion of :terminal in (neo)vim, it feels like these editors fall more and more in this trap.

To avoid the same fate to Kakoune, I hope we’ll stay vigilant about all new introduced features and after each new release introspect on design questions like Is there anything that you would remove from Kakoune? or how can we improve the glue commands by observing recurring patterns that surfaced in recent plugins.

[andreyorst]

From linked Wikipedia article:

It is normal for software developers to create a library of custom functions that relate to their specific project. The inner-platform effect occurs when this library expands to include general purpose functions that duplicate functionality already available as part of the programming language or platform. Since each of these new functions will generally call a number of the original functions, they tend to be slower, and if poorly coded, less reliable as well.

On the other hand, such functions are often created to present a simpler (and often more portable) abstraction layer on top of lower level services that either have an awkward interface, are too complex, non-portable or insufficiently portable, or simply a poor match for higher level application code.

And this is exactly what I experience when interacting with many tools from Kakoune, either when writing plugin, or just by using pipes. And the main problem for me is that

most cli programs expose human interface as programmatic interface

For example, ls it has a lot of options to variously format output, but there’s no porcerlian mode, so I could reliably parse its output. Therefore I had to make sure that my calls to ls in kaktree plugin are portable and will be parsed equally on all systems. And using all these -x letter arguments isn’t really a programmatic interface.

So when we create inner platform, we do it for the reason of convenience. Another example is my fzf.kak plugin. I do have my own, quite complex, tangled, fzf function, that is a monstrous wrapper around fzf executable. But this is done for the sake of convenience, so new extensions could be done easilly by using this fzf command, and it could be even used interactively if you really want to.

@Delapouite

One could argue that the kitchen-sink approach of emacs also follows this trend while other could counter this by stating the all-text approach and consistency sublimes the underlying platform.

Emacs has this problem, yes. However it’s plarform is always it’s great strength. Being lisp machine with orientation at text manipulation is the reason why Emacs is still alive. However, despite the fact, that Emacs Lisp pretty much allows everything you may need, Emacs, as Kakoune, uses a lot of external tools when it will be faster and easier than implementing the same feature in elisp.

It also has the habit of wrapping things into functions for convenience, but Kakoune also does this, for example grep function is far more than a simple call to grep. Or ctags command, that does the parsing of ctags inside Kakoune with awk. The difference is that Emacs would do the parsing with Emacs Lisp, but it would still use ctags to generate tags.

My point is, that both Emacs and Kakoune use external tools in great ways to improve speed, portability and keep things simpler. But when Emacs uses it’s own language, Kakoune has to fall back to external languages like Perl, Awk, Sh, Lua, e.t.c.