Hello, my name is Fermin.
Today, I'm going to talk about the Emacsen family,
the design of an Emacs, and the importance of Lisp.
So we're going to talk about Lisp.
I want to start from the end.
The first question I want to ask is
why I think Lisp matters.
When I'm talking about Lisp here,
I'm talking about the idea of Lisp,
so the family of languages that are Lisp.
But given that there's no formal specification of Lisp,
so the opinion might vary. I will expect that Lisp,
most of the Lisp have these kind of features.
The first one is homoiconic:
the code is data, basically.
They also have a REPL: read-eval-print loop.
That is very powerful and can help in development.
Also, I think a good Lisp
should have a powerful macro system.
I'm good with compile-time macros,
but read-time is also interesting.
There's a lot of Lisp that you can choose.
There's the main three ones, of course,
with Scheme, Common Lisp, and Clojure.
Scheme by Guile, Common Lisp by Common Lisp,
and Clojure by Clojure or ClojureScript.
So let's talk about Emacs Lisp.
I didn't mention Emacs Lisp.
I'm going to talk about why Emacs Lisp
was chosen for an Emacs editor.
We're going to explore this kind of design of the Emacs.
And Emacs Lisp is the main language of it. Why?
Given that there were a few alternatives at the time,
why Emacs Lisp was chosen?
So RMS, Richard Stallman, needed a Lisp,
and there wasn't one available at the time.
Keep in mind, this was the early 80s.
Stallman was writing at that point the GCC, I think,
and he was writing the core components
of what is going to become GNU.
He needed an editor. He wanted Lisp. He wanted Emacs.
So he wrote Emacs Lisp. So at that time,
the functionality was more important than "perfection."
What I mean [by] "perfection" is: we programmers
sometimes like to make everything good
or very, very good when sometimes, indeed,
it's more important that it works
to do the task that it should.
And it's not a bad language.
It's not that bad. At that time, it was mostly nice.
Today, it's good enough, I think.
He wasn't the first one, the GNU Emacs,
nor the only one, of course.
There were others: Hemlock, Zmacs, and Climacs...
Two of them, I think, were written in Common Lisp,
and Zmacs was written in a Lisp from a Lisp machine,
so it was an implementation of Emacs.
Not GNU Emacs, but the original idea
of Emacs for a Lisp machine.
So Hemlock was written in Common Lisp,
but it's no longer used and no longer developed,
as far as I know. And Climacs, it was developed,
but it was abandoned, I think.
So three of them failed for different reasons.
Zmacs was because of the Lisp machine market crash,
and yeah, it also failed.
So Emacs got alone. And in the 90s, interesting to explore,
some people suggest that why
now that we have a standard Lisp, right,
because Common Lisp was standardized in '94,
why don't we change Emacs Lisp to Common Lisp?
These are the other reasons I think are important,
because that's why Stallman didn't choose Common Lisp.
But I think the main one
that I didn't write here
is that Stallman wasn't a big fan of Common Lisp,
and he was at the time the main developer
and maintainer, of course, for Emacs.
So he chose not to move to Common Lisp.
But other reasons may be why...
Because he had a late and painful standardization.
Keep in mind, the first book that Guy Steele wrote
was in 1984. The standardization finished in 19--
sorry, in 1984 was the first book
and the standardization finished in 1994.
So, like, 10 years of difference from one to the other.
10 years of a lot of talk, a lot of money,
and a lot of pain probably.
The Lisp usage declined in the 90s
due to the AI winter.
We all know about the Lisp machine market crash.
And the failure of commercial Lisp machine was
inevitable at that point.
So all the potential Emacs friends died.
And also a lot of Emacs Lisp was already available.
Emacs was already an amateur utility.
Unix won the war of the operating system, as we know,
and Emacs Lisp was available in Unix,
or in GNU/Linux, as we know,
which is the most successful implementation of Unix.
Sorry, BSD. Okay.
So Emacs won by being the "better" alternative.
I'm quoting "better" here because
I think Emacs does have a better design
and, well, it was the one that survived, right?
Which is the more important thing for a software or,
you know... So Emacs won by being free,
also in price, which I think the Lisp machine wasn't.
So that was also very good. It was included.
It had, and it still has, of course,
a nice collection of packages
that improve the standard functionality.
It was easy to extend because of the nature of Lisp.
And it has a very good integration with GNU/Linux,
of course. It was created to write it.
It makes sense that it's very good
for a system administration perspective.
But I think Common Lisp is not dead yet.
Or some people say that it's always dead,
so you cannot kill the something that is always dead.
So I don't always code in C,
but when I do, it's Lisp. I'm not a big fan of C
for a lot of things, but yeah.
Why I think Common Lisp is still relevant
and can be used for all kind of application,
both commercially and non-commercially.
The first one is the main implementation
of Common Lisp, which is called SBCL, which is awesome.
It's fast. It's a very good extension.
Basically, it's the reference one today.
The namespaces of common Lisp,
I really like the implementation.
Some people don't like it. It's a matter of taste.
But I think it's really good.
I have a timeless standard. So it was standardized
in the 90s, as I said.
And it doesn't really need a new standard.
Some people say it does need, but I don't think so.
Also it does have macro readers,
which I think is a very nice feature of Common Lisp
that other Lisp doesn't seem to have,
or a lot of them don't: in my mind, Emacs Lisp and Clojure.
Also, it's image-based development,
which is also quite unique to Common Lisp.
I don't know all the Lisp that does have this.
Basically, you develop a REPL
and then you dump the entire REPL into an image.
Java would be like a core dump.
And you create an executable.
Which at the time, I guess in the 90s,
was a huge one, right?
Because you have the entire language, and the REPL,
and the code. But today are like 20 MB,
which in today's standard is nothing.
There's pictures in your phone larger than 20 MB.
So there's a new Emacs in town--well, Emacs, not Emacs,
Which is Lem. I think it's a very good Emacs implementation.
What I mean by "Emacs" here is not a clone of GNU Emacs,
but an Emacs-inspired editor with similar characteristics,
and written in a Lisp,
which is why I said that Lisp was very important.
So first, I'm going to address the elephant in the room,
and the question that maybe most
of you are now thinking.
Why not just use GNU Emacs? It's the project.
It's the main one, right? Why choose another one?
So Lem is relatively new, 2018.
And it can explore different ideas.
It was developed by Sasaki-san.
Basically, it was mostly a one-month project,
but we are getting there. I'm not the maintainer.
I'm a developer of Lem. So given that it's
relatively new, it can explore different ideas.
You're not bound to a community or backwards compatibility.
You can explore different ideas,
and I think that's always nice.
Having multiple options creates competition,
which benefits the community. So Emacs and Vim,
the competition between the two
always create nice packages like evil or, you know...
It's really good to have some kind of a competition,
healthy competition.
And it doesn't share any code base with GNU Emacs.
I want to clarify this because some people think that
Lem is kind of a, you know, Spacemacs or Doom.
No, it doesn't share any code.
It has zero Emacs. So that's it.
Getting this out of the way.
Why I think Lem is interesting.
I'm going to show why Lem.
Why? You can try Lem, and maybe you like it.
First thing, these are the features
that I really like from it.
Can be different from person to person,
but I think these are the main ideas
it brings to the table and are really interesting.
I want to say that Lem is not a research project.
It's not like some people did that
and it's still in development. No, no.
This is a usable product that can be used
to [do] day-to-day programming
in a very good experience.
This is not like--I want to clarify this
because some people bring some exploratory projects.
This is not that one. This is finished.
Well, finished in the way that you can use it.
It's not, you know, have everything in place.
So let's continue.
It's written 100% in Common Lisp.
I say this because Emacs is not
100% in Emacs Lisp.
You have to modify the C code,
I think, well, if you... You don't have to,
but if you want to change the internals, you do.
I think that given that Lem does not care
about the implementation of the language itself--
so for example, Lem doesn't have to deal with
how Common Lisp works, it just used the language, right?
It's on top of the language.
You can say that. Emacs Lisp is Emacs and Emacs Lisp,
so you have to, you have both in the same place,
which is, well, it's a double-edged sword, right?
Then you have the both--similar to Emacs--
you have ncurses and SDL2 frontends.
One is terminal-based and the other is graphical
using the SDL2 library,
which you can do a lot of crazy things.
Of course, it's meant to program games and stuff,
but Lem uses, and it works fairly well.
You can program games if you want.
Not that you need to or anything, but we have Tetris.
So there's that.
Also, separate front-end interface.
So like I said, you have two, but you can create more.
In the past, had an electron one,
but it got abandoned for obvious reasons, I think. Sorry.
This idea is taken from Neovim that had a lot of frontends.
In fact, we don't have that many,
but not that many people we have two.
That works fairly well.
We have superb development experience thanks to SLIME.
So we have Micro,
which is a SLIME version for Lem, basically.
SLIME is awesome and Micro is also awesome.
We have a very strong development experience
that we don't have for a Lisp,
which I think is very important.
If you want someone to develop packages or to use your tool,
your Emacs at least,
you need to have a very good development experience,
which enhance the extensions for the editor.
So we have also Vim-like integration.
This for me was mostly mandatory
because I'm an evil-mode user, and I think it's really good.
Because evil-mode is very good and the VMode,
which it's called, even though it's more like Vim mode,
it's called VMode. It's written by
Fukamachi-san and it's really good.
So yeah, that's the thing that I think Lem brings to
the table and that's really interesting.
So I'm going to do a small demo of Lem, a Emacs example.
First, the similarities,
the nomenclature is very similar: modes, buffers,
commands... The commands are very similar in nature.
It was written with GNU Emacs in mind
to mimic a lot of things.
I think GNU Emacs is the best Emacs implementation
in that way. So why not just take what is working, right?
I have similar command,
but flexible to add other default ones.
It's not like Emacs that you have Emacs commands.
Lem has Emacs command by default,
but you can easily change that
with other default ones, right?
It's like, you can think of it like a major mode, right?
Well, more like a global mode,
sorry. That's a global mode of Emacs commands,
or something like that.
In general, the feeling is really close.
So you will tell that it's really close to how both work,
similar commands, and that shows.
Differences, Common Lisp is not Emacs Lisp,
it's similar in the surface.
So it uses `defun`, you know, have parentheses
and yada, yada, but it's not the same language, really,
and sometimes you will find
that the differences are substantial.
The internals are completely different,
of course, nothing, well, completely.
They have a buffer implementation and other things,
but in general, yeah, aside from that,
it's completely different.
And it's true that GNU Emacs
has a better documentation tutorial.
So GNU Emacs for me, I think it's
one of the best-documented software ever.
We're trying to go there, but we're still not there.
Let's do the demo. So to open Lem, you compile it,
and then you have it available,
and you open Lem. As you can see,
we have the temporary buffer. On the top left is the mode--
not mode,
the beam, insert, normal, visual. This is the V mode, right?
In the top right corner, we have fundamental,
which is the major mode, then paredit,
which is like the minor mode, but you know,
this is like the paredit for Emacs.
In the top left buffer,
you have the current buffer.
So let's open the... Emacs, we all know how to do this.
This is a command, like explore this command,
like `open-init-file`. This opens the init file,
which is in this directory, in `~/.lem/init.lisp`.
As you can see, this is very similar, right?
You define a command, which is not interactive,
and then you get the buffer, right?
This is a... So my personal command...
Let's go to the one that I just opened. Init file, right?
So this is a command that I did,
which is `find-file`.
This is very similar to [??], but just `find-file`.
As you can see, very similar.
This is the way that you program in Lem.
This is the major mode, which is Lisp,
that we're seeing at the top, right?
And we can connect if we `slime-self-connect`.
This is the prompt. This is the REPL.
So if we... Keep in mind that this is Common Lisp,
so this has different things.
So we have to go to the Lem package,
which is very important. This has namespaces, right?
It's not the same. And we can say, okay,
`current-buffer`. We get the buffer.
We can explore everything that is in it, right?
We have all this stuff. This is... If you're familiar
with SLIME or Sly, this is it.
It's just that we can say, buffer, I think it's `buffer-name`.
Yes. And we can take this,
and then we'll give you the name.
So as you can see, the development experience
is really powerful. We can also `lisp-scratch`,
which transform... basically apply
the major mode of Lisp to the temporary buffer.
This is very similar to Emacs.
Let's go back to the theme. I think that's it.
Thank you all very much for listening to me.
I think I point out
the Emacsen family is really interesting.
Lisp is really good, and GNU Emacs is really good,
and I think Lem is also pretty awesome.
So thank you all very much.
I'll be answering the question now. And happy hacking.