Welcome to this EmacsConf 2021 talk
on Emacs as Design Pattern Learning.
I'm Greta Goetz, and this talk
is for people who are interested
in thinking about Emacs
as a tool that's sophisticated enough
not only to cope with activities and tasks,
but also sophisticated enough
to cater to a complex assemblage
of [not just] tasks and activities,
but also people, outcomes,
as well as tools.
This is a definition of epistemic fluency
from a work by Markauskaite and Goodyear
that is relevant to us
if we're interested in
learning how to learn [and]
how to continuously iterate knowledge
to fit changing complex specific contexts.
Some software oversimplifies.
Emacs both helps users
implement design pattern learning
that can cope with complexity,
and it models complex design pattern learning.
So, what do we mean by design patterns?
The term comes from design theorist and
architect Christopher Alexander,
whose work influenced
a broad variety of disciplines.
I'll be drawing on a work in programming
by Richard Gabriel, and in pedagogy,
by Peter Goodyear.
What are design patterns?
They are patterns of micro solutions
combining method and artifact,
and macro solutions
of these micro patterns
when viewed together.
This approach allows for the
specialization, customization,
extension, and reuse of patterns.
This is useful if we're seeking to
deal with complexity. It helps extend
the assemblage of learning components
that we have, without having to build
from scratch.
Another important feature
of design patterns
and their relevance to Emacs
is the human-centeredness.
Christopher Alexander critiqued
the mechanical
and championed the human place.
Emacs, too, champions the human place.
So why Emacs and design learning?
One reason is indeed this extensibility
through Emacs, which allows a person
to extend their learning and use of Emacs
as far as they wish to take it.
This is thanks to its free software core,
and this permits what we call
in networked learning
'e-quality' [cf. Beaty et al.],
which is to say,
the opportunity to co-create knowledge.
So if one wishes to extend
their learning trajectory with Emacs
such that they're able to
write packages for Emacs,
if these packages become part of the core,
they're really co-creating knowledge
within the community
and extending the capabilities of Emacs.
Emacs can also be considered
in terms of design pattern learning,
because it can be used
for different purposes.
This is true even at the very basic level
of Emacs functionalities,
which is a point
that should really be stressed.
So even newcomers coming to Emacs
who don't know programming
can do a very broad variety
of different things with their Emacs,
using these basic functionalities:
for example, simply by customizing
the language variable
in the initialization file.
This, thanks to the powerful Emacs Lisp
interpreter, makes it possible for one
to do a wide variety of different things
within Emacs: from making graphs
to exporting in LaTeX.
And also part of the Emacs basic
functionalities are
how we can cycle through
different tasks and texts very easily
through buffer cycling,
or how within Org we can use tree outlines
that can hierarchize the material
that we're working with
and even change a headline
into a to-do. So we see this extensibility,
this flexibility. Also, within Org,
we can see how by writing
just a few lines of code
such as through header arguments
or code blocks, we can change the way
in which a file,
or part of a file, is executed.
An illustration of what this means
to the beginner would be how easy it is
to export a LaTeX file,
so one doesn't even need to know
all of LaTeX to be able to implement
parts of LaTeX within Org. So this
variety of different purposes, then,
can be experienced by the beginner.
Emacs is also an example
of design pattern learning
because it is a design pattern
of learning itself.
Here we're thinking about design patterns
as a visual representation.
We can think of how systems of systems,
which Emacs is an example of,
stem from a successful center,
and 'this center is surrounded
by a boundary which is itself
made up of centers' [Gabriel].
So, where we have Emacs at the center,
we also have packages such as Magit.
Magit can be viewed as a center
unto itself. However, this center
only exists thanks to the center
of the center, which is Emacs.
And thus we speak of Emacs
as being a successful design pattern
implementation [cf. Gabriel].
And why do we care about
design pattern approaches? Here, well,
what I'm trying to say is that
this is useful to the person
who is interested in being able to
more efficiently cope with
complex and specific situations,
and this design pattern allows for this
because of its extensibility,
because we can find these specializations
or customizations that are able to reach
these changing contexts [that we seek to interact with].
This can be compared with
other software applications
that are prefabricated
so they already decide
what it is a person is going to do
when they use them.
This also means that what they're doing
within these applications
can get stranded there,
that it's harder to integrate
their knowledge or their texts
or their activities
with each other.
A lot of software also makes assumptions
on who their users are. We know that
we speak in user experience design
of the 'customer journey' or of 'personas',
and very often, then,
the customer journey is pre-designed.
But within Emacs, we can be
our own persona.
Practical use of Emacs
can also make non-programmers
into programmers.
So this is to say that
as we are using Emacs,
we can continue to develop
as far as we wish.
Therefore we are not only users
within Emacs, but we are also
creative persons and producers.
So here I am citing work by ivan Illich.
We can further contribute
to the evolution of the rules of Emacs.
To draw on Bernard Stiegler,
if I may also make an analogy,
within our inits, we contribute to
the evolution of the rules
according to which our Emacs works for us.
But again, if we're extending
our learning trajectory,
and if we write a package,
and the package becomes part of the core,
we do indeed contribute to the evolution
of the rules of Emacs.
But because it stems
from our personal use
and our personal customizations,
we can think of it as being
a personal toolkit [cf. Stallman].
So this design pattern iteration approach
to Emacs is the very reason
why it is that we can customize it
to our own liking,
and using Emacs to extend our freedom
then helps us to develop heuristics.
It helps us develop our decision-making,
our problem-solving
and responsibility for what it is
that we're doing,
and these skill sets
are extensible beyond Emacs.
These can be considered as life skills
that have relevance beyond.
This is a very good example
of why it is that being exposed
to complex assemblages
matter to us as human beings.
It's good training ground for life.
But it's also important
for a very basic pedagogical point.
So now I'm going to draw on work
by Hélène Trocmé-Fabre,
who explains that
reduced and poor contextualizations
flatten communication.
So, for example,
within the field of software,
if we are using an application
that only asks us to swipe left or right,
this deprives us of our ability
to respond in a more sophisticated way.
By contrast, by being exposed
to a rich contextualization within Emacs,
we are learning to contextualize,
which Trocmé-Fabre says is the first step
in learning how to learn.
So we can understand
just how important it is
to be exposed to complexity.
It's not just a mere
intellectual exercise,
but it is indeed how it is
that we begin to learn.
If this sounds too abstract,
maybe we can step back for a moment
and think about visualizing Emacs
as a mental map. So here, too,
I'm going to draw on Trocmé-Fabre,
and she is building her ideas
on those of Tony Buzan,
who was the popularizer of the mind map.
So mind maps begin with a core,
which with Emacs is the Emacs core,
which now includes Org.
They extend outwards from the core
through relational codes.
And then through keywords and cycling,
mind maps function to bring out
further ideas, and this may be
the experience you've already had
with your Emacs. Then finally,
these mind maps extend outwards
at the periphery.
In thinking about how this applies to Emacs,
we can think about how yes, indeed,
we all share the same core,
but then we extend this core outwards
into our personal configurations.
So this is the social moment,
but this social moment
is integral to Emacs
because Emacs fully achieves its meaning
when it is being applied, extended,
and customized in this way.
Further, these social branches
are relevant to the continuation
of learning how to learn how to use Emacs.
So for example, we may have
our first configuration file,
and then we might want to compare it
with other people's configuration files,
not only to see what code they're using,
but also to see how it is that they are
implementing certain functionalities
within their workflow.
So along these lines, then,
descriptive configuration files
are extremely helpful.
This map, then, of Emacs
can be considered as a
frontierless heuristic schema,
borrowing from Trocmé-Fabre.
Frontierless, because we can extend
our use of Emacs as far as we want.
Heuristic, again, because we're using it
to solve problems, etc.
This is a free system that extends
following our own 'paths of desire',
if I can use that phrase from design.
So it's following our own 'paths of desire',
but yet it is a shared tool,
so this is an idea of the convivial tool
to draw on Ivan Illich.
Emacs is itself
a design pattern framework,
so we can visualize this
through the mind map,
but we can also go back to thinking about
how Christopher Alexander's work
inspired Richard Gabriel
to think about systems of systems
within software. And he,
drawing on Alexander,
says, well, there is such a thing
as a "being" of successful software,
if it succeeds in being
a center of centers,
as we saw before.
So in Emacs, then, we have a system
that's made up of other systems
of 'communicating components
that work together
to provide a comprehensive set
of capabilities that can be customized,
specialized, and extended
to provide more
or slightly different capabilities' [Gabriel].
So if we're not finding what we need
within the core, we can look for packages
that allow us to extend in a certain way,
or we write our own,
or we begin to write in Emacs Lisp.
And speaking of personal customizations,
Emacs can be considered as an extension
of the as yet unfulfilled promise of
general computing.
In the 1980s, Michael Crichton wrote
that it's easy to use computers, which is
fortunate because everyone's going to
have to learn.
It's not easy to use computers wisely,
which is unfortunate because
everyone's going to have to learn.
Emacs is wise computing
because everyone's Emacs is their own.
We see that it is an exercise
in heuristics, but while it is complex,
at on some level, we want to remember
that it can be used easily by anybody,
as often or as seldom as they want,
for the purpose that they are choosing,
and shaped according to their own taste.
So again I'm drawing on Ivan Illich here.
Emacs then champions the human place
and is a support in our learning
how to learn.
So now I want to think about
being inspired by the Emacs design pattern
and comparing what I think
I've learned about how Emacs works
with some research that has been done
by Philip Guo and his colleagues
about how technology is being used
in certain online teaching contexts.
Researchers continue to note
how the modes of delivery of content
continue to change in terms of
what is considered effective
and what is not.
The talking head was considered effective,
for example. Lectures needed to be
broken down into shorter segments.
But I would say that by using Emacs
and by working within the Emacs ecosystem,
one is already used to
're-presenting' one's knowledge
in a variety of different ways.
So if we are called tomorrow
to deliver in a different way,
we're already used to
thinking about this within Emacs.
So, for example,
merely by changing a header argument,
one can change the way in which
text in a file is executed,
so we see then this easy iteration
within Emacs. We can also think about
how Emacs can be considered in terms of
a help for developing rhetorical 'topoi',
'topoi' being places where we find things,
places where we find ideas,
because we can circulate
among the different tasks and texts
that we are working on
within Emacs seamlessly.
This increases the likelihood
that we can gain inspiration
from the collage of different ideas
that bring out new ideas.
At least this is how
I've experienced Emacs,
if I may add that anecdotal observation.
And speaking of bringing out ideas,
we see how changing Emacs functionalities
can help us bring out ideas
for example, through how we can
use PlantUML easier today
than ever before, so we can now include
mental maps within our Emacs files
if we want to, but also
if we're thinking about Emacs helping us
both remember the material
that we're working with
and 're-present' it,
we can think of it
in terms of its archival functions,
So we can see an example of this
in Sacha Chua's init,
where she is using Emacs
to manage her recent sketches.
This would be really useful
for implementation
in terms of what the researchers
(Philip Guo and his colleagues) discovered
with regards to how today
Khan-style slides are considered
more effective than traditional slides,
because if one is able to integrate
the other kinds of sketches
that one has been doing within Emacs -
and therefore have them at hand
more easily, it would be easier to
're-present' this material as needed
in the ever-changing context of the classroom.
We can see from this example
of Sacha Chua's init that we learn
by following the traces
left by others in the community.
So we were saying then that
Emacs extends outwards
through these social branches,
and indeed we can speak
of the grammar of interaction,
that we benefit from by being
a member of the Emacs community.
And this wonderful phrase comes to us
from a book that was co-edited
by our very own former Org father,
Bastien Guerry, in an interview
that he led with Nicolas Gaume [Andler & Guerry].
Nicolas Gaume was explaining
how in video games, we see our character
and compare our character
to other characters,
and we watch how other characters
make decisions,
and the outcomes of these decisions,
and their trajectories in the game,
and then we compare where we are
with respect to this,
and by having this comparison,
it helps us chart out our own path.
So we can experience
this grammar of interaction
within Emacs every time we compare
our config with that of others.
Emacs further champions the social element
through co-individuation, which is
a term coined by Bernard Stiegler.
This means the meaning that is known
and shared by other individuals.
What is it that we know and share
within Emacs? It is how to
improve our lives
through customizing Emacs
in specific ways. So if one person
reaches the apotheosis
of individuation,
and they're living the life
they dreamed of
through their Emacs use,
they can share this information
with somebody else
who too can come to realize themselves
in this way.
Without the social milieu,
without this attention
to the human element,
the technical milieu inevitably becomes
a negative externality
[which is a philosophical problem].
Here I'm drawing on Bernard Stiegler.
What does this mean? This means
where knowledge becomes automaticized,
it becomes a closed
and self-referential system.
Because it's self-referential and closed,
there is no need for any human input,
so the human within this system
turns into a servant.
By contrast, by using human-centered Emacs,
we are able to take care of our neighbors.
We can write extensions for them.
We can help each other on the forums.
We can even teach just one more person
how to use Emacs.
And this idea comes from Ivan Illich
who extends it to say
that by taking care of our neighbors
in this way,
this enables us to excel
at using the best available tools.
The tool here being Emacs.
The community aspect of Emacs
can also be seen
in how the core of Emacs itself
is evolving. So just like we are
configuring and programming Emacs
while we are using it,
Emacs, too, continues to develop
as the core expands.
So in this, too, we see how Emacs
is a model of design pattern learning
that we can be inspired from,
and the fact that people
from the Emacs community
are able to contribute to the core
brings emphasis to the community role
in this design pattern.
So at the beginning, we were saying
we're interested
in the complex assemblage,
not just of activities and tools,
but also of people.
So here we are talking about
an 'Emacs community'.
This is also thanks to
the selfless work of people
like Sacha Chua, or blog rings
such as Planet Emacs Life
that bring us together
so that we truly can say
that there is a community.
This conference is an example of this:
and thank you to the conference organizers.
But this community,
because of the free core,
allows for there to be
different viewpoints
within the community.
One thing that I've noticed
about the Emacs community
is that there are sometimes even
competing views within the community.
This can be considered
proof of concept of systems thinker
and philosopher Edgar Morin's idea
of a 'cognitive democracy',
which is to say,
a community that is nourished
by antagonisms
while also regulating them.
The "being" of this
very special community,
then, very importantly,
stems from how at the center,
we have free software
that allows for this range of difference
and range of extensibility to exist
even within the community.
So, by way of a conclusion,
we can think of Emacs
as the center of centers that expands,
that is relational and free.
Only in some systems, we should add,
does this "being" emerge.
So going back to Richard Gabriel,
just to champion Emacs one more time
before we say goodbye:
only in some systems,
some software systems,
does a system succeed
in becoming the center
of all of the other centers
and become a framework
that can be used and reused,
which gives systems and objects
their spirit.
So Emacs is being used and reused
through these packages,
and it gives to them their spirit.
The spirit, I would argue,
is in part this extensibility,
and sometimes even difference.
Emacs values the value [cf. Stiegler]
of the freedom to create,
use, and share [cf. Illich],
so we can be inspired
by this design pattern.
It is... It rallies
an autonomous designer mindset
and encourages and supports us
on our path towards
design pattern iteration.
It is not a 'flattened' contextualization.
It permits ongoing learning,
reassembling contexts,
and an adaptable design pattern
extensibility.
Ultimately, it helps us create
circumstances where learning is coherent
with what is valued in the rest of life:
pleasure, growth, and transformation.
So thank you, on that note,
to all of the developers, maintainers,
contributors, and community
for championing our freedom
to co-individuate complex design patterns
the way we want to, so we, too,
can leave original traces, if we want to.
Thank you very much.
[captions by sachac]