Welcome to my talk, which is pre-recorded, so please don't blame me if I come across
as a 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
in 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 are 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 speak 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.
Now 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 basic technology, 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.
What 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 six and 28 participants per course.
And 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.
And 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.
And 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 Litwack 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 Litwack programming with Emacs and Org Mode.
So you see the before and after introducing Litwack 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.
So 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.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.
Thank you.