Welcome to my talk, which is pre-recorded,
so please don't blame me if I come across
as wooden and humorless.
It's hard to work up any emotion
when looking at a mechanical eye.
Of course, I am German,
so I am pretty wooden and humorless to begin with.
What else do you need to know about me?
Not much, I suppose, except that I have been
an Emacs user on and off
since my days as a graduate student
in theoretical physics in the 1990s.
I picked Emacs and Org Mode up again
for teaching during COVID
when I had a lot of time on my hands,
and when the teaching and learning needs shifted
because of the exclusive online teaching.
Now I'm going to take my picture away.
You had a good look at me.
I think that's just going to be in the way.
So my interest in this topic began with
an Emacs talk given by Daniel German
from the University of Victoria in Canada in 2021.
Daniel demonstrated in detail
how he uses Emacs and Org Mode
to prepare and deliver lectures
on different programming languages.
This gave me the idea to try the same thing
with my students with an important alteration.
I wanted to force them to use Emacs and Org Mode
just as most computer science instructors
force their students to use whatever they are using
when they develop their material.
I carried my plan out and mandated Emacs and Org Mode
as the only programming platform and IDE
for three consecutive terms in all my courses,
nine courses in total.
I will give more details later.
I published my results as a case study
in September of this year,
and it contains the missing bits
that I will not talk about today for lack of time,
especially regarding the methodology,
the assessment, et cetera.
Please also use the Q&A to inquire about such details
if they interest you.
I probably don't have to explain what computer science is,
but not everyone may know what data science does.
I teach courses in both disciplines
and the boundaries between them are blurred,
so much of what I'm saying about data science
will also be relevant for computer science.
Conceptually, data science is an interdisciplinary affair
that intersects with computer science
and with whatever it is that the data scientist
or his or her clients know very well; their domain.
Because of this interdisciplinary character,
and because their focus is on the data
rather than only on algorithms or mathematics,
successful data scientists need to be more broadly educated
than specialists in computer science or statistics.
In particular, there's a need to master
the entire so-called data science pipeline:
from data cleaning, which you see
on the very left in this slide,
over coding, to statistical modeling,
and to data storytelling through visualization,
which you see on the very right.
This is why until recently,
data science was a graduate-level education
only for software engineers, computer scientists,
statisticians, psychologists, biologists, business people,
or for whoever took a special fancy
to data in their chosen field.
Only with a growing interest in machine learning,
this has changed.
And now we train--or try to train--data scientists
in undergraduate programs as well.
Now, what I'm saying here, I think is true
for all areas of computing,
from software engineering to data science.
They are mostly taught and learned like a craft
rather than a science, not through research,
but through drill.
The elements of this drill can be illustrated
by learning how to fix cars.
They include taking a problem apart
with the tools you already know,
learn a lot more tools in the process of doing that,
then solve many, many problems
of increasing difficulty
while being or getting more literate, as it were,
about the mechanics of computing,
including the hardware, the infrastructure,
and finally develop a way of thinking
that allows the learner to identify patterns
to solve new problems better and faster.
Unlike learning how to fix cars,
all of the objects of our interest--
both hardware and software--are evolving rapidly.
In this field, radical innovation is the rule,
not the exception.
The problem that I identified is that students,
especially undergraduate students
in computer and data science,
often do no longer understand the infrastructure.
Here are a few examples of the problems
that the students seem to have.
They do not understand computer architecture,
except in theory.
They cannot navigate their way around their own computers.
They don't understand the value or the issues of networks.
They are often more interested in convenience
than in customization of the environment.
As a result, the machines which we're meant to control
have all the power--though passively,
of course, for now anyway.
Enter Emacs, the self-extensible operating system
disguised as a text editor.
You're at EmacsConf, so of course I don't have to tell you
what Emacs can do.
Here's a rundown on the right-hand side
of some of its most important properties,
and an Org Mode file excerpt
from one of my classes on the left.
What you may not know is how to onboard students who have,
at the start, no interest whatsoever
in leaving their comfort zone,
which is defined by a lifetime of Windows,
pre-configured graphical interfaces, and software bloat.
In fact, when I started this, I wasn't very hopeful,
but the results have made me even more optimistic
than I already am by nature.
So to rein in your expectations,
you cannot do entirely without
configuring the student's experience.
An important part of this
is the initial Emacs configuration shown here.
The minimal configuration file,
which you can see on the right-hand side,
allows the students to run code in C and C++, R, SQL,
SQLite, Python, and Bash.
It will allow them to update Emacs packages
from the stable Melpa repository,
and it will allow them to create code blocks easily
using skeleton commands for code blocks,
and to auto-load the Emacs Speaks Statistics package,
which you particularly need when you run R in Emacs,
and lastly, to disable toolbar and graphical menu bars.
To do that encourages the exclusive use of the keyboard
to control Emacs, and to stop the students
from flicking all the time to the mouse;
seems to be an essential part of getting used to Emacs.
Now Org Mode was included in Emacs in 2006 as a major mode,
and as you know, it's a structured plain text format
with notebook live code execution.
It's an ideal platform for literate programming,
which is a term for programming that intermingles code,
documentation, and output within a single document,
and that can, as you can see here from an org file,
either be tangled into source code
or woven into a documentation file, which could be PDF,
could be Markdown, could be OpenOffice,
could be a notebook format.
This methodology was conceived by Donald Knuth in 1984,
and it is therefore even older than Emacs itself.
The main purpose of literate programming is not only
to make code or documentation or output more manageable,
but to allow humans to create a data story with ease
from a single source.
So what you see on the slide on the left-hand side
is the story and code inside a Org Mode file.
The file starts with some documentation,
then with the white background is the code,
and at the bottom you see an output file,
which is not shown here on the slide itself.
In the middle, you have the source code,
which is the result of tangling
or of opening a buffer inside org-mode.
And on the very right-hand side, you have a PDF--
actually this HTML rendering of the very same file
that you see on the very left.
So the humans look at some of this code,
and the machines will look at other parts of the code.
I actually did all my programming in a literate way
even in the early 1990s, not using org-mode,
which didn't exist yet,
but using Norman Ramsey's Noweb preprocessor.
And I still use it inside org-mode today.
This preprocessor, Noweb, allows you to tangle code
from within an org-mode file that's a self-standing file,
much like org-mode's edit functions,
which export code blocks into buffers
in whatever language the code block is written.
In data science, these interactive notebooks
in one of the interpreted languages like Julia,
Python, or R dominate.
The basis technology,
is that of Jupyter notebooks, which take their name
from Julia, Python, and R.
And these notebooks use a spruced-up shell (for example,
IPython for Python) with an option to add SQL cells.
Org Mode inside Emacs has a large number of advantages--
some of them are listed here--over these notebooks.
Two of these stand out particularly.
Different languages can be mixed, as shown in the image,
while in Jupyter notebooks, a notebook is limited to
running a kernel in one language only.
So the content of the notebook--
its document code or output part--
can be exported in a variety of formats,
which makes it much easier to share with others
and to use one's work in different reporting formats;
for example, to read it out into a LaTeX publication.
Actually, to come back to this,
the file does not show different languages.
That is something you can see in a paper of mine,
in one of the figures.
Now, coming to the case study itself,
here are some of the overall results of the case study.
Now, the courses ranged from introductory to advanced,
as you can see here in the table on the left-hand side.
The topics covered different programming applications.
The courses were taught
over a period of three consecutive terms.
There was between 6 and 28 participants per course.
I used a few other tools besides Emacs:
GitHub as the main repository for all the material,
Datacamp for structured online lessons and exercises,
Canvas as a learning management system,
and Zoom to record the sessions for later use.
Now, the material for all these courses
is openly available on GitHub,
and the address is on the slide at the bottom.
I'm now going to briefly comment on
the most important aspects of using Emacs and Org Mode
in and outside of class.
Essentially, these two--Emacs and Org Mode--
were used all the time for almost everything
that the students were doing in and outside of class.
The only exception were multiple choice tests
and online assignments
on the Datacamp learning platform
in the data science courses.
But everything else--code-along lectures, home assignments,
student projects, practice in class--
was done with these two tools.
To facilitate the onboarding,
so to get students used to Emacs in the first place,
I developed a simplified Emacs tutorial,
which was focused on the basics of literate programming.
It included navigation in major modes,
managing files and buffers, customizing the interface,
and keyboard shortcuts.
It was considerably shorter;
about a quarter of the size of the standard Emacs tutorial,
which contains a lot more stuff.
As a result of this onboarding,
by the end of the second week,
most students were able
to use Emacs and Org Mode competently
for their assignments in and outside of class,
completely independent of their previous exposure
to any of these tools.
Most of the students, in fact, had never heard of Emacs.
All the classes were taught physically in a computer lab.
Emacs with Org Mode
and the necessary languages for the class
were pre-installed on the computers.
The computers ran Windows, unfortunately,
like most of the students' personal computers.
A typical class involved a lecture delivered by me
in Emacs as a code-along.
The students would get an Org Mode file
with all the code removed.
You can see an example here
on the slide on the right-hand side.
This example is actually only one line of code in blue,
visible at the bottom for an award file.
Then the students submitted home assignments
also as Org Mode files, complete with documentation,
code and sample output.
Working this way makes the classes highly interactive.
So the students are busy coding
and they learn to control their environment better
all the time.
In my classes, the students have to complete
an independent, agile research project
using an adaptation of Scrum as a methodology.
You can find examples of these rather high-octane projects
in my paper.
Now, using literate programming for the projects
provided some unique benefits.
By having to continuously interweave documentation,
references and output alongside functional code,
the students learn to communicate their work
throughout the term
in various stages of completion,
from the research question at the start,
over the prototype to the finished product.
And here on the right-hand side,
you can see one of those assignments
that the students received,
including some of the metadata for their Org Mode files
in the beginning of the course.
Here are two graphs that I created early on
when I started doing this.
They show how the test results of the students
in two different courses, actually three courses,
changed from before to after
introducing literate programming with Emacs and Org Mode.
So you see the before and after
introducing literate programming in the red curve before
and the blue curve afterwards.
And the improvement, especially on the right-hand side,
is quite significant.
It was this performance improvement,
apart from the students who were voicing their support,
that made me extend the Emacs experiment
after the first term
and continue for the following two terms.
The courses... Coming to the result, the overall result...
The courses were formally and informally
also evaluated by the students,
but you need to look at my paper
for some explicit student comments,
which you will find there.
Here, I'm giving you only the summary.
So first of all, Emacs proved to be hard to learn for some,
but all students succeeded in all courses,
independent of the level of
their previous knowledge and skill.
The documentation practices remained pretty uneven.
So some students wrote a lot, others wrote little.
But they were overall much higher than in classes
without the use of Emacs and Org Mode.
The interactivity enabled through Emacs
was highly praised by the students
and always identified on the evaluations.
And lastly and most importantly, given the problems
that I identified earlier, the computing file
and data handling competence
of the students who worked with Emacs throughout
opening Emacs shells, running programs through Emacs,
these skills increased massively.
In the published paper, I have expressed
a little more doubt than you see on this slide.
But now, actually, I'm feeling quite hopeful again,
especially because recently for one term,
I have returned to Jupyter notebooks.
In the current term, I abandoned Emacs again
for online Jupyter notebook installations.
The reason is that these Jupyter notebooks
that I use from DataCamp have generative AI support
from ChatGPT integrated into the notebook.
And I wanted to try that.
But after one term without Emacs,
I regret that decision now.
The AI advantage does not make up
for the loss of the immersion
that Emacs and Org Mode deliver.
And here's the summary.
When learning computer and data science,
immersion is everything.
The best students will aim at immersion anyway.
But for the majority of students,
immersion must happen in class.
Emacs and Org Mode performed throughout very well
as the central literary programming platform.
And the pre-configuring and the onboarding,
which I showed to you, were very important
to train the students quickly.
In the paper, I also speculated on the impact
of low-code, no-code, and AI coding assistance.
And my general view on this is that
the arrival of these tools
make literary programming as an immersive technique
focused on teaching a broad range of skills
even more important.
So even with AI--or especially with AI--
this kind of approach, I think, could be critical.
And that's it.
I'm at the end of my presentation.
Thank you very much for your attention.
And I'm looking forward to the Q&A.
Thank you.