emacs/var/elfeed/db/data/96/964f47eb70f58ad769978651371d2cc381f958ee

         
         <p>Raw link: <a href="https://www.youtube.com/watch?v=FmOYj0SyKfg">https://www.youtube.com/watch?v=FmOYj0SyKfg</a></p>
         
         <p>This was a live stream that got recorded.  It started on 2021-09-26
13:00 +0300 and lasted for about two hours.</p>

<p>I talked about the persistent question of how Emacs conforms with the
Unix philosophy, what it means for a set of views to constitute a
philosophy, whether those tenets are generalisable, and what lessons may
be learnt from them for our day-to-day computing.</p>

<p>After the presentation was concluded, I joined the live chat for further
comments on a variety of issues.</p>

<p>The text of my talk is copied below.  It is written in Org notation:</p>

<pre><code class="language-org">#+TITLE: Live: Emacs and the Unix philosophy
#+AUTHOR: Protesilaos Stavrou (https://protesilaos.com)
#+DATE: 2021-09-26

* How I approach the Emacs VS Unix problématique

Hello everyone!  My name is Protesilaos, also known as "Prot".  In this
live stream, which is being recorded as well, I will talk to you about
the Unix philosophy and how Emacs conforms with it while addressing its
main usability flaw.  The show notes are available on my website:
https://protesilaos.com/codelog/2021-09-22-live-stream-emacs-unix/

My approach to today's topic is informed by my experience as someone who
had used a combination of a tilling window manager, Tmux, Vim, various
ncurses-based programs (e.g. Mutt), and command-line utilities for years
before consolidating around GNU Emacs.  My perspective is further
informed by my background as a social scientist and, ultimately, a
philosopher.  Not as a programmer, though these days I do code a lot for
recreational or educational purposes.

In this presentation I will make arguments against dogmatism; against
misunderstandings in what Unix stands for and how it must work in the
real world.  I will also critically assess the vaunted notions of
minimalism and so-called "bloat" as they pertain to software and discuss
what the appropriate attitude should be when thinking about this and
concomitant issues.  The key word is "attitude": the disposition we
ought to have in order to avoid becoming dogmatic.

This is my second video on the topic.  I did one a couple of years ago,
shortly after I switched to Emacs.  I have also published an article:

+ Emacs mindset and Unix philosophy:
  https://protesilaos.com/codelog/2019-08-09-vlog-emacs-unix/
+ Comment on Unix versus Emacs:
  https://protesilaos.com/codelog/2020-12-28-comment-unix-vs-emacs/

The reason I am doing this again is because I keep getting questions
about my experience with Emacs; questions which typically reveal
deep-seated assumptions that are either outright untrue or ill
considered.

In short, much of this talk will be about theoretical issues.  While I
understand that coding is a technical endeavour, I still believe there
are important insights to be drawn from theoretical work; insights which
will eventually find their application in everyday scenaria.  Besides,
we cannot afford to assume the Unix philosophy as a technical constant
when it clearly is formulated as a /philosophy/.

Finally, note that I will participate in the live chat after I conclude
this presentation.  If you have any questions related to today's topic
or any other subject I cover on my website (https://protesilaos.com),
please let me know.

* Unix minimalism is not a dogma

The Unix philosophy consists of teachings that are based on decades of
experience with systems programming.  Those are encapsulated in the KISS
principle of engineering: Keep It Simple Stupid (or variants).

Unix values specialised tools that can interface with each other to
contribute to emergent workflows.  Its brand of minimalism rests on the
practical consideration of maintainability: both with regard to fixing
bugs and conserving programmer time.  The Unix philosophy prioritises
modularity and composability over monolith-like implementations.  Simple
designs can adapt to evolving circumstances while those that make all
sorts of assumptions and have lots of explicit or implicit dependencies
are unsustainable over the long-term.

Unix programmers did not invent all the concepts associated with their
philosophy.  Humanity had discovered them through aeons of continuous
experimentation and practical reasonableness.  And what better teacher
than the vastness of life all around us?  Natural systems consist of
subsystems, just like our body, forests, oceans, and so on.  In nature
we find division of labour or else the separation of concerns,
specialisation and compartmentalisation, composition of localised
patterns into emergent phenomena...  Everything.

This is not to discount the contributions of Unix, but rather to couch
them in terms of the wider milieu in which we operate.  By framing it
this way, we are better prepared to let go of views that are ultimately
detrimental to our life.  Such as the dogmatic belief that the Unix
philosophy is impeccable and must not be criticised.

Dogma is the misrepresentation of a context-dependent insight as a
universal truth.  In practical terms: when you find yourself not
listening to a counterpoint, consider whether you are giving the other
side a fair chance.  If not, you are most likely being dogmatic.

The Unix philosophy is not the undisputed source of truth.  As with
every corpus of thought, what we learn from Unix remains open to
interpretation.  This means that its followers must assume a sceptical
disposition.  They have to remain open-minded about cases where the
principles of their tradition should not be followed to the letter.  The
practitioner has to exercise judgement and use their discretion to find
the right answer for the task at hand.  Dogma is the enemy of every
school of thought.

Consider the difference between the disciple and the grandmaster.  The
student knows how to faithfully abide by all the precepts of their
tradition.  Whereas the grandmaster not only applies the rules but
understands their underpinnings and thus knows when to suspend their
application and why.  In other words, the student is prone to dogmatism
because of their enthusiasm coupled with their lack of perspective.

* Emacs conforms with the Unix philosophy

In analytical terms, Emacs has two facets to its being:

+ The Lisp interpreter :: We must think of it as the equivalent of a
  POSIX shell like =#!/bin/sh= or whatever environment we use to execute
  scripts.  With Emacs we run or "evaluate" Emacs Lisp code (Elisp).
  That is all we can do with it.
+ The interactive environment :: This is the counterpart of command-line
  shells like =bash=, with the difference being that its event loop, which
  is its interactivity, is more pronounced.  Simply put, Emacs is like a
  shell with superpowers, which looks a text editor upon first sight.
  And this is possible because it is built on top of the interpreter.

Those two aspects of Emacs are woven together into the same application,
making it a /computing environment/ rather than yet another text editor or
IDE.  Still, the analytical distinction is important in light of the
Unix philosophy.  As I already noted, Unix is all about sharp and
specialised tools that can be combined with one another: modularity and
composability.  Emacs is such a tool through its Lisp interpreter.

Just as it is perfectly fine to have a shell interpreter with which to
run arbitrary scripts, it is acceptable to have a Lisp machine for the
purposes of evaluating Lisp.  Similarly, it is customary to run an
interactive shell inside of a terminal emulator.  By the same token, it
is perfectly reasonable to use Emacs' own interactive environment to
interface with the Lisp interpreter.

Emacs should not be compared to Desktop Environments like GNOME or KDE,
or to tilling window managers such as i3, BSPWM, etc.  The reason is
that those are wrappers of otherwise disparate programs.  They basically
bundle different processes inside of a main session, where the joint
presence of distinct applications is a mere coincidence.

In contradistinction, Emacs only runs Elisp and what happens inside of
Emacs participates in the same environment.  This is best understood by
means of an example: if I want to change the font size in my current
BSPWM session, I have to edit the configuration file of my terminal
emulator, my settings daemon for GTK apps, Firefox, and so on.  In other
words, those applications do not know that they are all subprocesses of
the BSPWM session.  Whereas in Emacs, if I change the font size, the
effect is propagated across the entire Emacs environment.

This means that not only does Emacs conform with the Unix philosophy,
but it also has the potential to address its main flaw.  By following
Unix precepts we often find ourselves in scenaria where there is no
integration between the programs we use.  While Emacs ensures that we
get a singular experience /without hacks/: the same commands, the same
fonts and colours, the same paradigms of interaction, and so on.  This
makes Emacs an /integrated computing environment/.

* The integration that Emacs offers is not "bloat"

Which brings us to the dubious notion of bloat in software.  You will
find self-professed proponents of the Unix philosophy dismissing the
value proposition of Emacs on the premise that it is just doing too much
and thus does not abide by the tenets of the Unix faith.  This stems
from the misunderstanding of treating Emacs as a text editor.  Which
naturally raises questions, such as "why should Emacs ever be my Git
front-end, when I already have the command-line?" or "why use Emacs'
windows when Tmux is specialised in multiplexing?".

This is why I stressed that Emacs is a Lisp interpreter that only does
one thing: evaluate Lisp.  And so it is capable of all those wonderful
workflows like editing code, handling your agenda, doing presentations
with plain text like this one, and so on.  If you cavalierly talk about
bloat in Emacs, you are effectively making the argument that =#!/bin/sh=
is at fault because of what shell scripts the user may be running.

Then we have another problem with those who criticise Emacs from a
position of, dare I say, ignorance or based on rumours and hearsay.  And
that is that they themselves do not follow the simulacrum of the Unix
philosophy that is their dogma.  What I mean by that is that you will
often find them using Vim as their text editor.  Last time I checked,
Vim can do multiplexing, it has a concept of workspaces or tabs, it can
spawn a terminal with the =:term= command, and so on.  If you think that
Emacs violates the Unix tradition because it too can do the things that
Vim does, then why do you use Vim?  Why aren't you doing everything with
=ed= or perhaps =sed=?  Or, at the very least, why are you not switching to
=vi=, which is closer to what you claim to stand for.

Maybe then the problem is that you have misunderstood Unix altogether
and are being dogmatic.  Take a pause and think how your totalising
claims are detrimental to your own computing experience: if you follow
them to the letter, you will be missing out on quality-of-life advances
in software.  For what?  Plus you will be tacitly holding that the Unix
tradition is flawless, which is nonsense.

Make no mistake: Vim, Tmux, Mutt, Newsboat, tilling window managers are
all excellent programs in their own right.  But what about their
combination?  What about the /gestalt/?  They lack integration.  To
configure Vim you use Vimscript, Tmux has something like a shell syntax,
Mutt and Newsboat use something else, your window manager may
communicate with shell commands or might require editing a C header
file, and so on.  It is a bit of everything.  And their joint operation
is a mere coincidence, as I already explained: they do not share a
common basis.  Whereas Emacs only knows how to interpret Elisp and all
you do inside of it is an extension of that basic principle, to the
effect that you get what every GNU/Linux power user actually wants: a
singular computing experience that minimises the distance between their
mind and what the machine is doing.  What better minimalism than that?

* Understanding minimalism in context

Let's now consider minimalism as such.  I define minimalism as the
attitude of achieving minimum viable sufficiency for a given task.

To test whether something is minimalist, we must know what it is
designed to do.  Design, however, has two sides to it.  The first is
what the designer thinks is the telos.  The second is what the user
considers as the end goal of the design.

As an example, imagine a sword.  The smith who forged it fathomed a
telos where the sword is fit as a weapon or, at the very least, that it
has a cutting edge.  Now suppose that some collector buys this item and
installs it on their wall for decorative purposes, perhaps to show their
wealth and social status.  To understand the utility and end goal of
this sword, we have to account for the context or, as I say, for the
constitution of the case.  And that is because nothing has a standalone
presence: it always exists in a given context which contributes to its
actuality.

[ Read (among others): On role and actuality
  (https://protesilaos.com/books/2021-04-15-role-actuality/) ]

The same goes for minimalism, whether it is about software or not.  When
we assess the minimum viable sufficiency for a given task, we have to
consider the foresight of the designer or developer but also try to
anticipate the expectations of users.  In other words, there is no
innate minimalism; minimalism that is intrinsic to an otherwise
decontextualised thing.  We must always look at the context.

Allow me to tell you a personal experience with markdown editors from
the days I first switched to GNU/Linux in mid-2016.  I wanted something
that could centre text on the screen like how I am doing it in this
presentation.  It should also have spell checking for English and Greek.
And it should let me configure the colours on display and the size of
the fonts.  So I found several self-styled minimalist apps which would
lack at least one of those basic features.  Now you may think that
changing colours is "bloat", but to me it is a key usability feature,
especially when the designer has not considered applying good colour
contrast for legibility, else accessibility (by the way, I am the author
of the =modus-themes= which are also built into Emacs version 28---they
are designed for the highest legibility standard).

When software calls itself minimalist, it sometimes means that it
actually is incomplete and has not reached the state of minimum viable
sufficiency for the tasks it seeks out to accomplish.  And, by the by, I
will let you connect the dots when marketing folks peddle "minimalism".

* You don't have to switch to Emacs, though you might want to

In conclusion, I encourage you to exercise judgement when thinking about
how some philosophy influences your day-to-day experience.  Do not let
yourself fall into the trap of dogmatism and become a victim of your own
misunderstandings.  In practical terms, always give the other side of
the argument the benefit of the doubt, always keep an open mind, and
always maintain a dubitative and inquisitive disposition.

Emacs is all about integration.  And I already gave some examples, but
let me add another one here.  In Emacs, we have commands to introspect
the environment.  So I can invoke a command which tells me what a key
combination does (=describe-key=).  Or I can call another command which
informs me to which keys is a certain function bound to (=where-is=).
Whereas in my otherwise Unix-y tilling window manager, I have no
built-in way to introspect what the hotkey daemon (=sxhkd=) does when I
type in a certain key chord.  Similarly, my terminal emulator has no
such capabilities, nor do the programs that run inside of it like Vim
and Mutt.  Finding what you want is part of the reason you are using a
computer, so that you do not have to memorise everything.

Basic functionality does not really need that degree of homogeneity.
For instance, =grep= and =sed= get the job done perfectly well, whether
independently or in tandem.  The importance of integration becomes
evident when you operate at a higher level of emergence, where things
must work in concert for optimal results.

To me the Unix philosophy is very important.  It is what inspires me to
separate my programs based on their scope and, more generally, to avoid
duplication of effort.  It also guides me to pursue minimalist solutions
which are fit for their purpose.  I also am, however, a pragmatist who
understands that the Unix tradition is not a dogma.  We can find cases
where improvements can be made to it, such as with the integration of
applications.  When we have a layer of interconnectedness, such as the
one provided by Emacs, we get more consistent results for emergent
workflows, which ultimately lead to a superior end-user experience.

So, should you switch to Emacs?  The answer is "it depends".  If you
need a singular experience that allows you to draw linkages between your
various workflows, then I would say "yes".  Otherwise it really is up to
you.  Whatever you do, however, do it from a position of knowledge, with
a clear purpose, and remain committed to it.  Do not follow trends or
pernicious memes without applying common sense.  Emacs has a learning
curve, but so do all the disparate programs that are glued together in
an ad-hoc fashion in some GNU/Linux power user's setup.  You have to
work for the good things.

That's all for today's presentation, folks.  Now I will check the chat
and comment on any questions or remarks.  Thank you!
</code></pre>

<hr />

<p>The video thumbnail is a tweak of the Levitating, Meditating,
Flute-playing Gnu under the terms of the GNU General Public License:
<a href="https://www.gnu.org/graphics/meditate.html">https://www.gnu.org/graphics/meditate.html</a>.</p>